The Folly of Scaling Agile

I’m jotting down a few notes on Scaling Agile software development as Bucharest Agile group invited me to talk about doing this. I have already warned them that I am very skeptical about attempts to apply agile practices on large endeavours. While preparing for our conversation, I thought it might be helpful for me to blog about the reasons why I’m not a fan of Scaling Agile as this may make our conversation easier to follow and help the group to come up with some questions.

When we apply Agile principles, we strip away process so that software developers can work more collaboratively with business people to identify what is the most valuable thing for them to deliver next. We focus on building working software and releasing as early as we can to help us figure out what to build based on feedback from users. Working this way is much harder when a lot of people are involved!

A bunch of things break down as you scale up. The biggest one is not being able to maintain interpersonal relationships through which rich information flows, these are replaced with weaker lossy forms of communication and misunderstandings about what is the right thing to build next follow.

Typical things that become difficult at scale are access to business people and infrastructure controlled by others outside immediate team. Meetings get long and tedious, we start sending a representative from each team, which introduces more secondhand information, emails and documentation.

When a project is big and is being changed by many hands it becomes much harder to understand the whole, we start to introduce hierarchy with a select few looking at the bigger picture and paying attention to separating concerns to allow different teams to work in parallel. As a result, choice is removed from the team and it can feel in teams that edicts come down from on high through a series of chutes and screens that mask the reasoning behind them.

Often the initial attraction of Agile approaches to a business is to reduce delivery timescales and enable developers to work faster with a lightweight approach. Working in small teams allows individuals to feel more engaged because they have some influence on how things are built. When a lot of people are working in parallel coordination becomes harder. Ideally we need skilled people who have enough experience to work independently without the guide-rails of process.

Yes, I have seen plenty of organisations with large systems being maintained, expanded and extended by multiple teams. When each team has to interface to many others decisions take longer to make. Where a large number of people are working on a complex thing, it takes a lot of effort to keep up with what’s happening other areas and most reduce their focus to the work at hand. Once they reduce their focus and interfaces between teams become walls to hide behind. When myopia is easier then teams tend to make local suboptimal changes rather than considering the whole.

A large body people working on a large body of code often feels crazily chaotic or oppressively bureaucratic to work within. In these conditions developer motivation is often dimmed, people leave taking away valuable knowledge of how the system evolved and why things are. New people who need to learn how things work join and struggle to make sense of it all, the situation gets worse.

There are a few agile practices that can help in scaled up situations - such as having reliable automated builds, decent test coverage and teamwork but these are also painful to maintain with a lot of people involved. I’ve seen many large organisations attempt to apply Agile at scale. It’s hard and although it can bring more humanity to work in-the-small, I’m not sure there is much evidence that it is actually better than traditional ways of organising the work.

I appreciate that there are large systems out in the world that need to be supported and evolved to better meet user and business needs. I remain unconvinced that throwing a lot of people at the problem makes things any faster. I believe deadlines driving this behaviour are defined without realising the impact on the maintainability and quality of existing software. Code is an asset and so is the knowledge that software developers carry - businesses can run into costly mistakes if they ignore their value.

Attempting to scale to go faster is driven business greed and ambition - not a bad thing in the commercial world but it’s like seeing a someone blindfold attempting to run along a cliff edge while juggling priceless antique glass vases. Mistakes at scale are costly!

When it seems that scaling up is the only way to go, challenge yourself to think of a smaller simpler thing to build sooner that gives faster feedback. Try to limit your total Work-In-Progess by reducing the amount of development being done in parallel across the organisation. When a smaller group of people is involved in development, choices about which way to go next can be made more quickly and there's less waiting around. Ultimately, this goes back to Agile Manifesto values - focus on better interactions betweem individuals to produce valuable software sooner -- not on a process to enable lumbering projects at scale.

Comments

[Allan Kelly]

I can feel you are thinking the issue through as your are writing this, and I think your conclusion could be broadly stated as "Don't do it."

Which is kind of how I feel myself.
But I also recognise that some people feel they have a need to do "big".

Bluntly, Software development is difficult to do in the big, however you do it, Agile or otherwise, you are going to have problems. Therefore avoid "going large" if you possibly can.

I blogged about this myself last year (http://allankelly.blogspot.co.uk/2013/08/scaling-agile-heuristics-safe-or-not.html) if you want my full version but basically....

When people say "How do you scale Agile?" I think they are actually asking one or more different questions:
- How do you do Agile with a big team?
- How do you do Agile with multiple teams?
- How does an organization govern Agile work?

Each question has its own answer - which might be combined - but each started with "get good at doing it small."

I've come to think that while people may think they need Big Agile I don't think thats the problem most of them have. The problem they actually have is doing any Agile.

But there are those people see an opportunity to sell Big Agile so they've defined such a problem.

[RobVens]

I share your scepticism, Rachel, and the pitfalls you mention are important to be aware of. Nevertheless I do think scaling, within certain conditions, is possible. The main one that I find is mentioned seldom, is architecture: with a loosely coupled large system your teams can be related one-to-one to one component, and have clear (and minimal!) dependencies with other teams/components. Check my blog post http://www.robvens.com/en/scaling-agile-means-scalable-architecture/
Do you think this could be a mitigating strategy?

[Adolfont]

I agree. It makes sense. Nassim Taleb explains the problems of big companies in Antifragile.

[clarke ching]

Hi Rachel,

I agree with a lot of your thoughts, but I have a different conclusion and - I suspect - a slightly different view of what Agile is. I don't think scaling Agile is folly, I think it's HARDER because of all the things you've described but I think (I know, actually) it can be done. Agile in big organisations is different to Agile in smaller teams. I think (know) it's worth trying to do it though because it makes the working lives of people who work in software development businesses happier (though not necessarily easier).

The starting point for me is that scaling Agile usually involves teaching all sorts of people in all sorts of roles who are unfamiliar with - and often very hostile to - Agile to work in what is a very counterintuitive, to them, way. Small-scale Agile, with a team of converts is easier for all the reasons you've described.

So, part of the solution, is to adopt agile in a way which doesn't cause push-back from the adoptees.

I do use some new Agile words, but I try to use old words as much as I can.

I start at the high-level and try to get the customers and project management to chop 1 big project - how they'd normally do it - as, say, 2 or 3 or 4 smaller releases. I trick - in a nice way - the teams into collaborating, by getting the testers to sit down with the developers and analysts before any code is written and discuss what and how and when they're going to test it. I get the analysts to work with the developers and testers and PMs to slice and dice the functionality and then think about how they can build those slices up bit by bit. A get vendors to ship their work in, say, 4 or 5 drops, rather than 1 big drop, and I ensure we test the arse off each of those drops as we go.

When I work this way I try real hard to ensure that I'm always removing pain for people - but sometimes I have to let them realize they are feeling pain first.

We've launched a brand-new product this way (with a team of about 80) in the last 2 years and also a brand new business. If you look at the way the teams work with your XP eyes you'll see tonnes of things the teams could do differently, but for me it's a step by step process which takes considerable time, but it's worth it.

Clarke

[MartinBurnsSV]

There's no question that trying to use Agile methods for larger things that encompass more of the value stream is hard. And if you can avoid it, you should.

And you're right, you can't simply throw more people at a single team and expect things to get better - Brooks' Law predicted failure for that a long time back simply through the number of required communication channels. So you split into multiple teams, each with a domain focus. However, for some things, you can't simply find neat independent domains that can deliver independently. Think of a retailer introducing a loyalty card. That touches almost every system they have, plus marketing, branding, training, stock demand patterns and so on, all of whom are trying to do their own initiatives. You have successfully reduced the number of most rapid/interactive communication channels (intra team), with an inter-team sync that doesn't need to run as quickly.

You've spotted the loosely coupled pattern's risk though: Systems thinking alone will tell you that individual excellence and optimisation can make the whole system less effective, and your symptoms are exactly those that arise.

Is this better than small team Agile that is effectively delivering and engaging the whole value stream already? No.
If you're succeeding at that already, keep doing it.

Many of the organisations that have that situation are also struggling to do Any Agile - for these people, a quarterly regular delivery that takes feedback from the real world of both delivery and outcome is an ocean of better than their current situation.

Alan is right - those 3 excellent subquestions do tend to get conflated by such organisations. Partially because the reason why they have not adopted Agile so far is that they have some combination of them.

So the key question is: Given this situation, is Large Scale Agile (note: I'm avoiding talking about specific methods here!) better than what they're doing now?

We can talk about 'many people' struggling to maintain personal relationships, but our 'many' is 'moderately sized' for such organisations. Most Large Scale Agile methods talk about delivery groups of up to 100-150 people (note: Dunbar's number limit, either accidentally or explicitly designed), which is a lot more than 7 +/-2, but less than the thousands that have worked on some multi-year programmes.

We can talk about quarterly delivery and planning cadence being slow, but compared to the 5 year, €50m programmes that deliver once? This is light years better.

We can talk about top down strategy, but these organisations have never given a vote on strategy to everyone. At least in these approaches, there's an acknowledgement of the difference between alignment of direction and autonomy of means of getting there - it's Clausewitz and Von Molke Mission Planning all over again.

Will this result in the whole organisation changing culture and mindset? I can't guarantee it. But I have seen a recurring pattern of: once one team is actually delivering regularly with a happy, motivated group of people, it becomes infectious, and people start asking "how the hell do we do that?" Not everyone will be ready for the change of course, but not all enterprise managers are PHBs, and some actually take this seriously and do change. Again, I've seen it recurrently.

Not a guarantee, but a promising set of experimental results. As I read once, the sound of science is not "Eureka!" but "Hmm, that's odd/interesting..."

[twitter.com/chrismdp]

The more I do this, the more I think agile at any scale lives or dies based on attitudes of people in the organisation, rather than the scale at which you are attempting to do it.

Software development is harder at a greater scale, but I've seen small teams with such a lack of trust that they burden themselves with suffocating process, and larger organisations with so much trust that they're able to operate at the speed of organisations a quarter of their size.

The attitude problem is not normally at the lower levels, but at the middle and upper management levels. If managers would try leadership rather than control, agile is possible at any scale.