Are Scrum Roles Really Sufficient?
Okay… so you are making the transition to Scrum… awesome!
Let’s start by taking a quick inventory of your team and figure out who is going to do what in this new methodology. Scrum defines three roles for us: ScrumMaster, Team Member, and Product Owner. Everyone’s pretty excited and ready to get going, so let’s take a look, and see where everyone fits in.
If your organization is like most traditional software development organizations, your team probably has a bunch of developers, several QA analysts, maybe some interaction designers, a database guy, and usually a Business Analyst and a Project Manager. You might be working with a real customer, but more often than not, you are working with a Product Manager who’s job is to define your product requirements.
Is that everyone on the project? It might be everyone on your project team, but is that really everyone on your project?
When you look outside the immediate project team, the number of people with influence over your project actually gets much larger. You likely have several Product Managers, maybe a few marketing folks, a sales team, and of course your support organization. You may have a team of engineers that implement your product and probably a few consultants that train your customers on how to use new features.
Do you have any interested functional managers, directors, or vice presidents? What about the Business Development and Strategy team? Does your project have visibility at the Senior Executive level? Where do the CIO… the CFO.. the CEO all fit in? These folks not only have an interest in how the project is coming along, they might need to actually insert some requirements and shape the direction and timing of your project.
More than likely, these folks actually funded your project. Do these individuals have a defined role in Scrum? If so, what do we call them… what do they do? Is it sufficient to call them chickens and tell them to talk to the ScrumMaster?
Over the next few posts, we are going to take a look at the role of ScrumMaster, Team Member, and Product Owner and explore how many of our traditional roles play on an Scrum team. We’ll examine how, from the team’s perspective, many of our traditional stakeholders are abstracted behind the role of the Product Owner, what this means for the agile team, and its implications for the broader organization.
We’ll assess some of the risks and suggest an alternative or two for dealing the Product Owner at scale.
This is a problem that a lot of agile teams face, but it’s nothing that can’t be resolved with a little bit of common sense…
the product owner should be somebody who takes on the responsibility of navigating the massive marketing teams, project stakeholders, real customers, etc.
a product owner should be chosen because he/she has real muscle within the business side of the organization, I can help keep the disagreements to a minimum, or very least shield the delivery team from the majority of these disagreements.
In reality, the person chosen to be the scrum Master also has to pitch in in handling the stakeholder mess, in my experience he/she typically try to get agreement among the “technical” stakeholders i.e. the army of architects, operations managers, methodology police etc.
Both of these roles act as “blockers” dealing with the typical massively bureaucratic and complex environment, while allowing the team to focus on delivering software employing as many agile practices as possible.
I almost never use the scrum definitions for roles…
I usually use more, but scrum is as good a starting place as any…
Mike, This is a great topic and these concepts really get at the crux of managing successfully within the discipline of agile. I look forward to reading the series and engaging in the conversation.