mikkeman.nl

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.

Back from vacaction. It was nice, 2 weeks in the heart of France. Perfect weather, nice day trips. I read a few books (see my previous post) and am back to work now.

What’s up next? At the moment I’m working out a publishing schedule for this blog. Sounds easier than it is. At least for me. Although I really love to have my own blog, I’m not actually flooded with concrete ideas for interesting posts. I’m quite confident that things will work out, maybe I’ll consult some colleagues.

Next week will be busy.

Monday is my regular evening to work for Find’em, a new startup I’m running with a friend of mine. Just before my vacation we introduced the concept to a few Dutch study associations and their reactions so far are positive. We are working hard to make sure this website will serve its audience well. In the coming months we expect some more associations and companies to get on the bandwagon.

Wednesday is a network event by alumni association Eksbit. A few members organized the evening “Nieuwe Werkers… of het Nieuwe Werken?” at the Microsoft office in The Netherlands. Already 40+ people signed up and the program looks nice. There will be several speakers and room for discussion about the consequences of information technology on people’s work and office space. More working from home, less commuting? Or is face-to-face contact underrated? What are the benefits and drawbacks for people, organisations and society? Next to that, I hope to talk to some people I haven’t seen in a while.

Thursday evening is a Meet and Eat with my colleagues of Whitehorses. We meet and… we eat (duh). The meeting is about our new website (which is about to be launched, exciting!) and the role of blogging in this new website. My colleague Edwin Biemond promised to enlighten us on running a successful blog, he has a respectable audience on his Oracle and ADF blog. And also an excellent opportunity to catch up with colleagues (you don’t see each other too often when you’re working at a client site).

For now, have a nice weekend!