Thoughts on Scrum – Part 2

So in the last post I gave an overall description of Scrum. In this post I want to lay out more about the roles. Now, you can find this information anywhere. What I thought might be helpful is to give you my impressions as they compare to traditional or waterfall PM. Again, these are my thoughts not the Scrum Alliance’s per se. They seem to go out of their way NOT to make comparisons.

Product Owner:

This is the person who has the vision of what he or she wants to build or create. He or she keeps a product backlog which lists features. (I had a hard time getting my instructor to use the word requirements. I’m not saying it’s unknown. But the Scrum folks seem to prefer the word features). I’ve also heard the backlog can include bugs which need fixing. It’s the job – in part – of the Product Owner to prioritize the features that are in this backlog. If I were to make comparisons this sounds very much to me like a product manager. Or perhaps a hybrid of the product manager and sponsor. What’s very interesting (to me) in Agile is how frequently the requirements can change. Since a sprint is only 2- 4 weeks long, the product owner can change his mind. Or said better, he can better understand what he wants as he sees it done.

Scrum Master

This person is responsible for facilitating the team and helping them stay focused and remove impediments. She is somewhat of a coach but not necessarily the leader. A scrum master asks three questions at the daily scrum:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

If you, like me, are a “traditional” project manager you will notice something missing. No schedule. For that matter, no real management per se, at least not in this role. Try though I might to equate this role to project manager, I simply cannot. This may be the hardest adjustment to make for PM’s. What’s my role in Agile? The only conceivable one I personally can see is Scrum Master. But it’s not quite as all-powerful or as guiding and task-leading as Project Manager. Now, I have met Scrum Masters who use, say, Microsoft Project. But that’s usually when they’ve been running multiple sprints and they need to coordinate between them and/or have a report for senior management. No such tool is called for in Scrum.

Team

Last but not least we have the team. Let’s start by defining how PMI sees the project team. In addition to the project manager, there are “other team members who carry out the work but are not necessarily involved with management of the project. This team is comprised of individuals … with a specific skill set who carry out the work of the project.” And while it’s not stated specifically in this definition, the PMBOK makes clear that the project manager manages the team.

Agile says that the team self organizes to meet sprint goals. The team has autonomy to choose how to best meet the goals and is held responsible for them. So even though Scrum Alliance does not in any way, shape or form say this, it’s almost as if the team is the project manager. Collectively they make decisions, coached by a scrum master, with guidance from a product owner who represents the customer’s interests.

So those, in a nutshell, are the roles. And as I understand it, those three roles play out their parts in a series of sprints (2 – 4 weeks each) towards their ultimate goal of making a product. For me, this spins traditional waterfall development on its head and I’ll talk more about my feelings and opinions on it in the next post.

If there are any Scrum/Agile experts out there who want to comment on any of this, feel free. I admit that my Agile experience is entirely theoretical. And in the short time since I got my CSM, I have talked to several people with wildly divergent ideas about its use. And its ultimate longevity.