SAFe: Lessons for Product Owners

I recently finished my tenth Product Interval Planning session. I was asked to chat about the values we've collectively realized throughout our adoption of SAFe, as well as the challenges we've overcome, from the perspective of a product owner. Here's a writeup of that discussion.

Starting as a product manager in the midst of our agile transformation was a unique opportunity to see us embrace Scaled Agile Framework (SAFe): an agility-at-scale methodology to empower agile teams, align business units, and breakdown technical and communication siloes. While I observed the previous status quo as a secondary stakeholder, the timing was perfect for me to 'get my hands dirty' at the ground floor.

Starting with PI Planning

As a first-time Product Owner (PO) who was just learning the ropes of product management and getting a lay of the (product) land, deciding what to prioritize and bringing it to a group of seasoned and incredibly intelligent developers to tell me how much of their valuable time it would take to implement was... daunting. So, I clung to the process (as I was learning it) as a life-preserver, fought off the imposter syndrome, and got feature estimates. Of course, we had to be agile: the end result of our first PI Planning had few similarities to my initial feature list. But the process worked: we collectively banded together to build customer-driven and innovative features and set considerable groundwork for future enhancements.

Since then, I've been lucky enough to partner both with that initial team and scores of other capable developers, talented designers and researchers, system architects with seemingly boundless knowledge, and various other stakeholders who care about the outcome of release planning. Through those release cycles, by learning the why of certain activities within the process, I've been able to better lead those activities (and determine, sometimes, how to best accomplish the why even if the process had to be modified on the fly). With each stakeholder, understanding their key objectives helped me develop more empathy, approaching disagreements and competing priorities with respect while staying centered on the end-user experience.

Over the last ten product planning cycles, a better understanding of those whys has been critical to addressing and mitigating some of the common challenges we've seen:

Challenge 1: Feature Reprioritization

A common frustration, when one project is dropped in favor of another after work has already been completed. Estimates better analyze potential ROI of a feature and can help prevent work commitments towards one goal getting dropped before value can be added for users. In addition, advocating for end users as part of the product vision can be the right approach in helping teams accept shifting priorities when reprioritization does inevitably happen.

Challenge 2: Hesitation to Guess

Giving educated estimates on scope of work is tough - so building structures that helps guide guesswork without treating them as hard commitments can help break down the hesitation to give those estimates. Try breaking down raw time estimates into complexity, size, and risk values as a way to come to a more educated guess; approach those evaluations as a team effort rather than one leader providing esoteric numbers. Reviewing past works' actual time and effort and using it as a benchmark - alongside other examples for larger or smaller items - for future changes also provides more accurate estimates.

Challenge 3: Falling into the Rabbit Hole of Details

For many folks, technical unknowns are opportunities to dive in and learn and discuss every element of potential solutions. Similarly, having to provide an estimate means that risks are 'threats' to the accuracy of those estimates, so addressing them can lead to more confidence. These are totally valid approaches to planning, but it's up to the PO or team lead to keep solutioning conversations for falling into the rabbit hole. In other words, those unknowns will probably need to be explored at some point - but not necessarily at that point. As long as they're identified and tracked, and the PO commits to ensuring they're addressed, they can be tabled for the sake of the meeting's velocity.

Challenge 4: Treating Plans as Promises

Whether a team is voting on their confidence for a specific epic, have a tentative priority order of stories to tackle, or want to 'finalize' a release plan, they may be less likely to share confidence if these plans are viewed as promises. SAFe is agility-at-scale - which means circumstances will change and even the best laid plans may end up unrecognizable a few sprints later. That's OK! A 5/5 confidence vote doesn't mean the team won't change their plans - it just means they've mitigated what they can and have secondary objectives identified. They're confident that the plan is an appropriate representation of what they can accomplish in the next release cycle, but are prepared to be flexible.

Tackling these types of roadblocks, misconceptions, and challenges takes time, effort, communication, and care. But they're worth doing! Here's why:

Benefit 1: Build Situational Awareness across a Product Portfolio

Shared roadmap sessions and vision-setting presentations are valuable to help product managers get a sense of the overall puzzle, and general awareness of the features that make up the puzzle pieces - but spending time reviewing feature enhancements team by team can really help build an awareness of the moving parts that make up a release within a product portfolio. This awareness benefits product owners by better equipping them to hold a conversation about their product family with external audiences, as well as contextualize their own efforts to contribute to the broader portfolio vision, but also benefits technical teams as a way to uncover opportunities for shared elements and reducing duplication of effort. Plus, it streamlines dependency tracking and the utilization of common components, ensuring that product teams can rely on one another to increase velocity with the proper level of support from leadership.

Benefit 2: Grow Stakeholder Buy-in & Involvement

Another major benefit of agile release planning and building a product interval plan is the increased buy-in of stakeholders: both folks involved in the delivery of the work and the leaders and cross-functional teams that rely on the work. By providing the context of specific changes and stories within a broader release, the developers and teams who work on those smaller changes still have a sense of the impact their work will have with end-users - ideally treating them as missionaries, not mercenaries. This expands to teams adjacent to direct development: research, design, enablement, etc.

These plans also can help inform go-to-market teams, equipping them with the details of in-progress development to help share, when relevant, timelines of feature requests and enhancements. This should be coupled with proper enablement and readiness programs to ensure customer expectations are set properly but can be a very valuable way to improve the relationship between customers, GTM teams, and developments.

Additionally, the release planning process and the plan itself helps leaders across the organization stay more in tune with the product's direction at a higher level, sharing investment priorities and strategy. This isn't a micro-management strategy, rather a way to for engineering and product leaders to help mitigate risk, support dependency management, and otherwise streamline blockers to ensure teams are supported with what they need - and to help teams make trade-off decisions when necessary for the broader benefit of the portfolio.

Benefit 3: Agility-at-Scale

The implementation of something like SAFe can certainly be misconstrued into a waterfall methodology wearing a mustache. These implementations miss the core element of agility-at-scale. Embracing agility gives teams flexibility in what they can ultimately do in the release in order to maximize value to users and to other groups that rely on them while making smarter and quicker tradeoffs in the ROI calculus. Agility-at-scale, then, brings those benefits to larger, more complex product portfolios, allow for the earlier engagement of supporting resources while mitigating the snowball effect of unplanned changes mid-release.

Benefit 4: Team Unity

Finally, PI Planning is a chance to build unity between the members of the product team (developers, product owner, and designer) and between the various product teams and other stakeholders involved. This unity is built through intentional action: we've had a PM play the guitar while waiting for folks to join a sanity call, I've made bingo cards, we've gone out for release parties and celebrated the completion of PI Planning. I've worked with developers and architects to get out of an escape room, and had meaningful, virtual side conversations during session breaks. Unity is also built through shared experiences: working together to solve problems and overcome issues.

The work to address the challenges with release planning has certainly been worth the effort, when we contextualize it all within the benefits highlighted above. Ultimately, as product managers working with the SAFe methodology, we have to remember that...

• SAFe is agility-at-scale, and we should be agile in our planning, development, and deployment. Our plans are plans. Plans will change. That's OK! The earlier we start planning and engaging stakeholders, the impact of those changes can be mitigated.
• Release planning builds our relationships with engineering teams & leaders through shared purpose, defining co-dependence, and a united approach to challenges.
• We want to build and share confidence, but it's okay that it won't be at 100%.
• We (and our teams) must share a commitment to growth over multiple releases... that's how we all get better, and deliver even more quality solutions to our end users!