Friday, May 30, 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:
  1. Are iterations time-boxed to less than four weeks?
  2. Is the software tested and working at the end of an iteration?
  3. Do iterations start before specifications are complete?
  4. Does the team know who the product owner is?
  5. Is there a product backlog prioritized by business value?
  6. Does the product backlog have estimates created by the team?
  7. Does the team generate its burndown charts and knows its velocity?
  8. Is the team protected from project managers (or other people) disrupting its work?
This week's quick poll has 2 parts. The top part, are the Nokia questions, the bottom, your total. (The number you give in part 2 should correspond to the number of boxes you clicked in part 1, but that's obvious, and you'll remember to vote on both, right?)

As usual, I will post the results in this space in a week's time.

Thanks!

[Update - Joe pointed put out two important flaws in my retelling of the Nokia test which are now reflected in this post - see the comments for more details. Thanks, Joe!

Unfortunately this meant editing the poll, which means throwing away the first votes, so if you have already voted, please vote again. Thanks!]

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 Pressure
  • Handle customers who want additional scope for no addtional money
  • Stop and correct a decline in Software Quality
  • Manage Developers who are "out of control"
  • Quote and deliver fix time/fix price/fix scope projects
  • Reconcile the many interests of the many people in the project
  • Smooth high developer peak workloads
  • Make Better Estimates
  • Improve Process Maturity
A tall order. And, as most of the users were already using TargetProcess, there was an implicit wish to know TP better to solve their problems.

I like doing Scrum courses and workshops, because of the information exchange which really flows in both directions.

Like every good teacher, I have a questionnaire for the participants at the end of the course. Mine is patterned on a Scrum retrospective: High Points, Low Points, What should be improved?

What came out was that the particpants were satisfied to very satisfied. It's important to find out at the beginning of the course what the participants expect, and make sure that those points are covered by the end of course. Beyond that, the wishes were quite diverse. Some wanted more concrete examples and more discussion. Others wanted to spend more time on the exercizes. Others would like the theoretical part to provide more background on Scrum, to compare and contrast it more with the established approches, or to show how to scale Scrum in a larger organization.

All in all, a lot of food for thought, and so, in the spirit of continuous improvement, I am looking forward to preparing the next course!

Wednesday, May 28, 2008

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.

Friday, May 23, 2008

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...?

Tuesday, May 20, 2008

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 context
Participation 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.

Monday, May 19, 2008

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 Conference
  • June Scrum Breakfast in Zurich
  • Course - Agile Project Management with Target Process
Vote! 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 experiences with converting to agile methods in the Gmail project. 12 other speakers will present topics ranging from software quality to current technologies like Silverlight, Rail, Flash, and much more.

This should be very interesting for anyone who wants to improve their software development practice, either and the management or engineering level. BTW - attendees of the Scrum Breakfast in Zürich qualify for member rates at the conference. Let me know if you want to qualify.

June Scrum Breakfast in Zurich

Professor Stuart Read of the IMD in Lausanne will be giving a talk on Guidewire, a 500 person software house organized entirely according to scrum. If you want to see how Scrum can help your company achieve competitive advantage, this talk is for you. Register for the talk and join us for lunch.

And last but not least:

Course - Agile Project Management with Target Process

This week, I will be holding my new course Agile (Scrum) Project Management with Target Process for the first time. Andrey Mihailenko and Eugene Khasenevich from Target Process will be joining 8 participants from 3 countries. I'm excited (and working hard to get the finishing touches on the course program done!). BTW, even though the registration deadline has passed, there is still room for one more person to register.

Thursday, May 15, 2008

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 corporate agility is now a bookmarkable link]

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 work
  • bigger/harder stories imply longer sprints

But most argued for shorter sprints:
  • It should be short compared to the length of the project
  • Quicker response to changes/new information
  • More and earlier data points for measuring velocity
  • Achieving closure - there is a feeling of success associated with a successful sprint - the more often the better
  • Agility (and ROI) - the shorter sprint sprint, the quicker you can get functionality to the customer or user
  • Feedback - the sprint end is a chance to learn from the customer and from yourselves - the more often the better
  • Reliability of Commitment - the deadlines are nearer, the committments fresher in your memory
Very short sprints, i.e. 1 week are appropriate for very short projects, say 1 month. To do a 4 week project in 1 sprint, or even 2, does not leave much opportunity for feedback.

Mike Cohn pointed out:
3-week sprints have become very popular over the last 12-18 months. Before then most teams considered them odd ;) Seriously, it's a recent change for most teams
And the closing word:
The preferred sprint duration is the one that works best for your team :)
--Dmitry Beransky
I'll second that!

Thanks to Dmitry, Ben, Ash, Ilja, Paul, Kiran, Paddy, and Brett for their comments, as well as to everyone who voted!

Monday, May 12, 2008

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:
  1. What will the system do? (Functionality)
  2. How with the team implement the system? (Tasks)
  3. 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 actually implement the individual functions in the course of one sprint. The fundamental message is that the team is delivering working functionality every month. The functionality may be a very small increment, but it is working and tested and of production quality.

The priorities define what the customer would like to have next.

So: you negotiate work between team and product owner purely on the basis of what the system will do. You also measure progress based on how much of the needed functionality has actually been implemented.

How do you measure progress? At the beginning of the project, sum the estimates for all the functionality required. At the end of each sprint, deduct the estimates for the functionality actually completed (adjust as well for changes in scope which were caused by adding, removing or reestimating stories). Do not deduct anything for work partially completed (not done) or for work with does not provide actual functionality (e.g. a design document). Graph the estimated remaining effort as a function of time. This is the burn down chart. If you keep the sprint length constant, the slope of the chart (your velocity) will validate your estimate for the time needed to complete the project. Expressed mathematically:
  • estimatedSprintsRemaining = roundUp(functionalityRemaining / functionalityAccomplishedProSprint) ; 0 )
  • estimatedTimeRemaining = estimatedSprintsRemaining * sprintDuration
If your estimates are right and you scope is constant, then estimatedSprintsRemaining should decrease by one every sprint. If not, there is a problem, and the product owner and scrummaster need to deal with it.

So you see, at the planning and controlling level, we don't talk about "tasks" at all, only functionality.

Question 2 is the responsibility of the team.

At the start of each sprint, the team commits to a set of functions to be implemented by the end of the sprint. As a first step, the team decides what has to be done to implement the agreed upon functionality. This is a list a of tasks and each task is estimated in hours. The estimate at the user story level is usually more abstract. This estimate is updated daily. How much work is remaining (how much has been invested is not relevant!). This is also graphed daily to produce the sprint burn down chart. The slope of this graph tells you whether the team expects to complete all the functionality of the current sprint.

Question 3 is also the responsibility of the team, but the level of quality you need to achieve depends on the larger goals of the system and is best agreed on with the product owner at the beginning of the project. If the system has an expected life of more than 6 months or so, the architecture will have to grow and change over time. Your engineering practices must support that. Otherwise your test and maintenance costs explode, and after a few years, the system is no longer maintainable and you have to build something new. (Explaining this to customers outside the IT branch can be difficult!).

Implementing architectural changes is called refactoring and being able to refactor reliably is an essential engineering discipline. To do this effectively requires extensive automated test suites -- "as-built documentation" -- not extensive blueprints written before anybody wrote a line of code.

Project Overview with Scrum

So with through the Product Burn Down chart we review progress toward the overall goals, and with the Sprint Burn Down chart we evaluate progress to the immediate goals on a daily basis. Taken together, these two charts forecast whether the project goals will be met.

A detailed architecture specification at the beginning is not helpful. The architecture needs to adapt over time. So keeping it minimal and flexible is usually advantageous.

Thursday, May 8, 2008

Quick Poll: How long to sprint?

Following the discussions both elsewhere and on this blog about how long to sprint, the questions poses itself - what is the preferred sprint duration?

I've set up poll - please share with world how long you sprint for!

Thanks!

[Update May 15: The results of the poll with the definitive(?) answer how on long to sprint is now a linkable article]

Wednesday, May 7, 2008

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 or end.

By mainting a constant 4 week sprint duration, you can guarantee to management or to customers an average response time of 6 weeks, and a worst case of 8 weeks. If the sprint duration is variable or not defined, it is very difficult to measure or calculate how agile the team is, which is probably a synonym for "not very".

BTW - there are a variety of strategies for improving this measure of agility: shorter sprints, multiple teams with overlappying start dates (you're never more than 2 weeks away from a sprint planning, so you average response time is reducted from 6 weeks to 5 weeks, and the worst case from 8 to 6 weeks).

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:
  1. dealing with complexity
  2. maintaining 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 the parameters violates the Sprint Contract, and this is clearly not allowed.

Harry Sneed's "devil's square" shows the relation between Scope, Quality, Time and Cost.

And the end of each Sprint, the Product Owner inspects the progress of the team -- defined exclusively through the amount of scope produced -- and has the option of changing the course of the team.

Changing any of the other parameters, say the duration of the sprint, is 1) a violation of the sprinnt contract and 2) hides from the project owner that progress is not being made as planned (or hoped). He is deprived of the chance to make a course correction.

I believe there is a close correlation between corporate agility and fixed length sprints, so the next question should be, how long to sprint...

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 cases and research in the following areas:
  • New ventures and innovation
  • Specifically investigating expertise in the entrepreneurial domain
  • Marketing of innovations with network externalities
  • Non-predictive strategies that enable managers to effectively make decisions in situations of true uncertainty
His academic credentials include a Ph.D. in marketing from the University of Washington and a Bachelor's degree in computer science from Harvard University. He has nearly 20 years of industry experience, having participated in the creation of six high technology start-up firms. Four of those firms were acquired by industry leaders including Sun Microsystems and Lotus Development Corporation. Two are publicly traded. Stuart also spent 6 years with enterprise database software provider, Oracle Corporation.

The Scrum Breakfast in Zurich is a monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. The Scrum Breakfast takes place the first Wednesday of each month. The program starts with a short presentation about on an in interesting topic around Scrum. Then follows a moderated discussion among the participants to encourage an exchange of know-how and experiences.

The talk will be held in English.

Attendance is free and our sponsor namics provides the coffee, gipfeli (croissants) and orange juice.

Date: June 4, 2008
Time: 10:00 to 12:30 (Special Case!)
Location: namics ag, konradstrasse 12, 8005 zürich

Registration for the Scrum Breakfast via xing or via comment (won't be published). If you wish to join us for lunch, please register separately at xing.

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:
  1. Eliminate waste
  2. Amplify learning
  3. Decide as late as possible
  4. Deliver as fast as possible
  5. Empower the team
  6. Build integrity in
  7. See the whole
Personally, 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 look forward to discussing those principles with the Scrum Breakfast community.

The presentation (in German) Schlanke Software-Entwicklung: von der Idee bis zur Rendite ("Lean Software Developement: getting from the Idea to Profitablity") is now online.

Monday, May 5, 2008

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

Two quick reminders:
  1. 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).
  2. 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!