Coke machine projects
"Coke machine" is my tag for a category of projects. I can't believe I haven't blogged this before.The joke goes like this - this blonde walks up to a coke machine, puts in fifty cents, gets a coke. She does a little dance, grabs the can, puts it on the counter nearby. Opens her purse, puts in another fifty cents, gets a coke. Puts the can away, starts all over again. Meanwhile as it's a busy time of day, a small queue is forming behind her. People want to have a go and start to get equally annoyed and amused. "Lady, when do you think you'll be done here ?" And she answers, of course: "Hell, buster, as long as I keep winning I intend to keep playing !"
(I know it's a sexist joke told like that. The first time I heard it, in French, it was about a Belgian. The geek way to tell it would be "this [insert favorite stupid stereotype] walks up to a coke machine...".)
Anyway, I've come across projects which are exactly like that. The business keeps paying, and as long as the business keeps paying the developers keep developing.
In these situations, you won't need the exact same scheduling practices you would use in a project where "predicting the end date" is an important concern, or even knowing what will be in the product by a certain date. For instance, I'm OK if this kind of project keeps a small "planning horizon" (the number of iterations which the team is capable of planning ahead), such as one iteration. Or uses a continuous scheduling tactic, such as kanban.
As the name implies I feel vaguely uncomfortable about this kind of "project". For one thing, it contradicts the common wisdom that projects are well-defined endeavors with limited resources. I like it better when even long-running efforts are cut up into major milestones which have the feel of a distinct "project". If nothing else, that gives the team defined opportunities to create "generations" of their product, opportunities to cut loose from a design grown too old for instance. That's a topic for another blog...
six comments:
Interesting! I’m not clear, though, on exactly what sort of project you mean by that phrase.
I work mainly with startups, where the goal is indeed to put some money in, play, and see if you’ve won. If you do win, then you put more money in and try to keep winning. This definitely isn’t well defined. Although it has limited initial capital, the hope is that it will produce enough cash that you can keep playing and winning indefinitely.
On the other hand, I have seen projects where execs keep putting money in and getting software out, even though they never get a payoff in the form of value delivered to users.
I think the difference is whether the project is focused on metrics about delivered value, or just about “progress”. Do you consider both sorts “coke machine” projects?
William Pietri (URL) - 12 06 09 - 22:11
It seems very agile to me to only plan one iteration ahead. Every iteration is a project in itself, with a release to the business. Why would you need a longer term planning horizon if the business is happy? If you’re consistent about TDD and refactoring, the design should not grow too old or need to be cut loose from. You have opportunities every iteration to update it.
Emily Bache () (URL) - 13 06 09 - 14:51
One or more comments are waiting for approval by an editor.
No trackbacks:
Trackback link: