Something to open my blog site with…
What is scaled Agile. Well we know what Agile is, been enough books on the topic. I have often said that “Agile Doesn’t Scale” – but that is just a glib throw away remark aimed at those that think they can put a process in place, and, like a clockwork mouse, just let it go.
If we run on the premise that a small scale Agile (assume SCRUM) team is effective then multiples of that team would also be effective. However this will only remain true if the inputs and outputs of each team remain true to the original team’s principles. So you know what you want, you can deliver it in the team and what you do is put into production to gain learning for future work. Having multiple teams able to operate independently and a Dev Ops capable of deploying each team’s work is a rare situation – but if you have it then you have a wonderfully scaled agile project running with the same processes and governance that you had in the original small project.
And….. back in the real world where you have features that are being delivered by multiple teams, maybe over multiple sprints (moving to a multi-sprint release model) with dependencies in all directions, well then the original process and governance model doesn’t cut it any more. Now we enter the hot topic of the moment – how to apply processes and governance to enable Agile delivery at that scale without killing the goose that laid the golden egg.
So if you are going to ignore some of the basic principles of Agile Scrum projects by not immediately releasing and adding external dependencies then you are going to need some manner of process to compensate – if you don’t then you are in a world of anarchy. It is those processes that shape what we all know have come to accept as “Scaled Agile”. There is no right way to do that (although there are some wrong ways) and I hope to give (and learn) some thoughts on that topic in future posts.
Follow me on @philagiledesign