How long to Sprint?

As we were preparing to use Scrum, the customer asked, How long should a Sprint last? What is the right length for a Sprint? Should it always be the same, or can we vary the tempo?

There are general considerations, but these will be influenced by the specific situation.

Here in Switzerland, the public transportation runs on a beat. The intercity train from Zürich to Bern leaves every half hour. There's a train on the hour and at 32 minutes past the hour, every hour, and they arrive 57 minutes later - dependable and predictable. This is a good reputation for software teams to strive for.

The neighborhood bus that takes me home applies almost the same deal: 17, 37 and 57 minutes past the hour during rush hour. But during the day, the bus suffers from what's known as a Taktbruch - breaking the rhythm. During the day, it leaves at 17 and 47, and on the weekend it's completely different. So I have to remember when which frequency applies, which makes me (and everyone else) much less likely to use it.

So, lesson number one about Sprint duration: it's OK to experiment at beginning, but then you should set a duration and then stay with it. That makes it easier for everybody.

Based on the bus & train example, you might think shorter is better -- If that bus comes every 5 minutes, that's more convenient for the customer -- but a passenger has no work to prepare for the bus's arrival, except when s/he actually plans to take that bus.

Short sprints do have a number of advantages:

• Intense customer contact
  
• Frequent Examination of Project Situation
  
• Quicker Feedback Cycles
  
• Good for Building Trust with Customer
  

But short sprints are not without their disadvantages:

• Harder to tackle big problems
  
• More Meetings and Preparation
  
• Developer Acceptance
  

In my experience, one of the hardest parts of adopting Scrum has been convincing developers that they can deliver incrementally. This is made more difficult by limiting the time available for Sprint. (Having said that, once the developers are convinced it is worthwhile to release incrementally, then convincing them that they can actually do it becomes easier.)

More meetings can be an issue. Sprints have a regular meeting cycle: Preparation (Scrum Master and Project Owner), Estimation (Team), Sprint Planing I & II (all), Sprint Retrospective (team). This predictability is good, every thing can be planned months in advance, but it occupies a lot space in your calendar. There may also fixed costs associated meetings, e.g. travel time, so the time spent in meetings may not shrink linearly with duration of the Sprint.

In our case, we had seven weeks to clean up the software and get out a release by Christmas. We started with a two week sprint. I had proposed a one month sprint, but the customer wanted to have a chance to influence the process. So we did 2 - 2 - 3. The second and third sprints were release Sprints. Functionality developed in the previous sprint was shipped (tested and accepted by the customer) and deployed on the live server. The second release was a "major release", with database changes, so teh customer wanted to do more regression testing, but since three weeks was what we had available, it worked out perfectly.

We noticed quickly that Sprints on a two week cycle was a lot of work for everybody involved, especially the product owner (who previously, as a mere customer, had relatively little to do). But the P-O was wary of not being able to influence the development for a month at a time, so we decided on a three week sprint interval.

This proved to be a good compromise, somewhat unconventional, but even after 22 sprints (and yes, Virginia, once in while, we did make changes to the plan to accommodate issues we couldn't control), no-one is talking about changing the beat.

Sprint Zero

When I joined the project, we had just finished a release, but didn't have a clear definition of what to do next. So the developers were instructed to use the time productively, to wrap up whatever they were doing or do any long postponed housekeeping. I didn't want to take time to figure out what they were doing, much less tell them what they should be doing. So it was their first taste of self organization.

The customer was a bit skeptical about Scrum, but given the problems to date and the time pressures, he was willing to play the guinea pig.

During Sprint Zero, we got ready for our first Sprint. Scrum makes very clear what needs to be done before you can start Sprinting.

Scope, Quality, Cost, Time. These are the factors that any project manager has to have under control and these are defined very precisely for each sprint.

One one level, getting ready for Scrum means getting an initial definition of the project parameters. On the other level, getting ready for Scrum means educating the people involved (team and customer) so they know what is expected of the them, what they can expect from the other players, and how they can influence the process.

Scope

We had many feature lists, bug lists, wish lists and absolutely no idea what was really important. So this first step was to define the total scope. I collected all the feature lists, wish lists and bug lists I could find, and sent them to the customer with instructions to consolidate and prioritize the list on a scale of 1 to 3. The consolidated list had over 100 entries, and customer himself realized that the list of priority 1 items was so long that he had to introduce a Priority 0 to mark the items that were really important to him. This consolidated list became our product backlog.

During Sprint Zero, the team estimated all the Priority Zero and good chunk of the Priority One tasks (the twos and threes we left for a later date, which turned out to be never).

Quality

The team's first task was to take an hour or two and come up with a definition of done. Here's what they came up with:

• Tested (Unit Tests, Test Casses passed)
  
• Deployed on the Acceptance Test Server
  
• Documented (JavaDoc)
  
• Checked into Subversion
  
• Successful build
  
• Successful check-style
  
• Completed code review
  
• "Usable" for the User, approved by our usability guru
  

This last point had some problems with it, which I will write about some other day.

The team was also introduced to Scrum during this period, but that is also a topic for another post.

Time

How long should a sprint last? 2 Weeks, 4 Weeks? Originally my thinking was true to the book, 1 month. But we had a serious trust problem with the customer and substantial pressure to get a release out by the end of the year. So the customer wanted to work closely with us.

Not knowing what a release really entails, but knowing that a release takes about 3 weeks (with only 7 weeks left in 2006), I suggested we do a two week sprint, with a dry run release to exercise the process. Then another two week Sprint to get all the urgent functionality finished for the December release.

This idea was accepted, but the pressure from the customer's customer to get out a new release with bug fixes and missing functionality was intense, so we ended up installing our dry run release as well. This proved to be an important learning experience.

Cost

In our case, cost is defined by the number of developers assigned to the project and the duration of the Sprint. Sum for your team (Availability * Duration * Daily Rate) = Cost. Actually it's a cost ceiling. Under Scrum, there's not much overtime, so there is an upper limit on the costs defined by the time.

The actual cost will be lower, because people provide support, get sick, take a day off, get called urgently into another project, whatever. (Real availability of the development staff for actual development work can be a very hot topic with the product owner).

Communicating the upper limit proved to be a very good trust building measure. Our actual costs were always a bit lower, so the customer was always pleasantly surprised by the actual invoice.

Once we had the team prepared, the product backlog in place, and agreement on the Sprint Duration, we were ready for our first planning meeting.

Really Getting Started

"... and do exactly what he [Ken Schwaber] says."

Sounds easy, doesn't it? Well, it is, and it isn't. And mostly it's not. But the Ken Schwaber's book does outline how to do Scrum and it does work. Even if you don't do everything, you'll get better, but you do have to get key things right or it can backfire on you.

I've had the "pleasure" of taking over two foundering projects and converting them to Scrum. So there is the way I did it. And there is the way I would do it, the next time I have the situation.

My first big project had been in development for over two years before I got involved. They had done two releases, but the releases were perceived by the customer as being of poor quality, there was much missing functionality (functionality which his customers needed, but for whatever reason, wasn't in the product), and the the functionality that was present had bugs.

The emotional level between my company and the customer had deteriorated to the point where customer and project manager were barely on speaking terms. The issues had escalated to the Executive Management Level at all three companies (Us, Our Customer, Our Customer's Key Customer). It was one of our largest and commercially most important projects, so it was important to get things back on course quickly.

I had been promoting Scrum in the company for some time, so when the company asked me to take on this project, I took this as a mandate to do Scrum. I didn't really discuss it, I just did it. Since everyone was at wit's end, no one really argued, but that caused some issues further down the road.

Before officially starting with Scrum, we did a Sprint Zero. This wasn't really a proper Sprint, but was more a transition period until we were ready to do our first Planning meeting.

To be continued...

Next Scrum Breakfast in Zürich Feb 6, 2008

At the next Scrum Breakfast in Zürich, Marcello Leonardi, Scrummaster of the namics Project White Label Classifieds will present his experiences with this project. WLC -- known in the market at "Publisherconnect" – is the basis for many classified advertsing market places. Some of the more prominent examples include NZZexecutive.ch, Publicjobs.ch, osthome.ch, pilote.ch hand many others. Marcello has been a member of the development team since over 1 year and took over the scrummaster Roll about 6 months ago. He will talk about the project, both from the perspective of a developer and from that of the Scrummaster.

Topics:

• WLC Project Overview
• Introducing Scrum into the WLC Project
• Current State of the development of WLC 5.0
• Leasons Learned

Date: 6.2.2008 (always the first Wednesday of the Month)
Time: Doors open at 8.00am, conclusion 10.00am.
The talk starts at 8.35 (so that you can come by train at 8.30 and still be on time).
Location: namics ag, Konradstrasse 12, CH-8005 Zürich

The talk will be held in German.

Attendance is free and namics is sponsoring the coffee, gipfeli (croissants) and orange juice. To register, just send me a private message or better register on xing: https://www.xing.com/app/events?op=detail;id=171305

How to Start Doing Scrum

I got interested in Scrum when I heard about it at MySQL. They had something called a Daily Scrum, in which all the developers participated. Not working in development, I wasn't part of that process, but a year later, I was wandering through Barnes & Noble at Crossroads Mall, and there was Ken Schwaber's Book "Agile Project Management with Scrum".

My previous contacts with project management convinced me that project management was about estimating and counting beans, producing lots of documentation, and other very useful tasks. Maybe something a bank or other large enterprise would want to do, but somehow very removed from the actual process of producing software.

Ken's book spoke to me, so I bought it. It was a revelation! Finally a book on project management that actually provided useful information about how to plan, estimate and organize a project. A book that talked about people, what they should be doing, and how they should organize themselves.

So if you want to start doing Scrum, start with Ken's book and do exactly what he says.

Why the name Scrum Breakfast?

The Scrum Breakfast in Zürich is an event which I organize and moderate. Sponsored by my future ex-employer, namics, the Scrum Breakfast is monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. 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 Scrum Breakfast takes place the first Wednesday of each month. The doors open at 8am and the talk starts at 8.35 (so people coming by train can arrive at 8.30 and still catch the start of the talk). The presentations & discussion are usually in German.

In April, I will become an independent consultant, but I will continue to organize the Scrum Breakfast in Zürich and namics will continue to sponsor it.

So the Scrum Breakfast is a focal point for the Scrum community in Switzerland and that's what this blog should be as well.

Getting Started

This is a new blog about Scrum.

Scrum is a Project Management Framework, right? Well yes and no. Scrum is both a tool for managing projects, but is also a way of life. The heart of Scrum is a simple cycle: Plan, Do, Evaluate, Improve. On the one hand, Scrum empowers the team to get things done. On the other, it empowers the Scrum Master to recognize and remove impediments. This makes Scrum the tip of much larger icebergs, Lean Software Development and Lean Product Development.

The core idea of Lean is eliminating waste. This idea has already transformed manufacturing and has tremendous potential to transform service oriented businesses. A team that implements Scrum will quickly become more efficient, but also start to discover the waste, delays and inefficiencies elsewhere in the organization. Converting the first team to Scrum is potentially the first step in transforming the organization to a higher, more efficient level.

This blog will address the topics that I address professionally:

1. Getting started with Scrum. Getting the first team working with Scrum.
   
2. Crisis Project Management. The project is behind and over budget. Everyone is unhappy and no one sees the way forward. What now?
3. Transforming IT into a Lean Organization - what would it mean to reduce the concept-to-release-time of major projects from 3 years down to 1 year, or even less? How do we do that?