shelidonSeptember 24, 2024Leave a Comment

I don’t know who picks acronyms for Agile frameworks, but I know I’d like to keep my distance from them.

Anyway, in my effort to propose methods and techniques that aren’t old enough to drink, today I’d like to show you these three frameworks, all born around 2011.

What do they have in common?

They’re all trying to scale up and discipline Agile, which might be counterintuitive but addresses two of the main concerns in adopting the method:

1. “My Project is Just Too Big and Complex and Projecty For Your Puny Tools” (even if we saw that Agile is born in situations where waterfall was failing because the project was… well… too big and complex, this concern often comes from the project manager’s own sense of superiority);
2. “People Who Aren’t Controlled Do Not Work” (see above).

Regardless of my personal criticism towards the attitude, the frameworks have merit, so let’s see them one by one.

The Frameworks

1. Scaled Agile Framework (SAFe)

The Scaled Agile Framework (SAFe) is a structured approach designed to help large organizations implement Agile practices across multiple teams and departments. It was developed to address the challenges of scaling Agile methodologies beyond individual teams, promoting alignment, collaboration, and delivery across large numbers of groups.

SAFe was introduced in 2011 by Dean Leffingwell, a software development methodologist, and Drew Jemilo, an executive-level enterprise consultant and now retired co-founder. It evolved from Leffingwell’s earlier work resulting in The Agile Enterprise Big Picture, a chart which aimed to provide a comprehensive view of how Agile practices could be integrated into larger organizational structures. Since its inception, SAFe has undergone several revisions, with the latest version, SAFe 6.0, released in March 2023. The framework has gained widespread adoption across various industries, including software development, finance, and healthcare, becoming one of the most popular frameworks for scaling Agile practices.

SAFe operates at three primary levels:

• Team Level: individual Agile teams work using frameworks like Scrum or Kanban;
• Program Level: multiple teams collaborate on larger initiatives, coordinated through an Agile Release Train (ART);
• Portfolio Level: aligning strategy and execution, managing investments and ensuring that initiatives align with business goals.

The Agile Release Train (ART) is a key component of SAFe, where multiple Agile teams work together to deliver value in a synchronized manner. ARTs typically operate on a fixed schedule, delivering increments of value every few weeks. To do so, it introduces various roles, such as Release Train Engineer, Product Manager, and System Architect, which help define responsibilities at different organizational levels.

Specifically, an Agile Release Train is essentially a long-lived, self-organizing team of Agile teams, typically consisting of 50 to 125 individuals. These teams collaborate to develop, deliver, and often operate one or more solutions within a defined value stream. The ART operates on a fixed schedule, delivering incremental value through a series of Program Increments (PIs), which are time-boxed periods typically lasting 8 to 12 weeks.

ARTs are composed of cross-functional teams that encompass all the necessary skills and expertise required to define, build, test, and deliver solutions. This cross-functional structure not only promotes collaboration but also minimizes dependencies between teams, fostering a more seamless workflow. One of the defining features of an ART, however, is the alignment around a common vision and set of goals. All teams within the ART share a unified Program Backlog and strategic objectives, ensuring that their collective efforts are directed toward achieving the same overarching goals. This alignment is crucial for maintaining focus and cohesion across the teams.

Operating on a fixed cadence provides a predictable schedule for delivering increments of work. This regular cadence helps synchronize the activities of multiple teams, facilitating systematic planning and execution. Key roles within the ART play vital roles in ensuring the success of this process. The Release Train Engineer (RTE) serves as a servant leader, facilitating ART events, managing dependencies, and driving continuous improvement across the teams. The Product Manager is responsible for defining the vision and prioritizing the features within the Program Backlog, ensuring that the most valuable work is being addressed. The System Architect oversees the architectural integrity of the solution, ensuring that both functional and non-functional requirements are met. Business Owners, who are key stakeholders, hold accountability for the business outcomes of the ART.

A critical component of ARTs is Program Increment (PI) Planning, a collaborative event at the start of each PI where teams come together to define objectives and commit to delivering specific features. This planning event fosters collaboration, provides clarity on priorities, and aligns the teams on what needs to be achieved.

Implementing an ART involves:

• Identifying Value Streams: as usual, the first step is to identify the value streams within the organization that the ART will focus on;
• Launching the ART: this includes assembling the teams, defining roles, and conducting initial training on SAFe principles;
• Executing Program Increments: teams work together to deliver features during the PI, with regular checkpoints to assess progress and adjust plans as needed;
• Continuous Feedback and Adaptation: after each PI, teams reflect on their work and make adjustments to improve future performance.

Continuous improvement is a foundational principle of ARTs. Regular retrospectives and inspect-and-adapt sessions are conducted to evaluate performance, identify areas for improvement, and ensure that the ART continually evolves and adapts to changing needs. This commitment to continuous improvement helps ARTs maintain high levels of performance and effectiveness over time.

The latest versions of SAFe emphasize the importance of business agility, encouraging organizations to respond quickly to changing market conditions and customer needs. It can be tailored to different organizational needs through four configurations:

• Essential SAFe: the foundational elements necessary for successful implementation;
• Large Solution SAFe: for managing complex solutions that require coordination across multiple ARTs;
• Portfolio SAFe: aligning strategy with execution at the portfolio level;
• Full SAFe: integrating all aspects of the framework for comprehensive scaling.

2. Large Scale Scrum (LeSS)

As you know if you’ve been following me throughout the years, Scrum is possibly my favourite Agile framework, and I have talked about it multiple times.

Large Scale Scrum (LeSS) is a again framework designed to extend the principles of Scrum to multiple teams working on a single product. It aims to maintain the simplicity and effectiveness of Scrum while addressing the complexities that arise when scaling Agile practices across larger organizations.

LeSS was developed by Craig Larman and Bas Vodde in 2005 while they were working at Nokia Siemens Networks (so yeah, at least in Europe it’s old enough to drink). They sought to apply Agile and Scrum methodologies to large, multi-site product development environments. Over time, they refined their approach and published their findings in the book Large-Scale Scrum: More with LeSS, which outlines the framework’s principles, practices, and guidelines.

LeSS emphasizes a “barely sufficient” framework, meaning it aims to reduce complexity and overhead while retaining the core elements of Scrum. This approach encourages teams to focus on delivering value and trim unnecessary bureaucratic processes.

One of the key differentiators in LeSS is the use of a joint Product Owner for the entire group of teams. Unlike traditional Scrum, where each team might have its own Product Owner, LeSS employs a single Product Owner to ensure a unified vision and consistent prioritization across all teams. This centralized role helps to maintain a clear direction and alignment with the overall product goals.

LeSS also emphasizes the importance of cross-functional teams. In this structure, teams are equipped with all the necessary skills to deliver a complete product increment, we minimize dependencies between teams and enhance collaboration, enabling teams to work more efficiently and independently.

The sprint planning and review processes in LeSS are adapted to support large-scale efforts. Sprint planning begins with a group-wide planning meeting, where all teams gather to discuss the overarching goals and strategy for the sprint. This is followed by individual team planning sessions, allowing each team to detail its specific tasks and contributions. Sprint reviews in LeSS involve all teams and stakeholders, promoting transparency and enabling collective feedback, which is essential for continuous improvement. Retrospectives, however, go beyond the team level and encourage an overall review at the end of each sprint. This group-wide retrospective focuses on identifying improvements for the entire group rather than just individual teams. This is a way to foster a culture of continuous improvement and shared growth, ensuring that the organization as a whole can evolve and adapt more effectively.

LeSS is guided by ten principles that inform decision-making and practices within the framework:

• Large-Scale Scrum is Scrum, as opposed to the “Scrum But” principle stating that, when you make exceptions or modifications that deviate from the core principles and practices of Scrum, you’re losing value altogether;
• Empirical process control;
• Transparency;
• More with less, emphasising the idea that complex product development does not require complex solutions;
• Whole product focus;
• Customer-centric approach;
• Continuous improvement towards perfection;
• Systems thinking;
• Lean thinking;
• Queuing theory stating that, especially in software development, we often build up invisible queues, such as requirements documents, untested code, or features waiting for integration, and these queues can significantly increase cycle times and introduce delays.

3. Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a hybrid Agile framework that provides guidance to optimize the delivery process. It was created by Scott Ambler and Mark Lines, with its foundational concepts first introduced in Ambler’s 2013 white paper, “Going Beyond Scrum: Disciplined Agile Delivery.” This paper laid the groundwork for a more flexible and comprehensive approach to Agile, one that could adapt to a variety of project types and organizational needs.

The primary reference for understanding and implementing DAD, however, is the subsequent book Choose Your WoW! by Ambler and Lines, with the acronym standing for Way of Working. This book serves as a detailed guide for Agile practitioners, offering a toolkit of practices and strategies to tailor Agile methodologies to specific project contexts. The Project Management Institute (PMI) acquired the rights to the framework in 2019 as a part of PMI’s broader strategy to get their hands on Agile and provide project managers with a set of tools that wasn’t covered in mold.

DAD is based on eight core principles, some of which are taken from the Agile manifesto:

• People-first: people and interactions are the primary determinants of success;
• Goal-driven: production should focus on clear goals and outcomes;
• Hybrid Agile: practices are chosen from various Agile frameworks and methodologies;
• Learning-oriented: continuous learning and improvement are emphasized;
• Full delivery lifecycles: address the entire delivery lifecycle from ideation to deployment;
• Solution-focused: deliver consumable solutions, not just finished products;
• Risk-value lifecycle: explicitly manage risk and value;
• Enterprise aware: understand the organizational context and dependencies.

One of the distinguishing features of DAD is its support for multiple lifecycles. Depending on the nature of the project, teams can choose from six different lifecycles: Agile, Lean, Continuous Delivery, Exploratory, and specialized versions for large teams. This adaptability allows teams to select the most appropriate lifecycle for their project’s goals and constraints.

The Frameworks compared

While all three frameworks share the common goal of scaling Agile practices to meet the needs of larger organizations with multiple teams and incorporate principles from Lean and Agile methodologies, they get there proposing significantly different structures, prescriptives, focuses across the project lifecycle, and adoption patterns.

SAFe is known for its structured and prescriptive nature. It provides detailed roles, ceremonies, and artifacts that are designed to coordinate work across multiple teams, making it particularly appealing to large enterprises that are looking for a clear, comprehensive roadmap to guide their Agile transformation. In contrast, LeSS emphasizes simplicity and transparency. It retains the core practices of Scrum while adapting them for larger, multi-team environments. LeSS is ideal for organizations that prioritize simplicity and wish to stay closely aligned with Scrum’s original principles, even as they scale. DAD, on the other hand, takes a more flexible, context-driven approach. It allows teams to tailor Agile practices based on their unique needs, making it particularly well-suited for organizations that require a customized approach to Agile, depending on the specific demands of their projects and teams.

When it comes to lifecycle focus, SAFe extends its influence beyond just the team level, focusing on the program and portfolio levels to align strategic objectives with execution. This ensures that work at the team level is closely connected to broader business goals. LeSS, in contrast, focuses on scaling Scrum across multiple teams while maintaining a single Product Owner and Product Backlog, preserving the integrity of Scrum practices even in a larger context. DAD takes a comprehensive view, addressing the entire delivery lifecycle from ideation to deployment. It includes aspects like solution architecture and portfolio management, making it suitable for organizations that need to consider the full spectrum of delivery, not just team-level practices.

In terms of adoption, SAFe is the most widely adopted framework, especially among large enterprises that benefit from its structured approach and extensive guidance. LeSS tends to be better suited for organizations with a strong Agile foundation that prefer simplicity and decentralization. Its focus on maintaining core Scrum principles appeals to those looking to scale without losing the essence of Scrum. DAD, due to its need for customization, is particularly valuable for organizations undergoing traditional-to-Agile transitions or those managing complex projects. However, this customization often requires experienced consultants to tailor the framework to specific organizational contexts, particularly in large projects.