How Scrum Teams are different from other teams
Joining a real Scrum team can be a fundamentally different experience from joining a “regular” team. The expectations from you as a team member are going to be more than what your job title might imply. Do you know what it means to be in a Scrum Team?
If you’re in a Scrum Team or joining one in any role, this article will help you understand what will be expected of you. It will also help you find out if you’re having the real Scrum experience, or if you’re experiencing yet another Zombie Scrum.
For the Scrum Masters, I will pepper some advice concerning what you ought to do (and more importantly, not do) to help teams along their journey.
The fundamental unit: The Team
The fundamental unit of Scrum is a small team of people, a Scrum Team.
- The Scrum Guide (2020)
In most organizations, the fundamental organizational unit is the person. Every person has a role, a responsibility, a manager, and a place somewhere in the organizational chart. If that person happens to do anything productive, you’ll typically find them somewhere at the bottom, buried beneath an array of middle managers. This is such an ingrained concept that it can seem like a fact of life, not an organizational design choice.
For a Scrum organization, the atomic building block is the Team. A Scrum Team is a cohesive, long-standing organizational unit that is not assigned a particular function or has a particular manager telling it what to do. It is a fundamentally different approach to organizational design compared to the “person as a fundamental unit” organization, with many implications.
Scrum Teams are cross-functional… They are also self-managing… The Scrum Team is small…. It is a cohesive unit of professionals focused on one objective at a time.
Excerpts from the Scrum Guide (2020)
A Scrum Team is Cross-functional, Self-managing, Focused on one objective at a time, and Small. Each one of these attributes is like a piece of a puzzle — A team is not a Scrum Team if any of these is absent, because these characteristics are interdependent: Each one is needed to realize the others. And a team that does not exhibit these characteristics, cannot act as the fundamental unit of Scrum.
Let’s briefly go over each one to understand what they mean, and then we’ll put the pieces together to have an understanding of how these conditions play with each other to generate the dynamics that Scrum thrives on.
Cross-Functional
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint
- The Scrum Guide (2020)In scrum, a product increment is whatever you previously built, plus anything new you just finished in the latest sprint, all integrated, tested, and ready to be delivered or deployed.
— Scrum Alliance (source)
A Scrum Team needs to have all the skills to create features from zero to valuable without having to depend on anyone outside the Team to do so. If a team is dependent on someone from outside the Team to create an Increment, for example, they need to ask someone else to deploy, or they need another department to give the final OK, then how can the Team be accountable for doing this every Sprint?
If a Scrum Team is not able to deliver a useful increment, it is unable to learn, thus tending to end up as a feature factory, a team that is optimized for delivering Output, not Outcome. While a feature factory may superficially look like Scrum, it’s the opposite. Scrum is about maximizing outcome, NOT output. To maximize the outcome, learning must take place based on product increments being used by real customers and users.
Is your Team Cross-Functional?
When increments reach the hands of users and customers, that’s when learning can occur. If your Team is capable of taking items from zero to the customer without getting permissions or requiring handovers, your Team is sufficiently Cross-Functional.
Self Managing
Scrum doesn’t describe or recognize any managerial titles. The word “Manager” is absent from the Scrum Guide, and that’s on purpose — in Scrum, the people who do the work are the people who decide how the work is done. That means that as a member of a Scrum Team, you can’t expect someone else to decide for you what to do and how to do it. A team that is told how to work is not a Scrum Team.
Is your Team Self-Managing?
A team whose work is managed and monitored externally on a daily basis is not a Scrum Team. The organization can inspect the team at regular intervals (like at the end of Sprints), which is an important mechanism for the team to get feedback so it can adapt and improve itself, but these inspections need to be dispersed enough to leave the team room to self-manage.
Scrum Master tip: Don’t be an implicit manager
Contrary to popular belief, the Scrum Master isn’t intended to facilitate every Scrum event, nor are they the “process owners”. If all the events are facilitated by the same person, even if it’s someone who’s technically in the Team like the PO or the Scrum Master, then they are very likely also acting implicitly as Team managers. If the organization considers the team’s process to be owned by any single individual, the team is not self-managing.
Focused on one objective at a time
Being in a team MEANS having a shared objective. In a Basketball team, players all share a single objective: Winning the game, even if each player has very different roles at different times, like Guards and Forwards. In an Orchestra, the conductor and the flutists, two drastically different roles and skills, share a single objective: perform a musical piece. Why should it be any different for a software team?
To be in a Scrum Team means that each person in the Scrum Team is accountable for the same things: The outcome, and the Team’s ways of working (or the ability to deliver outcome). It doesn’t matter if your job title is Engineer, QA, or UX — when you’re in a Scrum Team, you are accountable for the same things anyone else in the Team is accountable for. Imagine a concert where the orchestra had an individual goal for each player. What would it be like if every player gained or lost a bonus based on how many notes they managed to fit in a concert, how would that concert sound?
How to tell if your Team isn’t focused
If you are in a team where each member has their own objectives; the frontenders work on frontend items, the backenders work on backend items, and those items only come together by a matter of chance, not only that you’re not in a Scrum Team, most of the people who are supposedly in your Team aren’t truly your teammates, since you share very little work and responsibility with them.
If your Daily has the pattern of a subset of the Team discussing specific issues while the rest wait passively, only to switch roles thereafter, that’s a strong indicator that your Team is internally divided and doesn’t share the same focus.
Scrum Master tip: Don’t fill the gaps
If there are Sprints where some people don’t have anything they can do in their specialty to contribute to the Team’s goals, that’s not an impediment for you to solve, that’s a learning moment for the Team. Don’t spoil it by filling the gaps for them. More on this later in the article.
Small
Scrum is based on short cycles of work and learning, based on the idea of incremental product development. The shorter the cycles — the better the learning. Short cycles are harder to achieve with many people closely collaborating. The more people you have in the Team the more overhead you have to keep everyone moving towards the same goal, and the costs grow exponentially. This is why Scrum recommends a team to be 10 or fewer, and taking into account that Scrum recommends a Sprint to be a month or less, and most teams opt for less, I would say 10 is also too big.
How to tell if your Team is too big
If you’re always running out of time in the Daily, if some team members don’t know what other team members are doing, or if you find it difficult to align everyone around the same goals, your Team is probably too big.
Small AND Cross-Functional??
Wait a minute, if a team is expected to be both small and have all the skills needed to deliver a valuable increment, doesn’t that represent a conflict?
This certainly looks like a conflict if you are coming to Scrum from an organizational mindset that looks at people as single-purposed resources (e.g. a Front End engineer can only do Front End). But remember: In a Scrum organization, the unit is the Team, not the individuals. Therefore in a Scrum organization, the Scrum Team is expected to have all the needed skills and knowledge, but the spread of knowledge and skills within the Team is the concern of the Team, NOT the concern of the organization.
Scrum requires constant learning
Here we are uncovering a critical expectation from Scrum Team members, that’s unfortunately a bit tucked away rather than highlighted in the guide:
Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.
- The Scrum Guide (2020)
When you join a Scrum Team, you will be expected to contribute to the shared team goals, and sometimes that means expanding your skillset and domain knowledge, thus working in areas outside of your comfort zone. There is absolutely no guarantee that there will be a constant influx of work that matches your expertise. Even when the work needed doesn’t align with your expertise, you are expected to contribute.
Shared accountability (everyone sharing the same goals) reinforces this need even further. If team members have tasks, items, or even whole domains assigned to them, they will find ways to create work to stay in their domain of specialty, even if that work doesn’t contribute to the Team’s immediate goals. For example, QA engineers who only do QA will always find another documentation to update or a test to refactor, even if that’s not where the Team’s bottleneck is. This kind of behavior seems useful on its surface (people are busy working on what they know best), but being busy and being impactful isn’t the same thing. Remember one of the Principles of Agile Software Development:
Simplicity — the art of maximizing the amount of work not done — is essential.
- Manifesto for Agile Software Development — Principles
If teams organize themselves so that everyone always has work in what they’re comfortable doing, this Agile principle would not be met, and it’d very unlikely that the Team would be focused on one objective at a time.
If you’re still unsure how business and impact aren’t the same thing, Erik de Bos recommended me this excellent video on this topic: https://www.youtube.com/watch?v=CostXs2p6r0
Does everyone do everything?
People who join Scrum Teams after working in a single-domain specialists setup typically take from this that the pendulum swing goes completely in the other direction from “one person is in charge of one domain” to “everyone is doing everything”. But in a healthy Scrum Team, that’s not how it goes. While it’s true that from the organization’s perspective, a Scrum Team is collectively responsible for its work, a Scrum Team is self-managing, and that means that the Scrum Team internally decides who does what. In reality, different people have different interests and preferences, and they will gravitate toward domains that are within or adjacent to their areas of interest.
Learning is key
For Scrum Teams to be successful, the Team members need to be lifelong learners, rather than pigeonholed in a narrow domain of expertise. The Team needs to discover what its members’ interests are and leverage those to spread the necessary knowledge among those who are inclined to it. Note that not everyone needs to learn everything, and not everyone needs to know everything, but if for every domain the Team needs, you have a few people in the Team interested in learning it, you’ve got a good team.
Scrum Master tip: Support team learning
One of the areas where the Scrum Master can contribute greatly is in helping create the safety and space for teams to engage in ongoing learning. Learning incurs short-term costs in the form of decreased output but provides invaluable long-term benefits in the form of allowing for smaller, more dynamic, and more outcome-oriented teams, who can continuously focus their efforts on the most important work. The greater a team’s capacity to learn, the more successful it will likely be as a Scrum Team. One of your key responsibilities to the Team is to make sure the organization understands this and supports a culture of learning.
Putting it all together
Scrum Teams can act as fundamental organizational units BECAUSE they are made of a small group of people who are self-managing, cross-functional, and focused on the same objective. All of these properties are needed, otherwise, the organization will need to micromanage at the individual level to have any hope of finding alignment between the skills available and the critical problems to be solved.
While a top-down, micromanaging organization can superficially resemble Scrum, it won’t be reaping the core benefits that Scrum has to offer, namely, Reduced managerial overhead, a simpler and flatter organizational structure, and the full utilization of everyone’s creativity and skills focused on the most promising problems. Properly implemented, Scrum empowers teams to collaboratively steer the product in the right direction, a task traditionally reserved for higher-level management.
Expectations from a Scrum Team member
Now that we’ve seen what a Scrum Team looks like and what characteristics it has, what are the implications for you, as a Scrum Team member? I’ve listed some of the differences in expectations you’ll encounter when moving from a typical organization to a Scrum organization.
In a Scrum Team, you’ll be:
- Responsible for the Team’s outcomes, not your individual contribution.
- Expanding your skills and knowledge towards where the Product and its needs lead you.
- Sharing your expertise with your team members so that no single person acts as a gate or a bottleneck.
- Evolving your ways of working to improve your Team’s ability to focus on and deliver high-value work.
- Working closely with other team members regularly, as that’s the only way to achieve all of the above.
Summary
Working in a Scrum Team can be fundamentally different from working in a non-Scrum Team. You will be expected to take higher-order responsibilities, continuously grow as a professional not only vertically, but also horizontally, and regularly work closely with others to achieve shared objectives. You will also be given much more freedom and trust than you would in a traditional organization.
Is Scrum for you? It certainly isn’t meant for everyone. If you want to focus on a single specialty, work alone and undisturbed, and/or climb a corporate ladder, other organizational structures would suit you better. But if you love learning, growing, solving complex problems with other motivated people, and having the freedom to do it your way, Scrum might be for you.
Bibliography
The ideas presented in this article are derived from:
- The Scrum Guide (Schwaber, Sutherland, 2020)
- The new new product development game (Takeuchi, Nonaka, 1986)
- Leading Teams: Setting the Stage for Great Performances (Hackman, 2002)
- LeSS principles (Larman, Vodde)
- Range: Why Generalists Triumph in a Specialized World (Epstein, 2019)
Serious Scrum
Do you want to write for Serious Scrum or seriously discuss Scrum?
