Project Management

Who says you have to iterate in Agile?

From the Agility and Project Leadership Blog
by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility

Categories

Date

linkedin twitter facebook Request to reuse this  


I saw this interesting thread in a LinkedIn discussion group for Agile and Lean Software Development, that questions the the common perception of Agile being an iterative method and process.  I'm guilty of this myself as I often talk about Agile methods in those terms, but as the post indicates, there's nothing inherent in the original Agile Manifesto that promotes having to do iterations:

The vast majority of people assume that Agile = Scrum = Iterations but the agile manifesto doesn't say anything about iterations or Scrum. What it does talk about is early and continuous delivery of value which could be achieved in other ways such as multiple overlapping iterations or continous flows.So are iterations really essential for agile? Are continuous flows of value a better way? Have you done agile without iterations? If so how did you go?

It really was Scrum that advocated using interations (or what they call "Sprints") and since it is the most popular of the Agile methods, those in the community often equate Agile with iterating.

For me personally as a practicing project manager, I'm naturally more inclined to align myself with Scrum's notion of iterations and delivering a "potentially shippable" product at the end of each iteration since it will give a clear delineation of when a project is done.

Having a process based on continuous improving flows seems more like developing operational efficiencies rather than delivering a project that can adapt better to changes in a highly uncertain environment.  That is not to say that a project's process could not benefit from continuously improving flows.  That's why things like incorporating Kanban is highly beneficial to moving task flows.

It's just my preference to have something like Scrum be the driving force for my projects and to incorporate things like Lean and Kanban process improvement flows where needed.

What's your take on this?


Posted on: March 26, 2013 07:11 PM | Permalink

Comments (4)

Please login or join to subscribe to this item
avatar
Neil Shaw Derby, United Kingdom
Unfortunately until the Holy Grail of "Right First Time" is attained there will always be the probability of iterations in projects. The difference from what I understand is that Agile acknowledges this, whereas those of us who follow Waterfall kid ourselves they won't and don't plan for them!

avatar
Wayne Mack Retired| Retired South Riding, Va, United States
I think the issue is not so much "Iteration" but "Planning". We have always had iterations, but the change was in the lenght of the iteration. As XP (Extreme Programming) defined it, we were turning the knobs up to 10. Instead of having 12, 18, 24 month or longer iterations, we would have 2 week iterations. It is not the idea of iterations that is new, but rather the pace at which iterations are completed that has changed.


The difference between XP and Scrum versus Kanban is not that there are iterations, it is the planning for the iterations. XP and Scrum use a fixed schedule for completing iterations - every X days. In Kanban, one can deliver either faster or slower based on the business value of work that has been completed. Completed work is held until their is a need to deploy, at which time an iteration is finalized.


The differences with XP, Scrum, and Kanban deal more with the planning needed to complete work in timeboxes. The work itself, however, is still performed as a self contained effort (no grandiose plans for future enhacements) and still needs the same level of task definition (meaning of "Done").

avatar
Alaa Hussein Program Manager| MEMECS Baghdad, Iraq
Thanks for sharing

avatar
Samer Alhmdan Senior Project Manager, PMP, PMI-RMP, LEED AP, EDGE Expert| dar Dubai, United Arab Emirates
Thanks

Please Login/Register to leave a comment.

ADVERTISEMENTS

"A thing worth having is a thing worth cheating for."

- W.C. Fields

ADVERTISEMENT

Sponsors