maA deeper understanding on…
The Scrum Team
Road to PSM III — Episode 6
[revised for 2020 Scrum Guide update]
“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. - The Scrum Guide
Scrum is teamwork
Sometimes, someone may not want to be part of a team.
Other times, team members may not act like they are part of the team.
Scrum challenges those who have a shared goal to stop hiding behind ‘invisible walls’ called job profiles, departments, offices, and organizations. Scrum challenges individuals in teams to take collective ownership.
Scrum is a way for teams to continuously improve itself, the product, and the working environment.
Improving the working environment starts with collectively aligning on work principles and values such as we addressed in the previous episode.
To be a team, individuals build together, they learn together… they help each other along the way. When challenged, they recover fast together.
- “Let’s take a look at this together?”
- “Do you want to work on this together?”
- “What do you think about this?”
- “Do you think the same?”
- “How can I help?”
- “What do you need?”
- “What’s the first next step?”
- “How can we make this even better?”
- “Did we miss anything?”
It is essential that a. servant-leadership, b. self-organization of work, and c. product ownership, are split into distinct accountabilities. Scrum doesn’t exempt a person from acting out multiple accountabilities, but take note that it generally affects the team dynamics negatively.
Agile Coach?
An Agile Coach is not an accountability in Scrum. It is also not senior (or more holistic) to the role of Scrum Master, as many organizations might let us believe. Coaching adaptability is already part of the accountability of a Scrum Master as defined by the Scrum Guide.
A Scrum Master must be an empowered member of the organization if it is to effectively empower teams.
When it comes to scaling, a (Nexus) Scrum Integration Team might support multiple Scrum Teams in its collaboration to deliver integrated increments.
Products, not projects
“Scrum is a framework for developing, delivering, and sustaining complex products.” — The Scrum Guide
A Scrum Team develops products. The product emerges and evolves. According to the Scrum Guide, each Sprint may be considered a project.
“Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.” — The Scrum Guide 2017
This is why Scrum doesn’t have a role called Project Manager. How to deal with organisations that already have project managers or even a PMO?
The organization introducing Scrum will likely already have Project Managers, or perhaps they are already thinking in terms of products instead of projects, and thus, they may have Product or Portfolio Managers. To work effectively with a Scrum Team, or become part of the Scrum Team their accountability changes. They will need to work out what it means for the team to be self-managing and what interactions will be helpful and which won’t. The Developers will learn to self-manage their work.
Self-Management
“Self-managing, meaning they [developers] internally decide who does what, when, and how.” — The Scrum Guide
Self-management works best when approaching product development empirically. The team itself can best assess the situation they are in and work out, using their collective skill and experience, how to best inspect and adapt. This requires traditional management to refrain from ‘barging in’ and handing the team directions when conditions change or new complexities emerge.
Often, a Scrum Team is run only as a container within a different organizational framework (like Prince2 or SAFe). Management in such organizations has the tendency to pick up on anomalies such as scope changes, interpersonal conflict, and impediments — and they lean towards a habit of ‘steamlining’ teams. Managers step in often interfere with the natural development of a team — impeding it from becoming a self-managing one (often under the guise of ‘maturity’).
This interfering behavior is generally well-intended but counter-productive.
A common pitfall for fresh Scrum Teams is that each member, coming from different departments or organizations, may have various managers as stakeholders to report to.
Everyone in the organization must understand and experience what it means to trust teams to manage themselves. This is not to say that Scrum Teams won’t need help from the organization to manage itself.
Individuals in the organization can learn that the best way to support a Scrum team is to empower them to resolve challenges themselves.
We already covered that the Developers, not the Scrum Master, own the processes of getting work done. However, many will argue that it is the Scrum Master’s responsibility to iron out the processes and resolve internal team conflicts. We might be inclined to consider this to be a responsibility as it fits the narratives we know on what leadership does. But this isn’t what the Scrum Master does. Just so we are completely clear about this: The Developers are accountable for managing their own work, processes, conflicts, and impediments. The Scrum Master is there to guide them in Scrum and eliminate impediments to self-management and empiricism.
Cross-functional
“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.” — The Scrum Guide
A cross-functional team is a group of people with varying expertise working toward a common goal. When they encounter situations in which they cannot resolve them, they will collaborate to work out how to resolve them. This may require the team to develop or onboard new competencies as needed.
A cross-functional team may include cross-skilled individuals, or at least promotes the development of cross-skilled individuals. This is not to say every individual should have all the competencies, but it should promote a healthy overlap that is needed to collaborate effectively and to limit dependencies. For example, someone adept in programming might also write and automate test scripts or help better specify requirements and work out scenarios.
Having specialists work together on shared objectives in the same cycle introduces challenges. Consider multiple hamsters running together in one wheel. The wheel (sprint cycle) is optimized to allow this, and the individuals will need to practice to work out how to run together smoothly.
Flexibility, creativity, and productivity
“The team model in Scrum is designed to optimize flexibility, creativity, and productivity.” — The Scrum Guide (2017)
Some will argue that, as the Scrum Framework works best when exercised in its entirety, it is ‘dogmatic’ and thus inflexible, un-agile, and limits creativity. This couldn’t be further from the truth. It is precisely the framework, which lightweight, that promotes flexibility and creativity and provides the best conditions in which teams can truly work empirically. It is when the pillars and values of Scrum aren’t upheld, that these abilities will are lost.
When a team doesn’t self-manage or isn’t cross-functional, it may:
- lack flexibility to calmly adapt to changing conditions and timely detect and resolve impediments;
- lack creativity to work out better ways to work through tough, complex challenges or learn and experiment with what could increase the value of the product;
- lack the productivity to produce valuable and qualitative “done” increments in a timely, consistent, and predictive manner.
Sudden changing conditions can introduce stress and conflict, but in complex product development, such changes are natural. Teams will need to work out how to focus and flexibly adapt to make development sustainable. In complex product development, these changing conditions are desired as reacting to them creates/unlocks value. Changing conditions shouldn’t be considered to be disruptive, and, as such, they shouldn’t be approached as disruptions. It is a flow, and the flow fluxes.
When we reveal complexities or discover better approaches, isn’t this a great thing? It only creates stress and conflict when we haven’t accounted for it in the expectations we set for ourselves and others. ]
When there is little or no room for flexibility in a plan, or teams aren’t trusted and empowered to creatively work through challenges.
Note: several of the memes used are from the movie Office Space, a dilbert-esque comedy about software developers gone rogue.
