Yuval Yeret

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? 

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.

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. 

It's time to look at the Scrum Events In previous posts in the Scrum Guide for Leaders series we explored what Scrum means for Leaders, using the Scrum Values to create a Scrum-friendly culture, and how to effectively support the Scrum roles/accountabilities. Next, we turn to the Scrum events. Leaders should understand the Scrum Events, participate and not participate as needed. The Sprint The Scrum Team performs all work within Sprints. 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. Some Leaders use this commitment is judge the Scrum Team. You 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. In general, the Daily Scrum is just for people who are involved in the work of the Sprint. Others 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 should be in the background to support it. 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. Summary While Leaders aren't mentioned explicitly they can serve their teams by creating the environment in which effective Scrum events take place, with the right people and the right mindset. Without the Empiricism enabled by Transparency, Inspection and Adaptation on Scrum events, Scrum is but just a mechanistic theater. 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 even a 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. In addition, Leaders should look at other events they're asking members of the Scrum Team to participate in and experiment with how to minimize waste and duplication. Classic Status Meetings could be replaced more effectively by Sprint Reviews for example. In our final chapter of the series, we will turn to the Leader's role in enabling empiricism via the Scrum Artifacts. This article was originally published on AgileSparks.com

We started the Scrum Guide for Leaders series with a discussion of what Scrum means for you as a Leader. Next, we discussed the conditions where Scrum's Empiricism, Self-Management, and Continuous Improvement can thrive. We then explored some concrete examples of how adopting the Scrum Values as a Leader can help you create these conditions.

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.

If you’re leading Scrum Teams or generally are a leader in an organization that’s leveraging Scrum?

I'm encountering more and more people that are trying to solve different kind of problems with Scrum..

I'm hearing from more and more companies that are using the Entrepreneurial Operating System® (EOS®) and are also looking at or practicing Agile e.g. using Scrum. In discussions with these companies two key questions surface time after time: My teams want to use Agile/Scrum - is that aligned with the fact that we’re using EOS® in the organization? My teams use Agile/Scrum, can we use EOS®? The short answer is that Agile and specifically Scrum and EOS®are mostly complementary. EOS®, as well as Agile approaches, emphasize focus, alignment, a disciplined approach with structured events, artifacts, and policies that attempt to limit the amount of work in process (WIP) in a systematic way, and create better flow with cadence. So what’s one big thing that’s different about Agile/Scrum in comparison to EOS®? Transparency and Empiricism Transparency is emphasized in both but is used differently. Both approaches make the work transparent. Agile frameworks like Scrum are designed to deal with VUCA (Volatility, Uncertainty, Complexity, Ambiguity) through empiricism - an aspect which EOS®isn’t explicitly solving for. And in this environment Transparency goes much further - it is not just awareness of what the team and individuals on the team are working on - it is the transparency of whether the product of the team’s work (whether the team is building a product or leading a company) is working and effective. Scrum can help teams: align towards the Vision - making the Vision or a specific sub-aspect of it their “Product Goal” (even if they’re not a Product team - it’s the overarching goal for the product of their work - be it winning deals, operating the company, growing, etc. ) plan and deliver on their Rocks and achieve Traction®- by using Product Backlogs, Sprints, and potentially concepts like “Program Increments” from SAFe which align very well with the EOS®Quarter. EOS® Big Rocks can map almost 1:1 to PI Objectives. For teams, We recommend having them at the team level and not an individual contributor in order to drive collaborative collective ownership towards results. When scaling across the organization each team/function does have its own list of PI Objectives/Big Rocks like in EOS, as well as an organization-wide list of Big Rocks / PI Objectives. SAFe PI Planning or other types of Big Room Planning could complement EOS®Quarterly planning by involving the actual Teams and not just the function leads in the planning and accountability cycle. Issues are very similar to Risks and how they’re managed in SAFe via ongoing ROAMing (Resolving, Owning, Accepting, Mitigating) Scrum Sprints map to the Weekly Level 10 cycle. Sprint Review/Retrospective/Planning is an opportunity to inspect and adapt where we are within the quarter, which is especially important in VUCA We’re not just executing a quarterly plan. We’re intentionally learning what works/doesn’t and adjusting course accordingly. Another opportunity is to use Scrum at the leadership level - as a way to apply more empiricism to complement EOS®discipline. All of the above could be used by the leadership team itself. The “Product Backlog” is focused on the “product” of the leadership team’s work - which is leading the company - solving issues, growing, implementing strategies/tactics, etc. Changes in Process, People, Dealing with Issues, Advancing Rocks. The Increment of each Sprint is not just a “Done / Not Done” answer to to-do items - it’s an actual “working change” in how the company operates. (For example - list of candidates for a VP position, draft scorecard, analysis of desired profitability range, etc. ) This Increment is ready for the leadership team to inspect, review, with the goal of adapting their plans (Product Backlog) accordingly each and every Sprint/Week. A leadership team could also decide to run longer Sprints e.g. Monthly and use a weekly cycle similar to Scrum’s “Daily Scrum” to inspect and adapt progress within the Sprint. The Sprint length should match the level of VUCA the leadership team/company is facing. Leadership Team acts as the “Developers” of the “Product” The PO/SM Scrum roles could map several ways - Option 1 Visionary - Product Owner Integrator - Scrum Master Option 2 Visionary and Integrator™- Sharing the Product Owner role Dedicated coach/Scrum expert as the Scrum Master Similar to how EOS®starts at the top, Organizations NOT using Scrum yet could use Scrum to complement EOS® at the top level and then expand from there into the various teams. This would follow the guidelines/mapping described above. In this scenario, a solid Scrum Training/Coaching would be provided to the leadership team in advance of the whole organization and they would become Scrum Practitioners better able to understand as well as drive what’s going on when Scrum/EOS®gets implemented throughout the organization. For teams in an organization using EOS®… If you’re starting to use Scrum in an organization using EOS®or if you’re using Scrum and your organization is in the process of implementing EOS®the list of mappings above will help you create some common language and reduce the conflict/confusion that might arise due to running both EOS®and Scrum at the same time. Real/Imaginary conflicts between Scrum and EOS® Is EOS®Waterfall? The main aspect of EOS®that looks waterfallish is the fact that it runs a quarterly cycle with planning the Rocks for the quarter in advance. I don’t consider that waterfall. And if care is given to making sure that Rocks focus on WHAT rather than HOW and leave enough space to account for variability/learning, I don’t see a problem. It’s very similar to SAFe’s PI-level planning, which is again properly done with an eye towards emerging learning and adjusting course as needed while staying focused on the high-level objectives for the quarter. How about individual accountability in EOS®- isn’t that in conflict with Scrum’s “Collective Ownership” approach? Isn’t EOS®in the way of Teamwork? Indeed this is a potential area of conflict. But even EOS®makes several mentions of the fact that in order to succeed team members need to prioritize the team’s rocks over their individual ones and support each other. When implementing EOS®there should be an emphasis on accountability towards team rocks rather than individual rocks, even at the leadership team level. Isn’t EOS® Micro-management under a thin veil? The way to look at this is that EOS®allows teams to micro-manage their work - with the understanding that in a VUCA environment there’ll be lots of surprises and emerging realities that are better addressed quickly. The Integrator role, like the Scrum Master, should lead the team through this discipline of tight-loop inspection and adaptation, rather than feel a need to micromanage work or output. Learning the proper “Leaders who Serve” Scrum Master mindset would be very useful to any EOS leader if he wants to avoid EOS becoming a checklist-based micro-management tool. Conclusion As you can see above, as long as you understand the purpose and practices of EOS®, Agile, and Scrum, and are thinking about how they can complement each other, you can definitely use them in tandem. If you want some help in thinking through what this would mean in your context, we'll be happy to discuss it further. Credits to Erez Tatcher, AgileSparks CEO who participated in the thinking and writing of this article.

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.