Like many of you reading this post I have struggled to understand how to scale from a single team practicing Scrum in 2009 (initially by the book, later after various productions releases and production support we moved into ScrumBan in 2010 and 2011) to multiple teams and from a product to a line of products in the last years.
Over the years I have read a lot in this area and also experimented on my own skin various approaches.
Scrum of Scrums was for a while a great next step to scale the teams.
Scott Ambler, probably one of the best software methodologists in the industry, published a great book to describe a methodology for scaling Agile called Disciplined Agile Delivery (DAD) that despite the somehow discouraging title 🙂 was for me a great reading. Have a look here: Disciplined Agile Delivery
I am very honest: plan your journey into understanding the agile delivery in enterprises with this book above. Especially if you have some roots into Unified Process like it was in my case.
Now after I tried some of the practices and we even had some experiments in the company where we played with things like Inception in DAD and its lightweight envisioning , Agile Modelling, Agile Architecture … I realised that this is actually a RUP process with a flavour of agile(lightweight, short feedback loops, travel light, etc). Not that this was bad , not at all because RUP had its merit in a lot of companies over the years but I did not feel DAD is mature enough and supported enough for the expectation of an enterprise and for my context so I decided to try something else.
So I stopped at Scaled Agile Framework (SAFe) and from the first day I felt that this is what I need. I did not started “by the book”, actually I did somehow the opposite: in the beginning I only introduced small SAFe elements into my current processes and it was immediately clear that this is the way forward.
These elements I initially introduced were:
– PI planning
– common and clear goals
– scrum of scrums
– feature teams (well, cross-functional in my case )
– the system team
– release train
– continuous delivery
– a release train engineer, in the beginning we had a developer taking parts of this role by rotation 🙂
I started small applying these only in my teams (about 30 people and 3 products in that time) not in the whole company but elements like predictability of the releases, risk management, less waste, clear identification of the sources of waste , better productivity and increase in the moral of the team members by offering visibility and transparency were good arguments to prove to upper management that this is the way for the whole company.
I was very happy when Alex Yakima, a SAF Fellow, published his book “The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe” because I found myself in this book and gave me another chance to evaluate where we are in this transformation and how important is to look all the time for opportunities to learn and to improve.
Actually reading both Alex’s book and the reference guide for SAFe proves to be a very good combination.
BTW, I am happy to tell you that we are now into this SAFe journey with the whole company. This time “by the book”. And the signs are very encouraging.
We are not on this journey because I took the risk to start it a while ago, not at all but for sure the lessons we learned those years proved useful now when we make it right and global.
My journey into scaling Agile is somehow a never-ending Inspect and Adapt, only possible because I have great teams, real friends and co workers that believe in “make it run first”.
I guess you all remember that XP principle of “Make it run, Make It Right, Make it Fast” that influenced a lot how the new generations of programmers started to develop products. “Extreme Programming Explained” by Kent Beck was published more than 10 years ago but will continue to be a great book and a source of wisdom for any new programmer.
Along the way I also met detractors and philosophers both in online and in person. In your journey you will meet them as well . When you will meet them pls remember that talks are cheap… but deeds are precious.
Like many other journeys the journey of scaling agility is not an easy one: enterprises are complex, production systems needs to be up and running, customers needs to be delighted, and your role as a leader is to create great teams so they can create great products.
Scaling Agile in the end is not the final purpose but just a way to establish a flow of value for customers and how to achieve that value.
*The views in this post are personal and do not represent the views of any organisation or employer
Ionel Condor, Cluj-Napoca, Romania 