I’ve written about the idea of an iteration-less process before, and we’ve been using the spirit of the idea at the startup I work at (Cinch) for the past few weeks.
The idea is simple, and has two parts. First, eliminate the concept of formal iterations (use a pull-system to let work flow through the pipeline – use Kanban cards if you like). Second, replace the rhythmic heart-beat of iterations with actual releases to customers (internal or external).
These releases do not have to be spaced out by a week or two or any arbitrary span of time. They ought to be, in fact, the shortest amount of time that the software system can be re-stabilized after undergoing change (through adding features or fixing defects). Hence, if it takes 2 days to do a release, do it then. If, for some reason, it takes 6 days (instead of the old five), then so be it. However, the focus of the team should be on getting quality software into the hands of the final users. After all, everything else is inventory.
Pretty simple, eh? We have combined this with the idea of the estimation-less process, for even greater effect. I have been hearing from some people that I have worked with in the past, and they’ve reported excellent results through just such a process. So, anyway – that’s what iteration-less means. 🙂
P.S.
In a past life I had spoken about this with Jeff Sutherland when I attended Deep Lean (in 2007) – and he agreed that this made sense. He didn’t recommend it for any but the most experienced team – and I certainly agree with that. If your team is new to agile or is lacking in some other way, getting it going with the standard approach to agile is probably the best thing to do.
However – if your team can pull this off, you might want to give it a shot and see how much productivity increases over time.
Good post, but I do have to disagree with you about the “He didn’t recommend it for any but the most experienced team – and I certainly agree with that” There’s a very deep thread going on over at the kanbandev group right now… I’m going to link to one of my posts on the topic that directly addresses this, but the entire thread it worth a read.
http://finance.groups.yahoo.com/group/kanbandev/message/965
[…] way we accomplish this is through extremely loose-coupling. In our case, we take a very release-driven approach to our software process. So our architecture evolves according to our current needs… […]
[…] same time (and getting paid for doing that!), it has also been a great opportunity to do this as incrementally as possible. I strongly believe in set-based engineering methods, and this is the approach I took […]
I think this is something that I am already fighting against.
I am sorry if it sounds roude but
– imagine a group of people who think that they are the experts!
– Now imagine that they are working without a process.
What can you imagine they will be doing?
they will certainly be doing it the way I happen to perceive the idea of iteration less methodology.
Then there are some questions.
– Where will we adjust Reviews and planning?
– what will keep focus of the team?
– How can lean satisfy stake-holder’s changing bussniss requirements?
My comments may have made someone upset (due to may be spelling mistakes …)Please ! accept my appologies.
What you’re suggesting is that the people you’re working with think they’re experts and that using an “iteration-less” approach is equivalent to having no process.
Two comments here –
1. No methodology can help you if the people you have aren’t good at what they do. And usually, smart software developers grok the idea of iteration-less agile – often they gravitate towards something like it on their own. It just takes a team that keeps delivering results and is still focused on self-improvement.
2. The idea of this being development “without a process” sounds familiar to me -it was exactly what all the critics of agile methods said when the world was first transitioning from waterfall. The truth of the matter is that going iteration-less requires even more discipline than is required by a waterfall team going agile.
[…] same time (and getting paid for doing that!), it has also been a great opportunity to do this as incrementally as possible. I strongly believe in set-based engineering methods, and this is the approach I took […]
[…] way we accomplish this is through very loose-coupling. Additionally, because we take a very release-driven approach to our software process, our architecture evolves according to our current needs… […]