Better Software - April 2008 - (Page 28)

looked, and climb back up to the scaffold and repaint the body. This would be a bad use of time and energy—that is, a poor iterative development strategy. He made a full-scale, rough-draft “cartoon” of the whole ceiling, so that he would know what to put in each section of the ceiling. He also made fullsized sculptures of certain human torsos, which he lit so that they would mimic the lighting from the windows in the The patron looks at the painting so far and complains again: “You can’t make her head that big! Shrink it to her body size!” Leonardo, assessing that all the major obstacles have been met (and probably also thinking to himself that he doesn’t want to give the patron any more leeway in how it looks in the end), finishes the painting without showing it again, see figure 11. Figure 9: Iteration 1 of the Mona Lisa Figure 10: Iteration 2 of the Mona Lisa Figure 11: Iteration 3 of the Mona Lisa Sistine Chapel. He sketched the lit torso, and then carried the sketch up the scaffold, so he could paint the plaster correctly the first time. This was iterative development involving throw-away prototypes, a version of the second strategy. To show more complete use of the second iterative strategy, I must invent an imaginary progression of work resulting in Leonardo da Vinci’s Mona Lisa. Jeff Patton started this comparison [2]; I am modifying his progression to more clearly demonstrate the energy-saving value of the early iterative strategy, and to show the rework done. Leonardo, experienced in the way patrons change their minds, first draws only a sketch, as shown in figure 9. He asks the patron for his thoughts. The patron comments (we imagine): “Oh, no! She can’t be looking right! That’s not her good side. She has to be looking left!” Happy only to have done a sketch, Leonardo proceeds and blocks out the figure and the background—see figure 10—so the shape, the colors, and the background can all be seen. He is, perhaps, one-third of the way done by time and cost, so this is a good time to get more feedback. 28 BETTER SOFTWARE APRIL 2008 We can imagine that the patron grumbles a bit at the very end, but looks at what he has spent and says, “I’d rather have her eyes bigger but let’s call it done.” This second strategy—“Do the least work before getting feedback”—is a popular one in the software world, because of the frequency of changes and the cost of those changes. However, either of the two strategies is valid. Managing Incremental and Iterative Development Combined The two fit together quite naturally in what I call “VW Staging”[3], which can also be thought of as “cycle unrolling”[4]. Figure 12 illustrates. In the figure, the letter “S” means that the system ships at that point; the letter “E” means that the system only gets examined. The figure shows that it is common to revise one subset of functionality several times before considering it good enough to ship. This is quite normal, but otherwise difficult to show on the schedule. Figure 12 shows it in an easy-to-read manner, and one that maps easily to a sponsor’s calendar. Of the two, iterative is the harder one www.StickyMinds.com to manage, because the question always arises as to how many times to iterate and how much to allow to change. It’s not that you won’t do rework if you don’t schedule it—you would just like to have a way to forecast and allocate that time in advance. On Project Winifred (see the sidebar), we developed a useful heuristic, which I recommend to this day: Allocate two revisions for every piece of functionality. For the first revision, allocate onethird of the original development time. For the second, allocate half of that. These numbers are, of course, heuristic—a starting guess—but they are better than nothing. Tune the numbers for your team over time, as you gain experience. These days, agile projects like the one at the start of the article make the mistake of not allowing for user review and correction. Let’s revisit that project, which we’ll call Project Laddie. In Project Laddie, development cycles were two weeks long. Their incremental development strategy was standard XP and Scrum: Put the user stories into a list, work from the top down, and show the customer what has been built at the end of the iteration. Their iterative strategy was to have the customer say whether to put the completed-but-not-satisfactory story back on the top of the work queue, to put it somewhere down into the work queue, or to accept it. This is normal XP/Scrum behavior. What I learned from talking to the customers on this project was that this is not as good a strategy as I had once thought. Very few customers (or product owners) are really strong enough to say, “Return it to the front of the queue— don’t work on anything new until it’s satisfactory.” Instead, they feel the pressure to deliver so strongly that they are torn whether to deliver on time something that is not right, or to delay the project to make it better. What these customers were missing, and I have since come to appreciate, is that they should have several chances to view and correct the growing piece of software as it is being developed. In other words, what I am coming to call the “user’s bill of rights” is that they automatically get two chances to correct 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.