mikkeman.nl

One of the key practices of agile project management is continuous delivery of valuable software into the hands of your customers. Doesn’t that sound cool? Unfortunately, it’s all too common that customers don’t want continuous delivery of software. Why?

There are many reasons why someone wouldn’t want that. It might take too much time to educate your users continuously. Or continuous change to the system might disrupt daily production. These might all be good reasons to delay delivery to once every month (or 2, or 3). Please note, it does not mean you should stop looking for ways to increase the pace in which the organisation can digest change (after all, we prefer shorter time scales).

Recently someone asked “can’t we just postpone this software release with another year to implement many more features?” Of course we could, but why would someone want that? The answer was simple: project funding. Many organisations fund projects to deliver software. When the software is delivered, the project is over. No more funding, no more people, no more project. The software is transferred to a maintenance contract and you might be lucky to have 1 or 2 RFC’s approved in the next 10 years.

If an organisation works this way, it makes perfect sense to order as many features as you can think of, and delay delivery as long as possible. Because you know that extra funding is only negotiable as long as the software isn’t live yet. Your boss will consider your project “done” as soon as the software hits production. Good Bye Budget.

This problem can only be solved on a strategic level. Management should rethink their attitude to project funding. It might make perfect sense for an organisation to have software delivered after a month, and keep the project funded for another year. Such a change would make your entire organisation much more agile (buzzword alert!). Agile project management is much more about these kind of changes than introducing daily standups, pair programming and taskboards.

How does your organisation fund projects? And do you consider that agile?

Picture taken under Creative Commons license from jayneandd’s photo stream.

Photo by ohskylab

Velocity is an agile metric used for making long term schedule predictions. It gives you a range of possible release dates (given a set of user stories) or a range of stories to be delivered (given a fixed release date). Several people have written extensively on agile estimating and planning and the importance of hours and story points in the process.

Please note the emphasis on “long term”. What to do with the short term? How many story points are we committing to in the next iteration? The simplest approach is to commit to the number of story points delivered in the previous iteration. Or use the average velocity of the last 3 iterations. Or take all velocities of the last 5 iterations, eliminate the highest and lowest values and average the remaining three. Or… (I think you can figure out something useful yourself by now).

But. This is a ceteris paribus assumption. It assumes the same team composition, no holidays, no illness, no sudden fires to put out, etc..etc.. I while ago I read this post from my colleague Martin van Borselaer. In that post he proposes to:

1. add up all hours really used for delivering stories in the previous iteration
2. estimating how many hours we have available for delivering stories in the next iteration (correcting for holidays, illness and the like)
3. use the ratio between (1) and (2) to derive the number of story points to commit to

At the moment Martin and I work on the same project and we have metrics from 8 iterations. It turns out that we have a sustainable pace of about 35 story points. It doesn’t really matter if someone is on a holiday, gets ill or we have to put out a fire. The number of available hours can vary up to 40 hours without having a significant impact on the velocity. Of course, this doesn’t hold up for extreme situations, such as extremely long holidays, illness, or that one specific user story you need those specialist skills for (BTW, if this happens regularly, you have a different problem – food for another blog post).

What does that tell us? We now know he team can safely commit to approximately 35 story points without “calculating” the available capacity, as long as we recognize that there will be no significant irregularities in the next iteration.

What should we do with the overhead to register hours worked? It doesn’t add much value to make a useful commitment. However, since the project also has stakeholders that are not so aware, interested or educated in lean and agile, it does add value in our communication to these people. Since it is a lightweight process, the effort to do it can be justified.

Traditionally, software teams are allowed to develop software in a large timeframe. They can read the entire list of features at the beginning of the project. They then usually start designing and developing a generic framework to support all those features. It is not uncommon that developing the generic framework takes more than half of the total project time. The justification is that “once we have the framework, slapping on the features is dead simple”.

As soon as they start “slapping on features”, it turns out to go slower than initially thought.

And as soon as the customer gets a sneak preview of his product, the changes keep coming, which leads to inevitable changes to the generic framework.

Damn.

One of the key concepts in lean/agile software development is to develop software in small, usable pieces. Scrum calls this “potentially shippable”, meaning that a customer may decide to deploy a piece of software and monetize its value. Obviously, such a small piece of software can’t contain all the features the customer ever dreamt of.

But because the customer didn’t ask those features now, doesn’t mean he won’t ask them in the future. Some of those features are even very likely to be implemented in the future! What to do now? Should you build those features anyway? Or maybe partially, just to make it easier to implement them fully in the future? How can we make a generic framework for all features if we are only allowed to build a few? How can we make a generic framework if we don’t know all the features anyway?

The answer is: you can’t.

This is a difficult paradigm shift for teams starting out with lean and agile. Just make the features the customer asked for in this small piece. No more, no less. Experience taught us an important lesson: once you start delivering pieces to your customer, the list of features changes. And keeps changing. Until the end of the project, and even after that. The solution is to make your solutions adaptable.

Adaptable is not the same as generic, although I have met quite a few developers that use these terms interchangeably. Generic means “applicable to all specific situations”, a one-size-fits-all solution. Adaptable means “able to adapt to a certain situation”. Those things are related, but not the same. I have seen too many “generic solutions” that weren’t generic enough to support a new feature (“gosh, we didn’t think of that”). And they weren’t quickly adaptable, because they were designed to be… generic, right? It is not necessary to change a generic solution, so adaptability has never been a design criterion.

On the other hand, if you have an adaptable solution, you just… adapt it to support a new feature. Think about it for a while. It doesn’t matter when you didn’t think of a new feature upfront, because you designed the software to be adaptable in the first place.

Next time when you’re working on a new design, make sure it’s adaptable, not generic. You’ll do your customer (and yourself!) a big favor.