The seven problems of large agile programmes and how to fix them

In my last article I shared some techniques for identifying and fixing problems that were getting in the way of your business agility. This is something every modern organisation needs to tackle if they want to remain competitive in our digital age

Those of your who have already established a large agile delivery capability will be tackling the issue of co-ordinating work across many teams. To give you a hand, I thought I would share some of my experiences of organisations trying to deliver ‘agile at scale’ and the common problems I see. It’s not an exhaustive list, but if you were to ask me what problems you need to solve next, I bet we would agree on a few of these.

These are in no particular order, but I have seen them everywhere. 

Not organised around feature teams

Too much reliance on scaled frameworks

Lack of business confidence

Mismatch with established processes

Not fully releasing software to live

Too much reliance on Agile practices

Poor engagement with impacted teams.

Not organised around feature teams

The ideal setup for Agile is to organise teams around business features. That is each team has all the capability it needs to deliver valuable functionality to the customer.

In large organisations this requires considerable transformation and re-organisation. The commitment to move away from practice or skill-based teams towards feature teams is significant and disruptive. Without feature teams you will need compensating processes and coordination. This can be a significant overhead and introduce quality issues if not fully understood or bought in to by teams expecting to operate using agile practices.

Actions to take: start introducing feature teams incrementally and measure benefits. Implement compensating processes carefully.


Too much reliance on scaled frameworks

A number of standard frameworks now exist for delivering Agile in large programmes. However, they risk removing the agility you are trying to achieve.

Programmes that rely too much on a framework risk undoing the benefits of agility. The ability to adapt and shape your approach to increase the frequency and quality of output can be lost when conforming to a strict or poorly implemented framework.

These frameworks give false confidence in your agility prospects. To truly gain agility at scale you need to understand your own constraints and target specific solutions to remove them.

Actions to take: Understand available frameworks but don’t be a slave to them. Choose the elements that solve your organisation’s specific problems.


Lack of business confidence

Agile significantly changes the way work is done. With change comes the need to build confidence. Business teams are often disconnected from the ways of working and are not given the checks and controls they expect.

Agile is often seen by business teams as IT changing its delivery process (again). While previous IT changes have typically focused on technology practices, Agile is different. It requires both business and IT teams to combine into product focused teams.

For agile to work well, IT needs full buy in from the business and the business need to understand how this new way of working can deliver products that are more responsive to changing customer needs. 

Actions to take: Work with business teams to build an agile business. Agree ways of working that build understanding and joint working practices.


Mismatch with established processes

Organisations that deliver large programmes have established processes for control and effective decision making which do not fit well with an Agile delivery approach.

Typical control and reporting mechanisms are based on waterfall governance processes. They focus on approval gates and effective utilisation of resources. They require detail before commitment.

Agile focuses on empowering teams to deliver the right thing at the right time. Measuring against value and output is at odds with the way in which established delivery processes operate.

Actions to take: Incrementally change processes to fit with a changing fast-paced delivery environment. Establish reporting that works with all delivery.

Too much reliance on Agile practices

Much focus has been given to the agile practices teams use. However, a focus on team practices alone risks missing the objectives of Agile: To increase quality and output.

It is easier to assess if teams are following practices. While this will give you some confidence Agile is being adopted, our experience is that this focus has been at the expense of the reason for introducing agility.

Teams get too obsessed with perfect techniques rather than good enough to achieve the goals. Large programmes do not operate in a text-book Agile world. The team need to know which techniques achieve programme goals and which cannot go further.

Actions to take: Re-focus on team output. Measure value teams are delivering. This will drive a behaviour of only changing practices that increase value.

Not fully releasing software to live

Large programmes are complex and typically require many components to deliver valuable functionality to the end customer. The need for established, exhaustive regression testing makes frequent incremental releases untenable.

But not getting software to live undermines a key benefit of Agile. Working, production software is the only true measure of progress. Without it, a programme will drift into old ways of larger, riskier releases.

Customers expect regular, incremental functionality improvements. Large programmes need to meet this expectation. Automated build, testing and releasing will speed up validation, reduce risk of error and build confidence.

Actions to take: Understand why software is not being released to live. Ensure your test team are fully integrated. Move towards continuous delivery.

Poor engagement with impacted teams

Large organisations run many programmes. Cross-programme working is a necessity. However, Agile practices do not cater well for external dependencies.

The answer is typically to leave commitment until very late in the cycle, thus minimising dependencies. However, non-Agile parts of the business cannot plan in this way. This results in tension between the Agile teams and those they interface with.

Ultimately, you want to enable these teams to be more agile, but this will take time. There needs to be a recognition of the current needs of impacted teams as well as a movement of those teams towards an agile mind set. 

Actions to take: Work closely with impacted teams to understand needs of both parties. Build in appropriate processes until impacted teams are agile.

How Wisereach can help

At Wisereach, we recognise that large Agile programmes are complex. They are solving complex problems and applying agile disciplines often adds to this complexity. But the benefits of getting this right are significant.

Our approach is pragmatic. We focus on your top problems and work with your teams to solve them. Our experience of working in large organisations both on waterfall and agile programmes mean we understand the difficulties introducing this approach into established organisations.

Rather than simply introducing new techniques, talk to us about helping you solve the problems that are getting in the way of your business agility.