Pigs and Chickens
These three roles are the pigs… the ones that actually have skin in the game… the ones that are invested and will do the work. Scrum also talks about Chickens… management types that might have an interest in the project, but are not actually involved getting the work done. Never heard the story of the Pigs and Chickens? Click here to check it out.
This post we’ll start with the roles of ScrumMaster and Team Member. We are going to try and sort out all these farm animals, figure out who is going to do what, and look at where some of our traditional project roles might fit in.
The ScrumMaster is reponsible for making sure the Scrum process is followed. These folks also make sure that impediments are identified and resolved in a timely manner. You might find one of the technical guys playing this role (in addition to their day job) but unless they’ve got the right facilitation and leadership skills, this can get a little complicated. I’ve seen developers and QA analysts do very well playing ScrumMaster, I’ve also seen them struggle.
Some people think this is a good place to put the Project Managers. Right now our industry has a bunch of Project Managers scrambling around to get their CSM certification. Many agile methodologies, Scrum included, don’t call out the role of a Project Manager. The idea is that Project Managers aren’t really necessary on a self-organizing team. Sometimes you get a Project Manager that plays the role well, but for now, we just need to understand that a ScrumMaster and a Project Manager are not the same thing.
ScrumMasters are process facilitators and support for the team. Project Managers are usually responsible for managing the team and ensuring that time, cost, and scope are balanced according to predefined project constraints. Project Managers usually have ultimate accountability for delivering the project and are authorized to spend money to make that happen. This is not the same as a ScrumMaster, ScrumMasters have no authority over the team. ScrumMasters are more servants of the team… Project Managers are more like a boss.
I used to think the ScrumMaster role was a good place to tuck our Project Managers… now I am not so sure. But that begs the question, if Project Managers are not ScrumMasters, are they Team Members? If not, are we suggesting Project Managers are left out all together?
The team should be pretty easy to understand. These are the folks that do the heavy lifting getting the product built. The team decides the implementation details… they write the software… they make sure it is sufficiently tested. The team gets to define how the product is going to be built, and how long it will take, but don’t really have a say in what get’s built or in what order… that’s the role of the Product Owner. The team reviews their work with the Product Owner to make sure it meets their acceptance criteria.
The development team, the database guys, and QA can probably be worked nicely into the role of Team Member. These folks have direct responsibility for designing, building, and testing the code. But what about the business analysts, systems analysts, and user experience specialists we talked about in the last post? These guys don’t actually write the code… they more likely play a role in helping the Product Owner translate requirements for the developers and testers. Are they part of the team too? Maybe… that’s where many of them end up today, but it’s not a slam dunk.
For now at least it doesn’t sound like we have a good home for Project Managers. We may have also left out the traditional requirements and design oriented roles as well. We still have yet to find a home for the other chickens we talked about earlier. Hmmm, I wonder if we are getting into trouble here.
Running Out of Roles?
If these traditional roles are not ScrumMasters or Team Members… where does that leave us? The only thing left is Product Owner. There is NO WAY that Scrum could save all these roles for the Product Owner, could it? Might we need to define a few extra roles to accommodate all these missing people in the development process?
Next post we’ll talk about the Product Owner role and see if we can figure out where to tuck all these extra project participants.