« Conference Club | Main | Good Enough Software Design? Try Testing DX of your Code »

19 June 2014


Feed You can follow this conversation by subscribing to the comment feed for this post.

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.


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?


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.



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..."


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.

The comments to this entry are closed.