Some time ago, as part of trying to help a core line-of-business system team improve their effectiveness, we brought Driven Software in to provide expert guidance. Driven (for short) are experts in assisting teams and organisations in streamlining how they manage their development work, or, as they would probably put it: “optimize the delivery of value to the customer”.

The long and short of what I, as well as the targeted team learned is that the intuitive way of doing things isn't necessarily that which will produce the best outcome, at least if getting quality work out which fulfils the customer’s need is what is of highest interest. In particular, our intuition (conditioning?) tells us that the way to deal with a large hairy challenge is to “divide and conquer”—in the case of software development, divide the work into vertical “chunks”, applicable to specialist groups:

The results at each stage are then “flipped over the wall” to the subsequent specialist team. This is the knowledge-work equivalent of the familiar widget-producing factory conveyer belt setup.

Divide-and-conquer we must, but there is more than one way to eye out the next small bite to take from the proverbial elephant. It turns out that when dealing with high-variability work (which systems development happens to be), separating the work into stages, as was typically done in the days of Waterfall isn’t a good idea. A waterfall approach is well-suited to a problem that has clearly defined boundaries and is straightforward to specify. Also, Waterfall is most effective when the likelihood of the specification changing is limited.

Unfortunately, the very nature of the “game” is that the only reliable constant is that change is guaranteed to happen.

It’s therefore in our interests to approach something like systems development with a particular sensitivity to its fluid nature. Similar to a sculptor who modifies his approach as he progresses, the software developer’s job is less about translating a specification into code than teasing the masterpiece out from a block of marble.

A software developer today, therefore, is no code monkey, as was the stereotype of past decades. In the modern world, a truly effective software developer has to encapsulate all the skills required in order to deliver value end-to-end:

Of course, individuals who are well-skilled in all areas of digital product delivery are about as common as four-leaf clovers. Never-the-less, each member of the value delivery team should have some knowledge of each skill and should, at the very least, be open to learning about the areas that don't happen to be their forté. The collective offering of a delivery team should be an appropriate balance of all skills needed to produce a quality product.

For instance, a team of three software developers, each having a different “major”:

Recognising the need to incorporate all disciplines required to deliver a digital product into a single delivery unit (more often that not, consisting of multiple people) is one of the key steps in establishing an effective value delivery pipeline.