Iterative Project Management

Iterative Project Management Chapter 2 – How Do Iterative Projects Function? Part 2 Iterative Project Management / 01 - Iterative and Incremental Development

Key Characteristics of a Successful Iterative Project • Demonstrable, objectively measured progress • Incrementally increasing functionality • Continually improving quality • Continual risk reduction • Increasingly accurate estimates • Reducing levels of change • Convergence on a accurate business solution • Let’s look at some of these… On time, on budget, meeting the customer’s real needs. Iterative Project Management / 01 - Iterative and Incremental Development 9

1. Demonstrable, Objectively-Measured Progress • Lots of ways: From book: • Number of products / documents produced • Number of LOC produced • Number of activities completed • Amount of budget consumed • Amount of schedule consumed • Number of requirements verified to have been implemented correctly. •  Best one by far: number of requirements verified to have been implemented correctly • Others are indirect and may not measure real progress. • But we must test the release and we must record the amount of verified software! • Nice graphs in book re: requirements verified vs project schedule Iterative Project Management / 01 - Iterative and Incremental Development 10

Demonstrable, Objectively Measured Progress 100% Requirements Verified 0% Project Schedule / Iterations Iterative Project Management / 01 - Iterative and Incremental Development 11

Avoid Feature Creep • Feature Creep is natural and practically unavoidable. • Frankly, if the number of requirements grows, team will not make schedule. • Solution1: Just say no. • Will keep you on schedule, but will create ill-will and will likely result in escalation. • Often unforeseen features are ‘essential’ • Solution2: Prioritize them and negotiate with Customer • What can be removed from a features list if the delivery date and resources remains constant – that is, trade? • Be careful of ‘added resources!!!!!’ • Best to discuss this at iteration end when plans for the next iteration are being firmed up. • Underlying theme: have frequent deliverables and value present to the business sooner rather than later. • Do not recommend extending the current project. • Have more critical / core functions in earlier iterations Iterative Project Management / 01 - Iterative and Incremental Development 12

2. Incrementally Increasing Functionality Essential that each iteration produce more verified, demonstratable functionality without compromising sacrificing quality established in previous iterations. But we have issues: “All iterations are not equal” Amount of Effort may have been less during a previous iteration (time off; illness…) Team productivity: As we progress through the iterations, we typically increase the productivity as the architecture becomes more stable, team members become more confident in the process, risk is reduced, as well as reduced breakage (ahead) Stability of earlier iterations: Inevitable for rework and breakage. Thus in a given iteration, the code growth for the ‘next’ iteration may come up short than that previously planned

Incrementally Increasing Functionality The S curve (coming) depicting increased functionality shows that early and late iterations tend to yield ‘lesser’ increments Earlier iterations due to cost / effort of start up; familiarity with environment; stability, … Late iterations due to transitioning to the user community, training, customer service, latent bugs, clean-up, etc. Most functionality - middle iterations normally produce the most significant increases in high-quality increments that supplement previous increments. Too, risk is reduced, environment becomes more stable as well as the architecture, etc.

Incrementally Increasing Functionality F U N C T I O N A L I T Y Increment n + 2 What is this decrease? Increment n + 1 Increment n Iteration n Iteration n + 1 Iteration n + 2 Each iteration has more complete functionality than the one before. Iterative Project Management / 01 - Iterative and Incremental Development

3. Continually Improving Quality Healthy projects constantly assessquality and this must increase every iteration. But quality can be impacted by assessment at end of iterations: 1. testing does not totally address coded functionality (need more testing / development) and 2. just plain breakage (code does not pass tests). This regression is shown in the next slide.

Continually Improving Quality Q U A L I T Y Regression in functionality from previous iteration(s). But overall higher quality code will be produced, as shown in the graph. Iteration n + 3 Iteration n Iteration n + 1 Iteration n + 2 Each iteration has less breakage than the one before. Iterative Project Management / 01 - Iterative and Incremental Development

Continually Improving Quality One problem with the effort to continuously improve quality is the perception that taking care of problems should be given precedence over adding new functionality But by ignoring / ‘pressing on’ in the face of defects causes more significant problems. The graph (see figure 2-8 in your text – page 61) shows that by subordinating the addressing of breakage, etc. causes more time spent in fixing ‘other’ problems and less overall progress and quality. And, this rate of ‘lower’ progress/quality increases…

Continually Improving Quality  Too much emphasis on adding functionality leads to degrading quality… We know that earlier iterations must concentrate on stabilizing the architecture and reducing risk at the cost of increased functionality and we must recognize and support this! Exercise care in planning the iterations to address these parts of the project where architecture concerns and risk are high. Functionality can be added secondarily to these factors. Oncerisk is reduced and the architecture stabilizes, then more functionality will be added and a higher quality product continues its evolution.  Avoiding accumulating defects will increase the quality of the increments.

4. Continual Risk Reduction Healthy projects address risk up front, as this reduces the likelihood of project failure. This is old news and is essential to early iteration planning. See next slide for graph: Graph reflects an immediateincrease in risk up front rising to a high point, and then dropping to be much lesser in importance as project evolves. Earliest iterations are usually the most difficult as items of high riskmust be addressed. Too, a team rarely really understands all the risks up front. Thus there is a period of (book) risk exploration.

Continual Risk Reduction High Controlled Risk Management Total Risk Exposure Risk Exploration and Resolution Low Project Schedule / Iterations Iterative Project Management / 01 - Iterative and Incremental Development

Controlling ChangeControl Change and Rework! Knowtherewill always be change and rework. But we must control and manage these activities!  Changeandrework generally come at a much higher expense later on in the project because the architecture is stabilized and much functionality has been verified and integrated into the project. Bringing Change and Rework under control dramatically impacts overall project completion.

Controlling ChangeHow Much? When? Early in lifecycle, we expect change – typically between 35% and 100% - as we become more stable and learn more about the project. Rework will then typically decrease and should drop to something below 25%. We must watch the stability of the interfaces – subsystems, packages, layers, etc. Major responsibilities of components! Earlier in project – no problem. Typically if these require change well into the project, then we likely have deeper problems. Watch for these!

6. Increasingly Accurate Estimates Accurate estimates for both short-term and long-term activities must be predictable. All estimates have an element of probability in them. Traditional estimates (COCOMO model) converged (as expected) as we approach end of project. (next slide) Iterative projectsdo better due to revised estimates based on real progress measured / verified each iteration. (following slide) We constantly revise our estimates and hence converge more quickly to actual costs As time progresses, the closer we get to actual results Margin of error decreases as time moves on in the iterative approach.

Increasingly Accurate Estimates Traditional approach for estimation using COCOMO II Model. Source: COCOMO 2 Model Manual Iterative Project Management / 01 - Iterative and Incremental Development

Increasingly Accurate Estimates Iterative estimating: note quicker convergence and reduced margin of error. (Convince management of this) 4X Expected size rangefor a traditional project Expected size range for an iterative project 2X Relative Size Range X By iterating, and applying disciplines of software development, team: learns a lot more about the problem to be solved, the technology being used to implement the solution, their own capabilitiesand, by estimating repeatedly every iteration, how to estimate resulting in the production of more accurate estimates more quickly. 0.5X 0.25X Project Schedule / Iterations Iterative Project Management / 01 - Iterative and Incremental Development

Plain Facts on Estimating - 1 • Facts are that • Estimating is so very poorly done. • Often “estimates” are dramatically influenced by management; perhaps negotiated. Why? •  “The reality is that reductions in schedule without corresponding reductions in scope have the effect of setting the project up for failure from the start.” p. 69

Facts on Estimating - 2 • Facts are that • Software professionals don’t develop estimating expertise • We tend to be overly optimistic • Development teams don’t cope well with political problems. • There’s little historical information to base estimates upon • Teams do NOT continuously revise estimates • But by continuously estimating via learning more, developing additional business value, assessing, and verification, and, equivalently, developing our own history, our estimates canbecomemuch more authoritative and result in more predictable outcomes.

Increasingly Accurate Estimates Note the margin of error decrease over time. X X X X X X Estimate of work to complete X X X This slide illustrates a project re-estimating the amount of work left to complete the project every iteration. It shows although the estimates are becoming more accurate they are not necessarily becoming smaller. Original Target Date Project Schedule Iterative Project Management / 01 - Iterative and Incremental Development

7. Reducing Levels of Change Reducing levels of change? How so? Discuss. 100% Early in the lifecycle you would expect there to be a lot of rework of the items produced (typically between 35 and 100 %). Later as amount of change decreases rework should drop < 25%. Rework (% of Total) 50% 0% Project Schedule / Iterations Iterative Project Management / 01 - Iterative and Incremental Development

High Defect Density /Defects per Line of Verified Code Low Project Schedule / Iterations Defect Density Not only defect density, but their severity. If so, how so? Iterative Project Management / 01 - Iterative and Incremental Development

8. Convergence on an Accurate Business Solution The following perspectives converge iteration by iteration: • Discuss • What the customers think they need • What the customers expect to get • What the developers think the customers need • What the developers expect to deliver • What the users actually need • What the developers are actually going to deliver • What the customers actually going to get Iterative Project Management / 01 - Iterative and Incremental Development

More on Convergence… Reality is that users and business analysts often don’t know what they really want until they see it. Too close to the action in many cases… Too busy; bad attitudes; resistance to change; seniors vs newbees; turf;…. Often “specifiers” ‘need’ the world… until they see the cost and impacts on schedule.  Nice thing is that early iterations address risk and force early problems to be resolved via demonstrations, proofs of concept, prototyping, etc….before long term project commitments need to be forthcoming.

Discussion: ResourcesWhat do we need to Iterate? • What skills do you need to iterate? • What are the key roles in an iterative project? Iterative Project Management / 01 - Iterative and Incremental Development

Project Management Requirements Management Development Architecture Assessment Team Responsibilities Who does what? What perspective do they come from? What specific skills do you see absolutely necessary? To iterate, key management and development skills need to be in place. Iterative Project Management / 01 - Iterative and Incremental Development

Increasing Enthusiasm, Morale, Collaboration, And Effective Teamwork Iterative approach is characterized by Regular demonstrations Assessments Retrospectives Feedback loops That reinforce team building and process improvement. BUT: team attitude is critical… How about team balance? How about team respect? How about a shared vision?

Team Attitude - 1… Oftentimes an iterative approach is taken due to previous project failures. Often many individuals / groups doubt the other’s ability to meaningfully contribute or have commitment ‘they’ have. (lack of respect??) DIFFERENCES: (for management…) (book) Iterative approach provides greater ability to see what’s happening Force issues to be dealt with immediately and not put off… Feedback is folded into the planning of iterations Actions taken to resolve issues. Iterative projects produce code almost immediately!! And these are addressed each iteration!! (unlike traditional approaches)

Team Attitude - 2… Developers (paraphrased) commonly doubt the customer’s commitment to the project and question their willingness to become actively engaged in steering and assessing the project through the iterative elaboration of requirements providing feedback on the iteration demonstrations and contributing to the iteration assessments. Customers often question the development team’s attitude toward their (customer’s) taking a more central role in the projects and actually listening to their inputs.

Summary and Review • Maniacal focus on producing working software • Something ‘runnable’ produced every iteration • Objective measurement of progress • Continuous integration and testing • Active reduction of risk • Incremental completion …. • Convergence Iterative Project Management / 01 - Iterative and Incremental Development

Iterative Project Management