How to un-manage your scrum teams
Scrum teams are meant to be self-managing and maybe that’s why we don’t spend a lot of time talking about the roles surrounding them. But scrum teams don’t work in isolation. They are affected by product roadmaps, staffing plans, and other interests across the organization. I’m proposing a framework for how people surrounding the scrum team should work together. As a group, I call us the support unit.
Which roles are included in the support unit depends on the organization. You could imagine a small startup where the founder and CTO are involved in guiding scrum teams. In a large corporation this could be any number of different roles. At Revel Systems the support unit includes Dev Managers (DMs) such as myself, Product Managers (PMs), QA Managers, and even Product Owners (POs), Designers and Scrum Masters (SMs) even though they are also part of the scrum team.
The concept of the support unit was born from questions I had started hearing amongst ourselves: Where does my role end and someone else’s begin? Who gets to decide X? I don’t think that’s part of my job description. We had started debating how to differentiate the roles of PMs and POs and where DMs should get involved.
I see parallels to questions I’ve gotten from members of scrum teams:
Should backend or frontend devs do their part first? Should frontend or backend devs define API contracts? Should UX designers participate in tech design discussions?
In the case of the scrum team, it’s a familiar challenge. The team is struggling with some principles of agile and the values of scrum. Specifically, a team looking for definitions of fixed roles and responsibilities fails to live the agile principles of self organization and working together and the scrum values of openness and commitment to a common goal. Scrum team members should leverage their T-shaped skill sets to tackle problems together. When they do this, their questions melt away as they realize that they must leverage their individual skills and knowledge to achieve a common sprint goal.
Just like members of their scrum team, support unit members should also embrace agile values. Support units should follow the same principles that we promote on our scrum teams.
Embracing Agile Principles and Scrum Values
Self organization means that we don’t need hierarchy in order to achieve our goals. We are all professionals and can work together to build a shared vision based on research and debate. We are dedicated to a common purpose and allow that to drive our work.
With self organization comes working together. We all bring our own skill sets and organizational perspectives to the table. But we work to achieve a single goal.
Neither of the first two principles work without openness and commitment. When we aren’t committed to a common goal, we tend to build up walls and try to define where their role ends and ours begins. We build fiefdoms and tend to toss work back and forth. If we are open with our opinions, domain knowledge, failures as well as our successes, then we can start to build the strong relationships that underpin all high performing, self organizing teams.
At Revel Systems, here is some of what each support unit role brings to the table:
Product managers bring a market view with a good understanding of all internal and external pressures on our product and roadmap. They have close relationships with executives, account managers, and industry thought leaders. They have a strong opinion of where we should position our product and the big problems we should be trying to address.
Product owners bring an understanding of how our product works and how to break down future deliverables into workable chunks. Because they are in the weeds of the product every day, they know minute details about past products and understand the specific challenges posed by future work. They also tend to work more closely with customers and will have a nuanced understanding about the problems being addressed.
Dev managers are similarly involved in the weeds of the product, especially from a technical standpoint. They can help give quick cost estimates and look for opportunities to simplify products. Often overlooked, they also have a good understanding about the team structure, skill sets and any plans to grow or change the structure of the team.
Scrum masters also have a good understanding of the team and what affects their productivity. They are uniquely positioned to help the scrum team develop scrum values and progress towards agile delivery. They leverage feedback loops, transparency, inspection and adaptation throughout every scrum ceremony to deeply understand the team.
Finally, our QA manager has a deep and broad understanding of our existing products and can help provide missing context from other domains. They are also talented at identifying hidden complexity through the lens of testing.
None of the above descriptions are meant to define silos or strict limits to individual roles. Rather, these descriptions hint at ways in which each role can contribute to the task of guiding a scrum team to build an amazing product.
Sounds like chaos, does the support unit mean the abolishment of individual roles and accountability?
While working as a support unit encourages collective ownership it does not eliminate individual accountability. Rather than seeing it as your job to individually deliver on your responsibilities, the mindset shifts so that you help the team deliver results while being accountable for guiding the team through to delivery.
How does it look when these roles work together to drive product as a team?
A product manager comes to the team and shares an opportunity in the market. Together the support unit works to define a clear problem statement. They bring knowledge from each of their domains to help refine this statement. They also take this problem statement to the team to get further insights. The product manager then takes this jointly created problem statement and represents the scrum team to top leadership.
Problem statements evolve into products which become backlogs. This process is a complex task involving elements of market forces, customer feedback, long term product vision, current product details and the engineering team itself. The team aspect includes individual interests and skill sets of the engineering team members.
No single individual in an organization has the skills or knowledge to optimally design a roadmap that takes all of these factors into account. Therefore it should be the scrum support unit that collaborates in creating this shared vision.
By envisioning PMs, POs, SMs, DMs, and QA Managers as a support unit, we can find a better way of working. As a support unit, we embody the principles of self organization, teamwork and values of openness and commitment that our engineering teams have learned to use every day. Let’s learn from the scrum teams we guide.
