Scrum Roles in the Time of Chaos
Today I’m going to talk about roles. This will be the first of a series on the subject, with the intent being to clarify, simplify and make your lives much easier.
And now, story time…
Imagine this scenario:
You’re at a baseball game and you notice that the game is taking longer to play than you remember. There’s no scoring, and everyone seems overworked and frustrated. You start to take a look around and notice that the way we do things aren’t quite right.
To ensure that the right pitch is thrown, and you know, get a second set of eyes on the read, your team has employed two pitcher for each pitch. They confer with each other which is the right toss, and then neither of them holds the ball and throws because neither of them know who’s actually responsible for executing the pitch. After the coach starts yelling, and the umpire reminds them, one of them picks up the ball, and throws it to the hitter really quick, forgetting the planned pitch.
Meanwhile, because the hitter wants to ensure that they truly understand the guidelines, and make the right call, the hitter asks the umpire whether it’s in the strike zone, whether he should swing or bunt, whether the pitch is considered a fast ball or a curve ball, and at what angle he should swing, what happens if he hits the ball left of center, but not high enough to hit the fence, which direction he should run, and what material the bat is made from.
After the hit, the hitter doesn’t actually run to the base, but has subcontracted that role to The Runner, who waits to hear the crack of the hit, notices that the ball has gone deep midfield, and starts running to second base, because that’s the most efficient way to get to where he believes he’ll be anyway. At the same time, the first baseman also begins to run to second base.
Mid game, the guys in the booth decide that really, it would be better if the team wore roller-skates while playing because they can move faster. That’s probably what is keeping them from scoring.
The coach is a committee of people representing sponsors, vendors, batters unions, left field position consultants and several others, all beholden to their own committee of stakeholders, and are unable to choose the best strategy for improving the team because they can’t agree on what to focus on.
The outfielders have each determined their own language for communicating and what their best practices are so that none of them knows who is going to catch which ball, where they are throwing it to and where to stand.
Meanwhile, fans and sponsors are invited onto the field in the middle of the game to chat with the players and give their critiques. To be safe, they are all wearing helmets and asked to only speak to the players before the pitch.
This is clearly an exaggerated and hilarious scenario, and I feel like we have seen pieces of this play out in one way or another either here or on other teams we’ve been on.
Knowing what we are here to do, who owns what accountability, (aka, Roles & Responsibility) and trusting that not only are those in their roles are capable of executing, but also of making the right decision.
Scrum has a very lean outlook on the structure of the team, where there are only three roles, a Product Owner, the Development team and the Scrum Master. The emphasis is on self-ORGANIZED, and SELF-managed. Meaning, we give the Scrum Team the trust to do the work, and the Scrum Team is who manages all aspects of the project. We’ll get deeper into the nitty gritty of what that means, but let’s take a look at the Agile Manifesto and take a peek at the Scrum Guide to help us better understand the intent of those who’ve created the philosophy and the framework.
The Manifesto
“The best architectures, requirements, and designs emerge from self-organizing teams.”
- Self-organizing, in this context ranges from organizing the priorities, the technologies, and the processes of the team. The team that is doing the work are the ones that are best to determine how to work. This can be guided with improvements in mind, and there are agreements and expectations that need to be met, but how the team works, comes best from the team.
“Business people and developers must work together daily throughout the project.”
- The closer the team works with the people they are working to solve problems for, the better the team can solve the problems. Keep in mind that this is a two-way street, where the developers are not just order takers, they are part of the conversation.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
- Research has shown that what motivates us may be misunderstood. Scrum and Agile does a good job to address this, when trust is present.
- This article helps us understand what has been found to motivate people. Pink’s Autonomy, Mastery and Purpose Framework — From MindTools.com
- If you’re more into videos, this is a great summary. RSA ANIMATE: Drive: The surprising truth about what motivates us — YouTube
Below is the Scrum Guide, that we’ll dive deeper into in the coming weeks.
The Scrum Guide:
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. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint. Scrum defines three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
A brief introduction of our team:
The Development team —
The Development team is the collection of anyone who contributes directly to the creation, design and delivery of the product. This can include, but is not limited to, software developers, designers, QA Experts, Project Managers and external team contributors.
You may have gasped when you saw that a Project Manager is included here. I hear you, I see you, we’ll talk about that one later.
The Product Owner —
The Product Owner helps set the vision of the product. They work with the customer to understand the need and the direction they would like to go. The Product Owner sets the priority for product and helps the team understand what we are building and why.
The Scrum Master —
The Scrum Master is the person responsible for ensuring the team understands and adheres to the Scrum Framework. The reason for this is not to police the team, but rather to help ease the burden of paralysis by analysis. The Scrum Master is A • Servant Leader • Facilitator • Coach • Manager • Mentor • Teacher • Impediment Remover • Change Agent.
The role is the most defined, and least understood. More on that later.
Now that we know the foundation of the Scrum Team, we’ll dive into each role individually down the line. Stay tuned!
