According to the 2020 Scrum Guide, Scrum team members should be “self-managing, meaning they internally decide who does what, when, and how.”
There is a lot of confusion about what exactly this means. On the one hand, some Scrum team members think that self-managing means doing whatever they want. On the other hand, others may dismiss self-management altogether, replacing it with micromanaging techniques such as leadership assigning particular tasks to particular developers.
Self-management doesn’t mean developers can do whatever they want, and it doesn’t mean leadership should micromanage the Scrum team, either. The reality is somewhere in the middle. Self-management is nuanced, depending on the organization’s needs and the Scrum team’s maturity.
To better understand self-management, we need first to understand why the Scrum guide calls for Scrum teams to be self-managing in the first place. Our answer comes straight from the Scrum guide. According to the 2020 Scrum Guide, “Adaptation becomes more difficult when the people involved are not empowered or self-managing.” In other words, if the Scrum team uses empiricism and makes decisions based on what is known, they need to be empowered to decide how best to accomplish their work. This could include deciding who work is assigned to on the Scrum team and how the Scrum teams supporting an individual product should be structured to deliver value to that Product.
Self-management is important because, in complex work, we hire knowledge workers who are expected to figure out how to solve complex problems. They need to use their creativity and problem-solving skills. We can’t give them a set of work instructions because, in complex work, the outcome is often unknown and unrepeatable. Every time we build a new Contact Us page, home page, or product feature, we expect Developers to figure out how to do it. We must empower them to determine the best way to do their work. That’s why self-management matters for complex work.
Now that we understand why self-management is important, it’s important to understand where self-management comes from. Self-management does not just happen; the two main ingredients are clear boundaries and a shared goal.
The boundaries come from the Scrum Framework (Events, Roles Artifacts) and the organization.
The goal comes from the Product Owner and is expressed as a Goal Statement, measured with metrics and supported by the Product Backlog & Roadmap.
Guardrails
Below are some guardrails that organizational leaders typically set:
Approach: Determining where Agile, waterfall, or operational processes will be utilized
Product Strategy: Identifying the organization’s products and deciding whether Agile will be employed for product creation and management
Financial Governance: Establishing procedures for budgeting, accounting, and financial decision-making
Product Budgeting: Defining the budget allocated for the creation of new products
HR Policies: Determining and administering human resources procedures and policies, including delineating staff authority levels
Technological Guidelines: Implementing guardrails for technology usage and development
Security Measures: Establishing security protocols and practices to safeguard organizational assets
Contract Management: Determining how contracts will be negotiated, executed, and managed
Process Streamlining: Implementing and optimizing organizational processes for efficiency and effectiveness
Accounting Standards: Establishing procedures and policies for accounting practices within the organization
Strategic Objectives: Defining organizational goals and strategies to guide decision-making and actions
Empowerment: The organization should empower the Scrum teams to re-organize themselves into multiple cohesive Scrum Teams if a single team becomes too large. How this is done will vary by organization, but when multiple Scrum teams work on the same Product, they must share the same Product Goal, Product Backlog, and Product Owner.
Below are a few guardrails from the Scrum framework described in the Scrum Guide.
Empiricism: Ensuring that all Scrum artifacts are transparent, enabling frequent inspection and adaptation
Lean: Avoid waste, including by managing an emergent Product Backlog ordered by the Product Owner
Incremental delivery: A done increment should be delivered each Sprint
Composition: Ensuring each Scrum team includes individuals responsible for the three Scrum accountabilities: Product Owner, Scrum Master, and Developers
Team Size: Limiting each Scrum team to typically ten or fewer people. When multiple Scrum teams work on the same Product, they should share the same product Goal, Product Backlog, and Product Owner
Self-Managing: The Scrum team should manage their task assignments and is responsible for updating their own Sprint plan using the Sprint backlog, which allows the Scrum team to decide who does what, when, and how internally.
Timeboxing: Ensuring that the five Scrum events occur within their timeboxes
3 Artifacts: Ensuring that the three Scrum artifacts (Product Backlog, Sprint Backlog, and Increment) are transparent to appropriate stakeholders and managed according to the Scrum Guide
Definition of Done: Establishing and adhering to a mutual Definition of Done if multiple Scrum Teams collaborate on a product
5 Values: Embracing and embodying the five Scrum values in all team activities and interactions
Below are some examples of the things that the Scrum team should decide:
Scrum team organization: How should the Scrum teams supporting this product be organized (e.g., how many Scrum teams do we need, who should be on each Scrum team)
Artifacts: Where should the artifacts be stored in alignment with organizational policies?
Events: What is the duration of the Sprint, and when/where should Scrum events take place? (Some organizations may require a particular Sprint length to coincide with other internal activities)
Skills: Do we need additional skills on the Scrum team, and how should we find those skills? (Some organizations will place guardrails around how additional skills might be added to the Scrum team. The guardrails may differ based on the Scrum team’s maturity level, organizational needs, and budget.)
Product Backlog Refinement: The Product Owner is accountable for the content and ordering of the Product Backlog. Developers should work with the Product Owner to size higher ordered Product Backlog items so that they can be done within one Sprint. The Scrum team determines where / how frequently refinement activities take place.
Sprint Planning: Developers decide how much work to pull into the Sprint, and Developers decide how to turn Product Backlog items into a done increment each Sprint
Forecasting: The Product Owner creates a forecast which crosses multiple Sprints
Self-organization: If a single team becomes too large, the team should self-organize into multiple Scrum teams to support the Product under a single Product Owner. When several Scrum teams work on the same Product, they must share the same Product Goal, Product Backlog, and Product Owner. If three or more Scrum teams work together to support a single Product, the team should consider adopting a scaling framework like Nexus to help them improve communication around cross-team dependencies.
Product Goal
In addition to clear boundaries, Scrum teams need a clear goal to be truly self-managing. Self-management does not work if the Scrum team doesn’t know where they are going. The Product Goal provides clear guidance for the Scrum team on the product’s direction. Only with a clear understanding of the goal can team members collaborate together and make informed decisions about how best to approach their work. The clarity provided by the Product Goal minimizes the need for constant oversight and micromanagement, empowering individuals to take ownership of their work and collaborate effectively within the team.
A clear Product Goal also provides a sense of purpose and motivation, driving team members to proactively seek solutions and adapt their approaches as needed to accomplish the desired outcome. Ultimately, a well-defined Product Goal promotes self-management, shared accountability, and innovation within Scrum teams, helping the team maximize the value of the Product resulting from the Scrum team’s work.
Accountability Matters
So, how do managers who have Scrum team members reporting to them ensure that the Scrum team members are held accountable? Leaders should ensure that the Product Owner has created and communicated a clear product goal that aligns with organizational objectives. In addition, Leaders can work with the Product Owner to ensure that metrics are identified that measure progress against the Product Goal. Monitoring whether those metrics are improving or declining can help the leader provide useful feedback to the Scrum team.
Leaders can measure the effectiveness of self-management within Scrum teams by evaluating team performance against predefined metrics or key performance indicators, soliciting feedback from stakeholders, and assessing the team’s ability to adapt and respond to changing circumstances autonomously.
The Role of the Leader
Leaders are essential to the success of any Scrum team. Agile leaders should encourage autonomy, trust, and accountability among team members. They should also promote a shared understanding of the organization’s goals and objectives and encourage Scrum teams to focus on problem-solving by asking open-ended questions to refocus the scrum team when needed, such as “What are we trying to accomplish?” and “What would be the impact if we made this decision?”
Leadership can support self-managing Scrum teams by providing guidance, resources, and support as needed, fostering a culture of trust and empowerment, and removing any barriers or obstacles that may impede team autonomy and decision-making.
Conclusion
Self-management is very nuanced, and every organization must find out what works best in its unique environment. When setting guardrails, organization leaders must balance the Scrum team’s maturity, its unique environment, and organizational needs. The more empowered a Scrum team is, the more it can adapt to changing business needs, thereby providing more value to the organization. For more on self-management, sign up for the Applying Professional Scrum course or the Professional Scrum Master course with Rebel Scrum.
This year’s theme for Scrum Day 2024 in Madison, Wisconsin, is “Deliver Products with Value.” Break-out sessions will discuss how to use Evidence-based Management to focus your team on value and how to define products to ensure that teams are aligned around value. Other breakouts will focus on using AI to reduce repetitive tasks and help the Scrum team focus on complex work. Get your tickets before August 31 for early bird pricing.