April 2, 2015

Why Scale Agile? – Part 1

Why Scale Agile? Part one – Visibility

 

Visibility of progress has the net result of better financial outcomes that are derived by three types of behaviour. These are risk reduction, ability to direct progress and to increase trust between those paying for the work and those doing the work.

Risk reduction

The contract game whereby the supplier of services and procurer of services agree upon a delivery contract that is supposed to reduce risk by defined the terms of engagement upfront has the effect of hiding problems until the last minute.

The smaller batch sizes of Agile development reduces the risk by demonstrating working software every two to four weeks. Problems are obvious because the demonstrable software is either working at the end of two weeks or it is not. You cannot hide problems.

Scaling Agile means allowing multiple teams to produce working software across larger enterprise applications and removing the cultural, technical and operational problems that hinder this process.

This reduces risk across not just the development teams but all those operating to the same short sharp cycles.

All teams including HR, Legal, DevOps, Silo function teams and management all need to be aligned around delivering what is required and if they are not, this becomes obvious through the developer team velocity, stand-ups and retrospectives. There are mechanisms for making this work across many teams.

Risk is driven out from the organisation by making progress and the lack of it visible. With less risk and more successful delivery of the right thing, you achieve much better financial outcomes.

Ability to direct progress and build the right thing

The word agile implies the ability to change direction. The cost of changing direction is hugely increased if work in progress has to be abandoned. By shorter cycles of complete work, a cost of change in direction is reduced, making the business case for small changes easier.

By reviewing working software every two to four weeks, you can collect feedback from stakeholders, customers etc and use this to plan the next small piece of work. If feedback shows that a particular direction of value is not worth pursuing, then this can be abandoned and other lines of value pursued.

This allows the addition of new features and ideas to be added quickly or dropped quickly which gives a much higher competitive advantage over those working on larger cycle times.

Also, because new features can be added easily without fuss or change requests, there is no need to try to cram every feature you can think of into a project plan, thus further reducing the business risk of not delivering the right thing.

Doing this at scale means co-ordinating teams to produce small increments of value. When you have multi-tasking teams working on several streams of value, co-ordinating small increments of work and gaining commitment to deliver is very hard. Agile at scale solves these problems and aligns the entire organisation around short, high value delivery that can be directed at the last responsible moment for maximum competitive advantage and better financial outcomes.

Trust between those paying for the work and those doing the work

Using contracts to negotiate work scope and time within a single organisation is both inefficient and causes a whole host of secondary problems such as increased business, delivery and technical risk.

Increasing risk means there is higher likelihood of failure. As visibility decreases, and this failure is found later in the cycle after more money is spent, the impact of failure is increased. Agile development stops this process by removing the need for a separation between those paying for the work and those doing the work.

Instead, I.T function becomes aligned with business need and the idea of ‘the business’ and ‘IT’ is removed. Those paying for the work, work alongside and are available to delivery teams, so the communication is instant and often face to face. Delivery teams make working software available to those paying for it every few weeks and are transparent about progress.

When problems do arise, as they will in complex software delivery, these are discovered and discussed with all involved and problems are found very quickly as assumptions can be removed faster and the original business case is always honoured.

This kind of collaboration and the feeling of being one team removes the supplier / procurer dynamic and trust increases accordingly. As trust increases a synergy starts to happen and innovation becomes truly possible furthering competitive advantage and bettering financial outcomes.

Conclusion

Agile at scale is more than following Scrum and XP at the team level. It is about organisation change and alignment, optimisation and reducing waste and reducing risk while increasing economic / financial outcomes.

We have discussed the WHY, if you want to find out more about the WHAT and HOW, then please get in touch.

 

Read next:  What Are The Scaling Agile Frameworks and How Are They Different?

 

Simon Powers
Simon Powers is an Agile Coach specialising in large scale transformations and agile adoption. He has a background in very large enterprise architecture which has led on to organisational design and agile process refinement. Simon is the founder of Adventures with Agile.