Agile 3.0: The Third Wave

I can't believe it's been only a year and a half since Charlie Rudd wrote his piece on The Third Wave of Agile. In my opinion this still is one of the best pieces on Agile I have read.

You should, of course, read Charlies entire blog post. But for the sake of context I'll give a short recap;
The first wave of Agile started, just about, with the Agile Manifesto. The main influence of that manifesto was on the way teams do their work.
The second wave of Agile starts when multiple teams have to start working together. The main influence is on the way multi-team work is arranged.
The third wave of Agile comes in when those multiple teams run into problems with "the rest of the organisation"; the point where Agile isn't an IT party anymore.

That opinion comes partly from my own experience in Agile.

I started my first truly Agile project (as in; a *team* working together, using Scrum as guideline to how to do their work) in 2012. A failing project had decided to do a radical 180 on the way they worked and I was called in as a Scrum Master to help them pivot. And all was well. The pivot, the use of Scrum, was a huge success and from the minute they did the pivot, the project's effectiveness increased by about 400% (about 40% more productivity, about 10 times less work to be done by rigorous backlog refinement). The biggest challenge? Working together with the external teams that were producing modules to be integrated. The coordination was difficult, communication was difficult, in the end we could've been even more effective.

My next assignment was with a department of a huge company where about 20 teams were all working on the website. This is exactly what the second wave talks about. And of course we implemented SAFe since that's what everyone's doing. But we were lucky enough to have management that understood "Inspect & Adapt" and after the second big-room planning it didn't look like SAFe anymore. We kept the big room planning (or actually: Big room focus, commitment and team building excercise) but ditched most of the formal stuff. The biggest challenge? HR didn't understand Agile, marketing didn't understand Agile, management didn't understand Agile (although in this case, I have to say, they were open to it and adapted continuously).

And so I aimed my self-learning at that; how do we actually make entire businesses, entire companies, entire enterprises truly Agile. Last year I was asked to help with another scaling initiative. And so I started a coaching assignment mapping out the biggest impediments of a 3000 FTE IT software development department. The trigger to hiring me was the idea that inter-team dependencies were the biggest impediment. But drilling down to the root cause we found that the business unit design of the 125'000 FTE company was the reason behind the inter-team dependencies. You can go SAFe all you want but if you don't address the root cause you will never be Agile. And so we talked our way up to C-level of the holding company and they are now addressing this problem.

I have learned in the last couple of years that you may have Scrum teams, you may have SAFe ARTs, but if you don't look at the company structure you will always inevitably run into Conway's Law. Take special note of Coplien's addition: "If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble..."

Bottom line: If you're not thinking about the Third wave of Agile yet, then please start doing so. The implementation of Agile practices may come from the bottom up but the only ones who can make sure the organization is suitable for today's fast changing world are the top level managers.