The Product Owner is Part of the Team

The results are in: I asked whether product owner participates in the sprint retrospective. Despite the intensive debate on the scrum development list which led to the poll, the overwhelming majority of respondents - 72% - reported that the product owner participates in all retrospectives as a full participant. Only 13% said the the product owner never participated.

I am also pleased to report that no one invited the product owner but did not let him participate. I recently advised a team which did just that, with the justification he is not part of the team. While there might be some justification for this in the Daily Scrum, I believe getting good and timely responses from the product owner is one of the big challenges in the team. Not letting him talk smells of a power struggle and is not motivating fo rthe P-O in any case - why should he come if he has nothing to say?

The poll is still open and you can download the results directly from doodle. As I write this, there are 32 responses. Although those are enough votes that I have some confidence in the trend, it doesn't exactly qualify as a large sample. So if you haven't voted, please do so! If the the trends reverses, I'll post an update.

Towards Agile Talking Points [was: Towards an Agile Litmus Test]

Last week, I published a poll which tried to identify criteria for an agile litmus test.  I wanted some talking points to complement the Nokia test as I start to coach a new agile project. There seem to be strong feelings against testing. The inquiry generated little enthusiasm on dzone, whereas Michael's criticism of these tests came up strongly positive.

As I started the above mentioned project, I discovered that the questions I proposed were not that helpful.  The real problems become obvious very quickly as I watched the team do its sprint retrospective and sprint planning. Reacting to what I see is more important than doing an academic evaluation.

As I write this article, 8 people have voted on the poll. Not exactly the wisdom of crowds, but you can get an idea of what people consider important. Here are the top vote getters:

1. Colocated: Is the team colocated? - 8
   
2. User Stories: Do you define the product in terms of user stories? - 8
3. Releases: Have you delivered running, tested, usable functionality to users at least twice in the last six months? - 7
4. Continuous: Do you do continuous build / test / deploy? - 7
5. Retrospective: Does you team conduct a retrospective after every iteration? - 7
6. Testers: Do you have testers? - 6
7. Bug DB: Do you have a bug database? - 6
8. Access: Does it take less than three days from when you have a question to when an expert answers it? - 6
9. Build: Can you build in a single step? - 6
10. Talk: Does everyone talk to each other, constantly? - 6
    

One of the more interesting suggestions in ensuing the discussions was, When starting a project, I should not be looking for practices, but rather but looking for smells (or symptoms). I could identify a couple from the questions in the poll:

• How many releases have you put out in the last 6 months? ( 0 or 1 is a problem)
• How much effort is required to build and test the software?
• Does fear play a role in deciding when to give the boss bad news?

I still think it is useful to have some tools and approaches, readily available in my backpack, for "debugging" an agile development project. Some would be used when talking to management about their problems, to convince them of the need to do something. Others might be asked of the team in the course of a retrospective. Still others might find their way into an Agile RFP, so that non-agile companies don't make the cut.

Question for you, gentle reader: What are the symptoms and smells of bad software development and especially bad agile development?

Scrum Management Tool Poll Results: Moving Away From Cards?

The poll on Scrum / Agile tools usage was the most popular Scrum Breakfast poll to date — 100 responses, of which 63 were using a dedicated agile project management tool. A market leader seems to be emerging in the agile project management space. I've finally gotten a chance to compare the results of this Poll with those of the Scrumdevelopment poll on the same subject from December 2006. The results indicate significant changes in what tools agile teams are using to manage their work. I wanted the results to be comparable with the Scrumdevelopment poll, so respondants could only pick one tool. So even though they might use several tools, they had to choose which one was the most important.

The data indicates a significant shift towards dedicated agile project management software (from 7 to 63%), away from Spreadsheets ( down 38% to 9%) and Wiki &Other/Homegrown tools (together down from 33% to 6%), and to a lesser extent cards (down from 36 to 18%). Open Source solutions and traditional project management software(with 4% of the respondants) do not appear to play a significant role in this market. Dominant Player? Under the commercial suppliers, VersionOne was the most top ranked response (54% of those voting for a commercial tool), followed by ScrumWorks at 17%, and TargetProcess and Scrum for Team System (8% each).

The question was raised in the comments whether one manufacturer might have orchestrated a high response rate. It's hard to know for sure, but I don't think so. Three reasons:

• Representative of two suppliers other than the winner left comments on the blog while the poll was running and so were aware of the results as they developed. If they had wanted to orchestrate a get-out-the-vote campaign, they could have (and maybe they did!).
• I did put out a get-out-the-vote reminder on the scrumdevelopment list. It produced little if any effect.
• As I watched the voting progress, the development seemed organic: the pattern was established early and subsequent voting did not change the percentages much.

It will be interesting to see how these results compare with VersionOne's study, which will be published next month.

P.S. For those of you who want the details: the poll data can be downloaded as an ODF spreadsheet.
 
[Update: July 7: I have published a Directory of Scrum Management Tools with links to all the suppliers]

Results: Quick Poll on Scrum Training Needs

Last week's Quick Poll on Scrum Training Needs produced a lot of interest. The poll was divided into 4 sections. The 31 repondants voted on:

1. What kinds of courses are needed?
2. What advanced topics are needed?
3. What language do they what the training in?
4. What location/kind of course do they want?

Given the number of participants, I would not call this anything like a representative sample (and strickly speaking, an internet poll cannot be representative). Still...

The Certified Scrum Master Training seems to be well accepted among Scrum practioners. 48% of the respondants expressed a need for certified training. Scrum training however is expensive, and almost as many — 42% — felt the need for lower cost training (or at least would accept non certified training). Advanced topics (with out specifying which ones) and Getting Started courses were desired by only 26% of the respondants.

Under the advanced topics, (and more people checked these boxes than said they needed "advanced topics") Agile Planning and Estimating was the clear favorite: 48%, followed by Agile Contracting at distant 2nd — 42% —, followed by XP and Lean Workshops for Management (19% and 16%).

Interestingly, it seems the need for onsite training is larger than for open courses (or perhaps the demand for open courses is sufficiently satisfied): 35% wanted company courses, 19% each wanted open courses and webinars. Podcasts must be considered exotic with only 9% wanting podcasts.

The questions on language were interesting. The percentage wanting training in German was virtually identical to the % of visits coming from German speaking countries. The percentage wanting some other language was the same as the number coming from other non english speaking countries. Surprise.

On the other hand, 54% said English would be OK I suspect this result is a bit self-selecting, because this blog is written in English....

@jp - would you like to run this poll in german on your site?

One the whole, the demand looks healthy, particularly for on site training and training in local languages. (And Scrum Trainers know what they have to do to improve their training offerings...)

Next week, I want to revisit the poll on managment tools from January 2007.

Nokia Test Results: Is anybody really doing Scrum?

Last week, I challenged the Scrum community to take the Nokia Test: a Scrum litmus test to deterimine whether a team is agile and doing Scrum. How did the Scrum community fare?



Protecting Team Members from Management is clearly the biggest challenge faced by Scrum Teams. Only 51% of the respondants claimed that their team members were well protected from Project Managers or others disrupting work.



Prioritized product backlog and burn down charts are second and third from the bottom at 72% and 74% respectively.



Interestingly, all three points are issues relating to managment and the product owner (who is likely part of management), suggesting that management buy-in is a challenge. Either Scrum adoption is coming bottom-up or management is "talking the talk" but not "walking the walk".



On the total test score, only 26% of the respondants claimed an 8 on the Nokia scale. 36% claimed 7 points (total of 62% for 7 or 8 points). At least 7% did not meet the minimum definition of "agile"



Without question, doing Scrum is difficult. There was some discussion on the Scrum development group as to whether the Nokia test is hard enough. But even with this simple test, 3/4 of the teams in question are not doing Scrum. Or are they?



I have three issues with the Nokia test:

1. "Software tested" is too specific to software development. I would ask the question "Is there a definition of 'done' which is consistently applied'?
   
   


2. Continuous improvement is completely missing. Iterations don't necessarily imply retrospectives. I would add a question "Does the team perform retrospectives every sprint and implement top priority improvements?"
   
   


3. Intent is also missing - Is the team actively trying to use Scrum to better realize the project? I think even if a team had to compromise on some points for tactical reasons (e.g. "the customer said no"), it should earn points for trying.

Results: How agile are you?

After getting a good response to the sprint duration poll, I thought it would be interesting to ask the question at a somewhat higher level. How long does it take your company to deliver business value?

Well the poll is closed and the results are in. And the results are a bit, well, puzzling.

Duration	Responses	% with equal or better cycle time
< 1 Month	21	60%
1 Month	2	66%
2 Months	1	69%
3 Months	3	77%
5 Months	0	77%
8 Months	5	91%
1 Year	1	94%
2 Years	1	97%
longer	1	100%

I was surprised how slowly people responded to the poll. The sprint duration poll produced 20 responses almost immediately. This time, maybe 10 people had voted, despite high traffic and even after I published it on the scrum development list.

So I published it on the Xing Agile Methods forum and the Xing Forum English Project Management Lounge and got some more responses. All in all, 35 votes: 77% claimed 3 months or less, 23% reported 8 months or more. A very small sample, but perhaps some interesting trends can be found in the data...

First of all, I think there are more results from agile companies than non agile companes, so while the proportions within the groups (<5>=8 Months) may well be OK, I do believe the slow group is in reality the larger group. But how to prove this? And why the low reponse rate?

Could it be that most people don't understand the relationship between speed and success in the market? Next time I will be sure to add the responses "Don't know" and "Don't care" (perhaps, "not an issue" would be a bit less provocative).

Or perhaps is this is an issue which companies focussed on agile are aware of, but people from waterfall companies really don't know -- or maybe just don't want to admit -- how big the difference is between themselves and their more agile competitors...

Here are some Lean questions for you: if your company cycle time is high (say a year or more), what would it mean to reduce the cycle time by a factor of two? Say from two years down to one, or one year down to 6 months? What does it mean to have competitors who are 4 times faster than you? What would it mean to be 4 times faster than your competition...?