Scaling Agile and Making Sense While Doing It

It is well known that Agile (not sure about the big/small “A” thing, it always gets me confused) has gone mainstream nowadays. With big companies and conferences endorsing it, long gone were the days when you actually had to convince people this was a good idea… and that’s great!

However, with the early/late majority now adopting Agile, we are not talking about small companies anymore, and that means that the challenge is not how to get teams delivering better, but whole departments and organisations. So yes, scaling agile is one of the current challenges, with the preferred approach being the dreaded (at least by me) “Change Programs”.

I don’t believe agile is a fad or just a small team thing, since empowerment, short feedback loops and delivery of results it’s never going to be a fad and isnt IT specific either. There are many other examples, in different industries (errm… Toyota?) which show that the same principles can be applied successfully in a much larger scale, on complete different problems.

The problem begins though, when by scaling agile, companies try to scale the practices, keeping the control mindset, instead of scaling what’s important, i.e. the principles.

It is common to see companies, for example, adopting a hierarchical structure to create multiple agile teams, all “reporting” to a main office, killing most of what was good about the idea.

If agile in the organisation is the challenge, we need to think about empowerment, short feedback and delivery of real results for the whole company. Unfortunately, the more common behaviour is to talk about bigger walls, how to standardise velocity across teams and synchronisation of iterations.

And if we go back to the roots, and look at the manifesto, I believe we can find a good guidance of what can be done:

Individuals and interactions over processes and tools: Instead of scaling processes and tools to control teams, why not increase the ability of individuals to traverse the organisation, making software developers talk to real customers and sales people talk to qa’s?

Working software over comprehensive documentation: Scale by making a working product the final goal, removing the necessity of internal product briefs, extensive training of sales staff and long delivery cycles.

Customer collaboration over contract negotiation: It is actually impressive how this still makes sense now. We just need to change the customer. It’s not the product owner anymore, it’s _the_ customer, the one who buys your product and pays the bills.

Responding to change over following a plan: Feedback, feedback and feedback. Not from a showcase though, but from the market.

Yes, if it feels like you’ve heard these ideas before, it’s because they are not new. Product teams are the way to scale agile in my opinion. Small and independent groups of people that can get to the best results in short iterations with feedback from the market, in a Lean Startup style. The game shouldn’t be about execution anymore, it is about innovation.

1 comment
  1. TC said:

    Nice post Frank. This totally relates to my experience in my current project. It seems to me that some big companies are just willing to “do agile”, not seeing the real value that it could bring.

%d bloggers like this: