Scrum Team availability

If you read XP or Scrum books or online sources you find that team is a stable group of developers who work full-time to accomplish the goal. The recommended way of estimating its capacity is to use historical velocity and team members report effort remaining in hours to have daily updates of the burn down charts.

In agile estimation the estimate of the complexity of the features, often expressed in story points, is the easy part though not trivial. In my thesis I have a small experience report about the variability of the feature sets, but I will leave that now. Instead I want to talk about the variability of the team’s capability to implement what they have promised.

In real life the organizations are not so lean that they have dedicated teams for the development. Instead, each developer has responsibilities in multiple projects and also critical maintenance work that must be done as soon as possible. An of course, they are also vacations, trainings, corporate administration and common meetings.

Some the capacity variation mentioned in the previous chapter is known or can be estimated in the Sprint planning. Using just velocity averages assumes that this variability is irrelevant and averages out in a large number of Sprints. But if we know that most of developers have their vacation in July, then it is just reasonable to take that into account and adjust the promises accordingly. In my own Sprints I have asked every developer individually how many person days is he/she available for Sprint work. That is best guess of the capacity at the moment. An then the team limits the work into that. Naturally, there is a mathematical relation between velocity in story points and capacity in person days. So you can still use story points as your unit if you want.

We could argue about the best guess of the capacity. In historical average velocity we take into account the average changes of the availability of the developers, because we count only the story points of realized features. It could be better estimate of the capacity if the developers have optimistic bias in the Sprint planning. But in averages we don’t have known capacity deviations as we have if we ask the capacity from the developers.

The real variability of the capacity occurs during the Sprint. It is not enough that team members report the effort remaining of each task. Suppose that I have promised to be available 15 person days in the Sprint and I get an urgent need to put 10 days to something else. Then it is quite natural that I tell that as an impediment in the daily Scrum as soon as I know about it. The consequence might be that a feature is taken away from the Sprint. Obviously the burn down chart would have told the same thing but not so early.

I think that it is relevant to take availability variations into account in Agile projects, because they have impact on the stress level of the developers with all of its consequences. The variability has also consequences in releases especially when we work in a project which has many teams that depend on each other. Realistic daily view of situation is needed.

That’s it today. A long story of a small but important detail.

Agile adoption strategy

In information security area, it is common to talk about strategy. I have used the following paper that condenses what is important: Information security strategy.

The case of agile adoption is similar though the details are different. In both cases we need some funding to make deep changes in the way we work every day. To even start we need decisions about who does and what and why just that. Large bureaucratic organizations love their process guides and still more they want to spend in developing tools for the forthcoming needs. It is not a coincidence that we have so many agile tool vendors. In the following I adapt the previous paper to agile adoption.

A strategic approach that works

1. Implement baseline practices
Typical organizations have a dysfunctional practices or a few of them. Starting with something that gives immediate and visual results is something that is needed to justify spending. Starting with Scrum-type retrospectives is a good choice because it gives us subjective measures of how successful we are when we continue. I like to call retrospectives Japanese quality circles to emphasize that agile adoption is a quality improvement initiative

2. Analyze your value stream
Now it is time to start what the consultants and coaches are so eager to sell you. Analysis will give you ideas of improvement. At least you must check the impediments of your agile adoption. If you don’t have support of your customer or your upper management, it might be very difficult to succeed. I like Admed Sidky’s agile adoption framework which gives you the order in which you should implement the agile practives.

3. Prepare business case for the improvement(s)
Now you must justify the adoption of the individual practices. Note, of course that they depend on each other. Creating a business case for each adoption step also gives you a view in which order your organization should go ahead. Of course you must consider risks as well.

4. Initiate your improvement programme
Now you are on your way with real money and as always with people and organizations you can’t predict what happens. So you must use empirical process control to steer your way. You need to establish the part of organization that facilitates transparency, inspections and adaptations. Becoming public is a necessary part of this programme. People, all of them, are an essential part of this. They make the adoption successful, not the things ivory towers can deliver.

5. Manage and deliver the programme
If your agile adoption goes as normal, more and more of your problems will surface. Some of them can be handled by the teams, but some others need corporate level development projects. Of course, your programme has multiple deliveries.

6 Review progress
In continuous improvement initiatives like this you must have your Deming cycle installed so that you can really facilitate your way to success.

This is it this time – a draft that can be extended. Comments are allowed in this blog. Because I do not visit very often, it may take time before I publish them.

Agile and traditional requirements in Systeemity├Âlehti

Our article about agile and traditional requirements is published in the latest printed Systeemity├Âlehti 2/2009. Its content can be partially found in Tieturis discussion forum.. In Finnish, sorry ­čÖé

Then something that I did or did not say in this discussion.
The word “requirement” is harmful because business decisions about content and technical decisions about its implementation depend on each other. So, the business decisions can’t be done in a vacuum before any technical issues. This means that in a software engineering project there is no phases of requirement development, design and so on.

From lean we find that we should postpone decisions to last possible moment, because we have then more information and we can assume that we make better decisions with better information. We should even study carefully multiple options before we commit to any of them. And that is not waste. It is also important that we use scientific method in our decision making. For example we test the architectural choices before we continue.

The role of specifications is also different. We start with minimal specifications and use face-to-face communications to make sure that that the parties of the development understand each other. Specifications are not the maintenance documents of the forthcoming software because they change quite much during the development.

A month gone

I started this blog more than one month ago. I have written almost nothing about lean and agile software development. I mean here, because I do that almost every day at work..

The main reason for starting a new domain was to get rid of spam. It means that I change my email-addresses. It was a surprise that I take part in so many mailing lists. Most of my email was actually not spam but mails that I hope to have time to read. Updating an email-address in Software Engineering World, ECOOP and so on was quite easy.

Then I have bought a book or something 10 years ago and they still hope that I return. Finding all of them in my gigabyte of email might not be feasible. I don’t even try because I can find them again if needed. The same applies to registrations of products that I have bought.

My one-time registrations are collecting spam to free anonymous mailboxes. No problems.

I suppose that this all is done after summer.