Download Iterative Project Management

Iterative Project
Management
Lifecycle Planning
Chapter 4 – Selected Sections
Are you Ready for Iterative Project Management?
pp 123-131; 142-153
I. Introduction
• There are many problems with adapting to an
iterative / incremental development approach that
people perceive.
• We will discuss several of the key issues.
• Right Attitude: In truth, much of the transition
requires the team to have the
– right attitude toward the projects and
– how to work together.
– Real change in mind-set must be accommodated
– Willingness to eschew the conventional methods.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
2
Attitude is Critical! Attitude is the Real Key!
• New attitudes are needed.
– Must Address Uncertainty and Change –
• Best way: clearly demonstrate real progress;
• Best shown: working software that provides real value.
– Verified; testaments…
– Must deliver immediate and realizable value back to the business
– Must address our attitude regarding teamwork and accountability
• Will be interacting with many stakeholders continuously ;
• shared responsibilities, etc.
– Must adopt a progressive attitude – a real change in estimating,
planning, and managing the software project
• The right team attitude is critically important!
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
3
Value Delivery – The Key to Success
• It is absolutely essential to produce real business value
• We must realize:
– Requirements are not all equal.
– Value working components vice technical components (like a sort)
• Delivering requirements with verified code might not be delivering
the best business value
• Don’t worry about implementing lots of requirements at the
expense of not focusing on real desired outcomes.
– Track stakeholder and business value, not project cost and schedule
• It is all about delivering verified, measurable Business
Value!
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
4
Quick failure recipes: Requirements  Business Solution
• Implementing requirements versus solving problems.
– Problems are of a higher order… will include meeting requirements
Iterative / incremental projects can fail too if developers
concentrate on implementing requirements rather than
iteratively solving problems.
• Addressing technical risk which is fine - without
concomitant business value.
Iterative projects can fail if developers concentrate on
addressing technical risks and yet fail to deliver usable
versions of software that provide realizable benefit.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
5
Value Delivery – The Key to Success – slide 2
• Great Statistics:
– Research indicates only two-thirds of implemented features in
successful projects were often actually required.
– Around one-third of developed software had little or no business value.
• What an incredible waste of resources!!!
• Consider: “20% of requirements have been implemented by such and
such a date.”
– This does NOT necessarily reflect real value
• Generally, by the end of the first iteration or two in Construction, we
should have a usable, complete release that may implement around
50% of the requirements. (Why?)
– Interestingly, at this point with proper iteration planning, they may have
produced a system with 80% of desired value
– But if iterations not carefully planned and pressed on implementing lesser
(but perhaps more in number) requirements, then may have around 20%
of desired value.
•
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
6
Value Delivery – The Key to Success – 3
• The key is to ensure requirements implemented in an
iteration can be mapped back to specific outcomes.
• The first iterations must implement the most
important desired outcomes as constrained by
technical risk
• Must be able to support these claims!
• Do so by demonstrating desired / measurable
outcomes.
• Ancillary: technical risks / issues are resolved.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
7
Demonstrate Measurable Value – Executable Threads
• Iterations simply must deliver measurable value to the
project team and the business.
– Assertions are fine. Demonstrate it!
• Successful Iterations define release contents in terms of
Executable releases that contain end-to-end behavioral threads of
system usage.
• Executable Thread?
– An end-to-end thread may be a use-case, or user story, scenario.
• (A scenario is an instantiation of a use-case)
• Complete threads of usage drive other development activities
to ensure verifiable systems are produced.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
8
Planning that Iteration! Plan those Early Iterations!
• Know use-cases describe the goals of the system stakeholders.
• Planning iterations via use-cases / scenarios allows us to scope and
prioritized development.
• We also know risks in projects threaten the team’s ability to deliver.
• Confront the Risks:
– Overall risks of a solution may be mitigated by choosing scenarios
that force the confrontation of the risks!!!
• Map Risks into Early Scenarios:
– Map these scenarios into the early iterations
– Successful development and demonstration provide objective
assessment that thus measurably reduce risk,
– Provide key functionality and show real business value.
• Iterations can thus be planned to ensure every iteration
steadily reduces project risk and increases business value
realized from the solution.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
9
End-to-end Threads and Tangible Value
• Successful implementation of end-to-end threads (scenarios)
provides tangible business value.
• Selection of scenarios also subdivides the requirements
enabling their assignment for development / delivery
– Scenarios in a use case may be assigned to different iterations. WHY??
• Each scenario tells a complete story of how discrete value
is delivered by the system.
– By delivering a complete scenario one-by-one, we are adding an
increment and thus realizable value.
• This provides focus on delivered value and enables
tracking to project’s desired outcomes and risks that threaten
its success
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
10
II. Changing the Way You Think About Planning
We know:
– Management of the development process is most critical.
– Common knowledge that most projects fail due to poor planning
and requirements management.
– Entire project must be managed iteratively.
– Successful iterative program management is more than just
repeatedly applying technical knowledge
But:
• The Project Manager (PM) must really believe the
iterative approach is the best way to manage the project.
– PM may need to convince many people.
– But if PM is not convinced, then little likelihood to convince others.
– PM must be ready to set aside any inflexible, predictive, waterfall
management practices used in the past.
• This may be very difficult.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
11
Conventional Project Lifecycle Revisited:
•
•
•
•
•
Specify
Design
Develop
Test
Change Over.
Traditional, Sequential Approach
• But this is an engineering approach used for years – but
never meant for software.
– Approach is predictable.
• Engineering approach was applied to software development
• Its sequential notion of activities gave rise to Waterfall Model.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
12
Conventional Thinking About Planning – Morphed from Engineering
Specify
Design
Develop
Test
Change Over
The Conventional Project
Lifecycle
Requirements
Analysis
Design
Code
Test
Deploy
The ‘Waterfall’ Software Development Lifecycle
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
13
Waterfall Planning is based on several beliefs (from book):
•
•
•
•
•
Products can be completely developed in one pass
Requirements can be completed and frozen early
All requirements are of equal importance
Designs can be verified without building and testing something.
The entire project can be planned in detail with a high degree of precision
at the start of the project
• Everything important can be known at the beginning of the project
• The project can ‘earn’ value by only doing one discipline at a time.
• Most importantly, if we follow the prescriptive steps of our process, then
all the project risks will be addressed and therefore one should measure
teams on their ability to follow a plan and managers on their ability to
create a plan.
– Plan-driven
– Documentation intensive, etc.
• The waterfall process attempts to do each step very well and eliminate
redoing any steps again, once a step is completed
• The plan itself is regarded as ‘lock’ and ‘contract;’ inviolate and perfect.
• Any deviations are considered highly undesirable.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
14
Problems with Waterfall Planning Assumptions
• Almost all the assumptions are incorrect for software development.
• We are always developing something new or redesigning something
to meet new requirements for a changing business.
• Business conditions change all the time as do technologies.
• But in the waterfall model: (book)
–  Problems are discovered too late to do anything about them
– < I left some out. See book for more very important issues>
–  Imagination and testing are always left until the end where, more often
than not, they are cut back in an attempt to meet original delivery date
–  Design feedback is obtained late usually leading to late design
breakage, when it is too late to fix problems in the architecture
–  Because objective feedback provided by demonstration and testing is
only obtained late in the project, risk resolution typically occurs too late
to be effective. (right arrows are mine)
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
15
More
• Reality is:
• Significant problems seem to always occur near the end of
the project.
–
–
–
–
Here, time is critical, staffing is maxed; costs at their highest;
deployment dates are set; perhaps equipment is installed;
transition to the new system is well established, and
many have staked their reputation (and future) on the successful
deployment of the application.
• So here we are:
• It is the failure of conventional planning wisdom on so very
many projects especially for high-value, high-risk projects
has led to the evolution of a
–
–
–
–
risk-driven,
progressive,
adaptive,
iterative and incremental approach to software development.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
16
So, here we go – the ‘cookbook:’
• Instead of developing the whole system in one ‘go,’ an increment
is selected and developed, then another increment, and so on
• The selection of the contents of the increment is based on risk,
addressing the highest priority risks first particularly those
involving core functionalities
• To address selected risk(s), select a subset of requirements from
end-to-end threads (scenarios) to be implemented and tested,
and verified (independently)
• Develop the minimal set of functionality that enables objective
measurement and verification (through a set of executable tests)
that the risks have been successfully addressed
• Then select the next highest risks and functionality associated
with these risks for the next iteration and increment. Continue…
• Each iteration produces an executable release.
• Each iteration includes integration and test.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
18
Framework – Unified Process
• We often use the Unified Process because it provides a
risk-based framework that supports and enables the
progressive, adaptive (“rolling”) planning of software
development projects.
• (Page 150) Note that every discipline in the Iterative
Lifecycle has some role in every phase (extents may vary)
• In this way, iterative planning is adaptive because plans
will change as risk is dealt with in an iteration.
– Thus requirements might change, analysis and design will likely be
impacted by change, etc..
– Hence the disciplines (analysis, design, configuration
management, etc.) are present in every iteration.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
19
Comparing Conventional and Iterative Thinking on Planning
Conventional
Progressive
Risk agnostic
Actively attacks risk
Risks drives the iterations.
Predictive planning
Adaptive planning
Planning can respond to change
Subjective measurement of progress
Objective measurement of progress
by demonstration of business value
Delays integration and testing
Continuous integration and testing
Not done until the end where time
is scrunched
Nothing runs until the end
Something executable produced
every iteration
Vice subjectively measure progress
Difficulties at the end of the project
Difficulties at the start of the project
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
20
Seven Habits of Successful Iterative Project Managers (book)
• In Summary:
– Break large projects into smaller projects and then break the smaller
projects up into iterations
– Attach the greatest risk in the earliest iterations
– Produce something demonstratable every iteration
– Do not delay integration and test
• Every iteration should include integration and test activities
– Be prepared to make mistakes and explore blind alleys.
• Mistakes are to be encouraged if they reduce the project risk or
challenge the project’s assumptions.
– Plans must be adjusted based on lessons learned
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
21
Application of these principles leads to Changes in management behavior
• These are summed up in the next seven habits: (book)
– Steadily focus on advancing the solution in small but deliberate
steps
– Focus on generating results but not afraid to fail
– Exercise adaptive planning continuously
– Always be risk-aware
– Always be open and honest
– Focus on objective results-based assessments (not subjective
opinion-based ones)
– Singularly focus on delivering a working solution.
© 2005 Ivar Jacobson International
Iterative Project Management / 03 - Lifecycle Planning
22