The objective of iterative development is to get regular feedback. Now, in a typical enterprise organization, it takes a while to organize users to test the application. Users, after all, will most probably have a lot of important work besides testing your application. If you announce a delay, users will have to reorganize their schedules in order to accommodate a new testing date. Their availability will probably not coincide precisely with when you intend to release your iteration, which means a further delay in testing. This leads to significant delays in feedback, which leads to wasted work because when feedback does arrive, the development team will probably find that it needs to revise a lot of the work they did while waiting for the feedback.
If your iterations come at regular intervals, say every two weeks, users can get into a rhythm of organizing their schedules to accommodate the testing and feedback, just as you get into a rhythm to accommodate a weekly family gathering or sports event. The way to do this is to always maintain the codebase at working, deployable state via Continuous Integration, so you can tag and deploy whatever code you have at the end of an iteration period, whether you have achieved all your goals or not.
An iteration should not be confused with a milestone. A milestone is a fixed set of goals but is not necessarily at a fixed point in time. An iteration should be a fixed length of time, to allow for the rhythm or synchronization of all those involved in the project. So you might find yourself in a situation where you negotiate with your client that it will take five iterations and not four as originally planned, or that the milestone objectives need to be revised in order to meet a schedule.
One crucial practice that's hard to do right is the recalibration once you miss your targets in an iteration. This is what usually causes project teams to tweak an iteration's length rather than tweak the number of deliverables per iteration.
ReplyDeleteIt also then boils down to estimation. Though it is more an art than a science there should pretty much be a guideline to follow -- only finding the right guidelines is generally the hard part. :)
Scrum does well on ensuring that milestones are achieved on fixed date/timeline (say a 30-day sprint). Iterations can then be scheduled every after 10 days to keep the pressure on getting things done while making it easy to schedule external activities for the team (i.e. acceptance testing with users, re-estimation, etc).
ReplyDeleteSo far I managed to inject and applied some concepts from Scrum in my previous project and it seemed to work fairly well, except that politics and lack of financial support put the project into hibernate state...
my brother sent me an email. so found you online. i think a lot of the problems in iterations, scope creep and changes evolve from the lack of honesty on the part of the players. I wish more of the developers, project managers and even clients would just be more HONEST. mikehidalgo@yahoo.com
ReplyDelete