What if we really did get to apply Agile principles outside the technology teams? What would it look like?

This is the fourth and final part in a brief series. In the previous articles I’ve questioned whether Agile enthusiasts are being over-zealous in their belief in Agile; I’ve suggested that the problems that most need fixing are usually not the problems that Agile might be able to solve; and I’ve proposed that we moderate our approach when we wield our problem-solving tools.

But let’s suppose that we really do have a good and worthwhile opportunity to bring our Agile experience to a wider, non-technical, audience. What would it look like?

Well, it depends what you’re trying to do. Many experts I know help companies manage Agile projects higher up the corporate food chain, helping senior managers govern the groundswell of sudden productivity and continual change. Governance of Agile projects is a real need and brings tangible value.

And suppose that’s successful? Suppose the organisation wants to take this culture even further. Here’s how I would generalise just a little of what I value in Agile practices…

Embrace change. This is the subtitle of Kent Beck’s book that kick-started the Agile revolution for so many. Above all, act as if you know that your plans will not survive first contact with the enemy (reality), and structure your operations to handle continual change.

Focus on value. User stories are often written in the form “As a… I want… so that…”. The final part, “so that”, is essential to keep people focused on what they’re doing, so they can successfully navigate the currents of life’s changes. Focusing people on the value allows them to apply their intelligence, and so produces more intelligent outcomes.

Partnership. The concept of the on-site customer shows us that delivery is much more meaningful if people are truly partners, on the same side (site), rather than opposing sides of a contract, or in their respective bunkers.

Face to face. An index card is often described as “a placeholder for a conversation”. Face to face communication is significantly more productive and meaningful than large documents passed around.

Tight, effective feedback. Retrospectives help us learn, and feed back those lessons into our on-going work. Importantly, retrospectives happen throughout a piece of work, not after it, so the feedback can be utilised. Feedback is tight.

Risk reduction through incremental progress. Feedback can happen at higher levels, too, to reduce risk significantly. If you deliver working software every two weeks then you are demonstrating progress. You can see very quickly if you’re not going to make your hoped-for targets. Similarly, if you are embarking on a major corporate project then you have a choice as to how you tackle the work and report back. Some approaches will be waterfall-like and provide misleading or unhelpful feedback — perhaps worse than no feedback. But a genuinely incremental approach will provide early warnings.

These are just some generalisations drawn out from just a handful of practices. There are many, many more (for example over at David Joyce’s blog). The interesting thing for me is that many of these, and many others I omitted, are about the human side of things. That’s not the kind of thing that gets the attention in a typical Computer Science course, but if we Agile people do want to take our ideas to a wider audience then we need to tone down the evangelical rhetoric and act more like well-rounded humans.