What is SAFe’s perspective on the Product Owner role? How does it differ from the Scrum Guide? Why is Product Ownership split to Product Owner and Product Manager in SAFe?
SAFe’s approach to Product Ownership draws quite a bit of criticism. As a Professional Scrum Trainer who’s also a SAFe Fellow/SPCT, here’s my perspective…
Product Ownership is a crucial element in improving Outcomes
SAFe and Scrum both consider product ownership crucial to maximizing outcomes in environments of complexity and uncertainty. Teams are ideally organized around Products / Value Streams so they can apply customer-centricity. Product people and their teams are ideally accountable to outcomes and are empowered to figure out, inspect, and adapt requirements/scope as needed.
SAFe has multiple Product Ownership/Management layers
As organizations tackle bigger products, they have some alternatives for how to tackle product ownership/management. Scrum advises having one Product Owner for each Product, even if multiple teams develop the Product. This is at the core of scaling frameworks such as Nexus and LeSS. SAFe takes a path that is more aligned with the classic structure of Product Management organizations which is to have multiple layers of Product ownership/management.
Product Owners own Product at the Agile Team level. Product Managers own Product at the teams of agile teams level (Agile Release Trains). Solution Managers own Product for huge teams of teams of teams working on even larger products/solutions.
Why did SAFe make this choice?
SAFe takes the perspective of learning from experience in the trenches and what patterns organizations are using and applying lean/agile principles as needed to help organizations evolve. And many organizations have been struggling to scale product ownership when we’re talking about multiple teams. Product Management experts such as Melissa Perri also talk about multiple Product Management roles (see some thoughts about how this relates to SAFe below). Interestingly enough, Scrum@Scale also has Product Owners at every level. And LeSS/Nexus also introduce multiple Product Owners when you scale beyond a handful of teams.
The advantage of this approach is that it aligns with the Product Manager/Owner journey. Working closely with one or two teams, owning product choices for a couple of product features or a certain slice of the product can be a great jumping point for Junior Product Managers/Owners (What Melissa Perri refers to as Associate Product Managers in Escaping the Build Trap).
As the Product Manager/Owner gains experience, they can take on a whole product themselves. It takes time for a Product Owner/Manager to gain the experience to act as the visionary entrepreneur for their product. They might start feeling more comfortable writing stories and executing experiments and, over time, learn to influence, design product experiments, and make tougher prioritization decisions with multiple demanding stakeholders. In other words, Product Managers/Owners naturally evolve from focusing on tactics to strategy over time.
What are some downsides to splitting Product responsibilities between the Product Owner and Product Manager?
An anti-pattern we often see is that the PM/PO split allows an organization to staff the PO role with “story writers” and “project managers” – people who aren’t empowered as Product Owners, and that reinforce the project mindset of requirement order-taking and managing scope-budget-timeline. This lack of empowerment leads to delays and an environment where the team is focused on outputs rather than outcomes.
Empowering Product Owners and their teams is a common challenge in SAFe AND Scrum. What I’ve seen work well is carving out an appropriate product scope within which the Product Owner and team are empowered to figure out what to build to achieve the desired outcomes and optimize the value of that product or that aspect of a bigger product.
Doing this requires figuring out the product architecture and moving towards an empowering leadership style.
As in many other areas, SAFe takes the evolutionary approach. If you’re a purist or a revolutionary, you’ll probably struggle with it. Real-world practitioners are more likely to relate to the evolutionary approach. It’s important to ensure that the PO/PM separation is not seen as an excuse to continue doing everything the same.
Product Managers and Product Owners – A Collaborative Relationship
Leaders implementing the PO/PM split should ensure healthy collaboration, involvement, and partnership across the product ownership/management team.
Product Managers should internalize the SAFe principles of unleashing the intrinsic motivation of knowledge workers, in this case, Product Owners. Product Managers have a role as lean/agile leaders to nurture the competence, awareness, and alignment in the product team that would enable them to decentralize control and let Product Owners OWN a certain slice of the product.
Product Managers and Product Owners should have conversations about what decisions make sense to centralize and which should be decentralized. And the goal of Product Managers should be to grow Product Owners over time so they can make more and more decisions – and minimize the decisions that need to be made centrally. This is key to scaling without slowing down decision-making while still maintaining and ideally improving outcomes in alignment with strategic goals.
Increased risk of misunderstandings around Product Ownership with Product roles filled by non-product people
One very specific risk of the SAFe choice to split the PM and PO role is that it creates the need for many more people in a Product role than the number of people in the Product organization. This vacuum pulls people like Business Analysts, Project Managers, and Development Managers into the Product Owner role. Some people can become great Product Owners but come with very little Product (Management) experience. Business Analysts, for example, are used to consider what the customers say as requirements. They are used to the “waiter” mindset. They struggle to say no or to think strategically about what should be in the future or what should be in the product. Development Managers are used to being subject matter experts, guiding their people at the solution level, and managing the work. Project Managers are used to focusing on managing Scope/Budget/Timeline rather than value and outcomes.
Use the Professional Scrum Product Ownership Stances to Improve your SAFe Product Ownership
One technique I found very useful is to review the Professional Scrum Product Ownership Stances with SAFe Product Owners and Product Managers. We try to identify which misunderstood stances we’re exhibiting and what structures are reinforcing these misunderstood stances/behaviors. For example – what’s causing us to be “Story writers”? We explore the preferred Product Owner stances and discuss what’s holding us back from being in these stances. Why is it so hard to be an “Experimenter,” for example?
An emerging realization from these conversations is that SAFe structurally creates a setup where team-level Product Owners play “story writers” and “subject matter experts” more often. It’s non-trivial to switch to an environment where they are a “Customer Representative” and a “Collaborator” with the space to “Experiment” with their team towards the right outcome rather than take requirements as a given. It’s hard to get SAFe Product Managers to be the “visionary,” “experimenter”, and “influencer”. The issue here isn’t unique to SAFe. Product Owners struggle to exhibit these behaviors in most Scrum environments as well. What I find useful is to align on a “North Star” vision of what we WANT product ownership to look like at scale and take small steps in that direction continuously, rather than settle for “project management” or “business analysis” called a new name.
SAFe Product Management – Providing vision and cohesion in a Pharma IT environment
Let’s close with an example of how this can play out in practice. I’m working with the IT organization of a Pharma company. As they were thinking about how to help their Enterprise Applications group become more agile, one of the key questions was how do we create product teams that are empowered to directly support the business – by minimizing dependencies and creating real ownership of each of the enterprise applications as a platform that other IT functions can more easily build off of and leverage. Several Enterprise Applications have multiple teams working on different aspects of them. We created stream-aligned teams, each owning and managing that aspect as a Product. The Product Owners and their teams are empowered to consider needs and wants coming in from other IT functions and the business and shape the future of their product. Most of these product ownership decisions happen at the team level. Product Managers focus on alignment and cohesion across the platform. We are still working on establishing the right mechanisms to balance vision/alignment with local initiative at the team level.
SO WHAT NOW WHAT
SAFe’s approach to Product Ownership is a frequent target of criticism in the hard-core agile community. Some of it is pure business/commercial posturing (aka FUD) and some of it is fair and constructive.
My aim in this article was to help practitioners explore the rationale, the potential, and the risks behind SAFe’s approach to Product Ownership, as well as some patterns and models, such as the Professional Scrum Product Ownership stances, that can be used to inspect and adapt/grow the effectiveness of your product ownership approach.
As an individual Product Owner or Product Manager, you can use these models/patterns to drive your learning journey and to help you structure the conversation in your organization around creating the environment that empowers you to be a real Product Owner or Product Manager.
As leaders of Product organizations in a SAFe environment, I hope this can help you establish a vision of how you want your Product organization to look like and guide you on the way there.
It probably won’t surprise anybody that one of my most popular offerings these days is the “Fix our Agility” workshop/engagement with a starting point of SAFe Theater. More and more leaders realize that SAFe works better when built on the foundation of professional high-quality Scrum, which leads them to look for people with deep experience in both SAFe AND professional Scrum when looking for advice on how to bring the two together.
The story of Capital One laying off hundreds of people in Agile roles is making the rounds. I have no direct connection to Capital One, so I can’t comment about what’s going on there.
What I can share is for years now, I’ve been coaching companies and leaders to see the Scrum Master and similar roles like the SAFe RTE as accountabilities relevant leaders take on (it can be formal managers/leaders or natural leaders from within teams that are passionate about agility and gravitate to this). See the Scrum Guide for Leaders.
One example is the VP of Engineering in a growing startup, who decided to take on the SAFe RTE role (Chief Scrum Master for the Agile Release Train) since they felt it was up to them to provide this sort of leadership.
Remember – Scrum Accountabilities != Scrum Roles
This way of thinking is supported by the 2020 Scrum Guide update that changes the language from Scrum Roles to Scrum Accountabilities. SAFe also sees itself as a dual operating system in parallel to the organizational structure, which means the Scrum Master and other roles should be seen as accountabilities.
If/When leaders take these new ways of leading and showing up to heart, it creates healthy and sustainable agility. Getting there requires support and coaching of course.
Sometimes you do need someone dedicated to agility
In addition, there are situations where no one is passionate about organizational performance, health, agility, and development. In these contexts, the right move IS to have a person dedicated to these accountabilities. Most of the time, these people are brought in to become part of the leadership team of a larger group.
So what do the layoffs of Agile roles mean?
Is “laying off all agile roles” a sign that a company achieved agile nirvana? Probably not.
My take on what we’re seeing right now in the market is more often one of these scenarios:
Companies wake up to the reality that they are DOING Agile (rather than BEING Agile) and see the Agile roles as part of the problem.
Companies that believe in their Agile way of working and have achieved a reasonable level of agility. They want to continue to improve, but when they are looking to extend their runway in the current macroeconomic environment, they make the tough but necessary decision to spend less on the “future of work” and more around “doing current work”.
Change in leadership and the loss of a formal or informal Agile Champion leads to a change in perspective about agility.
Companies where people in agile roles are making an impact, but either don’t care or struggle to provide transparency to this impact in a way that will resonate to business people (think CFO). In the current context, this isn’t a very sustainable strategy…
Now what?
If you’re in an Agile role (Scrum Master, RTE, etc.) I recommend you focus on continuously improving the effectiveness and results of your team (or ART), in a way that is impactful to the business, ideally in a quantifiable way. Look at Evidence-based Management for ideas regarding what to focus on and what conversations to have with your team and your stakeholders.
It might be frightening but you should also consider asking your team, stakeholders, and leadership a question used in Netflix – How hard would you fight to keep me here? The answer and conversation might be hard to hear – but it will provide the transparency you need to inspect and adapt your focus.
If you’re in a big organization with a formal or informal agile role community of practice I recommend you make this a topic you work on.
The optimistic in me hopes that, as a community, we will use 2023 as a wake-up call that will positively impact what we focus on and the value we bring to organizations.
And finally, one of the hard truths about our role is that our ultimate success is when we’re not needed anymore. Moving between teams, contexts, and sometimes companies is part of this profession we took on…
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — The Agile Manifesto Principle
“programmers or software developers should not work more than 40 hour weeks, and if there is overtime one week, that the next week should not include more overtime.” — Extreme Programming
An unsustainable pace is unhealthy. It contributes to burnout, quality issues, and unpredictable results.
If you are an agile leader — do you know whether your teams are currently operating at a sustainable pace? Do you care? Would you rather not know because you’re afraid of the answer?
Measuring Sustainable Pace
Beyond having a general idea of the sustainability of pace, perhaps it would help to have a concrete KPI related to it?
If we use the language of OKRs, maybe something along these lines:
Objective Achieve a healthy sustainable paceKR1 — People working reasonable hours AMB (as measured by) hours per weekKR2 — People happy about their pace AMB continuous survey KR3 — Plans don’t assume unsustainable pace AMB ability to achieve forecasts without resorting to unsustainable pace measures
Forecasting towards Sustainable Pace by inspecting sustainability of past pace
The last KR relates to the planning/forecasting approaches we use in agile. Agile approaches leverage empirical planning approaches. They look at the past (Yesterday’s weather) to try and forecast the future. Whether it is PI Planning, Sprint/Iteration planning. Whether by looking at Velocity, Throughput, or Cycle/Flow Times — most approaches tend to ignore how these past results were achieved when using them to predict future capacity.
For example, if our velocity in previous Sprints was 15–20 points, we will probably take on about 15–20 points. But what if these 15–20 points required a herculean effort that wasn’t sustainable?
Similarly — if we just concluded a PI in which the ART achieved a Program Predictability Score of 85% we will be tempted to assume we have a pretty serviceable approach to planning/forecasting. But what if this required killing it through nights and weekends and skipping any sort of Innovation in the IP iteration? Where does this come into the calculation?
If our cycle/flow times are 7–10 days 85% of the time we will be tempted to set that as an SLE (Service Level Expectation) to ourselves. But does that make sense if this was achieved while working 60 hour weeks?
Planning/Forecasting using a Sustainability Factor
What I’m advising teams/organizations I’m working with is to consider the “sustainability factor” when considering any past results for the purpose of forecasting the future and adjusting accordingly. This isn’t trivial. It requires making sustainable pace an explicit “citizen” of the measurement dashboard and conversation.
We have learned that speed and quality are related. We now understand that inappropriate speed might be at the expense of quality, so we look at a balanced scorecard of speed and quality. Moving forward, we need to add pace sustainability to this scorecard and to the conversation around how much work does it make sense to forecast.
A metric I’ve been toying with is Weighted Predictability/Sustainability:
As you can see here, achieving reasonable predictability scores is weighted down by the unsustainable pace required to achieve them. so a score of 80% is actually weighted down to 53%. This 53% is what should be used for future planning purposes. For example in SAFe I&A and PIP.
Moving Forward — Treating Pace Sustainability as a first-class citizen
First, we need to come up with a good name for this metric / KPI. Flow Sustainability? Pace Sustainability? Work Sustainability? Burnout Risk? Are you explicitly measuring anything related to Sustainable Pace? Do you have goals around it? Do you take it into consideration when planning? Please share in the comments!
Aligning Scrum Team Topology to Strategy with OKRs and Product Goals
Yeah, I know. Could I squeeze more buzzwords into the title? I guess I could include Digital Transformation, Cloud, AI, and Machine Learning for effect. But seriously, I wanted to share some insights around how to align your Scrum Teams to your strategy leveraging OKRs and Product Goals.
Driving Change Using OKRs
We maintain performance by tracking the health of Key Performance Indicators(KPIs). We use Objectives and Key Results (OKRs) to drive performance change. Objectives point towards the desired state. Key results measure progress towards that desired state.
This performance change could be about our product or the ability to innovate/create that product. (Gap between realized and unrealized value / ability to innovate in evidence-based management (EBM) terms)
By setting OKRs we’re typically setting our sights on a complex problem — the space where Scrum and Empiricism thrive.
Achieving OKRs using Empiricism and Scrum
Working in self-managed empowered multi-disciplinary teams using fast feedback loops is a great way to tackle complex problems.
This is true regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from using Scrum’s empirical team-based approach.
For example, if a health care provider is aiming to digitize their patient journey to streamline it and make it more efficient, part of that will be to implement an electronic medical records system (EMR). But the objective isn’t just about implementing an IT system. It’s a change in the operating model. The organization supports this change by the development of new procedures, systems, and capabilities.
Focusing on Outcomes rather than Outputs
OKRs and Scrum are both designed to focus on outcomes over outputs. Most agile practitioners would recognize the N from “INVEST in User Stories” which stands for creating Negotiable user stories that provide optionality/flexibility for learning about what’s the best way to achieve outcomes. Having said that, most agile practitioners do feel like user stories are a form of requirements — meaning they are required.
Actually, user stories, any other form of Product Backlog Items, and even the Sprint Goal should be considered options — meaning they are optional. We currently think they are valuable, but we might learn of more valuable things to focus on.
Even the Product Goal is just an option. Maybe there we will find a better Product Goal for the Scrum Team to rally around or maybe there’s another better Goal that requires a different team topology.
Be Agile about your OKRs
Similarly, OKRs reflect the strategic direction at a certain point in time. We might learn something that would suggest a change in the Key Results or even the Objective itself. The frequent transparency provided by sprinting towards an OKR enhances the empiricism that might drive these realizations and is an enabler for strategic agility.
Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone.
The same sort of time, budget, scope-oriented project management mindset that is hampering so many agile teams is affecting OKR implementations as well.
The problem with activity/output-based OKRs
Many OKR practitioners struggle to figure out how to break an annual strategy/OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps a.k.a activity/output/milestone OKRs. It’s the project management mindset again — we basically bring in the classic work breakdown structure (WBS) into the OKR framework.
Going back to the patient journey digitization effort. Many organizations would define an initial OKR of choosing an EMR system. This is an example of an activity. It doesn’t deliver business value on its own. Once we set this OKR it’s harder to think of alternatives that might obviate the need for an EMR system in order to achieve the desired outcomes.
We’ve seen it happen countless times on agile teams struggling to slice stories in a meaningful manner and not sure how to come up with a useful Increment at the end of a short Sprint.
When working with OKRs we can leverage the same techniques that help these agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction.
Organizing Around OKRs
Another common reason why we see output-based OKRs is the team topology.
We often see organizations defining OKRs and then mapping them to their existing teams. In this example, this will mean cascading OKRs throughout different IT and business functions. The cascaded OKR grows farther and farther away from the desired Outcome because functions/silos can’t deliver these outcomes. They can only deliver outputs. Hence, the prevalence of Output-based OKRs.
After we define these OKRs the different functions will, of course, try to collaborate but we know how hard it is to collaborate effectively across functions. And with each group focused on an output-based OKR, we lose the opportunity to align around outcomes and are back to managing “projects”. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way.
OKR-Driven Team Topology
A better approach might be to consider the level of complexity each OKR exists in. Then, create focused cross-functional Scrum Teams around the most complex OKRs. You might call this “OKR Driven Team Topology”.
Each one of these teams would focus on an OKR and have that as their Product Goal. Their Product Owner would have ownership of the OKR. This team would be THE team to talk to about this OKR.
If an OKR requires more people than would fit one Scrum Team consider forming a Nexus (or any other agile team of teams structure) around this Product Goal. Or maybe you can split the Objective and have separate Scrum Teams working on each Key Results (KR). There are multiple possible topologies.
The key point is to try and keep the outcome orientation all the way to the trenches where people work to create usable valuable Increments. In your Sprint Review, Inspect the Increments created with an eye towards your OKR. Adapting might mean changing tactics of how to achieve the OKR or even changing the Key Result or the Objective itself.
OKRs and Focus
The approach I laid out above is the ultimate way to achieve focus on one strategic outcome.
Realistically, not all OKRs would map 1:1 to a team or Nexus. And that’s ok. For example, you might have 20% of your most complex/critical OKRs handled using dedicated teams with the rest of them mapped to existing teams/functions.
If that’s the approach you’re taking, make sure you’re limiting the amount of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of 3 per team per quarter. And when a team hits the limit, don’t set the OKR for this quarter. This will drive a tough but important conversation about priorities. But it will set the teams and therefore the organization for a better chance to actually deliver on the strategic outcomes that matter the most.
Having 3 OKRs per quarter that you actually achieve is much better than 6 OKRs per quarter that drag on from quarter to quarter.
NOTE: You might find it useful to start tracking flow metrics (WIP, Flow/Cycle time, Throughput, Aging) as they relate to your OKRs…
When to organize around outcomes with OKRs and Scrum
In this article, we explored the relationship between OKRs, Scrum, the teams’ topology, and outcome/output-oriented OKRs (and teams!).
A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.
This is the time of the year when many of you are drafting your annual OKRs. Take this opportunity to consider whether your current team topology (in IT/technology and beyond!) is well-positioned to achieve these OKRs.
Another opportunity to use this lens is If you’re currently trying to figure out what your Scrum team topology should look like (e.g. when starting your agile journey, extending or accelerating it). Considering your strategic focus via OKRs is a great perspective to consider in this process.
A discussion about Strategy/OKRs and how they map to team topology is now a core part of my conversations with clients and our implementation strategy workshops.
Are you trying to figure out how to connect OKRs and Scrum in a way that organizes around outcomes? Feel free to reach out and we can discuss how I might be able to help.
I encounter many organizations that are trying to improve the alignment between strategy and execution with the OKRs framework (Objectives and Key Results). There’s good intent there, but more often than not I see anti-patterns like:
OKRs that look more like tasks than strategic objectives — especially by the time they reach working teams
OKRs used to micro-manage teams and individuals rather than empower and enable them.
Too many OKRs that are set without any respect/consideration of the ability to actually deliver them in a sustainable way while dealing with other work happening in the organization
Defining OKRs and then forgetting about them until its time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…)
OKR Theater
These anti-patterns aren’t an inherent problem with OKRs. They are what you could call “OKR Theater”. They are what you get when you start to focus on the mechanics and forget the principles/spirit/reason you used the technique in the first place. OKR Theater has the potential to become a member of a big family — Scrum Theater, Agile Theater, SAFe Theater, and Lean Theater, Six Sigma Theater, you get the picture. It’s the sort of thing that happens when a good thing gets spread too thin and the people implementing it lack the depth and experience the original practitioners had. It’s what the late Jerry Weinberg called “The Law of Raspberry Jam” — “The wider you spread it, the thinner it gets.”
Dealing with the OKR Theater
This sort of theater is here to stay. What can we do though? One step that seems to help is to try to recall Why we are doing something — in this case, OKRs — and whether they are achieving the expected outcomes for us. To feed this snake its head — what was the Objective that we set out to achieve with OKRs, what were the expected Key Results, and are we seeing indications that this is heading in the right direction?
OKRs (and Scrum…) thrive in the Complex Domain
Next, we need to reflect on what kind of environment we’re operating in. Some of our work happens in a simple or complicated space where we could set OKRs, figure out a plan, execute it successfully, and celebrate.
Alas, OKRs are typically about challenging the status quo. Going beyond “running the business”. This could entail building new products, opening new markets, unlocking efficiencies, changing our organization, digital transformation, or scaling an existing business or product way beyond where it is right now. More often than not, these are complex problems where what we know is dwarfed by what we don’t know.
This is exactly the environment where Scrum thrives. Does that mean we need Scrum to implement OKRs? Scrum is definitely a great way to solve complex problems when you can organize a multi-disciplinary focused team around a certain goal and is indeed a great way to go achieve an OKR. But it also goes beyond that. We could benefit from applying Scrum’s underlying theory to move from OKR Theater to a more effective OKR operating system.
OKRs should be set and managed in a way that enables Empiricism, Self Management, and Continuous Improvement.
Let’s look at how the Scrum Values can be useful when trying to effectively implement OKRs:
An organization should limit the number of OKRs it askes people to focus on. It has the mindset of “Stop Starting Start Finishing” when it comes to OKRs. It considers how to set up teams such that they’re able to focus on one OKR rather than having to work on a complicated matrix of objectives touching many teams in the organization.
Openness — can enable people working on the OKR to find and surface better ways to achieve the desired Key Results than initially planned. Or to suggest different Key Results (KRs) should be aimed at. Or even the Courage to come back and say that the Objective should be reconsidered.
An organization leveraging OKRs should be committed to using OKRs as an alignment framework rather than a micro-management tool in disguise. Using OKRs this way is harder so everyone should be committed to experimenting with how to organize work, how to set OKRs, how to track and grade OKRs, all in a fashion that is aligned with the intent of achieving strategic alignment in an environment of uncertainty and scale.
This requires respect for the framework. It requires teams to respect the direction provided by the OKRs set by their leaders. It requires leaders to respect the ability of the various teams to find effective ways to achieve the set objectives even if its not necessarily how they would go about achieving that objective.
Now let’s turn to the specific anti-patterns I mentioned earlier and see how some Scrum concepts can help:
Do your teams have OKRs that look more like tasks than strategic objectives?
Step back from the tactical OKRs and ask Why? What’s the intent here? What are we trying to accomplish? THAT should be your Objective.
Like a good Product Backlog Item / Goal, An Objective that focuses on the WHY/WHAT leaves the details of HOW negotiable for the team to figure out based on the reality discovered in the trenches. What we’ve learned over the years in crafting good Product Backlog Items, Sprint Goals, and Product Goals can come in handy when crafting OKRs.
Do you have KRs that seem like a list of deliverables rather than results?
This is a sneaky one. Aren’t deliverables what we’re looking for here? In some cases deliverables are fine. But remember — we are frequently operating in the complex domain when trying to achieve the sort of objectives set using OKRs. And in these environments, we don’t necessarily know what deliverables would actually achieve the results we’re looking for!
We might have a situation where we achieved our deliverables but haven’t achieved our objective…
Therefore Key Results should come from the answer to the question “How will we know we actually accomplished this objective?” They should refer to some evidence-based measurement of outcomes or at least highly aligned leading indicators.
OKRs used to micro-manage teams and individuals rather than empower and enable them.
I can’t forget that client who told me ages ago “To tell you the truth, I see Scrum as a way to micro-manage my teams”. He was the only one open enough to say it, but I see similar behavior all around. Some people are aware that they’re using Scrum this way. Some just can’t get out of their micro-management mindset and see Scrum via this prism.
Unfortunately, A similar pattern occurs with OKRs. Leaders might or might not be aware that they’re setting OKRs in a way that “tunnels”/overly constrains teams and individuals.
Focusing OKRs on WHY/WHAT and KRs on outcomes rather than deliverables is a good first step towards empowering teams to solve problems.
Making sure teams understand the wider mission/OKRs and then come up with their own OKRs is an important next step. A leader is welcome to inquire or even advise a team on what OKRs to set. A leader would probably do well not to get involved too much in any further details.
Look at a similar structure in Scrum. The Scrum Team involves Leaders as Stakeholders in setting the Product Goal. Sometimes a team is set up around a Product Goal.
The Leaders are Stakeholders that have transparency to the Product Backlog as well as the Increment created by the team. The Sprint Review is an opportunity for inspecting both and providing feedback that will then be considered and perhaps reflect in the Product Backlog influencing future work. But planning and monitoring the work is the domain of the Scrum Team. The stakeholders trust and respect the Scrum Team’s ability to create value and proceed towards their Goal. They let the team focus on the work.
A similar structure should be considered when implementing OKRs.
Too many OKRs that are set without any respect/consideration of the ability to actually deliver them in a sustainable way while dealing with other work happening in the organization
In Scrum, teams consider their historical throughput, their capacity, their way of working, when figuring out how much work they can do in the Sprint. They figure out their forecast for the Sprint.
Similarly, when setting OKRs, the people who will be involved in achieving these OKRs should be the ones figuring out a realistic and sustainable set of OKRs to focus on for the time period. Setting OKRs isn’t done on a Sprint by Sprint level, so it is more like the activity of “Release Planning / Forecasting” in Scrum.
Defining OKRs and then forgetting about them until its time to grade them. (Even worse, some organizations don’t even bother with a serious consideration of how they did on their OKRs…)
OKRs are typically set on either a quarterly or annual basis. In many cases, teams struggle to keep this high-level guidance in mind as they go about planning their work week-to-week.
We’ve learned that keeping the Product Goal and Product Backlog transparent and always available to the Scrum Team and Stakeholders helps with alignment and consideration of what is important for the team to focus on.
Similarly, in the OKR context, the OKRs should be transparent and always available to everyone working on them.
If using Scrum to do the work, The OKRs could actually become items on the Product Backlog or even a Product Goal in some cases. They should be considered in the Sprint Review. The team should be asking itself whether it’s making appropriate progress towards its OKRs and whether anything needs to change with the work or with the OKRs.
The first step in dealing with OKR Theater is recognizing OKR Theater…
Fixing OKR Theater isn’t trivial. There are other anti-patterns beyond those identified above. Creating the conditions for the successful healthy implementation of OKRs takes focused leadership over months if not years. It all starts with the ability to recognize the theater and setting your sights on something better.
We are leveraging our vast experience in Agile/Scrum/Flow to help our clients go beyond OKRs as a buzzword towards OKRs as a way to achieve strategic alignment leveraging empiricism, self-management, and evidence-based measurement. If you need help realizing the potential of OKRs or helping your teams work effectively within an OKR Theater, maybe we should talk…
Are you leading Scrum Teams? Are you a leader in an organization that’s leveraging Scrum? Hopefully, you’ve read the Scrum Guide to gain an understanding of the framework your teams are using and to understand your role in it.
You probably feel a bit left out though… The Scrum Guide doesn’t explicitly call out the role of the Leader but successful implementation of Scrum definitely requires leadership.
The Scrum Guide describes the leadership required by the Product Owner, Scrum Master, and Developers.
In this article, we’ll talk about leadership outside the Scrum Team.
What Scrum Means for You as a Leader
Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
From a leader’s perspective, Scrum is an approach that can be leveraged whenever the organization is facing a problem/opportunity in an environment that contains uncertainty around either what value looks like or how to create it, or both. The three key ideas in Scrum are:
Empiricism — Constantly sensing what is going on using tight feedback loops and responding accordingly rather than sticking to a stale plan. This is the essence of agility — the combination of awareness of the situation with the flexibility to respond. Another way to look at this is that through different types of feedback loops Scrum helps us manage/control risks:
We manage/control the risk that we’re taking the wrong steps to solve a problem / build a product by doing the work in small increments and stopping to reflect and adjust course on a frequent and scheduled basis.
We manage/control the risk that we might be focusing on the wrong goal by constantly reflecting on the value of increments we’re creating, together with our stakeholders and ideally by actually trying to use what we’ve created, and having the ability to reflect upon our goals and adapt them.
We manage/control the risk that the way we work isn’t ideal for the situation through continuous inspection and adaptation of the way we work.
Self-management — As their organizations grow and scale, Leaders often feel growing stress as they become decision-making bottlenecks. Complex problems and environments require constant decision making since our original plans don’t survive contact with reality. Complex problems require the involvement of multiple disciplines and leaders find themselves coordinating the work of these multiple disciplines, adding even more to the dependency on leadership which eventually slows down innovation and progress no matter how hard the leader works. In Scrum we rely on multi-disciplinary self-managed teams that are able to make decisions and create value on their own, with minimal external dependencies and management guidance. To be clear, self-management isn’t anarchy. These teams are organized within constraints and are aligned to the mission set by leaders on behalf of the organization. We work towards self-management over time, as we nurture the competence and awareness needed for it.
Continual Improvement — For both the problem we are solving and how we are solving it Scrum encourages teams to continually strive to improve. The artifacts and events provide the opportunity to improve.
Many organizations struggle to create an environment of Empiricism, Self-management, and Continual Improvement since it’s very different from traditional approaches of structuring work, managing teams, and getting stuff done. The Scrum Guide describes the responsibility for this Scrum-friendly environment as “Scrum requires a Scrum Master to foster (such) an environment…”. However, the reality is there are many challenges that require help from other leaders outside of the team. These leaders typically find themselves in the middle — trying to set up the conditions for success in an organizational culture and senior leadership that is often at odds.
Before applying Scrum a leader needs to determine where and how to apply Scrum in the organization. Here are some of the typical questions a Leader would ask:
Focus — What work are we doing in the organization where it’s most worthwhile to implement Scrum?
Problem Ownership — For each of these areas, who should own value identification and maximization? (This is called the Product Owner in Scrum)
Team Structure — What’s the best way to organize into teams or teams of teams that will allow the team to focus? How can we create these teams in such a way that will enable them to self-manage and run an effective empirical process of learning and value creation?
Human Resources — What in the way we are structured, staffed, and governed do we need to change to enable successful value creation with Scrum?
Stakeholder Management — Who are the right stakeholders to inspect the results of every Sprint? How can we get them to engage with the team and give useful feedback?
Culture — How can we create an environment where feedback is an opportunity to do better rather than a demonstration of a mistake (that often has further consequences)
Scrum is simple so you can quickly understand it. It is incomplete — it requires you complement it with context-specific practices and solutions. The basic rules of Scrum can provide some guidance for what to do and how to behave as a Leader but they will not give you hard and fast answers to all of the above questions. Many of the right answers will emerge over time as the your team/s gain experience using Scrum in your context and you have a chance to test out some different ways to address the challenges that emerge.
To reinforce this concept — Scrum encourages teams and organizations to find the minimum viable way of working, try it out, and adapt based on experience. The more frequently you can close this “learning loop” regarding how your organization operates, the faster you’ll converge towards an approach that is optimized for your needs and context. As the organization and its context changes and evolves, the continuous improvement learning loop will enable further adjustment. Some practices might become stale and irrelevant. Your process can benefit from periodical “decluttering” same like your closet and your kitchen drawers. (If a practice/policy doesn’t spark joy… thank it for its benefit so far and stop doing it…)
The leader’s number one responsibility is to provide clarity of what good means and to help ensure that the environment that the teams are working in supports the use of Scrum.
Scrum Theory and Values
As mentioned earlier, Scrum is founded on empiricism — transparency, inspection, and adaptation. Empiricism is only possible in certain cultures and contexts. Leaders have the role of creating and nurturing the culture and shaping the context.
Focus -Are your teams able to focus on one important mission/goal? Do they have one clear set of priorities? They know when to say “No it doesn’t make sense to start this now, our plate is full”. If you’re a senior leader this starts at the portfolio level — being able to say “let’s focus on these key initiatives” and mainly “let’s NOT do these other things until we actually have the organizational capacity to deal with them” creates the culture where focus is possible. Ideally, Leaders make courageous choices and organize their teams around concrete Product Goals reflecting these choices.
Openness — Leaders should have open discussions about whether their organization/ecosystem is conducive to Empiricism and Scrum as well as inspecting and adapting the cultural behaviors and standards that can be impediments to an effective Scrum culture. Are you able to tell your senior leader they are wrong? Are your people able to tell you you’re wrong? How open will the conversation be in the Sprint Review when leaders and teams get together to inspect an increment of work? Will teams open up to what’s really going on? Effective transparency and inspection require this openness.
Commitment — Leaders commit to setting the Scrum Team up for success and supporting it through the removal of things that get in the way of flow and feedback loops. For example, an existing quarterly planning meeting requires a long detailed report which has no value for the Scrum Team. When this waste is raised the leader should work with the organization to remove the need for the Scrum Team to provide it.
Courage — Leaders have the courage to do the right thing when it comes to setting Scrum Teams up for success and when working on tough organizational problems. They make choices and communicate them and the rationale behind them. This doesn’t mean always siding with Scrum or the Scrum Team or making the popular decision. It might mean decisions that will create some hardship for them and others in the short term but are the right decisions when taking the long view.
Respect — Leaders understand and respect the Scrum Team roles. They work with these roles within the Scrum accountabilities. Because the Scrum Team accountabilities do not directly map to the organizations job titles and structures this may require the leader to help smooth out any disconnects. Leaders approach the different Scrum events with respect to the work being done, the opinions being shared, and the rules of the Scrum process.
Leaders should be open about the work, the challenges in the work, and the process/structural/transformational challenges. They should have the courage to share with other leaders and teams, in a transparent way, what the challenges are. They should be committed and focused on addressing these challenges. They should proceed with respect to the rules of the Scrum framework and the space the Scrum Team needs to thrive. Serving a Scrum Team requires a delicate balance. In some cases you need to teach/mentor. In other cases you need to let things be and actively do nothing. In some other cases you need to proactively work with the Scrum Team on the issue.
This provides an environment where leaders are demonstrating transparency and the values of Scrum and also by showing these challenges it provides an opportunity for others to provide insights and solutions.
In summary, The Scrum Values of Focus, Commitment, Courage, Openness, and Respect all correlate to an environment that enables Trust, Empiricism, and Self-Management that in turn support innovation and value creation.
Creating a culture that thrives upon the Scrum Values is a tough mission. A key issue is that inspecting and adapting the culture is hard when the culture isn’t very transparent. Scrum helps by making the culture and context painfully transparent. Leaders should pay close attention to the tensions that Scrum highlights between its empirical self-management approach and the current organizational culture.
Addressing these tensions becomes a key leadership role.
One additional way Leaders can communicate the importance of the Scrum Values is to start by applying the Scrum Values of Openness, Courage, Focus, Respect, and Commitment to their work and interactions with others — including but not limited to the Scrum Team. For example, when presented with an opportunity to be focused they should call out that they are following the value of ‘focus’ and then describe its use. By constantly re-enforcing the Scrum Values and providing context they become role models for the Scrum Teams.
There are some situations where Leadership teams become Scrum Teams — in these situations, this helps the leaders understand and model the Scrum behaviors and activities as well as helping them use Scrum to implement Scrum. Introducing Scrum is a complex problem which is a perfect context to use Scrum.
Each situation is different which requires Leaders to apply Scrum in a different way, however ultimately leaders are accountable for creating an environment where Scrum thrives and teams leverage empiricism and self-management to solve complex problems and create value.
Scrum Team
The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers.
Scrum defines some boundaries for the exercise of figuring out Scrum Teams. Scrum Teams have a certain effective size. A person should ideally be on one Scrum Team. Each Scrum Team should be committed towards one Product Goal.
While the Scrum Guide does not explicitly talk about anyone outside of the Scrum Team, Scrum assumes organizational leadership and support.
Leaders have the role of leading the process of creating and nurturing a portfolio of Scrum Teams that execute the organization’s strategy. They have to courageously choose which areas to focus on and set concrete Product Goals to organize the Scrum Teams around.
Leaders will need to bridge the gap between the current organizational capabilities and the strategic needs. They’ll need to have open conversations with the right people about the options and implications. They will have to apply some pragmatic choices while committing to working to close strategic gaps.
They need to learn about the different accountabilities on the Scrum Team, figure out how to map them to different roles and people in the organization, and model/support the behaviors that lead to success with Scrum.
Developers
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.
Developers are not necessarily software developers. The Scrum Guide refers to Developers as anyone responsible for developing a valuable Increment. This can include business analysts, testers, marketers, project managers, or anyone else.
Leaders should figure out how to identify the right set of Developers that together have all the skills necessary to create and deliver valuable Increments towards the Product Goal.
When identifying Developers for Scrum Teams there are a number of tensions that will become evident. These tensions include:
Creating a team that has enough skills to deliver value — Minimizing dependencies on people outside of the team while being small enough to have effective collaborations.
Managing Specialists — Many organizations encourage and reward people who are specialists in a particular skill set or domain. A Scrum Team needs to be focused and include all the necessary skills to deliver value. Deciding where to put specialists is a key decision made by leaders.
Managing ‘Resources’ — Scrum encourages organizations to think of people as people rather than resources and encourages stable teams. However many organizations apply the mindset of resource optimization and treat people as interchangeable parts. A Leader will have to spend time managing this disconnect.
Dependency Management — There is never an ideal Scrum Team and it will always require help and support from other teams or service departments. The Leader’s job is to ensure that the right compromises are made and when presented with opportunities for improvement as the Scrum Team operates to be able to make changes.
Addressing these tensions will require some tough choices as well as the investment of time/money with a mid/long-term perspective.
Product Owner
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.
Identifying the right Product Owner is a crucially important Scrum design decision that Leaders of the organization need to think through. As the Scrum Guide states “For Product Owners to succeed, the entire organization must respect their decisions”. That typically means a certain level of seniority. This must be balanced with the Product Owner having the time to focus on supporting the Scrum Team. Even if these “just right” Product Owners exist in the organization, the Leader might struggle to get them to be available and interested to become a Product Owner.
Product Owners should ideally be entrepreneurs caring deeply about the product and its customers (internal or external). If it’s hard to find a Product Owner it might be a signal to inspect whether the Scrum Team is organized around a real Product. Identifying Products (whether they are real Products or other valuable internal/external services) is a key leadership exercise. It is tempting to skip it and just organize Scrum Teams around the existing organizational structure rather than “rocking the boat”. Leaders that want to maximize the benefits they get from Scrum and Product Ownership have the courage and willingness to reflect openly on how their organizational structure aligns with their strategy and vision and are committed to organizing around products and value.
Scrum Master
The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.
“Scrum Masters are true leaders who serve the Scrum Team and the larger organization”
The effective Scrum Master combines a facilitator, coach, teacher, mentor, change agent, and impediment remover. Helping everyone means also being available to Leaders and Stakeholders.
In reality, we more often find Scrum Masters that act as scribes/secretaries/clerks for their teams, admins, project or people managers, heroes taking all the burden of delivery on their shoulders, or the Scrum police. They struggle to coach the organization and its leaders/stakeholders whether because of their abilities/experience or how they are perceived/positioned.
The Scrum Master role is a unique one that doesn’t map easily to current organizational structures or areas of expertise. Most environments and cultures struggle to cultivate effective Scrum Mastery or leaders who serve in general.
Leaders have the role of identifying effective Scrum Masters for their teams that would be respected and listened to at the team and organizational level as trusted advisors/partners.
The Scrum Master is accountable for the success of Scrum within the Scrum Team. That success relies on the right culture/environment which requires partnership with Leadership.
Leaders need to be open to feedback/coaching from about their behavior and their organizational choices. They need to commit to working with the Scrum Master on addressing systemic impediments that limit the team’s potential.
Leaders should consider the following when working with Scrum Masters:
Career path — Scrum Master isn’t necessarily a career path. It’s an accountability that requires certain competency. Having said that, Leaders looking to find great Scrum Masters for their teams need to figure out as well as provide transparency to how being a Scrum Master would support people’s career growth.
Reporting Structure — Setting the Scrum Master up for success means figuring out a reporting structure that enables the Scrum Master to be honest and open with minimal risk of repercussion. For example, If the Scrum Master reports to the Product Owner it might make it hard for them to be honest and open about their challenges. If they report to the same people as the Developers there might be a lack of understanding for their role. A Scrum Master that’s outside of the Scrum Team’s reporting structure coming in as either an internal or external “consultant” provides certain benefits but carries certain disadvantages as well. Finding the right reporting structure is difficult and depends on both the situation and the people in the role. Leaders apply empiricism to figure out this complex problem. This means trying out a certain pattern, inspecting its impact, and amplifying or pivoting away as needed. The fact that these “experiments” involve human beings makes them even more complex and sensitive.
Measurement — By putting in place the right measures a leader can clearly define what outcomes they are looking for, but deciding the right measures is often difficult and can become political.
Title — There is much debate in the industry as to what job title is held by a Scrum Master. The Scrum Guide describes Scrum Master as an accountability highlighting that the job title will depend on the organization. For many organizations, Agile Coach may be the right job title. Deciding on the job title helps set the scene for the role and helps with recruiting. But more important to the actual title is the reasoning for the title.
Teams Supported — Depending on the maturity of the teams, the complexity of the problems they are solving or the constraints of the situation the Leader must decide on how many Scrum Teams the Scrum Master supports. Leaders in many cases face the tradeoff between having a few passionate and effective Scrum Masters covering multiple teams, versus having a Scrum Master for each team that is also a Developer on that team and sees Scrum Mastery as their secondary accountability. Again, no clear choices here, but aim to have Scrum Masters who are passionate about Scrum Mastery and see it a key part of their career journey.
Employment Status — Each situation is different but making decisions about if the Scrum Master is better served as an external contractor, or an internal employee requires some level of thought and choice. Both approaches have merit. Think of the courage the Scrum Master might have to “speak to power”. The openness people in the organization and team would have to listen to their ideas. The commitment the Scrum Master would have to the team and the organization. The respect they would garner from the Product Owner, Developers, Leaders, Stakeholders. And how much they will be able to focus on helping the Team.
Where Scrum Masters come from — Often organizations naturally think that Project Managers should be the place Scrum Masters are recruited from. Project Management is a different, somewhat overlapping set of skills that may or may not house good Scrum Masters. Leaders should understand the Scrum Master accountability and open a wide aperture to find the right people for the role wherever they are in the organization. Sometimes, the right Scrum Master for the job is found by looking at the mirror…
Whether the Leader chooses to be a Scrum Master or not, they should draw upon the accountabilities, skills, and stances of the Scrum Master. By doing this they can better serve the team and the larger organization.
Scrum Events
Leaders should understand and serve the Scrum Events. Serving their teams can mean participating in an event and providing feedback or creating the conditions for a successful event (without participating, or sometimes even BY not participating). Leaders also serve their teams and stakeholders by considering the whole suite of events that take place in the organization and sometimes consolidating/eliminating non-Scrum events.
The Sprint
This is the fundamental structure that all work is done within. Sprints enable predictability and empiricism. Leaders should help their teams balance the risk of a long Sprint Horizon with the overhead and stress of too-short Sprints. During the Sprint Leaders help protect the team from distractions.
Sprint Planning
Sprint Planning is where the Scrum Team collaboratively plans their Sprint based on priorities set by the Product Owner. The Scrum Team discusses 3 topics — Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done? The Scrum Team commits to a Sprint Goal and provides a Sprint Forecast.
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
As Stakeholders, Leaders don’t usually participate in Sprint Planning (unless they are also members of the Scrum Team). They are welcome to work with the Product Owner to influence the direction of the Scrum Team while supporting the Product Owner’s vision and Product Goal before and after Sprint Planning.
Leaders use the transparency of the Sprint Goal and Sprint Backlog to gain an understanding of where the Scrum Team is focusing and what to expect to see in the Sprint Review. They should avoid diving into the details of the Sprint unless the Scrum Team asks for help. Often Leaders find it hard to leave the Scrum Team to work as they see fit and often ‘offer’ help. Help can be perceived as managing the Scrum Team, which ultimately will discourage self management.
The Sprint Plan is a forecast provided by the Scrum Team. There is a tendency to assume this commitment is then used to judge the Scrum Team. Leaders should avoid this, as the more complex the work the more uncertainty exists. The commitment is for the Scrum Team to do their best to deliver the Sprint Goal, or to learn if this goal is unachievable.
Daily Scrum
The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. It is a 15-minute event for the Developers of the Scrum Team … If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
Leaders generally don’t participate in the Daily Scrum. Any participants that aren’t involved in the work of the Sprint are considered a distraction. The people doing the work should focus on the work and solving problems rather than providing status updates or posturing. Leaders should help the Scrum Team with removing impediments rising out of the Daily Scrum that require their involvement.
Sprint Review
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The success of a Sprint Review is determined by who’s there and how they show up. Leaders can help the Scrum Team get the right people to the Sprint Review and coach stakeholders in what’s the effective way to behave in this very valuable opportunity to Inspect and Adapt the direction of the Scrum Team and the Product.
In some cases the Leader will also be a real stakeholder themselves and this can provide them with the key opportunity to inspect how the team is doing and engage with them directly. This is also an opportunity to demonstrate the values that Scrum encourages such as Openness and Respect.
Leaders have a role in making sure that Stakeholders understand the scope of their influence in the Sprint Review and the fact that it is a feedback meeting. The Product Owner might (or might not) adapt the Product Backlog based on the discussion in the Sprint Review.
Sprint Retrospective
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
While the Leader doesn’t participate in the Sprint Retrospective they can serve the Scrum Team by helping them implement improvements that span beyond the Team’s scope of control or even owning such improvements. The Leader can create an environment of continuous improvement that will encourage the Scrum Team to invest in improving how they work.
The Leader’s role in the Scrum Events
The Leader’s role isn’t necessarily to be IN the Scrum Events. Their main role is to create the conditions for successful Scrum Events and to serve the team by being interested in the feedback and insights generated.
Leaders enable the team to have a Sprint Planning event in which they are empowered to figure out a realistic and sustainable Sprint Goal. They gain an understanding of direction via the Sprint Goal. This enables them to communicate with other stakeholders about the work of the team. (as they might be expected to do).
Leaders don’t participate in Daily Scrum and don’t need to actively inquire about what takes place in them either. The Scrum Team will reach out to the Leader if there’s an impediment that requires their involvement.
Leaders can participate in the Sprint Review as a Stakeholder, gain visibility to where the Product is based on the Increment, and provide feedback that will be considered by the Team and the Product Owner (but not necessarily adopted as such). They have an even bigger role in enabling an effective Sprint Review by working with other stakeholders to create an environment of empiricism and respect/self-management.
Leaders serve their teams by helping them implement improvements that span beyond the team’s scope of control. They might take ownership of such improvements. They create the cultural conditions where continuous improvement work is a first-class citizen in the organization’s work plans and capacity allocations.
Scrum Artifacts
Scrum’s artifacts represent work or value. They are designed to maximize the transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured:
For the Product Backlog, it is the Product Goal.
For the Sprint Backlog, it is the Sprint Goal.
For the Increment, it is the Definition of Done.
These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.
Leaders use the Scrum Artifacts as a window into the work of the Scrum Team. This transparency enables inspection and adaptation at the appropriate level while enabling the team to self-manage.
Product Backlog
The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
The Developers who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Leaders respect the accountability of the Product Owner for the Product Backlog. The Product Owner will work with Leaders as stakeholders. They will make sure the Product Backlog is available and clear. The Product Owner and Scrum Team will be open to ideas from Leaders and other Stakeholders and will also have the courage to remain focused.
Commitment: Product Goal
The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract. The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.
Scrum Teams are formed to execute the organization’s strategic decisions. Each Scrum Team’s Product Goal is a key mechanism to ensure this strategic alignment. Leaders are responsible for ensuring that the right conversations take place between Scrum Teams and their strategic stakeholders around the progress made towards the Product Goal and its relevance. Agility at a strategic level relies on the ability to inspect and adapt Product Goals and adjust course as needed.
Sprint Backlog
The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).
The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal. Consequently, the Sprint Backlog is updated throughout the Sprint as more is learned. It should have enough detail that they can inspect their progress in the Daily Scrum.
The Sprint Backlog should not be used as a mechanism to control/manage the Developers on the Scrum Team or as a status reporting dashboard.
Leaders should respect the Developers ownership of the Sprint Backlog and give them space to self-manage their work within the Sprint. They should avoid treating the Sprint Plan as a tool to manage the Scrum Team. The plan is for the Scrum Team and enables leaders to provide feedback.
Commitment: Sprint Goal
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
Leaders can use the Sprint Goal as a window towards the Scrum Team’s focus and commitment for the Sprint and should help the team achieve their Sprint Goal if the team reaches out for help.
Increment
An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.
The ultimate accountability of the Scrum Team is to make incremental progress towards the Product Goal or to learn that is not possible and either reframe the Product Goal or focus on something else. Leaders need to work with the Scrum Team to help them make progress often in spite of the environment that they are working within. They need to support the Scrum Team to work within the technical and procedural and cultural confines of the organization.
Commitment: Definition of Done
The Definition of Done is a formal description of the state of each Sprint Increment when it meets the quality measures required for the product.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.
The Definition Of Done makes what it means to be done transparent. It provides a mechanism to clearly communicate what it means to make progress, incrementally towards the Product Goal and therefore deliver value. It often provides a great way for the Scrum Team to set expectations with external groups. Leaders work with Scrum Teams to create and improve appropriate Definition of Done standards for the organization. Improving the organizations’ Definition of Done is a mechanism Leaders can leverage to raise the level of quality, professionalism, and transparency while letting the Scrum Team/s self-manage. Leaders provide support for Scrum Teams that are striving to achieve a more complete Definition of Done.
I’m encountering more and more people that are trying to solve different kind of problems with Scrum:
People designing Consumer Goods
Accounting professionals focused on Revenue Accounting
Marketers of many kinds
Healthcare professionals.
I’ve been having some interesting discussions with them that I thought I might share.
One of the key questions I start a conversation about Scrum with is Why — Why do we need Scrum? What problems are we looking to solve with it?
Next we typically explore Where/When — Where would it make sense to use Scrum? When would it or wouldn’t it?
One thing to remember is that Scrum was designed to help people solve complex problems, not all sorts of problems. What does this mean exactly?
Let’s look at a couple of examples of Complicated processes that might not need Scrum/Agile
Accounting teams run several sorts of processes — like Closing (the month, quarter, year), Reporting, Accounts Payable, Accounts Receivable.
Healthcare professionals treat patients. Whether it is an emergency room, an orthopedics clinic, or a covid19 testing provider.
Should we use Scrum for Operational Processes?
These might be complicated processes but they aren’t typically complex. Lots of steps, lots of work they need to be careful and diligent about, but it’s not something they need Agile for on an ongoing basis.
Hopefully, these operational processes are stable and predictable. If they’re not, we have some work to do. We need to get rid of variability and surprises.
We can use Scrum for Improving operational processes
Where Scrum IS often useful is in the process of continuously improving these operational processes. We know how to run the current process predictably. But once we decide to improve it, this might be a problem we have more uncertainty about — what does better look like? What will/won’t work? How do we go about implementing it?
What we find in many contexts is that people call these improvements “Projects” and its one of the areas they struggle with. Beyond the classic challenges of complex work, we see many cases of teams working on improvement projects that are based on people who also work in the operation. (for example an A/R professional working on a project to improve A/R or a physician participating in a project to implement electronic medical records software). These teams working on improvement “projects” struggle to focus. As we all know, Allocating capacity to improvement is hard. And switching contexts between the day-to-day operation and improvement work is hard as well.
Scrum helps these teams optimize the value they create through their improvement work.
Their “Product” is an improved operation that achieves better outcomes for their stakeholders while making life easier for themselves and their peers.
We want the entire company to be Agile
We hear that more and more. As you can imagine, based on the above, I think we need to be careful and apply the right tool in the right context. Agile approaches make sense in many contexts, and most companies would benefit from applying them beyond software development/technology/IT.
Identifying the different “Operational” flows in the organization and the various “Development/Improvement” activities that work to improve them is a great way to drive a discussion with a company or a leader exploring Agile/Scrum all over the company.
In Summary — Scrum for Improving Operations, not necessarily Scrum for Operations.
This distinction between the ongoing “Operations” where we don’t necessarily need Scrum or Agile, and “Development” or “Improvement” work that aims to improve “Operations” helps people outside of software/technology/IT relate and buy in to Scrum or other Agile approaches. Scrum/Agile are typically a better fit for working ON business operations, versus working IN the business operation.
I’ve been asked several times now about Nexus and SAFe — what are the similarities, differences, etc. If you’re not familiar with either Nexus or SAFe I recommend taking a look at the Nexus Guide and the SAFe whitepaper first.
Nexus and SAFe — Similar Concepts
Let’s start with similarities — There are quite a few of them as you can see:
Nexus — ART
The Nexus group of teams is very similar to the Agile Release Train (ART) construct. In both SAFe/Scrum it is a self-managing team of self-managed teams with a couple of key roles at the team of teams level.
Following the principles of Empiricism, Self-management within constraints, organization around value, and flow.
Scrum theory emphasizes Empiricism and Self-management, coupled with Flow in recent years. SAFe’s theoretical base is more verbose but essentially similar.
Lean/Agile Leadership
Both SAFe and Scrum/Nexus emphasize the need for a different style of leadership — leaders who serve, have a growth mindset, lead by example, live and breath Lean/Agile principles and practices, and strive for relentless improvement.
Sprint — Iteration
SAFe chooses the term Iteration which is more reminiscent of Extreme Programming (XP) but looking at the details Sprints and Iterations are quite interchangeable. PS Some people feel the term Sprint isn’t the best choice if we want to emphasize “sustainable pace”.
One Product Backlog — Program Backlog
Nexus emphasizes that for one Product there should be one single backlog — the Product Backlog. While SAFe has multiple Team Backlogs for teams working together on a product, it does have the concept of the Program Backlog which serves a similar purpose to the Product Backlog.
Nexus Integration Team (NIT) — System Team
Both of these have a similar goal — enabling an Integrated Increment at the end of each Iteration/Sprint across the teams. When it comes to how these teams operate Nexus emphasizes the coaching/enablement role while SAFe has a bit more of an emphasis on the actual Integration work. The NIT approach should be a very interesting practice to consider on a SAFe ART / System Team.
Scrum Master in the NIT — RTE
The Scrum Master in the NIT has a role similar to the Release Train Engineer — orchestrating and facilitating the effective use of Scrum/SAFe across the Nexus/ART with the purpose of enabling a tight Inspection and Adaptation cycle leveraging working product increments.
Empiricism via working integrated increments every Sprint — System Demo & Nexus Sprint Review meeting a common Definition of “Done”
Both SAFe and Scrum make it very clear that frequent inspection and adaptation of working integrated increments are key to managing the uncertainty/variability inherent to product development in the complex space. The Nexus Sprint Review and the System Demo are similar events happening on a similar cadence — every several weeks (Sprint/Iteration)
Nexus Sprint Goal — Program PI Objectives — just at different cadence/frequency
Program PI Objectives serve a similar purpose to the Nexus Sprint Goal — a steady North Star goal for the Sprint or set of Iterations to focus on while the details might shift around.
You cannot scale crap — Scaling requires technical excellence
Both Nexus and SAFe emphasize building quality in and the importance of XP-inspired technical practices in order to effectively scale. Without the technical excellence, both SAFe and Nexus would drown in technical debt.
Important Differences
Nexus — ART
Didn’t I just say The Nexus is similar to the ART? Well, God is in the details…
A Nexus is approximately 3–9 Scrum Teams working together. An ART is approximately 5–12 teams working together. This seemingly minor change provides some insight into some of the design choices of the two frameworks. A smaller Nexus can be easier to provide Product Ownership for, making the “Single Product Owner” a more viable choice. Nexus-level events are easier to facilitate/orchestrate than whole-ART events, provide some insight into why SAFe only brings the whole ART together every PI, not every Sprint.
For larger teams of teams working on a single product, there’s Nexus+. Nexus+ is comprised of several Nexus. The “Organize around Value” challenge both for Nexus+ as well as the SAFe ART is to figure out what set of teams need to closely coordinate and collaborate.
One Product Owner vs Product Ownership/Management Team — PM/POs
SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities.
Nexus has Product Owner for the entire product. In real life, these Product Owners are typically accountable for the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale.
As we emphasize in Scrum.org Product Ownership training, Benefits from Scrum are quite limited if your Product Owners are Scribes or Proxies. It might be easier to coordinate meetings and get time with the Product Owner but its harder to maximize value. Benefits grow when the Product Owners are real business representatives, sponsors, or ideally entrepreneurs for their Product.
What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. Striving towards real product ownership and what it looks like within a SAFe ART is a key topic when I’m helping an ART “Organize around Value”. Similarly to the Feature/Component team discussion, there isn’t a single best-practice here. You need to apply Systems Thinking and look at the different options, and relentlessly improve.
Cadence/Frequency of bringing the whole Nexus/ART together for Planning and Retrospection
The Nexus reviews, retrospects, plans, and refines together every Sprint. That doesn’t mean the WHOLE Nexus gets together every Sprint though. Typically, Sprint Review has quite a wide attendance including Nexus stakeholders. Refinement, Planning and Retrospective is attended by the appropriate representatives of the Scrum Teams. What’s appropriate is a matter of context of course.
In SAFe, the only ART-level Iteration event is System Demo (which as we discussed is very similar to the Sprint Review). There’s no formal place for the ART to Plan/Refine/Retrospect across teams on a Sprint by Sprint basis. Having said that, The ART Sync provides an opportunity to inspect and adapt throughout the ART that many organizations use to Plan/Refine/Retrospect.
The formal cross-team Retrospection/Planning cadence in SAFe is the Program Increment which is explicitly a whole-ART event.
No team-level Sprint Review
Nexus only has one cross-team Sprint Review. On paper, SAFe has both the Iteration Reviews at the team level as well as the System Demo at the ART level. In reality, many ARTs skip the Iteration Reviews and get enough inspection and adaptation from the System Demo.
Scope — Team of Teams vs organizational-level
Nexus focuses on just the team of teams — what is considered the “Essential” configuration in SAFe. SAFe also covers other competencies needed for Business Agility — Lean Portfolio Management, Large Solutions. Some organizations using Nexus end up looking at SAFe’s Portfolio-level competencies or Portfolio Kanbans to complement Nexus.
Integrated Nexus Sprint Backlog vs various team iteration backlogs
A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. This doesn’t explicitly exist in SAFe and should be considered by ARTs that want to highlight dependencies and the flow of work during the Sprint across the ART. It can be seen as a Sprint-level version of the “Program Board”
Program Kanban
SAFe includes one of the most powerful techniques to help improve flow and collaboration across a team of teams — a Kanban Board that takes a cross-team perspective. I started using this technique back in 2009 and it’s one I “don’t leave home without”. Nexus doesn’t include a Nexus-level Kanban board but it’s a very nice complementary practice to consider. Read more here
Other potentially useful elements of SAFe that aren’t covered in Nexus
As Nexus is designed to be a lightweight framework, with a more limited scope than SAFe, its not surprising that there are a lot more elements in SAFe that Nexus doesn’t say anything about. Some of these can be useful in your context, some not necessarily. Think Architectural Runway, Innovation and Planning iteration, Team-level Kanbans, DevOps, Continuous Delivery pipeline, System Architect, Business Owner, Features/Enablers, Epics.
Some ideas for Improving SAFe inspired by Nexus
I hinted at some of these above:
Retrospect and Plan together across the ART every Sprint/Iteration
Don’t just review together every Sprint. Also retrospect and plan together. It doesn’t mean bringing the whole ART together necessarily. It just means creating some alignment across the ART before splitting off and doing Iteration Planning at each team and then coming back together. Sort of like the pattern Solution Trains use when they do PI Planning.
Use an ART-level Sprint Backlog
Similar to a Program Board for the PI, use an Integrated Nexus Sprint Backlog to look at dependencies at a more granular Sprint/Iteration level. This is an artifact that can support ART-level Iteration Planning
Some ideas for adding to Nexus inspired by SAFe
Use “Big Room Planning” every 8–12 weeks
Follow the SAFe PI Planning format for higher-level alignment/refinement once in a while across the Nexus.
Adjust Cadences and level of participation
Figure out what level of “big room” whole Nexus together makes sense every Sprint and what can fit a less frequent cadence (e.g. a PI) — Look at how you run the Nexus Sprint Planning, Retrospective specifically.
Get inspiration from the SAFe Lean/Agile Principles and Competencies
Looking at the SAFe Principles and complementary Lean/Agile competencies like Lean Portfolio as a way to support the Nexus within the traditional ecosystem in the organization. One specific technique you can use is to look at the “Measure & Grow” Business Agility assessments that are included in SAFe. Each category or item could be something you’re already doing (great!), something that you aren’t doing yet but makes sense to consider (also great!), something that doesn’t make sense in your context (fair enough), or something that you disagree with vehemently (totally acceptable as long as you’re looking at each principle/technique at its merits…). This exercise could create an improvement backlog/roadmap.
Conclusion — Options are good, Tunnel vision is bad
As professional agile practitioners we should be curious and open to new ideas. It helps to get exposed to different scaling frameworks — it gives us a better understanding of the one we’re proficient in and using, as well as provides some more ideas we can consider experimenting with. In our work with clients we try to steer them away from dogma and tunnel vision. Yes, learning multiple scaling “languages” can be confusing. (You know what I mean if you have a toddler in the house learning to speak when there are multiple languages spoken around them…) but I think it’s totally worth it. As SAFe principle #3 says “Assume Variability, Preserve Options”.
Get in touch with me if you’re interested in figuring out how Nexus can complement your SAFe implementation or vice versa.
What does Scrum Product Ownership have to do with Dinosaurs?
We typically say that Scrum Masters get to herd cats. But Scrum Product Owners actually need to learn how to ride a Dinosaur! With the click-bate established, what does that even mean?
I’ve been using a visualization that people find useful for understanding the relationship between the various Lean/Agile requirement containers. Some people call the full model a dinosaur. Others are reminded of the snake who ate an elephant from “The Little Prince”. (I’m sure there is a good connection to elephant carpaccio somewhere in here …). In this article, I’ll explore this model and connect it to the stances of the Scrum Product Owner.
Identifying a Unique Value Proposition
A lot of teams and organizations expect their Product Owners to be a mix of the Story Writer, a Backlog Manager, Project Manager, Subject Matter Expert, or a GateKeeper. Sometimes they’re even asked to be a requirements Clerk. These stances can be easier and familiar but when these are the expectations and when this is the stance that the Product Owner assumes, It’s hard to deliver value with Scrum.
In the PSPO-Advanced one of the first preferred stances, we talk about is the Visionary. The Product Owner as an entrepreneur. This vision will be based on customer and market insights. As a Customer Representative, you’ll use techniques such as Design Thinking, Empathy maps, Value Proposition Canvases, and Jobs to be Done to create a vision that’s grounded in understanding the customers. You’ll identify a Unique Value Proposition — the area where your product/service will be unique.
The Minimum Viable Product (MVP)
Very quickly even while assuming the stance of the Visionary, you need to also wear the Experimenter hat and that’s because this Unique Value Proposition is just a hypothesis that needs to be validated. So the next step is creating a Minimum Viable Product (MVP) to test your hypothesis. This is focused on your unique value proposition but typically also provides a little bit of “Table stakes” features just to make sure it is “Viable” as a product.
Evaluating your MVP Hypothesis
Your MVP is also a hypothesis. It might be good enough to find Product-Market Fit or not. The case where each potential customer you engage tells you “This is great but in order for me to use it I need X” and X is different for each customer/user is shown below. This shows you are not in a Product Market Fit yet.
At this point, you’ll need to be very careful not to fall for the trap of mistaking the Customer Representative for the Customer Order-Taker. The fact that potential customers are asking for something doesn’t NECESSARILY mean your product should include it. It’s ok to evolve your vision for the product based on validation but saying YES to everything even if it’s all over the place is probably not gonna create a great product. These will be tough decisions but an effective Product Owner is also a Decision Maker (also known as the Tough Decisions Maker…)
Pivot?
If on the other hand, you are seeing more and more requests for the same capability you didn’t include in your MVP then it makes sense to revise your Customer/Problem/Solution Hypothesis.
You essentially are executing a Pivot. You are building MVP2 focused on the new hypothesis based on recent Customer Development learning generated by the previous MVP.
Growth Stage
Let’s say MVP2 is successful and you are seeing real traction of early adopters. You want to increase growth and are looking for deeper penetration of your early adopters as well as bringing on new clients some of them beyond the early adopter’s crowd. Based on feedback you’ve been collecting and your product management research you have a couple of areas that can potentially bring this growth. Some of them, by the way, extend your unique value proposition and some of them make your current product more robust. As your product grows, your team and ecosystem will grow. You’ll need to assume the Product Owner as Collaborator and Influencer stances as well — working with new stakeholders, partners, a larger team, and maybe multiple teams working with you on the same Product via the same Product Backlog.
Steady Growth with Minimally Marketable Features
In the case of areas with a strong indication of value, you might go straight for Minimally Marketable Features (MMF). Finding the minimum piece that can start bringing in growth. The aim of the MMF is to bring in value. It assumes high certainty that there is value in this area and that we know what the product needs to be to provide this value. The reason to break a big feature into smaller MMFs is mainly time to market and the ability to bring in value in many areas, always keeping your option to move to another area and provide value in it rather than focusing for too long on a single direction. An indication that you are working on MMFs is that when one is being shipped you feel comfortable working on the next MMF in that area.
As the Visionary Product Owner, You’ll continue to provide and communicate an updated Value north star for the Product. You’ll be a Customer Representative who is also a Decision Maker for which direction it makes sense to focus on and when does it make sense to move on rather than continue to invest in an area where you’re seeing diminishing returns.
Experiment using MVFs
Even with an established product sometimes you remember that a Product Owner is an Experimenter. Sometimes it’s not clear whether a feature really is marketable and valuable. In these situations, your hypothesis is centered on a feature rather than your product. You have an area with high potential but also high uncertainty. The way to deal with it is to build a “pioneering” feature — the Minimum Viable Feature. The minimum feature that can still be viable for real use and learning from real customers.
If you learn that the MVF has hit gold you can develop more MMFs in that area to take advantage (if that makes sense). If not, you can pivot to another approach towards that feature area, or at some point look for alternative growth path. Essentially the MVF is a mini-me version of the MVP.
Voila — The Scrum Product Ownership Dinosaur!
There you have it. The full model. Essentially my point is that you grow a product in uncertain markets by attempting various MVPs. Then once you achieve Product-Market Fit you mix MMFs and MVFs depending on the level of Business/Requirements uncertainty in the areas you are focusing on.
While MVPs/MMFs/MVPs are atomic from a business perspective (you cannot deploy and learn from something smaller) they might be quite big from an implementation perspective.
If your organization positions you to be a Clerk, Story Writer, Manager, Project Manager, SME or GateKeeper you won’t get far trying to ride this dinosaur.
You’ll have a much better chance if you can switch between being Visionary, Collaborator, Customer Representative, Decision Maker, Experimenter and Influencer — the effective stances of the Scrum Product Owner (Which we cover in the PSPO-Advanced workshop)
Authoe’s Note: This blog post is an update of an article I wrote ages ago — weaving in the Product Owner stances which are a perfect fit in my opinion. Yuval
SAFe includes Scrum — so how come many Scrum practitioners and thought leaders consider it unsafe?
The Scaled Agile Framework (SAFe™) is one of the most popular approaches to applying agile at scale out there. SAFe’s perspective is that “Nothing beats an Agile Team” and it doesn’t try to reinvent the wheel or even innovate too much when it comes to the Team level. It takes advantage of established frameworks and techniques that work well — Scrum being the first and foremost of those.
Where it starts to get interesting (unsurprisingly) is when the patterns and practices for scaling are introduced — in SAFe’s Program Level. SAFe’s premise is that in the real world one team typically isn’t enough and several teams need to work in concert to build larger systems/solutions/products. In SAFe’s Program Level, a key piece is the Agile Release Train which is considered a team of Agile teams.
When it comes to the Program level SAFe doesn’t try to reinvent either — but here it uses Scrum/Kanban as a starting point and innovates in order to deal with some specific challenges of larger programs. SAFe also deals with Larger Solutions and the Portfolio, but let’s leave those out of the scope of today’s discussion.
The above intent, together with the fact that SAFe uses the Scrum Guide as its reference to what Scrum is, are encouraging signs. So, again, why do so many Scrum practitioners, trainers, and thought leaders consider it unsafe and a Scrum-but? I hear a lot of questions and claims. Let’s try to recreate some of these discussions and along the way make some recommendations?
Looks like SAFe’s Scrum Master is a coordinator and focal point for the team — not just a servant leader and coach accountable to enacting Scrum.
Yep. SAFe’s Scrum Master is more of an Agile Team Lead. This is much easier to implement in the real world but also means it will be much harder for the team to self-organize because they have a team lead that isn’t just focused on helping them improve via Scrum but is also their focal point for Scrum of Scrums, during PI Planning, etc.
The way I look at it — this is indeed a compromise that SAFe practitioners should be aware of. And part of the journey of implementing SAFe should be to maybe start with this Scrum Master stance but evolve towards more of the classic, professional Scrum Master stance over time. To use the leadership styles model we discuss in the Leading SAFe class — the starting point is more of an orchestrating and technical expert kind of leadership stance and the goal should be to evolve towards a more serving the team and the process style over time.
The main concern I have is not that SAFe’s Scrum Master is different than how Scrum defines it. It’s that this difference isn’t made transparent — which doesn’t give practitioners the opportunity to inspect, think about it, and maybe adapt. Maybe your organization is actually better off with an Agile Team Lead than a Scrum Master. But you won’t have a chance to think about it and decide if you think you already have Scrum Masters.
SAFe’s Product Owner is a proxy, not a real Product Owner. They are more similar to a team member focusing on the stories than a person accountable to optimizing value delivered by a Product.
SAFe’s approach to product ownership is that scale is achieved by splitting the product ownership role between Product Management, which is more like the classic Scrum Product Owner, and the Product Owner, which is indeed more like a proxy or technical product owner working more closely with teams. One of the main reasons SAFe takes this path is that it’s hard for one Product Owner to deal with too many teams while balancing both outbound and inbound activities.
Large Scale Scrum and Nexus prefer to have one Product Owner for the entire product with one Product Backlog. In real life, these Product Owners are typically accountable to the value delivered by these multiple teams and rely upon a lot of assistance from the Development Teams in order to deal with the challenge of scale.
If we ignore the differences in lingo, This is quite similar to SAFe’s approach. But we can’t ignore the differences in lingo. We DO want to see Product Owners as individuals owning products and being accountable to optimizing value.
What I’ve seen in the trenches ranges from SAFe Product Owners that really own a product within the bigger solution, own a set of features or even a specific feature that is currently being developed, all the way to technical product owners that aren’t real product owners. There’s definitely room for more discussion of this continuum and the impact of it in the SAFe PO/PM body of knowledge (Similarly to the discussion of the Feature/Component team continuum).
Scrum is a simple framework that deals with complex domains. SAFe seems more of a methodology to Scrum practitioners as it has many more details and seems to try to solve all challenges in a prescribed way. SAFe’s creators seem to enjoy the fact that it is complicated since it provides an excuse for more and more training possibilities.
Well, the reality is that SAFe serves the mainstream market of practitioners that struggle to get from Scrum’s simple framework to an approach that works in their reality. Scrum simply doesn’t provide enough answers to some of the tough scaling challenges, and not everybody has the time or skills to come up with an approach that works in their context. This market needs some more guidance.
Looking at SAFe as it grows over time I see a constant struggle between the desire and drive to simplify and focus on the essentials to the desire to give more answers. Like any other product, it is tough to figure out which features/aspects to build, get rid of, simplify, and how to optimize the experience. It’s hard to create the ideal scaling framework.
Beyond how SAFe is defined, there’s also how people perceive it. And yes lots of practitioners prefer to see it as a Methodology rather than a framework. As someone teaching SAFe Program Consultants, I try to discuss it in my classes. (See a recent blog post I wrote about this)
SAFe’s Sprints are 3 months long and are planned in detail — How is that Agile?
Well, let’s unpack this. SAFe has a cadence at the Team and Program levels. The team-level cadence is called Iterations but other than that different name is almost identical to the Scrum Sprint. It is 2 weeks long, the goal is to deliver a potentially releasable increment of working software, There’s Iteration Planning, Daily Standup (which is essentially Daily Scrum), Iteration Review and Retrospective.
I’m guessing the confusion kicks in when people look at the Program Increment. That’s typically 8–12 weeks long and includes multiple Iterations (4–6 typically). Why don’t we just have a Program Increment that is at the same length of the team-level increment? Because from an economic perspective the transaction/coordination costs for running the whole program on a 2-week cycle don’t make sense. Think about having big room planning with 100 practitioners every two weeks. Kind of hard.
Why do we even need this big room planning in the first place? Now that’s another question. In situations where teams do have some dependencies, when we need a longer horizon business planning and we do want to involve everyone in having discussions about what is valuable, realistic, and converge on plans, big room planning comes to the rescue. Do we have to have these discussions every two weeks? probably not.
So the approach SAFe takes is to look at each one of the program-level activities and consider both the coordination cost/overhead as well as the holding cost or cost of delay and come up with the right frequency. For example, while Program Increment Planning happens only at the Program Increment cadence, System Demo, which is similar to the Sprint Review but at the program level, happens on the iteration cadence so every two weeks typically. Why? Because the cost of delayed empiric feedback is very high and we understand we live in an uncertain environment, we assume variability and we want to preserve the option to adjust course throughout the PI.
This is similar to the Scrum Planning Onion. Teams and Agile Release Trains plan at the Daily, Iteration, and Program Increment levels. The deeper in the onion we are the more detailed we plan, but the shorter our planning horizon. So in Program Increment (PI) Planning we should plan for a longer horizon but at a much lower level of detail. Do a lot of SAFe practitioners plan the PI in too much detail, not leaving enough room for uncertainty and learning once we get to the Iteration and Daily planning levels? Oh yes. Does a lot of Scrum practitioners do the same thing for the Sprint not leaving enough room for uncertainty and learning throughout the Sprint?
Like the Sprint Goal guides the Dev Team in case they want to consider changing the Sprint Backlog, PI objectives help teams adjust course throughout the PI if it helps them achieve their objectives.
Bottom line, SAFe’s Program Increment and the way you plan it can be closer to “following a plan” or an agile basis for “responding to change”. I certainly see it and teach it as the latter.
SAFe focuses on predictability much more than it does on empiricism and value discovery
SAFe actually tries to balance business agility with predictability. Both of those are important to the typical enterprise-scale technology organization.
SAFe includes mechanisms such as PI Planning, Roadmaps, forecasts, PI Objectives, confidence votes to provide predictability. It includes Stretch PI Objectives, The Innovation and Planning iteration and specific recommendations on how to plan in order to maximize predictability in face of variability and uncertainty.
It also includes System Demos, Continuous Integration, Minimum Viable Products, and others in order to deal better with uncertainty.
And there’s no assumption that predictability will be absolute. A program/ART that achieves 80% predictability is considered within a reasonable range. And this predictability is measured in achieving outcomes, not delivering stories or points. This supports agility of adjusting what features we deliver and how as long as we focus on achieving the outcomes the business is focused on.
SAFe allows you to defer integration and hardening to the end of the Program Increment
Not really. SAFe used to have a Hardening iteration but it’s been decommissioned for years now. The Innovation and Planning iteration is the place to take a breather, do some innovation activities that work better when you can clear your head and focus on them (Which doesn’t mean by the way that innovation isn’t allowed or needed throughout the PI), reflect on the current PI and plan for the next PI. integration and hardening is part of the definition of Done that each team strives for within every 2-week iteration. The System Demo that happens every 2 weeks is an opportunity to review the whole integrated system increment, get transparency for where you are, and inspect and adapt the plan for the rest of the PI accordingly.
What you could do about this as a SAFe practitioner/trainer
I wish more SAFe practitioners would dive deeper into the Scrum world as a step in their life-long learning journey. A self-respecting SPC should also have enough knowledge and experience with Scrum to pass at least some of the Scrum.org assessments. The same applies to people training SPCs. They should have a very strong experience with Scrum and Kanban. An advice to those planning to register to an Implementing SAFe class and become SPCs — verify your SPCT knows his/her Scrum and Kanban. Check if they have a PSM1/2/3.
On an ongoing implementation, one useful thing you could do is run a workshop reflecting on the Scrum Guide and what are some key gaps to consider addressing. I’ve done this in one of my larger financial tech clients and it was a pivot point in the implementation. We looked specifically at the Scrum Master and Product Owner roles, identified a lot of gaps and changed our perspective about these roles.
What you could do about this as a Professional Scrum practitioner/trainer
As an SPC Trainer (SPCT) and a Scrum.org Professional Scrum Trainer (PST) I’m committed to helping people understand and implement SAFe safely. It isn’t the only scaling approach I work with, but a lot of people seek me out when they do want to implement SAFe but want to keep to the true spirit of Agile/Scrum.
I’m glad to see more and more of my colleagues in the professional Scrum.org community that are interested in working towards better understanding of Scrum Theory, Values, Events, Roles and Artifacts in the SAFe world. After all, that’s what it means to be a community that shows respect, openness, and courage.
Since SAFe is so prevalent, I think this is a huge opportunity to improve the profession of software delivery.
