Frequent Small Releases

With scrum, we try to deliver business value every sprint. That’s easier to do with some projects than others. If you have a mountain of technical debt facing you, delivering business value every three or four sprints can be a huge achievement. You might get lucky and find the occasional creative way of delivering business value quickly and easily, but most of the time you simply aren’t going to be able to manage it. Forget about it.

There are a lot different factors that make up a technically mature team, and they often take a long time to put together. Until you overcome those lower level issues, you won’t be able to properly address the higher level issues related to delivering business value quickly. Here is a graphic that I use to help make my point:

There are different levels of technical competence that need to be in place in order to support the rapid delivery of business value. If any one of these levels is missing, it is very unlikely that a team will be equiped to manage their work efficiently enough to deliver business value on a rapid and consistent basis. Teams need to be using source control tools and practices. Until they have source control, a team will not have the technical foundation in place to begin to put continuous integration in place. Once you have continuous integration working, you really aren’t getting the full benefit unless you can provide automated tests with every build. So on the technical side, a team has to have a lot of infrastructure in place in order to even think about delivering business value quickly.

There is another side to this issue that is very much tightly releated – how large are the releases that we make? Here is another diagram:

Here, instead of talking about technical maturity, we are looking at deliverables. At a relatively low level of process maturity, a team is really only capable of delivering files and resources with any real frequency. As the team becomes more technically adept, they are able to deliver components more frequently. As you can see, as the team becomes more and more efficient, they are able to deliver features and ultimately meaningful business value on a rapid schedule. These two hierarchies, the technical maturity and the deliverables maturity are linked tightly together.

So what’s the point? Well, if you are working on a team that is just adopting agile, don’t let anybody tell you that you are going to be delivering significant business value frequently – especially if you are like most teams and have a fair amount of technical debt accrued. It’s not that you can’t get there – you can, but it’s probably going to take a lot of work before you are able to deliver on that promise. People tend to expect immediate results when they switch to agile, and I’m here to tell you that often it just doesn’t work that way. If your teams are anything like the ones that I have worked on, you have a significant number of technical, personal, and other issues to overcome before you are going to be able to deliver the promised frequent delivery of business value. It’s definitely the way to go – I’m not saying it isn’t worthwhile, I just think expectations should be reasonable.

In the meantime, instead of trying to deliver business value every 5 mintues, why not focus on Frequent Small Releases (FSR) instead? Yeah, you heard me right. Learn how to deliver something – anything – frequently first. It’s all part of building a mindset of frequent releases that will ultimately (once the team is ready) culminate in the hallowed goal: the frequent release of business value.

Amen.

4 Responses to Frequent Small Releases

  1. Tim Ramsey says:

    I recently came accross your blog and have been reading along. I thought I would leave my first comment. I dont know what to say except that I have enjoyed reading. Nice blog.

    Tim Ramsey

  2. Tom Perry says:

    Thanks! I appreciate it!

  3. Good post… I would just note that the “automated test” block in your first diagram breaks into unit, acceptance, and GUI tests. Do you have an opinion on how they should be stacked?

    I would suggest that they should be tackled individually (because there is a lot of work in teaching a team about each of these unless they have agile experience), but I’m not sure if there is a required order or whether it should be simplest first because sooner is better.

  4. Tom Perry says:

    Kevin,

    No opinion about the ordering. Well, wait a sec. It may depend on the system you are working on. If it is a legacy system, then sometimes unit testing is harder to accomplish than GUI testing. Both are important, but IMHO trying to retrofit an existing legacy system with unit tests doesn’t make much sense. On the other hand, documenting the existing behavior with acceptance and gui testing makes more sense. My opinion would be the reverse for a greenfield app.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: