Is SAFe Truly Agile?
The Scaled Agile Framework (SAFe), created by Dean Leffingwell, has garnered significant attention in the industry. Its popularity indicates a strong following of proponents who attest to its effectiveness, though it also has its share of critics. Opinions on SAFe vary, with some recognising its merits but urging careful and considered use, while others find it overly restrictive.
Recent Experience with Leading SAFe 4.0
Recently, the opportunity arose to take the Leading SAFe 4.0 classroom course. The following are reflections on various aspects of SAFe.
Positive Aspects
SAFe is commendable for its consideration of agility at the enterprise scale, accommodating multiple portfolios of initiatives and potentially thousands of people working towards common goals. It adopts a Lean perspective at the portfolio and value stream levels and encourages the development of an architectural roadmap to enhance business capabilities. The framework also provides a method for prioritising various types of work, drawing on the principles of Don Reinertsen. The shift towards lean-agile budgeting, as opposed to traditional project cost-accounting, is particularly praiseworthy.
Areas of Concern
While many opinions on SAFe can be found elsewhere, the following points outline specific concerns:
Agile Release Train (ART): The term Agile Release Train is somewhat misleading, as it primarily functions as a Planning Train. The cadence in SAFe focuses on planning alignment rather than release alignment, promoting the idea of releasing any time shippable solutions are ready and the organisation is prepared to receive them.
8 to 12 Week Planning Cadence: The PI (Program Increment) cycle aims to make waiting times predictable, limit batch sizes to a single interval, provide scheduled integration points, and control the introduction of new work. However, this approach implies that batch sizes are limited to what can be accomplished in 8 to 12 weeks. If demand for a new feature misses a PI planning day, it must wait for the next planning session, potentially delaying release by 10 to 24 weeks. This seems contrary to lean and agile principles.
Hierarchical Layers: SAFe's big picture identifies four hierarchical layers of agility, each with specific roles, backlogs, and terminology. The distinction between a Program and a Value Stream is that the latter involves more than one ART and considers the supplier in the value chain. While the Value Stream layer is appreciated, the Program layer appears redundant. Combining these layers might simplify the framework.
Extensive Meetings: Organisations operating at the Value Stream level, strictly following SAFe, engage in extensive planning meetings, including a half-day pre-planning meeting, two full days of planning with hundreds of participants, and an additional day for post-planning. This results in a substantial amount of time spent planning, not to mention the demos and retrospective meetings at all levels. Smaller, more frequent planning sessions could be more effective.
Innovation and Planning Iteration: The concept of an iteration specifically for innovation and planning, occurring every 8 to 12 weeks, seems flawed. Innovation should be a continuous process, not confined to a specific time frame. Additionally, planning right before two full days of planning seems excessive.
Business Objectives: While business objectives are essential, SAFe recommends identifying them and assigning values (1 to 10) only on the second day of PI planning, after drafting plans and identifying risks. This sequence appears counterintuitive and misaligned with agile principles.
Overall Impression
SAFe appears to prioritise predictability over agility. Despite references to Lean principles, Value Streams, and Cost of Delay, planning in 8-week cycles offers limited flexibility for change. It is often cited as a method to integrate Waterfall and Agile projects, which may not be an ideal goal.
The framework's detailed agendas for planning sessions do not address what to do when business priorities change mid-Increment, suggesting that changes must wait until the next PI.
However, it is not all negative. Case studies often involve organisations adopting agile through SAFe rather than scaling an already agile organisation, indicating its appeal to those accustomed to large-scale projects and programs valuing predictability. The Value Stream layer introduced in version 4.0 should perhaps have replaced the Program layer instead of adding to it, as the additional layer has introduced confusing terminology and bureaucracy.
In conclusion, while SAFe version 4.0 has made strides towards agility, it still retains elements of large-batch, project, and program thinking. Future versions, such as SAFe 6.0 or 7.0, may benefit from fully embracing Lean principles, more frequent and straightforward alignment and integration, and eliminating the terms project and program entirely.