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?