Skip to main content


Showing posts from May, 2008

Quick Poll: the Nokia Test

Last week, I asked the question, "How agile are you?" which I defined in Lean terms, i.e. the amount of time needed to generate business value for the customer.

It turns out, just as Scrum teams create a formal definition of done, there is a widely accepted minimal definition of doing Scrum: the Nokia test (Jeff Sutherland Video) (see also the description in text form from Joe Little and his commentary on the Nokia Test).

The Nokia test asks 8 questions. The first 3 determine whether you are doing iterative development and the remaining 5 checks whether you are doing Scrum:
Are iterations time-boxed to less than four weeks?
Is the software tested and working at the end of an iteration?Do iterations start before specifications are complete?Does the team know who the product owner is?Is there a product backlog prioritized by business value?Does the product backlog have estimates created by the team?Does the team generate its burndown charts and knows its velocity?Is the team prote…

Retrospective: Scrum Training with TargetProcess

Last week, I gave my first public course on "Agile Project Management with Scrum and Target Process". Preparing a course is quite demanding, and I must admit, I underestimated the effort involved. But as any Scrum master knows, there is no problem that can't be solved with a good supply of Post-Its...

The participants were a very diverse group: 4 coming from Switzerland, 2 from the UK, one each from USA, Germany and Belarussia. Investment Banking, Media, Industrial Software, Internet Technology. Quite a diverse group. But they had more in common than you would expect. They wanted to improve thier ability to complete projects successfully. What did problems did they have or rather want to solve?
Win bids in the face of Price PressureHandle customers who want additional scope for no addtional moneyStop and correct a decline in Software QualityManage Developers who are "out of control"Quote and deliver fix time/fix price/fix scope projectsReconcile the many interest…

Lean Software Development and Scrum

Today (May 28) I will be giving on a talk on Lean Software Development, the optimal route from the Idea to Profitability at the Internet-Briefing Developers Conference. Well the talk is in German, so I guess I should call it by its German name "Schlanke Software-Entwicklung: Der optimale Weg von der Idee zur Rendite".

If you miss the management guidance offered by something like Rational (RUP), then Lean fills the gap while applying and extending agile principals. I'll be giving an introduction to Lean, present its principals and several tools, and show how it relates to Scrum and XP.

Of course you can download the slides to my talk: Lean Software Development, the optimal route from the Idea to Profitability.

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.
DurationResponses% with equal or better cycle time< 1 Month2160%1 Month266%2 Months169%3 Months377%5 Months077%8 Months591%1 Year194%2 Years197%longer1100%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 o…

CH Open Source Award 2008

The Swiss Open System User Group (/ch/open) announced the CH Open Source Award 2008. Prizes will be awarded in 5 categories:
Swissness - OSS Project with essential Swiss participation
Business - FOSS Service Company, which supports FOSS Projects
Pioneer - a Company or Public Instituion which leads by example in the use of FOSS
Advocacy - a Person who has made a special contribution to the development of FOSS
Youth - a Person still in school who has engaged himself for OSS in an educational contextParticipation is open to people and organizations that live in, go to school in switzerland or have a significant presence in Switzerland.

I have been a member of /ch/open "forever" and am honored to serve on the Jury.

Application deadline is June 27, 2008. You can apply on line or contact Andreas Heer directly.

Coming Events - May & June

There's a lot happening in the next few weeks:
Vote! 3 days left: Quick Poll - How well does your company deliver Business Value?Internet Briefing Software Development ConferenceJune Scrum Breakfast in ZurichCourse - Agile Project Management with Target ProcessVote! 3 days left: Quick Poll - How well does your company deliver Business Value?

There was a lot of interest in the latest quick poll - How agile is your company? For the first time, I had over 100 visitors in a single day, but the actual number of answers has been modest. So vote! (Poll is top right on the page). And if you can get me slashdotted, that would be great!

Internet Briefing Software Development Conference

Next week, Reto Hartinger's will be holding back to back conferences on Successful Project Management and Rich Internet Applications. I have the honor of opening Day 1 with a discussion of Lean Software Development. Jean-Pierre König of namics will present Scrum and XP, Aaron Arcos of Google will present his …

How agile are you?

In a recent post, I proposed a practical definition of agility: the average case amount of time required to deliver value to your customers, measured from the point where you have the go ahead to do the work to the point where that functionality is available to the customer (or user).

I thought for an agile team this would be 1 1/2 * Sprint-Length, but that is an over simplification, because I ignored things like project preparation, acquiring resources, regression testing, etc. which may or may not be negligible.

So I ask you, what is the minimum time, from the point where the customer says do it to the time you've delivered the functionality and he can use it in your company. The poll is on a modified Cohn-Scale, i.e. estimates are +/- 50%, so the sequence is basically Fibonacci, but big numbers are rounded to remove the illusion of excessive precision.

Thanks for your help! As with the last poll, I'll post the results after closure.

[Update: May 23: The results of the poll on …

Quick Poll Results: Sprint Duration

Following the discussions both elsewhere and on this blog about sprint duration, the questions poses itself - what is the preferred sprint length? So I ran a poll.

And the winner is... 2 weeks.

According to this very scientific survey (1 week on my blog, 228 Visitors, 50 votes), the most popular sprint duration is 2 weeks, followed by (early leader) 3 weeks, which lost by one vote.

The final results are:
1 week2 (4%)2 week18 (36%)3 week17 (34%)4 week5 (10%)1 month5 (10%)longer, but fixed5 (10%)variable1 (2%)
How long should the sprint be? There are many right answers, some of which argued for longer sprints:
The longest time you can shield your team from changes in workbigger/harder stories imply longer sprints
But most argued for shorter sprints:
It should be short compared to the length of the projectQuicker response to changes/new information More and earlier data points for measuring velocityAchieving closure - there is a feeling of success associated with a successful sprint - the more o…

Prejudice: Scrum lacks an overview

Over the last few days, there has been a discussion on the scrum mailing list on whether scrum provides a good overview of the entire architecture and whether it's possible to know whether the project is on course to meet its short term and long term goals.

There are three questions here:
What will the system do? (Functionality)
How with the team implement the system? (Tasks)
How will the features of the system be realized? (Architecture)
Under Scrum, the product backlog answers question 1 and only question 1. The product backlog is nothing other than a proposed feature list with an estimated effort and a priority associated with each feature.

The features are usually defined as "user stories" such as "a job hunter can upload his resume to the site to speed up applying for advertised jobs". Who wants it? What can he do? Why does he want it? As you get closer to implementing a particular story you may have to break it up into smaller stories, so the team can actuall…

Sprint Length vs. Team agility

A practical measure of agility: What is the minimum time that a team (or a company) needs in order to deliver an increment of business value to its customers? This is more formally known as "minimum cycle time."

Example: Your sprint duration is 4 weeks. So how long does it take to deliver an increment of business value (where that increment is doable in the course of a single sprint)?
Best Case: 4 Weeks (request arrived just in time to be included in the next sprint)
Worst Case: 8 Weeks (request has to wait out a full sprint before being prioritized)
Average Case: 6 Weeks (1 1/2 * sprint length).
Why? It's clear the team needs the duration of one sprint to realize the functionality, but under normal circumstances, the team can only start processing a request when that requested is included in the planning meeting at the beginning of the sprint. So it has to wait until the start of the next Sprint. That duration depends on where you are in the current sprint: beginning, middle…

Why fixed length sprints?

One common question for people new to Scrum is, "why should the length of the sprint be fixed?" What harm does it do to extend a sprint or plan the length of the sprint according to the task at hand?

There are probably as many answers to this question as there are ScrumMasters (25'000 the last time I looked), but two factors stand out:
dealing with complexitymaintaining agility of the team (and by extension of the company).Under Scrum, we keep complexity under control by defining the parameters of each sprint. Time (calendar), Quality (through the definition of done and possibly other functional requiremens), Cost (team size * time available) and Scope for each sprint. Since Time, Cost and Quality are defined, the only thing which can vary is the amount of functionality actually produced. This is what is inspected at the end of each sprint.

I like to refer to the agreement between prodoct owner and team as the "Sprint Contract". So arbitrarily changing one of t…

Scrum Breakfast in Zürich, Guidewire Case Study

[ Update - some 30 people attended - part 1 of the summary is now online ]

This month we are honored to have a special guest to the Scrum Breakfast in Zürich: Stuart Read, Professor of Marketing at the IMD in Lausanne.

You already know Scrum. You have likely seen it at work. In this discussion, we will investigate Guidewire Software, a financial services firm built completely on Scum. Not only does the firm use Sprint teams for every function in the company, the firm has used Scrum since its founding day. I encourage you to review the case study so we can have a focused discussion on the issues around such a complete adoption of the methodology, especially as the firm expands beyond 500 employees.

About Guidewire

Guidewire Software exclusively serves the property & casualty insurance industry. Guidewire builds and implements the core systems on which insurance carriers run their businesses.

About Stuart Read

Stuart Read is Professor of Marketing at IMD. He is currently developing cas…

Scrum Breakfast in Zürich: Lean Software Development

I started doing Scrum intensively back in 2005. It was a revelation. Finally a project management framework which actually made sense, which led to destination instead of just producing mountains of paper.

Scrum raises as many questions as it answers. Scrum teams become islands of productivity in oceans of corporate inertia. How can we apply the advantages of Scrum to the rest of the company?

So it was another revelation when I started to read about Lean Software Development and Lean Product Development. Lean not only explains why Scrum works, but also provides simple principles to maximize corporate effectiveness:
Eliminate waste
Amplify learningDecide as late as possibleDeliver as fast as possibleEmpower the teamBuild integrity inSee the wholePersonally, I am tempted to rename the first one, "Produce value for the customer"; it may seem like the flip side of the same coin, but the customer wants value and that value is what he is willing to trade time and money for.

Today I loo…

Reminders: Scrum Breakfast and Agile/Scrum Training with Target Process

Two quick reminders:
On Wednesday, May 7, (Scrum Breakfast) I will talk about Lean Software Development and how it relates to competitiveness of your organization and how to realize it with Scrum. Register Online at Xing or leave a comment on this thread (which will be kept private).
There are presently 6 places left in the course Agile (Scrum) Project Management with Target Process. 50% Introduction to Scrum, 50% Intro to Target Process, May 21 and 22, to be held a namics' Zurich office. Info & Registration.
Hope to see you soon at one of these events!