You’ve been redirected to SolutionsIQ.com. BigVisible and SolutionsIQ have joined forces, and–lucky you!–you still have access to all of that awesome content. Dig in.
Somewhere along the way Agile – and Scrum in particular – decided (or forgot) the fundamental difference between incremental work and iterative work. For some reason that is not clear to me, the two terms became synonymous antonyms where one was all good and the other all bad and at the same time could be used interchangeably. Admittedly my recollection of this is skewed from being addicted to the scrumdevelopment group for which I am going to find a 12 step program.
But that is another Blog.
Back to Incremental and/or Iterative. First they are neither synonyms nor are they antonyms but most of all they are not interchangeable. Incremental work is work that can reliably build upon the last deliverable or the last iteration. It lives in charted territory. For that reason it is fertile ground for all the neat things one can do with Lean and CMMI stuff like that. In addition to these good ideas there are other processes, fads and gimmicks that also purport to make things better smarter cheaper faster easier and brighten your teeth while turning your hair back to the color it was before it fell out. They may but the jury is still out and the panel may be in need of CPR in order to survive.
Now the strange thing is that iterative is all about what incremental isn’t and that is because iterative work is work that in all likelihood will be tossed out or only snippets of it will move forward. Iterative work is the land of fail often fail fast and succeed quickly. It tries very hard not to be repetitive because the odds are you don’t have to keep on making the same mistakes over and over. It is for that reason incremental processes like Lean and CMMI come out looking like those fads and gimmicks and this may be why some people are leading thinkers to accept that iterative is bad.
Sorry, would you mind taking that down the hall and seeing if some there wants to swap a bridge for that idea? Iterative is the innovation engine. In ‘the Day’ it was what we called the BIG R for research. Of course this is back in the dark ages when R&D was valued and people actually worked using things like Scrum and Agile before it was copyrighted and marketed and certified. Believe it or not people actually used to get paid to make lots of mistakes and hit it right once or twice in their careers.
So what did we know back then that has been lost due to modern management techniques and an economy that suffers from quarterly A.D.D? First you iterate until you stumble across something that works and then you incrementally improve it until you totally screw it up. If you work for a really good company someone will have been mucking about iterating on how to do it in a much better way and you will be able to latch onto it and claim you are doing best practices.
I hear something coming in from left field! Let’s do both at the same time and that way be innovatively efficient! Now, let’s cut this one off at the pass. No you cannot do both at the same time because it is task shifting (a no no for you incremental lean types out there) and it is BORING if you are a dyed in the wool iterative worker. Can you shift between the two types of work? Sure, that makes sense as long as you work in a place that knows the difference and applies the appropriate metrics to it. OOPS there are not many metrics in iterative work other than the Edison algorithm (success was measured in finding out how many items made lousy filaments for light bulbs and the answer was 8000 with only 1 failure when bamboo kept on going, and going, and going.)
So if you want to debate this come to the Agile conference and see if this actually makes it as a discussion. Better yet go make great comments on it at the agile2009 site. But until then remember that Incremental and Iterative are a fork in the road for Agilist and make sure you know where you are or you could get killed.