“How does the PM role translate to Scrum?” is one of the more typical questions in my Scrum courses. Here’s the results of one such exercise that we did with the participants to find an answer. 

As can be seen, a large chunk of typical project manager responsibilities become things Product Owners (green in the picture) are supposed to own, and another big chunk is for the Development Team (red). There’s a few splashes of blue (for ScrumMaster) and a sizeable number of items that Scrum is silent on (yellow). 

What is/was project manager anyways?

“Project” is an execution management structure. Projects are set up to deliver some target outcome, usually within specified timeline and budget. 

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

Again, I’ll post an email response to question from an alumni. This post is also available on Futurice Blog.

The question:

I am working on an agile project and I don’t know when to incorporate prototyping.

I’ve been too busy for too long to write blog posts, but here’s one, about the role and authority of the ScrumMaster.

The way I understand the Scrum framework is that the ScrumMaster is the person who does have a lot of authority over the process, but in the same way as in any other matter – everyone in the team is responsible for their own work. I don’t see how ScrumMaster has any authority to say anyone in the team that they must work in a certain way. He/she can certainly talk about the process, educate about better ways of doing it, showing where the process currently fails, etc., but I believe every single person in the team is responsible for the way they do their work.

This is not unlike in a soccer team – the coach does train the people, help them practice to become better soccer players, have a vision how the team should/could work together better, suggest better strategies, BUT when the game is on, the players are responsible for playing the game. I don’t know any single soccer game where the coach scored a single goal from the sidelines.

Recently I “rediscovered” the PDCA cycle, made famous by W. Edward Deming, consisting of Plan, Do, Check and Act phases, and forming the base for every process improvement cycle. According to Wikipedia (http://en.wikipedia.org/wiki/PDCA):

PDCA (plan–do–check–act) is an iterative four-step problem-solving process typically used in business process improvement. It is also known as the Deming circle, Shewhart cycle, Deming cycle, Deming wheel, control circle or cycle, or plan–do–study–act (PDSA).

PLAN – Establish the objectives and processes necessary to deliver results in accordance with the expected output. By making the expected output the focus, it differs from other techniques in that the completeness and accuracy of the specification is also part of the improvement.

I’ve come to realize recently that there are two types of Scrum. One is goal-driven, the other is story-driven.

The Story-Driven Scrum

This approach seeks to identify and prioritize user stories (or any requirements) small enough to fit in the iterations. In these Sprints, the team commits to delivering the selected set of stories. These stories can be estimated and the amount of results can be measured for longer term planning. This approach works best when enough design work can be done in advance to eliminate most significant elements of uncertainty prior to committing to work in a Sprint. I could call this type the Mike Cohn Scrum as this approach is excellently defined in his Agile Estimation and Planning book.

Last Tuesday, on 4th of May, 2010, I was participating the TIEKE Brief #10 “Scrum – ketterästi” as a speaker. I was closing the brief with a title “Reality Check”. There is much hype and unfounded optimism on Scrum and Agility that I felt it was appropriate to try to ground some of that. Scrum and Agile is hard. Change is hard. It’s easy to write bad software expensively; it’s very hard to try to do as good software as you only can with as little waste as possible. It is known that most Agile transitions fail to meet the expectations.

While the presentation should be appearing also on the TIEKE site, I’ll post it to my presentations page (also linked to this post). It’s in Finnish and in a very much simple format. Should I expand in text? Okay, will do quickly…

Agile isn’t a silver bullet. It doesn’t solve most of the problems typical organizations have. It will expose them. It’s up to the organizations to fix their bad habits or poor operation. Scrum is pretty quiet on “how” (purposefully, because it isn’t a methodology), so we must turn our attention to other sources. Lean Software Development gives a pretty good overview on the kind of product development Agile environments should foster. An upcoming book by Stephen Denning, labeled Radical Management, takes a more comprehensive look at how businesses can become radically better. Dan Pink made a great case in his TED talk about how rewards are actually damaging our businesses and our innovation. Etc. There’s lots to learn for us.