Better Software - April 2008 - (Page 25)

eople still get wrapped around the axle trying to understand the difference between incremental and iterative development. The Unified Process authors in the 1990s didn’t help by indiscriminately calling everything iterative development. The two are different and must be managed differently. Successful teams do both at the same time, usually without thinking about it. Then someone starts thinking about it and does one without the other. Bad news follows. Current agile practice doesn’t seem to make it important that the users get to see what’s being built and have a chance to change it. Iteration lengths are so short that the programmers barely have time to program up the basics before the end of the iteration, so there’s no time for the users to show up and say, “No, that’s not actually what I want.” I heard one Extreme Programming (XP) customer ask others in a multiproject exchange: Is it just me, or do you also have to get it right the first time? On our project, if I request a change, they tell me that story will go to the back of the queue and the project timeline will be delayed. As a result, I have to get it right the first time. Isn’t this against the very spirit of agile development? This person is right on all counts—it happens, it runs against the spirit of agile development, and it is bad business. This problem is the opposite of what we wrestled with back in the 1990s. Back then, we struggled to get people to do incremental development. Getting people to break work into small-ish pieces and build a piece at a time was all we aspired to. Many people understood that it was good policy to show the results to users several times, and so, oddly enough, we sometimes saw iterative but not incremental development! If you create smaller pieces but don’t show them to real users and incorporate their responses, then you revert back to the project failures of the 1980s, when users complained that what got delivered to them didn’t satisfy their needs. P How Did We Get into this Back in 1991, my assignment with the IBM Consulting Group was to investigate development methods for objecttechnology projects. In my research, I ran into two terms—incremental development and iterative development. I read articles and interviewed people to learn what they meant by these two phrases and learned that they refer to distinct staging and scheduling strategies. They are choices made by the project team on how to slice, integrate, and revise the work. We learned that: Incremental development is a staging and scheduling strategy in which the various parts of the system are developed at different times or rates and integrated as they are completed. The alternative is to develop the entire system with a big bang integration at the end. IteratIve development is a rework scheduling strategy in which time is set aside to revise and improve parts of the system. The alternative development is to get it right the first time (or at least declare that it is right!). Please notice that these strategies don’t imply, require, or preclude each other. It is possible to work incrementally without iterating (the product manager’s complaint at the start of this article), to iterate without incrementing, or to do both (the recommended strategy). In the next section, we’ll look at the definitions more closely along with how to manage the differences, but first: How did we get into the situation where the two became so confused? Back in the 1990s, the authors of the Unified Process—perhaps so excited to be able to revisit the requirements and design portion of the process at all— decided to call everything “iterations” and “iterative development,” erasing the line between the two. At that moment, the difference in the two strategies got lost. Since then, projects have failed by doing one without the other. You need both, and you need to manage them differently. Mess? www.StickyMinds.com APRIL 2008 BETTER SOFTWARE 25 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - April 2008

Better Software - April 2008 Contents Mark Your Calendar Contributions eLightenment Technology Speaking - A Change Would Do You Good Code Craft - A "D" In Programming, Part 1 Test Connection - Learning the Hardware Lessons Management Chronicles - The Art of Persuading Management Cover Story - Incremental and Iterative Development Developers...Start Your Engines Where Do I Go From Here Product Announcements 10 Things You Might Not Know About... The Last Word - Software Quality and the Prisoner's Dilemma Ad Index

Better Software - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.