SAFe for smaller development organizations?
Anyone reading this is likely aware that SAFe was developed to address the challenges of ‘people building some of the world’s most important systems.’ And while ‘important’ isn’t the same as big, I think most would agree that most of the world’s most important systems are indeed, big. Big systems are harder to build, more complex (and more fun). Addressing this challenge often requires hundreds, and even thousands of practitioners. SAFe was designed for that business case, which is more and more common as software and IoT continues to eat the world.
However, SAFe isn’t exclusive to big systems and big organizations. For example, we use SAFe here at Scaled Agile quite effectively. (Heck, I think we’d be lost without PI Planning and Inspect and Adapt). But it is is a legitimate question to ask whether or not SAFe can be applied efficiently to smaller development shops, places where less than 100 people accomplish great things.
Who better to ask than someone who has used SAFe in the large, and now has a new, and smaller business context? In the new guidance article “Six SAFe Practices for S-sized Teams“, Juha-Markus Aalto, applies some essential elements of SAFe to his smaller development shop. Here’s an excerpt that explains the ‘why’:
“However, there are at least four circumstances that I’ve found that using select SAFe practices, along with Scrum or Kanban, is more effective:
- Strategic software product with a long lifespan
- Dependencies with multiple non-software development teams
- Necessity to invest in long term capabilities like DevOps
- Expectation to scale from ‘S’ to ‘M’ size”
But simply noting that Juha-Markus has significant experience with SAFe understates the case a bit. He is a peer and colleague who was instrumental in conceptualizing the framework, long before it was SAFe. So he knows ‘that of which he speaks’.
— Dean Leffingwell