Iterative Rework: The Good, the Bad, and the Ugly Richard E. Fairley and Mary Jane Willshire, “Iterative Rework: The Good, the Bad and the Ugly”, Computer Cover Feature, Sept. 2005, pp. 34-41. SE 516 Technical Article Presentation Yvonne Krashkevich

Iterative Rework: The Good, the Bad, and the Ugly Abstract As the famous Greek philosopher, Heraclitus proclaimed “The only thing that is constant is change”, so too is it common to find change in today’s software development projects.  Varying degrees of change can adversely impact project delivery, budget and quality.  Given this state of flux, rework is both inevitable and beneficial, however, knowing how to balance too much verses too little is the key to a project’s success or failure. This article focuses on the nature of rework and why it occurs.  The article also reviews a process for collecting rework data to determine associated root causes, identify rework trends and to isolate avoidable rework.  Identifying and correcting the root causes of avoidable rework improves productivity, quality, profits and ultimately customer satisfaction.

Iterative Rework: The Good, the Bad, and the Ugly Iterative Development Models Continuously integrate and validate the evolving product Frequently demonstrate progress Alert developers early on about problems Deliver subset capabilities early on Systematically incorporate the inevitable rework that occurs in software development

Iterative Rework: The Good, the Bad, and the Ugly Agile Development Five principles of Agile process models Continuously involve the customer Develop test cases/scenarios before releasing the next version Implement and test the next version Periodically deliver subsets of the product

Iterative Rework: The Good, the Bad, and the Ugly Agile Development cont. Steps in the Agile Development Process Hear customer story Specify Requirements Add new features; review, test and rework Demonstrate capabilities Iterations occur in cycles of one day or less Note: “Requirements and Architecture Evolve”

Iterative Rework: The Good, the Bad, and the Ugly Incremental Build Based on stable requirements and architecture Partitions the design into prioritized build sequences Each build adds capabilities to the incrementally growing product Build-validate-demonstrate iterations Versions can overlap Customer is usually not in the loop

Iterative Rework: The Good, the Bad, and the Ugly Premise of Iterative Development - Rework is inevitable It provides the ability to gracefully modify the current version of an evolving product while adding capability to produce the next version It avoids the well known pitfalls of massive integration, testing and rework encountering in the waterfall model.

Iterative Rework: The Good, the Bad, and the Ugly Four Dimensions Characterize Software

Iterative Rework: The Good, the Bad, and the Ugly Types of Rework Evolutionary Modifies one or more of the current version’s four dimensions to provide new capabilities in the next version Due to change in requirements that developers were not aware of when developing the current version. Avoidable Work that no one would have to do had the previous work been correct, complete and consistent (i.e. satisfied it’s requirements)

Iterative Rework: The Good, the Bad, and the Ugly Rework Taxonomy

Iterative Rework: The Good, the Bad, and the Ugly Distinguishing Between Good and Bad The fuzzy part is interpretation Customers say that they are only clarifying requirements the developers should have understood (i.e. retrospective) The developers maintain that the customers changed the requirements (i.e. evolutionary)

Iterative Rework: The Good, the Bad, and the Ugly Collecting and Analyzing Rework Data The goal is to identify major trends and determine the rework’s root causes Four common techniques Anecdotes Observation Record keeping Automation

Iterative Rework: The Good, the Bad, and the Ugly How Much is Acceptable? Rule of thumb – rework is acceptable at 10 -20% of the total effort More than 20% of the total effort indicates problems in the work process Less than 10% indicates insufficient reviewing, revising and testing

Iterative Rework: The Good, the Bad, and the Ugly Dealing with the Ugly – How Control Charts Work Excessive Insufficient

Iterative Rework: The Good, the Bad, and the Ugly Rework can amount to 80% of all work Effort is saved by reducing defect, this reducing avoidable rework

Iterative Rework: The Good, the Bad, and the Ugly Six key questions to Process Improvement

Iterative Rework: The Good, the Bad, and the Ugly Conclusion Identifying and correcting the root causes of avoidable rework improves productivity, quality, profits and ultimately customer satisfaction.

Iterative Rework: The Good, the Bad, and the Ugly Questions???