Too much business conduct, not enough professional conduct

The title and inspiration of this blog comes from Chapter 5 of John Bogle’s book “Enough: True Measures of Money, Business and Life”. In it, Bogle calls for a change in emphasis from the increasing focus on the business of making money to a focus on the professional standards and technical excellence.

He quotes from Daedalus – the journal of the American Academy of Arts and Sciences – in outlining the six characteristics of professionalism as being 1. A commitment to the interest of clients, 2. A body of theory or specialist knowledge, 3. A specialised set of professional skills, 4. The developed capacity for sound judgement, 5. An organised approach to learning from experience 6. The development of a professional community responsible for the oversight of professional practice and professional educators

Of course this is a daunting shopping list for a profession such as ours that we all recognise is still relatively immature and therefore a long way from achieving of these things.

In our continuous advances towards achieving these characteristics, one clear advance for me is the agile principle of “Continuous attention to technical excellence and good design”.

But, it is clear also that our profession is about more than just elegant design and beautiful code, and that there is a sense in which focusing on these things feels like an overly narrow and introspective concern.

We know that the bigger picture – the true end and purpose of the profession that we practice – is to value to customers through the application of the software that we produce.

What we seem to suffer from within this bigger picture that encompasses the true scope of our profession is a worrying level of fractured and compartmentalised. The set of people that need to work together in pursuit of our professional goals are separated off into many separate and insulated communities, under banners such as software engineering (architecture / design / coding), IT project management, customer representation / product ownership and testing.

As just one case in point of how these different communities see themselves as islands unto themselves, I have on more than one occasion met project management functions and project managers within IT / engineering organisations who firmly believe that project managers do not need to know anything about software development – project management is project management is project management, they argue.

While it is true that many project management skills are transferable across all kinds of different kinds of project, this does not mean that business projects that involve software product development do not require some specific considerations, approaches, knowledge and skills which differ from those required for example in infrastructure migration or building relocation projects.

(Would Isambard Kingdom Brunel place someone who knew nothing about bridge building in charge of one of his bridge-building projects? Clearly not. In this kind of engineering project, the “chief engineer” is responsible not only for the engineering solution and blueprints, but also project plans and cost estimates and making sure that a project remains within the budget. The management of an engineering project cannot and is not separated from the engineering aspects of the engineering project.)

Likewise we suffer from a curious situation in our industry currently in which we find whole programmes and projects that are eager to dub themselves “agile” because it is the thing to be seen to be doing at the moment, but that have made no real attempt to come together collectively for example to really study the Agile Manifesto (all 68 words of it) or the underlying Agile Principles (182 words) and collectively agree the pervasive implications and impacts on the way in which the overall endeavour needs to organise itself and execute its practices across all the various collaborating disciplines.

In conclusion I would say that in the software business the key challenge that we face is that we are not in reality united as the single cohesive profession that we should be, united around a shared purpose to deliver customer value through software, united across all the various disciplines that collaborate in projects and teams towards these shared goals and united around a single shared set of values, principles and practices.

The Agile Manifesto

Related Content