What’s great about agile is that its tenets emerged from the culture of real teams responsible for actual technical delivery. For example, horizontal team structures emerge again and again as a key characteristic of successful teams. The same is true about frequent communication. Agile ceremonies and guidelines resonate with people because they explicitly and openly strengthen important cultural values.
How to scale agile to have the same kind of impact at the enterprise level- with much larger, highly distributed, multicultural teams- is the big question that many of us are interested to answer.
Scaled Agile Framework (SAFe) is a framework for enterprise system production, created by Scaled Agile, Inc. SAFe builds and extends agile principles to coordinate hundreds or thousands of team members. It is relatively new in it’s 4th revision after 6 years of development. The Scaled Agile team is composed of a number of smart, broadly experienced people.
Does it work? Scaled Agile lists many successful case studies.
SAFe is complicated. To paraphrase a recent comment by founder Dean Leffingwell at the 2016 Scaled Agile conference in Colorado,
SAFe may be complicated, only because the domains it addresses are complicated. It is as simple as it can be. If there’s a simpler way, we will change the framework.
Agile principles state that
Simplicity—the art of maximizing the amount of work not done—is essential.
SAFe- in its current form -is not simple. By Conway’s law, what does this imply for social architecture of organizations implementing it?
Scaled Agile makes extensive recommendations for roles and structure above XP/Scrum. But ultimately, the agile ideal is a pure horizontal organization. Agile principal #4:
Business people and developers must work together daily throughout the project.
SAFe documentation acknowledges this risk:
However, historical use of the waterfall model, coupled with the somewhat natural inclination to institute top-down control over software development, has caused the industry to adopt certain behaviors and mindsets that can seriously inhibit the adoption of more effective Lean and Agile paradigms.
Distributed teams are the reality for every organization building enterprise systems of minimum scale or larger. This fact impacts every aspect of the delivery pipeline: vertical slicing, repository structures and versioning, test strategy, and etc. The SAFe framework doesn’t cover this fundamental in much depth. Where it does provide guidance, it is exclusively about how to overcome challenges. Distributed and multicultural teams can provide powerful advantages such as 24-hour production cycle and 360 degree visibility. These are fundamental aspects that must be first-class concepts to fully extend agile to large scale production.
Along with distributed delivery, another relevant question is the number of teams SAFe can support. This is important because at some scale there are important overlaps with supply chain management. Apple and other companies are successfully coordinating hundreds or even thousands of separate suppliers. They do not use the concept of PI. Instead production processes are designed to be as loosely coupled as possible. Is software different? In what ways?
What’s great about agile is that individual ceremonies add clear, coherent value to delivery providing an understandable, incremental way for teams to increase productivity and quality. In contrast, SAFe states:
Embracing a Lean-Agile mindset, understanding and applying the Lean-Agile Principles, and effectively implementing the SAFe practices all come before the business benefits.
SAFe has many good aspects and is the result of a lot of smart people collaborating. Does it correctly extend agile as an asymptote of Leanprocess theory? Not yet.
Recent Comments