After much preparation and planning, Krishan and I now have our first two Leading SAFe courses behind us. The first course comprised members of the Agile Tuesday community. While Krishan described this group as “friendly” I was initially more suspect as I´m new to the Munich Agile scene – it sounded to me like we´d be giving a topical Scaling Agile course to an informed bunch of sceptics ☺. Luckily this proved not to be the case and we had a great two days with a very supportive (yes, and critical) audience who helped us improve our course and understanding of SAFe. So thanks to all those who attended the February course. In March, our second course proved a success with a diverse and experienced list of participants collaborating on joint understanding and connecting scaled Agile methods to current business realities. We all learned a lot.
Leading SAFe ends with a certification exam and so I´d like to congratulate the new SAFe Agilist`s in joining the global SAFe community.
Some snapshots from Leading SAFe:
So what have we learned so far? I´d like to share a few of the questions that raised their heads during the courses:
Who is SAFe for? : This was one of the core questions raised. We agreed SAFe is for larger organizations that have development programs requiring 50-125 persons and develop products within value streams (clear “concept-to-cash” product lines). Organzations with more than 125 people in each development program split their programs into two or more “release trains” each with 50-125 people. SAFe is not recommended for small development programs as the framework overhead eats away at the alignment, synchronization and planning benefits SAFe brings to larger programs. So SAFe is for Big Agile.
Why the “magic number” limit of 125? : This is related to Dunbar´s Number. Professor Dunbar (a Scot I might add!) studied social group dynamics and found that we have a natural limit to the number of social connections we can maintain. As members of groups smaller than circa 150 we can still understand the connections we make with other group members, and the relationships formed by others. Once we go over Dunbar`s number we start to get lost in the social soup. Note that Spotify´s Agile implementation also uses Dunbar´s number to restrict the members of their Tribes. Therefore if we need to form larger groups but also wish the benefits of in-group dynamics, we should not exceed this limit.
Is SAFe Agile? : In terms of the feedback from course participants then we can say the “jury is still out” on this question. It’s a perspective issue. From an Agile purist standpoint there are elements within SAFe that seem to conflict with the values and principles we associate with Agile. From a enterprise implementation perspective SAFe can appear considerably more Agile that current non-Agile practices – especially with the introduction of Lean-Flow principles at the portfolio level. So to what extent SAFe is Agile is up to you to decide – and how you decide to implement SAFe and embrace the agile manifesto. Remember – SAFe is a framework/template starting point – not an end itself.
Do I need to introduce all 3 Levels in a Big Bang? : No – unless you feel a need add 10 years to your biological age. Most success so far with SAFe implementation has been made introducing the Program level. In many cases enterprises have been working with Agile methods and so the team level is often relatively prepared. The Portfolio level touches on the underlying business processes of an Enterprise and this can be tough to influence in the short term – not to mention the fact that many business have their own well-functioning Portfolio processes. Therefore the Program Level is where to start – with a gradual alignment with the Portfolio level to ensure the Lean Flow benefits we want to achieve.
How do I implement SAFe? TRAIN EVERYONE and START a Release Train. Train everyone means executives, product management, product owners, architects, dev-ops, development teams, marketing.... In fact anyone who is going to be impacted by/have an impact upon the development effort. By training everyone we set expectations and create a single mindset. By STARTING we set the “train” in motion and get the plan-build inspect & adapt cycle rolling.
Is it true I can only release every 4-5 Sprints (A PSI cadence)? : No. You can release on demand. Its up to you and your business needs (and the state of your dev-ops team). The common misunderstanding stems from the fact that SAFe uses a planning cadence of circa 4-5 sprints – called a PSI (Potentially Shippable Increment). A PSI cadence is there to bring us the Lean/Flow benefits of synchronization, alignment and planning cadence – not tell us when we can release. Release value as often as you can.
If you want to learn more about SAFe and contribute to the developing discussion?, then please:
- follow me on Twitter: https://twitter.com/fishstua