Posted by: jsonmez | June 14, 2010

Release Management, Features or Time

There is an interesting constraint in release management that is pretty often ignored.

I think it is worth talking about because not too many people on Agile projects really realize the implications of this simple constraint.

You can either release based on a number of features or a date in time, but not both.

Translation please?

What do I mean by this?

Simple.  Let’s say that you are doing a software release in an Agile project.  (In any project really, this constraint happens to be one of the reasons waterfall projects often fail… death-march anyone?)  How do you decide when to release?  What is your release cadence so to speak?

Think about this for a second.  If you answered “on this date, when these feature are done,”  you are wrong.  You can’t choose both.

I am saying that you can either say, “I will release when X number of features are complete,” or you can say, “I will release every 2 weeks,” but you can’t say both.

A running metaphor

Let us translate this problem to a different paradigm for a second to see if it becomes more clear.  Many people right off will understand this concept, but others will be confused.

Think about running.

Have you ever done a running work-out or did some running training?  Ran a race perhaps?  Biking and similar sports apply here.

Think about the training programs or workouts you have done.

  • You might have a workout that is “run for 20 minutes.”
  • You might have a workout that is “run for 3.1 miles.”

Have you ever had a running program that instructed you to run for 3 miles and do it in exactly 25 minutes?  Pretty doubtful.

I’m not saying it can’t be done.  But, it would be pretty difficult to run for exactly 25 minutes and travel exactly 3 miles.  Most likely you would miss one of those marks.

The same with software development.  Features or time, but not both.  Both is kind of silly.

But we do it successfully right now

No you don’t.  It is called padding.

Back to the running metaphor.  So there is a way to achieve both time and distance.  If you really think about it hard, you’ll figure it out.  If someone was going to pay you a huge amount of money to cross a finish line at a particular distance within 5 seconds of a set time, how would you do it?

I’ll give you a second to think about it.


Well, the strategy I would employ would be to run really fast as hard as I could and come right up to the finish line, but not cross it.  Then I would sit and wait for the remaining time to tick down and cross the finish line, right on the money.

In software development, we call this “padding.”  Padding is a bad word.  Padding will take a productive development team and turn them into lazy sloths.  Once you start padding it is extremely hard to stop.  It becomes the norm.

That is why I say that if you think you are releasing software on a set date with set features, you are wrong.  What you are doing is padding.  Stop it!  Stop wasting your resources and choose one.  Features or time?



  1. “Padding” indeed is a four letter word in software development. I have seen first hand its corrosive powers work against teams. One thing you didn’t mention is the danger to the developer when enganged in padding. I know we are all perfect, so hypothetically speaking, what happens when we wait till the last second to cross the finish line and then trip on our shoelaces?

  2. John, I completely agree with the philosophy that it is either time or feature, not both. But, it doesn’t quite seem to work with offshore teams. Managers in offshore believe that features need to be delivered, irrespective of time lines. And hence quality sometimes suffers when the development is done by the offshore team.

    • Unfortunately it is not just offshore team managers that think that way.

  3. I like the idea. But how do i sell it to my clients? One is: Ok, we agree on which features you get, but i can’t say when. Or: Ok you will have some of the features agreed dat, but i can’t tell which. Will be a tough job selling…

    • You are correct, but let me ask you this question. When you promise them x features by y date, are you just blowing smoke?
      The reality of the situation is that you are either lying or padding when you promise to deliver a set number of features in a set number of time.
      My recommendation would be to explain this simple truth to your client, and let me know that even if vendor xyz makes that promise, that doesn’t mean they can deliver, but…
      What you can do is update them every week so they can get a real time feel for how fast features are being completed and you and have the most realistic projection at any time of when x number of features will be done. A projection based on real data, not WAGS, and one that is updated constantly.

  4. […] Don’t be a Liar I wrote a post talking about how you have to either choose to release based on features or time, but not […]

  5. I call it gold plating. This usually happens if the client requests the features to be done by date x and there are no negotiations. They going to get the feature on time however, it’s going to be quite buggy. On a project im working on, this is impossible as the client views unit tests report (using storyq – on TFS, so no goldplating.

  6. However in terms of the article, you absolutely right John.

Leave a Reply

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

You are commenting using your 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: