iterative project management l.
Skip this Video
Loading SlideShow in 5 Seconds..
Iterative Project Management PowerPoint Presentation
Download Presentation
Iterative Project Management

Loading in 2 Seconds...

play fullscreen
1 / 32

Iterative Project Management - PowerPoint PPT Presentation

  • Uploaded on

Iterative Project Management. Chapter 2 – How Do Iterative Projects Function? Part 2. Key Characteristics of a Successful Iterative Project. Demonstrable, objectively measured progress Incrementally increasing functionality Continually improving quality Continual risk reduction

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Iterative Project Management' - bachyen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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


1 demonstrable objectively measured progress
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


demonstrable objectively measured progress
Demonstrable, Objectively Measured Progress


Requirements Verified


Project Schedule / Iterations

Iterative Project Management / 01 - Iterative and Incremental Development


avoid feature creep
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


2 incrementally increasing functionality
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
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 functionality8
Incrementally Increasing Functionality














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
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
Continually Improving Quality








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 quality11
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 quality12
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
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
Continual Risk Reduction


Controlled Risk Management

Total Risk Exposure

Risk Exploration and Resolution


Project Schedule / Iterations

Iterative Project Management / 01 - Iterative and Incremental Development

controlling change control change and rework
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 change how much when
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
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
Increasingly Accurate Estimates

Traditional approach

for estimation using


Source: COCOMO 2 Model Manual

Iterative Project Management / 01 - Iterative and Incremental Development

increasingly accurate estimates19
Increasingly Accurate Estimates

Iterative estimating: note quicker convergence and reduced

margin of error. (Convince management of this)


Expected size rangefor a traditional project

Expected size range for an iterative project


Relative Size Range


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.



Project Schedule / Iterations

Iterative Project Management / 01 - Iterative and Incremental Development

plain facts on estimating 1
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 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 estimates22
Increasingly Accurate Estimates

Note the margin of error decrease over time.







Estimate of work to complete




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
7. Reducing Levels of Change

Reducing levels of change? How so? Discuss.


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)



Project Schedule / Iterations

Iterative Project Management / 01 - Iterative and Incremental Development

defect density


Defect Density /Defects per Line of Verified Code


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
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
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 resources what do we need to iterate
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

team responsibilities

Project Management

Requirements Management




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
Increasing Enthusiasm, Morale, Collaboration, And Effective Teamwork

Iterative approach is characterized by

Regular demonstrations



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 a ttitude 1
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 a ttitude 2
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
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