Yuval Yeret

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. Next, We are turning to the Scrum accountabilities/roles. This article provides a concise introduction of the 3 accountabilities on the Scrum Team. We mainly focus on considerations from a Leader perspective for how to create the conditions where the people in the Scrum accountabilities can succeed in their roles. 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 commit to pursuing 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. 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. Can these senior people spend the necessary time with 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 we organized the Scrum Team 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. They are committed to organizing their teams around products and value. Stakeholders While Stakeholders aren't an explicit accountability/role in Scrum, effectively working with Stakeholders is crucial to value creation. Stakeholders should respect the Product Owner's accountability and the direction they're steering the Scrum Team towards. The Leader might need to intervene as well as lead by example, being a stakeholder themselves. Leaders can help a Product Owner identify and access Stakeholders. They can empower the Product Owner to innovate with their team. They do this by collaborating with the Product Owner and the Stakeholders to establish a clear and agreed-upon Product Goal that the Scrum Team would be committed to strive towards. Once a Product Goal is defined, Stakeholders should respect the Product Owner's accountability. The Leader might need to help the Product Owner shape the Stakeholder interactions. Developers Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. By saying Developers the Scrum Guide doesn't necessarily mean 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. 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. In Summary As we've seen, the Leader has many considerations and intervention opportunities when it comes to choosing the right structure and people for Scrum to succeed and for agility to be unlocked. While the Leader isn't mentioned explicitly as a role/accountability in the Scrum Guide, Scrum will not succeed without Leaders taking on themselves the accountability to set up Scrum Teams for success and continuously inspecting and adapting the structure based on transparency Scrum generates. One key point here is to avoid analysis paralysis. While the complexity of setting Scrum the right way seems daunting, the right move is to start, see, adapt rather than spending many hours or weeks on perfecting a roles and responsibilities plan or waiting for the perfect people for the role. You'll learn much more by just starting - both about what surprisingly works better than expected as well as what doesn't. In the next article in the series, we will turn our attention to the Scrum Events and how the Leader can best interact with them and support the Scrum Team in using them.

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.

So you have a couple of Scrum Teams that are working in adjacent areas and you're starting to face some challenges in delivering value in a coordinated integrative way.

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. 

The COVID19 pandemic gives us plenty of opportunities to think about uncertainty, complexity, and how to deal with those using Empiricism.

The Kanban Guide for Scrum Teams aims to help Scrum Teams leverage the ideas and practices of Flow and Kanban in a way that is coherent with Scrum as defined by the Scrum Guide.