back
17 comments
Only today I was thinking how agile "sprints" are the wrong terminology. No one wins a marathon by running back-to-back sprints. I know it's only terminology but I think it affects our approach and in practice can encourage a Continuous Death March instead of the intended manageable workload.
I wonder whether there's some hidden wisdom in the terminology. Agile "sprints" are (in the folk-wisdom) ideal for getting somewhere quickly precisely when you don't know where you want to finish. In this case a "quick sprint, rest, reorient, sprint again" metaphor seems appropriate.

On the other hand, long-running maintenance work with a stable goal over a year or more probably benefits much less from sprinting. I guess in this case we would need to know what "marathon" development would be :-)

I'm in favour of using iteration over sprint
Bad code is a time and money sink.

The biggest mistake most companies make is not rushing bad code out the door too quickly, that's hard to prevent entirely, but rather failing to take the time to fix or replace bad code quickly once it's obvious the functionality isn't throwaway.

How is that relevant to the OP?
The OP extols the virtues of releasing code "when it's ready" due to the hazards of rushing code out the door in an "unready" state. Unready means bad.
ah yes I agree
In 2011 I started doing some independent consulting/dev work to supplement lagging employment income. I found that this works pretty well, that is, always having a couple of projects in the queue. If I get stuck on one or just sick of it I go to another for a while. I've not managed to avoid deadlines entirely, because my clients have deadlines of their own. But the pipelining concept is a good one.
"Start slow to finish fast" has been my motto for many things. It helps me avoid making mistakes at the beginning that I have to go back and change everything to fix. It also helps me avoid missing details that would make life easier.
I find it very similar to the motto I follow when jogging (and also what I"m trying to apply to other things): keeping a steady pace. By keeping a pace, you don't burn out towards later stages.
I think there is an unbalanced amount of effort and enthusiasm spent these days on development methodologies: agile, waterfall, what-have-you. I think the thing that makes or breaks a product is the customers; and customers don't care if your product is well made, they just care that it solves their problems.

As long as you are moving forward (even if it is by inches) you are doing fine. A shipped working product that solves an important problem is better than a late unreleased one that tries to do everything.

A well developed cloud app allows for transparent updates without an acceptance loop from the customer.

This has a certain feel of spin about it.

Great article.

Unreleased code is a liability and branches are a waste of time. If you're not deploying every day you are doing something wrong.

The best way to branch seems to be to release the code but hide it with a switch so that only developers can see it. This way, when you release the new feature, all you are doing is enabling it for everyone else.
I've found that, as a general rule, there's no such thing as actual deadlines. Or rather, actual deadlines are rarer than supposed ones.

One common excuse for a particular ostensible deadline is that it is due to some other, downstream/outside deadline, perhaps on the customer or stakeholder's side of the fence. But even then, very often, that entity's deadline is not really a deadline, it is typically yet another date pulled out of thin air because it sounded nice, regardless of whether it was realistic. A guess added to another guess added to another guess which get summed up and padded and turned into an estimate then pegged to a date then ever after referred to as a "deadline" (cue ominous music.) We come up with deadlines because we like to have certainty and the myth of control over things where in reality there's quite a deal of uncertainty and quite a large number of things over which we have no control. Deadlines can be good as goal dates associated with certain milestones, but even then it's best to call them that and treat them as such. I've seen too many software industry deadlines where teams worked like keyboard slaves to ship a particular feature set by a particular date, and ALMOST ALWAYS in the cases where the date wasn't hit there were NO significant negative consequences, no heads rolled, no business lost, etc., just a pleasant whooshing sound as the date flew past, and a quiet rethinking on the part of every developer who just took part in that "false alarm" march.

I've also noticed that, at least in the software industry, that deadlines are common when Project Managers are present. But PM's are, in my opinion, a bit of an anti-pattern themselves. Not that all PM's are bad -- because some of them are good and helpful -- but rather that if you're in a situation where you think you have to have a PM (or a deadline, or both) then that's usually a consequence of something else being wrong about your organization or process, and so you might be better off fixing those root causes instead.

In some situations deadlines, even if pulled from thin air, are at least something to focus on to get the project done. I've been on projects with no real deadlines, and they seem to meander forever and never actually get done. Finally someone will put a foot down on a date and magically everybody gets things wrapped up.
agreed! which is why I said this:

> Deadlines can be good as goal dates associated with certain milestones, but even then it's best to call them that and treat them as such.