It seems that Agile software development has been around forever, but in fact the Agile Manifesto was only released in 2001. That’s a pretty good sign that the Agile movement has achieved its goals. It shifted the balance of power and responsibility from management to developers.
Today, the Scaled Agile Framework (SAFe) framework is an attempt to apply Agile principles on a larger scale. However, while it may seem like a logical extension in principle, SAFe has been criticized by longtime Agile practitioners like Ken Schwaber.
To understand the critique of SAFe, we need to begin by looking at what it really is, what the four levels of the Scaled Agile Framework are, and how it compares to Scrum. Then, we can discuss each major problem highlighted by critics, the available solutions, and how Panaya’s Release Dynamix [RDx] fits into the picture.
What is SAFe
AFe applies the concepts that all Agile frameworks have in common, as laid out in the twelve points of the Agile Manifesto, on an enterprise level. Among these twelve points are:
- Prioritizing customer satisfaction by continually delivering software of value.
- The changing nature of stakeholder requirements.
- Working in short, fixed cycles.
The SAFe framework takes those key elements of the Agile methodology and translates them into nine new principles:
- Understand the economic and business value of a project.
- Make decisions using a systematic approach.
- Plan for potential changes.
- Build products in small increments.
- Set realistic objectives and deadlines.
- Limit batches to the smallest possible size.
- Work at a constant rate (cadence).
- Understand the true needs of stakeholders.
- Decentralize the decision-making process.
Building on these foundations, the development process for software-based projects can be effectively centralized across large enterprises and controlled by their management structure. As a result, they can plan for the long term, synchronize and coordinate efforts across the organization, and achieve ambitious time-to-market goals.
SAFe vs Scrum
The questions arises: If SAFe is a just a framework for applying the Agile methodology, then how does it differ from the more well-known and widely used Scrum framework?
The commonalities between the two frameworks are breaking large projects into smaller fragments, suitability for cross-functional teams, iterative repetition, and short release cycles. The teams involved constantly and quickly learn, improve and adapt throughout the software development or upgrade project.
Both frameworks adapt Agile techniques, but do so in slightly different ways. Scrum has proven very effective as a structured, daily workflow approach for small and mid-sized teams. However, it does not directly scale up to meet enterprise needs.
SAFe was developed to adapt the same Agile processes, including those common in the Scrum framework, for use in large enterprises. It coordinates the individual teams, placing them in a larger context, and allows the company to apply Agile workflows on a much wider basis to guide development coherently toward business goals.
DevOps stages such as deployment, A/B testing and release all take place in the SAFe framework. However, the difference in scale between Scrum and SAFe gave rise to new terminology to describe events in the two workflows. Scrum’s Sprint planning became Program Increment (PI) Planning in SAFe, the Daily standup became Scrum of Scrums, Sprint Review became System Demo, and the Sprint Retrospective became Inspect and Adapt (I&A).
There are a few Scrum-based frameworks for larger scale projects, but they too differ notably from SAFe. One is called Scrum at Scale and it was developed by Dr. Jeff Sutherland and Alex Brown. A network of Scrum teams are simply linearly scaled up, but no new processes or configurations are introduced to manage the larger scale. Therefore, as complexity in the software development increases, SAFe becomes a more suitable choice for maintaining effectiveness.
Another framework is called Large-Scale Scrum (LeSS), which applies Agile principles to up to eight teams. Unlike Scrum at Scale, LeSS accommodates the size of the teams involved with two different configurations. However, SAFe has four configurations designed for teams of different sizes and increasing levels of organizational complexity.
What are the 4 Levels of Scaled Agile Framework?
The SAFe framework can be implemented at four levels within an organization, reflecting increasing levels of complexity and comprehensiveness.
1. Team Level
The starting level, involving a few development teams working together. They coordinate iterative Agile development under the eye of a Scrum Master, with work divided into Sprints and delivered by the Agile Team according to the Product Owner’s specs.
2. Program Level
The program level brings together many development teams, business users and other resources for an ongoing solution development mission, usually with a definitive start and an end date. All the resources allocated for a single program, even temporarily, are organized in what’s known as an Agile Release Train (ART). ARTs are long-lived and have a more persistent self-organization, structure and mission than a traditional program.
ARTs are virtual organizations that coordinate the teams, roles and activities needed to incrementally deliver a continuous flow by eliminating unnecessary handoffs and intermediate steps. This accelerates value delivery.
3. Large Solution Level
When two or more ARTs get together to create large and complex solutions, there is a need to coordinate and manage their interdependent Agile processes. This is what happens at the solution level with what is known as a Solution Train.
4. Portfolio Level
In the context of the SAFe framework, the portfolio level is focused on bringing Agile methodologies to management practices. Portfolio execution can then be more easily aligned with enterprise strategy, as clear value streams make it easier to understand and shape investment in any given initiative. Multiple SAFe portfolios may exist across one enterprise.
Each SAFe portfolio outlines the strategic themes that guide development through changing business objectives and improve the productivity of cross-functional teams. This is achieved with a constant flow of feedback from the portfolio back to enterprise stakeholders, including:
- Current value stream KPIs for the solutions in the portfolio.
- Qualitative assessments of each solution’s fitness for purpose.
With SAFe portfolio level practices, management delivers the basic budgeting and necessary governance mechanisms to assure that solutions will provide the return on investment (ROI) needed for the enterprise to meet its strategic objectives. This may involve lean budgeting, intended to reduce project-based costs and increase throughput.
SAFe: Problems & Solutions
If we summarize SAFe as “still Agile, only bigger,” then why are some Agile developers so critical of it? Let’s take a look at the three main problems they like to highlight and how they can be addressed within the SAFe framework.
Poor Compatibility with Operations and Support
Agile development was created by developers. It was designed to resolve many of the problems they experienced with waterfall processes. Agile and waterfall may differ in how they handle project planning; however, both approaches rely on schedule-based planning.
But this is not how corporate IT, operations and support departments work. Their focus is on handling workloads on a day-to-day basis, which often include routine and scheduled tasks, unexpected events, and working on multiple projects simultaneously. There is hardly enough time for the scope of release planning that Agile requires.
Support might send a representative to a release planning meeting, but they are usually unwilling or unable to get involved. In any event, they have no control over their task backlog. If they did, the users they support would most likely get very upset. Moreover, unlike developers who can manage their own schedule, support staff are expected to provide ongoing coverage, often 24 hours a day, seven days a week.
The SAFe Solution
Consider DevOps as a way to address the issue. It marries development to operations by automating common operational tasks via written code. DevOps practices include test automation, distributed version control, and continuous integration, delivery, and deployment.
Increased Technical Debt
Technical debt is one of those things that is hard to define. Yet, most of us recognize it when we see it. In the context of this article, let’s say it is the accumulated build-up of unresolved issues over the lifetime of a project.
In a SAFe environment, the responsibility for resolving technical debt is centralized in the organization’s management. This centralization can be highly beneficial for certain types of technical debt (caused by market pressures or corporate policies regarding time, resources, and budget allocation, for example) that can be resolved by a high-level, top-down approach. However, centralization is not a good approach for technical debt that originates at the team level. This type of debt has highly specific causes (such as dev teams that don’t understand the long-term consequences of short-term decisions) or arises due to unstable teams with a high turnover rate. The organization’s management must take an active role in resolving such localized technical debt. If they don’t, then a larger, more intractable debt problem is created and it becomes more toxic over time.
The SAFe Solution
The best way of dealing with this type of technical debt is to follow Agile principles. For example, delegate problem-solving decisions back to the teams developing and testing the software. Give these teams the power to set their own deadlines and measure their output velocity. They will feel responsible for their work and be able to deal with problems as they arise. A culture of honesty and openness should be created, encouraging individuals to identify, assess, and fix technical debt and any related issues.
Management can play an important role in dealing with technical debt. This might include, for example, writing standard acceptance and exit criteria with a clear definition of “done” applied consistently across all projects. Management should also aggregate data from individual teams and create online systems that make this data visible to all.
Normalization of Story Points
Estimating how long it takes to complete a single task is a problem that has never been solved. The traditional solution has been to try to calculate the number of workdays needed to implement a single user story, indicating the absolute effort required for one person to execute a given task. A project manager who estimates that the effort involved is one workday, for example, might assign two developers and complete the task in half the time. Nonetheless, the overall effort calculation remains one workday.
One common criticism of effort-based estimation is that it does not take into account the complexity or difficulty of executing a task. Instead, the Agile world (including SAFe) has adopted story points, which take into account additional factors such as effort, difficulty, complexity and risks. Story points are expressed as a value on an abstract scale, such as a sequence of numbers, T-shirt sizing (small, medium, large, etc), or the Fibonacci sequence. For example, you can use a scale of 1 (easy) to 5 (hard), with each number translating to one workday of effort. So, a task that takes one workday of effort is equivalent to one story point.
In a SAFe environment, the defining story points are placed in the hands of management. As a result, critics say, the scale used to measure effort becomes more abstract and basically useless. It also makes individual teams feel that they have no control or accountability over the development process.
The SAFe Solution
One of the most important ways to address this issue is to give development teams the autonomy and trust they need. This involves giving them the authority to determine their own metrics and self-govern their actions. Management should also educate teams on how velocity should be used as a guide and not a measure of productivity and success. Management can again play an important role here, by educating and training the workforce to understand modern, Agile project management practices.
Making SAFe Work for You
Agile development started as a grassroots initiative by developers for developers. One reason for its rapid adoption was that it decentralized decision-making, handing developers the autonomy to make decisions and act on them in ways that made sense.
SAFe is an attempt to learn from the Agile movement and optimize project management, coordination and decision-making by centralizing them. One of SAFe’s many benefits is its value stream management, enabling a deep understanding what to develop and the optimal timing of any release.
As with many prescriptive frameworks, many of the problems with SAFe stem from trying to apply it too rigidly and not adapting it to the needs of a given organization. Ultimately sourcing the right solution for the job is more important than any religious adherence to the principles of any single method.
That’s why Panaya’s Release Dynamix (RDx) provides tools to make your Agile and SAFe deployments work for you. Unlike other release management products, RDx was built from scratch to manage large-scale Agile enterprise delivery. It lets you monitor the entire development process and manage your portfolio, project and release train, value trains, requirements, tests, and risks. It also collects data, displays metrics and provides dashboards for reports with key insights and analytics.
Panaya’s Release Dynamix can help you implement the elements from both Agile and SAFe that best serve your specific purposes and goals, be it on a program, project or portfolio level.
Quick FAQs
Scaled Agile Framework (SAFe) was developed to adapt Agile processes for use in large enterprises. It coordinates the individual teams, placing them in a larger context, and allows the company to apply Agile workflows on a much wider basis to guide development coherently toward business goals.
The twelve principles laid out in the Agile Manifesto:
1. Prioritizing customer satisfaction by continually delivering software of value.
2. Accommodation to the changing nature of stakeholder requirements, even late in development.
3. Working in short, fixed cycles for frequent delivery of software (i.e., Sprints and iterations).
4. Collaboration between business stakeholders and developers throughout the project.
5. Support, trust and motivation for the people involved in the various teams.
6. Face-to-face interactions are more successful, efficient and effective.
7. Working software as the primary measure of progress.
8. Consistent, sustainable development pacing, which can be repeated for each release.
9. Attention to technical detail and design quality.
10. Simplicity – develop just enough for now.
11. Self-organizing teams, with decision-making powers, will take ownership and produce high quality architectures, requirements, designs and products.
12. Regular reflection on how to become more effective, followed by the needed behavioral or operational adjustments.
From a bird’s-eye view, the Agile methodology involves breaking large projects into smaller fragments, iterative repetition and short release cycles. Cross-functional teams operating according to Agile principles constantly and quickly learn, improve and adapt throughout the software development or upgrade project.
The four levels of the SAFe framework reflect the application of Agile principles at increasing levels of complexity and hierarchy layers within an organization.
1. Team Level – A few development teams working together coordinate iterative Agile development under the eye of a Scrum Master, with work divided into Sprints.
2. Program level – Many development teams, business users and other resources come together for an ongoing solution development mission, usually with a definitive start and an end date. An Agile Release Train (ART) coordinates the teams, roles and activities needed to incrementally deliver a continuous flow by eliminating unnecessary handoffs and intermediate steps.
3. Large Solution Level – Two or more ARTs get together to create large and complex solutions, coordinating and managing their interdependent Agile processes in what is known as a Solution Train.
4. Portfolio Level – Bringing Agile methodologies to management practices, so that portfolio execution can be more easily aligned with enterprise strategy. Multiple SAFe portfolios may exist across a single enterprise.