I indirectly got a question that I thought would make a good blog post. The question came from the brilliant Emer on this LinkedIn post. That post in itself is a great read on the US Air Force’s thoughts on agile in general - great stuff in there.
Anyhow - Emer asked me:
Yes! I have read many posts by Allen Holub and our friend Woody Zuil on this. I do struggle though to find a way to practice “true” agility at a large scale. Do you have any good resources on this?
and I started to write a response but realized that I needed some more space. This blog post is that response.
Hi Emer - I am so happy to hear about your progress and to bounce ideas like this with you.
The trick with scaling is that there are no recipes that will work everywhere, just as with agile itself. This is also why some of us are ticked off with the packing of exactly that, like the one above. It’s a very unagile way to introduce agile
However, there are things to read that I think will trigger your imagination and inspiration: * Practices_for_Scaling_Lean_and_Agile is a good starting point * There are ideas about scaling in The Blue Kanban book that holds up very well. * I also like the idea of Klaus Leopold about flight levels , and his book is brilliant * There also the famous Spotify model that was the way they solved in 2012-2014, which is a good read
But ultimately it will be up to your own needs and your context - because whatever you choose to do will need to change. You will do something that works now but will have to change.
Here wanted to take a pause and quote two very different people. The first quote is from the CEO of Volkswagen, Martin Winterkorn I think:
There’s no economy of scale. We are now 10 times the people than before - Do we make 10 times the amount of cars? No.
The second quote comes from my colleague Svante Gidlund, that he used to drop after particularly badly run meetings we were in when we worked together at company X
Well… I’m sure that meeting made X’s customers happy.
I’m quoting these two gentlemen since I think they are touching on something very important - WHY do we need to scale.
Let’s do a thought experiment (stealing from How to measure anything) - let’s say that we do scale our agile effort according to method X and it works brilliantly. We run that for a year and everything is awesome. Now - what difference have we made in a year? How can I see that difference? Do we make more features per month? Better features? Are people happier? What is the difference? Why do we need to get there? Now?
In my experience, scaling efforts are started without really knowing where we are going. This is where much of the criticism of scaling agile stems from - it is rather adding a layer on top of the small agile efforts, that makes it look and behave like the traditional ways.
Let’s go back to all my questions and say that we do have an answer to them - it happens (rarely - but it does happen). Let me now ask this:
If we could get there without introducing method X. Or if we could get there by doing something very different than we think is the best thing to do right now - would that be ok?
Let’s say that instead of scaling the work method descale the work. Split up our architecture so that more small teams can work independently of each other (psst - this is a part of the Spotify model that rarely is talked about). Or building tools and contexts so that the teams we have now can do more by doing less of the things that are not value-added activities.
Compare the power a single developer team using mob programming, DevOps techniques, and cloud computing has now - compared to just 6-7 years ago when developers were working 1 by one and we ran our infrastructure on site.
My experience is that many (scaling) agile initiatives start in “getting more out of developers” which is a misconception. It’s not about making the individual works work faster - it’s about creating value faster. The most productive day a developing team can have is when they deleted code and the system became better. That is called refactoring and is a key trait of a great agile team. It’s not “creating more features” and most definitely great if you’re measuring the number of lines of code produced.
So where does this leave my reasoning? Well, I think it’s much better to “uncover better ways of developing software by doing it and helping others to do it”. I rather put a lot of emphasis on ensuring that everyone knows what/where better is and then give the individual teams the room to find a good way towards that better future.
The dirty secret is that I don’t know HOW that will look. Nor do you. And that is great because that means that anything is a good suggestion that we can evaluate, iterate and improve until we find what works for us. Now. Here. With the people in this group. Working on the current problem.
I don’t think there is a universal method that can prescribe a solution for that across teams, companies, countries, and the world.
PS. This might also be the reason I’m not working with agile transformation anymore… I got fed up with that and the futility of it. But that is another blog post.