Beyond Agile Delivery

You could be forgiven for thinking that the agile movement is taking over the world. For example, Amazon is famously agile and because it can make changes to its software every second it can maintain its lead in existing markets whilst conquering new ones. But look more carefully and, of course, things are more complicated than that. In many respects, leading digital businesses are not as agile as they seem.

Organisations like Amazon, Apple and Microsoft have grown to employ more than 100,000 people and operate massive facilities. Even Uber, famed for disrupting taxis without owning any cars, might be considering building a fleet of vehicles - even if they do happen to be autonomous. These organisations might be able to change their software in seconds but they can’t acquire and dispose of people, assets, relationships and physical infrastructure in minutes or days. Amazon’s CEO, Jeff Bezos, has even upset financial markets by taking things to the opposite extreme - ignoring the clamour for short term results and making large scale investments with payback periods measured in years.

If you cant beat them, fake it!

Out of the spotlight, many more organisations are struggling to get their, less ambitious, agile efforts to scale or make an impact on their traditional products and services. Some end up cutting corners, create technical or operational silos or just fake it to look good. New approaches are emerging, such as SAFe, which promise to deal with this more complex landscape but can get mixed results. There are also multi-headed monsters such as Waterscrumfall. Some think the difficulties are caused by the lingering influence of out of date practices. They suggest abandoning ideas such as enterprise architecture, organisation design and even project management in order to avoid clashes with new agile approaches.

So, should you continue to wrestle with agile techniques and hope that, eventually, you will make it work or should you dismiss it all as an impractical ideal that not even the agile leaders live up to? Fortunately, there is a way to reconcile these conflicting positions. A common thread in all of these approaches and methods, both old and new, is that all of them have been developed as a response to risk. They all provide a template or pattern to mitigate certain types of risk. For example, project management addresses the risks involved in making large, unfamiliar investments. The various flavours of agile software development mitigate risk by reducing the impact of undiscovered errors. Working with risks and understanding how the various methods try to mitigate them provides a way of blending different approaches in a pragmatic way.

Taking calculated risks

There is a good example of this kind of thing going on in my current assignment. I am leading a team in a large scale digital transformation which involves lots of different sorts of risks and draws upon a whole range of methods and tools. My team is focused on transforming some enterprise-wide processes and we are involved in all of the following simultaneously:

• Iterating the details of some back-office processes using a bespoke approach which is largely based on Scrum.
• Applying traditional data modelling techniques to define standards for systems being developed by separate agile teams. We are replacing some existing monolithic systems but still have to satisfy stakeholder needs for consolidated information.
• Running a fairly traditional project to define the learning and development activities needed to get operational teams ready for some significant changes.
• Writing business cases to reserve staff effort and funding for future work. The business case documents themselves look quite traditional but they are being developed iteratively alongside agile service development.
• Developing customer facing services using the hybrid approach promoted in the UK Governments’s GDS service manual.
• Exploring long range options for organisation structures and ways of working through some internal events modelled on recent “unconferences” and “hacks”.

My team regularly discusses the merits of different approaches. Occasionally, some strongly held personal preferences creep into these debates but they are usually settled quickly by considering the most significant risks and practical responses.

Go as fast as your team, but not faster

My team is making great progress but we are not going to publish some kind of beyond-agile methodology - you should be suspicious if we did. My team’s approach is just a natural evolution as we become more mature in how we understand and respond to risk. Like many teams before us, we are shifting from a dogmatic adherence to methods to applying them selectively, where they make most sense. If you would like some help to get started on a similar journey, please get in touch, but don’t expect to be carried to the destination. As I said at the start, “things are more complicated than that!”.

Related posts

• Time to abandon agile? One of a number of thoughtful posts by @alshalloway
• Spotify’s Engineering Culture [VIDEO]
• Why Isn’t Agile Working? Great insight from John Cutler