Agile is so pervasive these days, it often seems like it has been around forever. Few may remember that the Agile Manifesto was only released in 2001. Since then, the Agile revolution has been successful in shifting the balance of power and ownership from management to developers.
The Scaled Agile Framework (SAFe), a natural continuum of the Agile movement is an attempt to apply Agile principles on a large scale. Despite being a logical extension of Agile, SAFe has been criticized by longtime Agile practitioners. Ken Schwaber being one of them. SAFe’s critics raise three main objections to the framework:
- Incompatibility with operations and support teams
- Technical debt
- Over reliance on story point normalization.
This article presents an overview of SAFe. It discusses the key issues raised by its critics and available solutions. It further illustrates how to use Panaya’s Release Dynamix [RDx] to implement and manage SAFe in your organization.
What is SAFe?
SAFe applies some the Agile Manifesto principles on an enterprise level. These include:
- Prioritizing customer satisfaction by continually delivering software of value.
- The changing nature of stakeholder requirements.
- Working in short, fixed cycles.
The framework translates the key Agile work elements 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.
Based on these elements, SAFe was designed as an efficient framework for software development projects across large enterprises. SAFe is focused on centralizing overall control of the development process under a company’s management. This enables large organizations to plan for the long term. Efforts can be synchronized and coordinated across the enterprise. Business units can set and achieve their time to market goals.
EdgeVerve Systems saw major improvements within a year of implementing SAFe. Product release time was cut down thanks to defects being detected and resolved earlier in the product development cycle. As a result, EdgeVerve releases now incur fewer defects and higher customer satisfaction.
Fitbit has also successfully incorporated SAFe to create seamless workflows across its entire hardware and software ecosystem. Thanks to SAFe, coordination between multiple teams has improved. This helped to ensure a fast-flowing as well as flexible development and release process. It further provided mechanisms for handling complex issues across teams. Finally, applying scaled Agile framework helped Fitbit improve on all fronts:
- Task backlogs
- Cross-team program dependencies
SAFe: Common Critiques
SAFe can be summarized as “Agile, only bigger.” Why is it, therefore that many Agile developers are so critical of it? To understand, we must take another look at the three points of critique raised earlier.
Incompatibility with Operations and Support
Designed to cure the ailments of the waterfall method, Agile was crafted by developers.
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 routine as well as unexpected workloads on a daily basis.
The SAFe Solution
The DevOps structure presents a feasible solution to this problem. 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.
Technical debt is is hard to define, yet, easy to recognize when we see it. Generally speaking, it is the accumulated build-up of unresolved technical issues over the lifetime of a project.
In a SAFe environment, the responsibility for resolving technical debt is centralized under the organization’s management. Centralization can be beneficial when it comes to debt resulting from customer/market pressures or corporate policies regarding time, resources, and budget allocation. The best approach to resolving these types of debt is top-down.
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, development teams that do not understand the long-term consequences of short-term decisions. This type of debt accumulates 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 can only intensify over time.
The SAFe Solution
The best way to deal with this type of technical debt is to follow Agile principles. For example, delegate problem-solving decisions back to the development and testing teams. Empower these teams to set their own deadlines and measure their delivery velocity. They will assume ownership and deal with problems as they arise. Foster a culture of honesty and openness, encouraging individuals to identify, assess, and fix technical debt and associated dependencies.
Management can play an important role in dealing with technical debt. For example, by drafting standard acceptance and exit criteria. Management should provide a clear definition of “done” and consistently apply it across all projects. Management should also aggregate data from teams and make this data visible to all stakeholders via online systems.
Over Reliance on Story Points
Project-related time estimates are usually expressed as a number of man-days involved in implementing a single user story. However, effort-based estimation usually does not take into account task complexity or difficulty of execution. 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, difficulty, complexity and risks. Story points are expressed as a value on an abstract scale.
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 often makes individual teams withrow their control or accountability over the development process.
The SAFe Solution
Again, It’s important to give development teams the autonomy they need to determine their own key performance indicators (KPI’s) is key. Development teams should self-govern their actions. Management should educate teams on how velocity can be used as a guide rather than 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.
How to Implement SAFe
Scaling agile to enterprise levels is not just about processes and framework. To successfully transition to SAFe, your organisation must be ready for a cultural change. It must optimize project management, coordination, and decision-making by centralizing them. Release management practices must be guided by value stream management, for a deep understanding of the value behind any release and development effort.
Panaya’s Release Dynamix [RDx] provides the infrastructure to support your Agile and SAFe transformation and make them both seamless and highly effective. Unlike any other release management solutions, RDx was designed for the enterprise and can effortlessly handle large-scale Agile deliveries. RDx lets you monitor the entire development lifecycle and manage your portfolio, project and release train, value trains, requirements, tests, and risks. It also collects data, displays metrics and dashboards. RDx reports provide key insights and analytics.
As with many prescriptive frameworks, some of the problems with SAFe stem from trying to apply it too rigidly, rather than adapting it to the needs of a specific organization. At the end of the day, sourcing the right solution for the job is more important than any religious adherence to the principles of any single method.
Implement both Agile and SAFe with Panaya’s Release Dynamix [RDx], be it on a program level, project or on a portfolio level.
Disclosure: This is a guest post by Panaya’s product manager on scale agile framework.