It seems that Agile software development has been around forever. In fact, the Agile Manifesto was only released in 2001. The Agile movement achieved its goals. It shifted the balance of power and responsibility from management to developers. Today the Scaled Agile Framework (SAFe) is an attempt to apply Agile principles on a large scale. SAFe principles may seem like a logical extension of Agile. Still, SAFe has been criticized by longtime Agile practitioners like Ken Schwaber.
SAFe’s critics have three main objections to the framework:
- Poor compatibility with operations and support teams.
- Increased technical debt
- Over reliance on story point normalization.
This article has the big picture about SAFe. It explains the problems raised by its critics and discuss available solutions. It also addresses how SAFe is applied on the Portfolio and on the Program level. Lastly, learn how to use Panaya’s Release Dynamix [RDx] to implement and manage SAFe in your organization.
What is SAFe
SAFe applies the twelve points of the Agile Manifesto on enterprise level.
The twelve points include:
- Prioritizing customer satisfaction by continually delivering software of value.
- The changing nature of stakeholder requirements.
- Working in short, fixed cycles.
The framework essentially takes the key elements that go into Agile work 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, SAFe was created as an efficient framework for developing software-based projects across large enterprises. It achieves this by centralizing overall control of the development process under the company’s management structure. As a result, large organizations can plan for the long term. They can synchronize and coordinate efforts across their enterprise. They can set and achieve their time to market goals.
EdgeVerve Systems saw major improvements within a year of implementing SAFe. It was able to cut its product release time down to three months six months for small and large products respectively. SAFe helped EdgeVerve detect and resolve defects earlier in the product development cycle. This led to less defects in their software releases and higher customer satisfaction.
Fitbit also successfully incorporated SAFe to create seamless workflows across its entire hardware and software ecosystem. Fitbit was able to coordinate multiple teams. This helped to ensure a fast-flowing as well as flexible development and release process. It provided mechanisms for handling complex issues across teams. Applying scaled Agile framework helped Fitbit improve on all fronts:
- Task backlogs
- Cross-team program dependencies
SAFe: Problems & Solutions
If we summarize SAFe as “still Agile, only bigger,” why are many Agile developers so critical of it? To understand why, let’s take another look at the three points we raised earlier.
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. This is not how corporate IT, operations, and support departments work. Their focus is on handling workloads on a day-to-day basis.
Operational workloads often include handling routine and scheduled tasks. They involve dealing with unexpected events and working on multiple projects simultaneously. Time is limited and is hardly enough for the scope of release planning that Agile requires.
Support might send a representative to a release planning meeting. However they are usually unwilling or unable to get involved. More importantly, 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 solution. DevOps is an approach that 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 define it as the accumulated build-up of unresolved issues over the lifetime of a project. Most people deal with difficult situations by trying to delay making hard decisions for as long as possible. Managing a single project’s technical debt burden is a constant struggle. However, if the team is aware of the problem, they can deal with it via collective action.
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. This includes debt resulting from customer/market pressures or corporate policies regarding time, resources, and budget allocation. These types of debt 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. For example, dev teams that don’t understand the long-term consequences of short-term decisions. This type of debt also arises in unstable teams where members have a high turnover rate. The organization’s management must take an active role in resolving localized technical debt. Else, a larger and more intractable debt problem is created that 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. For example, by writing standard acceptance and exit criteria. Management should provide a clear definition of “done” that is 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 man-days involved to implement a single user story. A project manager might estimate that the effort involved in implementing a user story is one man day. Note that the number of man days indicates the absolute effort required to execute the task. In other words, the project manager could assign two developers and complete the task in half the time, but the overall effort required remains one man day.
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.
A story point is a measure of effort to implement a single user story that takes into account additional factors. For example, 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 man-day of effort. So, a task that takes one man-day 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, 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 solutions is to give development teams the autonomy they need. This involves allowing them the authority and trust to determine their own metrics. Dev teams should be able to 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.
Implementing SAFe on The Portfolio Level
In the context of the SAFe framework, the portfolio level is where management can check the alignment of enterprise strategy to portfolio execution. This is achieved by creating clear value streams that make it easier to understand the investment in any given initiatives.
The SAFe portfolio level provides an account of the teams and processes needed to build solutions that the Enterprise needs to meet its strategic goals. Multiple SAFe portfolios may exist across one enterprise.
Each SAFe portfolio outlines both the Strategic Themes for the portfolio that guide it through changing business objectives, as well as a constant flow of feedback from the portfolio back to the enterprise stakeholders. This includes:
- The current state of the portfolio’s solutions value stream KPIs
- Qualitative assessments of the current solution’s fitness for purpose
Delivering the basic budgeting and necessary governance mechanisms, management can assure that investment in solutions will provide the Return on investment (ROI) the enterprise needs to meet its strategic objectives.
Implementing SAFe on The Program Level
The program level is where management allocates development teams, business users and other resources are devoted to an ongoing solution development mission. All the resources allocated to a single program are accounted for in The Agile Release Train (ART). ART also includes the program level teams, roles, and activities that incrementally deliver a continuous flow of value. Usually, a program has a definitive start and an end date, as well as temporarily assigned resources.
ARTs however, are long-lived and therefore, have a more persistent self-organization, structure, and mission than a traditional program. ARTs are virtual organizations formed to eliminate unnecessary handoffs and steps. They accelerate value delivery by implementing SAFe practices.
Conclusion: Making SAFe Work
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. Optimize project management, coordination, and decision-making by centralizing them. One of SAFe’s many benefits comes with its use of value stream management, enabling a deep understanding the value of what to develop and the timing behind any release.
No matter how you reconcile the demands of Agile and SAFe, Panaya’s Release Dynamix [RDx] provides the tools to support your Agile and SAFe deployments and make them 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 dashboards. RDx provides reports that give you key insights and analytics.
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.
Panaya’s Release Dynamix [RDx] can help you implement the elements from both Agile and SAFe that best serve the purposes and goals of your specific task, be it on a program level, project or on a portfolio level.