Hopefully these two pictures taken from Don’t know what I want, but I know how to get it will help you understand it.
When you work incrementally you are adding piece by piece but expect that each piece if fully finished. One picture is worth of thousands words :)
When you work iteratively you create rough product or product piece in one iteration, then review it and improve it in next iteration and so on until its finished. One picture is worth of thousands words :)
So is Scrum incremental or iterative?
It is iterative by the definition as we are running sprints. We are improving application iteration after iteration.
But I believe it is also incremental because user stories finished in sprint should be of shippable quality and therefore we should not return to them in next iterations.
So Scrum is iterative incremental process.
Is this your opinion too?
6 comments:
Scrum sucks.
Very true! I've never seen a project that claimed to be incremental that wasn't (at least a little bit) also iterative. It's less obvious the other way around but I suspect that is also true. Even your diagram for incremental development demonstrates this. You show the developer envisioning the entire Mona Lisa. That may very well happen in your head but more often then not, the entire project (up to some stage) is envisioned in design documents, in prototypes, or in stubbed code. Even if you are doing "incremental" development, the vision of the entire picture is the first "iteration."
However, I don't find it useful to try to classify process definitions as either incremental or iterative. The development strategy for a particular project can have elements/phases that are either incremental or iterative, and may even be dominated by one or the other type. The process you use may influence your development strategy but SCRUM, RUP, XP and even traditional waterfall processes can support development strategies with both element types.
On the other hand, it is useful to distinguish between development processes that emphasize upfront requirements, design and planning versus those that think of the design, requirements, and plan as emergent properties.
The balance between Big Design Up Front (BDUF) (used to capture requirements and planning also) versus emergent design is a key consideration when thinking about your process and development strategy. Where your project should fall along the continuum from total BDUF to totally emergent design, should be a conscious decision based upon a number of factors including: stakeholder/organizational planning needs, precedentedness of the product/design, acceptability of certain types of risk (like safety and security), and the stability/duration of funding wrt initial estimates/scope. All too often folks don't understand the impact these factors will have on the likelihood of project success for a particular development strategy or process definition choice. The choice of SCRUM and an emergent design strategy is based upon marketing or "feelings" with little consideration of their particular project situation or success data to back up the choice.
Sorry for the long rant. I've been thinking about starting my own blog to talk about these subjects but haven't yet... so as a substitute, I lurk and comment when I see the opportunity. :)
Larry Maccherone
@Larry
Thanks for really detailed explanation. Your comment actually should be post because your thoughts are really deep.
Especially I liked part about factors which influence how to decide project position between total BDUF to totally emergent design. I must admit so far I thought this is just good feeling of team, project manager, and stake holders. But actually you are right, this is business decision that can be made according to project situation.
Jan
@Anonymous (Scrum sucks)
Actually in some situations Scrum really sucks :) I thought I will try to explain these situations in this comment but I believe this is good subject for next post.
Should Upper Management be included in Scrum Meetings??
@anonymous
Scrum is open framework with the probably highest transparency possible. Upper management can of course participate on Scrum meetings.
But from my point of view what really can be very interesting for them is sprint demonstration.
If they regularly participate on sprint demos they can see how project is growing and very often check if it is going to the right direction.
Other meetings need not to be interesting for them because mainly they can be only passive participants.
Post a Comment