What Is the SAFe® Framework?
Agile started with software development. However, many organizations have found the principles beneficial. The ability to quickly assess, adjust, and organize teams has benefits far beyond coding.
At first, when larger enterprises incorporated Agile into their processes, some things lost in translation or were unworkable. Especially given the many competing priorities and demands in larger organizations. There wasn’t an easy way to map the highly independent, lightly structured Agile worldview into huge corporations. The process complicates thousands of employees, tons of customers, and various products in different lifecycle phases.
The dexterity of Agile, Lean, DevOps, and other 21st century frameworks needed to be scalable. The challenges included massive bureaucracy, legacy product lines, and baked-in customer expectations and contractual obligations. Companies needed a reality-based middle ground.
Enter Dean Leffingwell, the man with the solution for scalable agile. He introduced the Scaled Agile Framework (SAFe) in 2011; its popularity quickly spread and improved over time. It’s already on its 5th iteration.
SAFe® builds on the seven core principles of the Lean Enterprise:
- Lean-Agile Leadership
- Team and Technical Agility
- Agile Product Delivery
- Enterprise Solution Delivery
- Lean Portfolio Management
- Organizational Agility
- Continuous Learning Culture
These translated into practical applications, demonstrating the necessary changes to apply these principles at an enterprise-scale organization. The framework provides a vast library of resources to educate staff and a 12-step implementation roadmap to enable success.
In scaled agile, product managers and product owners have greater responsibilities, but there are useful tools and simple steps to ensure success.
3 Heightened Responsibilities of Product Managers in a SAFe® Environment
Product management is a little different than usual in SAFe®. First, beginning with the fact that practitioners manage both products and solutions. This distinction is important because not everything in an enterprise setting can or should consider a product in a traditional sense.
These offerings may not be sold as discrete products. They may be bundled with professional services, consulting, or other less tangible elements. Not to mention that some solutions may be for internal customers that would never think of the deliverable in product-oriented terms. Products are rarely self-contained, independent offerings in a SAFe® environment.
1. Solution context
This approach requires a holistic outlook on the problems to solve and the environment where those solutions are delivered. In particular, product managers investigate, define, and utilize the solution context. This context clarifies how the solution fits into the bigger picture.
The understanding of the complete landscape is a vital element of SAFe®. Understanding will impact the solution’s definition will affect the ramifications the solution has on other systems and processes. In an enterprise, this is especially complex as there are many interdependent systems.
2. Increased collaboration
SAFe® Environments require product managers to be especially collaborative. Consensus building and stakeholder alignment are more difficult in a large organization than in a smaller, product-centric organization. Product managers must anticipate and identity conflicts and game out the consequences of their decisions. In larger teams, any decision makes a larger impact, so everything is carefully considered.
3. Additional customer types
Another heightened responsibility for SAFe® product managers includes the obligations to their customers. In an enterprise setting, a product or solution’s customer is just as likely to be an internal constituency as it may be an external paying party. This is sometimes for the same product or solution! These large, complex systems will often have many different people interacting with different aspects of the solution. One example is external brands bidding on shelf space in a grocery store and internal category managers optimizing their product mix.
But despite these extra complications, the core responsibilities of product management remain. SAFe® product managers are still working on hitting their KPIs. To ensure their product works and ships. Plus leveraging user feedback for iterative improvements and optimization.
Business goals may not always focus on revenue and growth. Such as when the solution is internal-facing and aimed at saving money, speeding up processes. There are other goals to consider when the organization is a non-profit or government entity.
Yet, there are similarities in the process. This includes prioritization, definition, collaboration with the implementation teams as well as go-to-market activities.
If the product is part of a larger solution, there will be additional duties. These focus on ensuring interoperability and cohesion across the entire solution. Duties may also include participating in activities related to the larger solution train a particular product plays.
4 Key Responsibilities of Product Owners in a SAFe® Environment
Product owners also play a pivotal role in SAFe®. Their focus lies in the iteration area of implementation versus setting the strategy or defining the key deliverables. A product owner’s focus stays with the specific solution, underlying and supporting technologies, and the implementation team(s) they’re working with.
1. Team backlog management
Product owners are responsible for the team backlog or user stories from the larger program backlog. These are all “optional” user stories, as they might get done at some point, but none of them have to be completed.
2. Prioritization
Management requires an ongoing balance between the many competing priorities of various stakeholders—ensuring a somewhat even doling out of these items to the implementation team to keep everyone satisfied. Product owners can rely on familiar prioritization frameworks such as weighted shortest job first or cost of delay.
3. Managing enablers
The team backlog will often include enablers who support initiatives for top-line business requirements, including architecture, compliance, and infrastructure elements. These elements must be addressed to prevent technical debt from piling up.
4. Defining stories
Product owners end up defining some stories themselves to convey the intention of iterations to the development team. These stories have a narrower scope and more specificity than those defined by other teams. Instead, the stories are designed to direct small improvements versus major new functionality.
While product owners may provide input to the product roadmap, the ownership, management, and communication of that artifact remain with the product manager. However, there are often multiple product owners for each product manager in the organization, and product owners may work with one or more Agile teams.
3 Ways Product Roadmaps are Essential in a SAFe® World
While every product benefits from a roadmap, those built in a SAFe® environment benefit, even more, there are a few key reasons for this imperative:
1. Scale and scope
Products and solutions in a SAFe® setting are rarely small or quickly delivered. Stakeholders will need to see how things will all come together.
2. Alignment
Product roadmaps can illustrate how the product or solution contributes to the organization’s larger goals and objectives (or identify initiatives that don’t.) Roadmaps also offer the visibility required for affected teams to plan accordingly.
3. Interdependency
Products and solutions in this environment are rarely self-contained. Other teams and senior management will need to see how each product or solution fits into the larger ecosystem and ensure that key milestones for deliverables are met.
This is where a portfolio-level roadmap can add a ton of value. This roadmap facilitates alignment across multiple products. The combined roadmap shows how everything lines up, and the audience can then drill down into the specific products, themes, and goals as needed.
3 Ways to Ensure SAFe® Success
SAFe® is a far more rigorous product development environment than many product managers ever experience. There is way more riding on every detail than a standalone product.
But the SAFe® model aims to mitigate many of the risks of such a large, interdependent system. All while still keeping the pedal to the metal and cranking things out via Agile. The benefits from continual iteration, user feedback loops, and nimble development and deployment are too good to pass up for an organization that’s betting on digital transformation to survive and thrive in the 21st century.
For those embarking on this journey (or dropped into an organization that’s already on its way), there are a couple of helpful hints to keep in mind.
1. Put the right people on the right jobs.
Organizations using SAFe® are usually quite large and require multiple product managers and product owners to succeed. But not all product professionals are equal. Because of this, it’s critical to assign the right personnel to the products and solutions which suit them.
Many of those products and solutions are extremely technical, so it would be wise to put someone with deep technical competencies into those roles. Those with a more commercial bent can better serve the organization by working on the portfolio’s customer-facing aspects.
2. Start small.
An entire organization doesn’t have to dramatically shift gears all at once and embrace SAFe® 100% on Day One. Many companies find success by creating a single Agile release train for a small number of implementation teams to get their feet wet.
These baby steps offer a few additional perks other than not having to convince thousands of employees to make a sudden change. They can identify system breakdowns or weak points that need to be rethought or bolstered to support Agile. These early adopters can also serve as a real-world, internal example for other parts of the organization.
But most importantly, these initial inroads can prove the ROI and realistic ability for SAFe® to work “here.” Dispelling the belief that Agile is for the “other guys” is a key step toward a successful wider rollout.
3. Optimize communication.
SAFe® doesn’t work unless the information shared remains accurate. Product roadmaps can play a major role in facilitating this.
When using a cloud-based, purpose-built product roadmapping tool, the audience can view up-to-date data instead of emailing around attachments that are quickly stale and incorrect.
Additionally, stakeholders can subscribe to receive update notifications whenever changes made using the asynchronous communication tools the organization already leverages, such as Microsoft Teams or Slack.
Product roadmaps provide context, status, and a high-level view that connects the dots for the teams in the trenches working on specific items. They can also surface any issues brewing in the background, particularly when viewing the entire portfolio’s roadmap in a single view.
