chapter 8athena.ecs.csus.edu/~buckley/csc233/apm_ch8.pdf · agile project management jim highsmith...
TRANSCRIPT
Failure to keep Release Plans current!
Management needs to know how a business problem will be solved, its
cost, how long it will take, and how much risk is involved!
Agile teams response: “How do we commit to something with a
reasonable assurance of delivery and at the same time leave room for
change, learning and surprises?”
Key is in understanding the purpose of the release plan… to:
– Foster a better understanding of project viability and feasibility
– Outline assessment and mitigation of risk
– Enhance a team’s ability to prioritize capabilities and stories
– Give the team a “feel” for the entire project
– Enable answers to management questions about value, schedule, and cost
– Create a comfort level about the project with both ream members and
management
– Create a plan for partial deployment
Wish-based planning
(balancing capacity and demand)
Managers think they can push teams hard enough they will
respond “heroically”… typical view
Reality… the result is dysfunctional teams, not high performance
teams.
… managers wishing the team can deliver 50 features in the next release
because of market demand, even though developers know that 30 features
is more realistic.
Wish-based planning results
Plans created where demands exceed capacity and development groups are
forced to accept the demands
Schedules and features are missed
Management typical response… improve estimating and planning
skills until the desired plan emerges
Developers often lack…
Appropriate estimating skills
… putting themselves in poor positions by always saying no
Good negotiating skills
Management and marketing “folks” are adept at negotiating
Developers are at a disadvantage with a lack of these skills
The ability to respond to managements use of plans as
“motivators.”
Internal motivation always trumps external / forced
motivation
Multi-level Planning
Executive and managers need some degree of
predictability… for financial and marketing planning
… as well as the ability to adapt to new situations and
information.
… as well as needing to monitor project status
Best perspective… to think at the capability level and
not the story level
Team’s plan reflects reasonable commitment to deliver the
planned capabilities
… but retains flexibility at the story level regarding which
stories would implement the capability
Product Planning Structure (Figure 8-2)
Iteration plan… the day-to-day
work plan for the development
team.
Wave plan… spans several
iterations and planned at the
story level… may represent a
partial deployment release
Release plan… results in a
deployable product (capability
or feature level)
Product roadmap… shows a
multi-release map for a
product’s evolution… over
several years
Roadmap (2 years)
Release (12 months)
Wave (3 months)
Iteration (2 weeks)
Large financial products software company
Product management group had 2-3 year roadmap of business
areas and capabilities to be implemented.
… worked out an 18 month feasible release plan of 300
capabilities for several teams
… each team developed a 3-month story-level wave plan and
then developed detailed story and task level iteration plans.
Each of the plans was updated periodically.
Product Planning Structure (Table 8-1)
Characteristic Release Wave Iteration
Timeframe Long-rage Medium-range Short-range
(6+ months) (3 months) (1-4 weeks)
Level of Detail Capability Story Story/task
Commitment Type Project feasibility Capability
commitment
Story commitment
Deployment Final release to
customer
Possible interim
relapse to
customer
Customer review
process
Capabilities
Capability describes a high-level business or product function
that is complete and valuable…
a story delivers a piece of useful and valuable functionality to a customer.
Story may be 2-10 days of work
Capability may be somewhere between 20-100 days
Capability cases bridge the gap between the wants and needs of
the business and what the system is to do for the business users.
Team's can commit to delivering a set of capabilities, while leaving the
detailed requirements and specifics about implementation (the stories) to
the project team.
Companies need predictability and flexibility. Using a capability-story approach can
provide both predictability at the capability level and flexibility in exactly how those
capabilities are delivered at the story level.
Creating a Product Backlog & Roadmap
Backlog grows over time… as capabilities are converted
to stories
Information about each backlog item improves…
Detail is not added until it is really needed… to avoid normal
changes (Just-In-Time philosophy)
System Change Requests (SCRs) are also added (typical
for legacy applications)
…maintenance requests, persistent defects, small
enhancements, technical debt reduction
Product Lifecycle (Figure 8-3)
Product conceptualization phase leads to a project chartering
session to through the product vision, project scope and
boundaries and release planning activities.
… generating release, first-wave, and first-iteration plans.
… new stories are identified and the backlog list is updated
Product
Conceptualization
Cycle
Initial Product
Development
Cycle
Continuing Product
Development
Cycle
Product Deliver
Continuous Flow of Value
Product
Release
Plan(s)
Product
Backlog
Product
RoadmapWave and
Iteration
Plans
Note: “… UML modeling can be valuable as a documenting technique, but is also
has caused many organizations to go diagram crazy.”
Optimal Planning Structures…
… oriented to mature agile organizations.
Two scenarios:
1. A product development effort in which the product
is continuously evolving over a multi-year period
“most typical”
2. A major product development or re-development
effort in which the minimum releasable functionality
takes 12 or more months to deliver
… a significant amount of functionality must be developed
before an initial release can be made
Value Point Analysis
Stories are small chunks of functionality… and estimates are either in terms of relative size (story points) or absolute terms (hours).
Value points… translate this data to cost?
Beneficial …value points:
– indicate to executive management a serious, quantitative approach to value
– assist teams in making priority decisions during release, wave, and iteration planning
– can assist teams in negotiating depth of story functionality (e.g. is a 3-value-point story worth 21 story points?)
– help increase ROI by pushing the planning of high-value capabilities and stories earlier
Value Point Determination
Done by the “product team”, headed by the Product Manager.
The development team needs to estimate effort at some level (story, capability) to develop a full release plan…
Value Point estimating can be just-in-time (JIT)
Story Point estimates have a built-in feedback process to correct bad estimates… not the case for value point estimates
Two methods to produce relevant & useful value point estimates:
1. Limit estimates to a short series of numbers (1, 2, 3, 5, 8, 13)
2. Allocate total value points on a percentage basis to capabilities (caps the number of value points in a set of stories)
Capability point values (1, 2, 3, 5)
5 capabilities with capability points 2, 3, 3, 5, 1
Convert to percentages 2/14, 3/14, 3/14, 5/14, 1/14 14%, 21%, 21%, 36%, 8%
Assign value points to the stories in each capability… and sum these for each capability
Total value points for each capability should have a 14%, 21%, 21%, 36%, 8% distribution
Story Cards with Value Points (Figure 8-4)
During iteration planning… if stories with low value-points but
high story-points, an assessment of whether or not the low-value
story (V-2) is worth the estimated work (C-21) should occur.
As a sales associate,
the ability to calculate
the total amount of
the sale
V-13 C-13
As a sales supervisor, the
ability to verify the
adequacy of the customer's
credit rating.
V-2 C-21
As a sales executive, the
ability to view all sales b
product type, geographic
region, and sales associate.
V-3 C-8
Value and Cost Delivered (Figure 8-5)
0
50
100
150
200
250
300
350
400
450
1 2 3 4 5 6 7 8 9
Cum Value (NPV)
Cum Cost
# Stories
# S
tori
es, D
oll
ars
Iterations
NPV
Actual
Costs
Non-customer facing stories
… technical debt reduction stories, refactoring stories.
Technical stories that support customer facing ones.
These are typically investment type stories.
Priority setting issue… who decides?
Product teams do not usually understand technical debt
reduction, maintenance items and technical infrastructure
stories.
Collaboration and trust is needed… a prerequisite
characteristic of a mature agile development process
Planning themes and priorities…
To bring an appropriate focus to business value, project need both an overall “vision” and shorter-term “themes” that implement the vision.
Themes can be useful for iterations and in larger projects for waves
Types:
Business function groupings of capabilities, features or stories
Business process flow is a sequence of business functions that produces some final result (e.g. order-to-shipment, bill-to-payment… )
Risk mitigation focus early on… where technical hurdles need to be overcome
Partial deployment plans… may impact feature/story implementation priorities and create wave themes
“The key question a team should ask itself at the end of
each iteration is, “What is keeping us from shipping a
product right now?”
Note… when practicing one iteration-at-a-time
planning, higher level themes may get lost.
Teams should not get in a positon where pieces of
multiple capabilities are finished… but nothing is usable
to the customer.
Increasing productivity…
Do better, or do less!
Familiar data: “… over 64% of software functionality is rarely or never used, whereas just 20% was often or always used.”
One of he reasons for projects becoming larger and larger is the absence of immediate feedback on efforts to accomplish individual features… the source of “featuritis”
User requirements… list of 50 to 200 items.
“The most interesting thing… learned… was by the time we got to 20, nobody is interested in the remaining 80 or more items.
Agile project can improve productivity by doing less in two dimensions – breadth (the list of requirements) and depth (implementing a req’t or story but altering the depth of functionality.
Risk Analysis and Mitigation
Core risks that dominate software projects:
1. Inherent schedule flows
2. Requirement inflation (creep)
3. Employment turnover
4. Specification breakdown
5. Poor productivity
“The best bang-per-buck risk mitigation strategy we
know is incremental delivery.”
Tom DeMarco and Tim Lister
APM techniques that address schedule risk…
• Team involvement in planning and estimating
• Early feedback on delivery velocity
• Constant pressure to balance the number and depth of features with capacity constraints
• Close interactions between engineering & customer teams
• Early error detection/correction to keep a clear working product
“Requirements evolution is a rational process in which the development and customer teams are constantly evolving the requirements of the product while considering other constraints.”
Requirements evolution is a joint effort where all parties participate in deciding on features.
Requirements creep occurs when there isn’t a joint effort, when customers or developers add features indiscriminately.”
Risk: Specification breakdown
When customers and the product team fail to agree on
specifications.
The product manager, aided by the executive sponsor,
is charged with either stopping specification breakdown
or halting the project until the specification process can
be fixed.
The product manager and team are responsible for
creating a viable specification decision making process.
Planning and Scanning (looking forward)
Frequent re-planning based on progress to date and new
information gathered during development iterations is essential to
deal with the uncertainty risk.
Too great an emphasis on adaptation (we can always fix or
refactor later) means that you do not take advantage of
information that should be known.
Example: Spending a week at the beginning of a project defining
customer req’ts and constructing a skeleton data model may
improve the quality of the plan and speed of development.
Agile teams can place too much emphasis on adaptation or evolution and too little on
anticipation (in planning, architecture, design, requirements definition).
Failure to take advantage of knowable information leads to sloppy planning, reactive
thinking, excessive rework, and delay. Remember: Agility is the art of balancing.”
Scanning
… looking ahead to learn the unknown as quickly as
possible.
• Reduce uncertainty by a systematic, proactive, and early
gathering of information or identifying the information that
needs to be gathered at a future point.
• Managing risks… estimating the probability something will
happen and the negative impact that would result.
• Managing assumptions… continually scanning to determine if
the assumptions still are valid
• Maintaining a key future decisions list… assuring that the
appropriate information needed is available at the future point
in time.
Timeboxed Sizing
For capabilities … during release planning
Constraining size rather than estimating size was much
faster than trying to discuss and agree on the scope.
Early sizing in release planning is inexact regardless of
method used… so
For timeboxed sizing to work… all parties need to
understand the benefits and the limitations of the
approach.
Other story types
“The overriding concept should be that all work should be accounted
for in release and iteration planning.”
Maintenance and enhancements requests (SCRs)… converted to
stories.
Task Cards… circumstances where several days of work cannot be
included in a story card.
Change Cards… the feedback from customers and product managers at
the end of each iteration may result in change requests.
Inter-team Commitment Story Cards… large projects where one team
commits to do work for another team.
Decision milestones… critical point in the project where decisions are
required. see Figure 8-6
Performance cards… key operations and performance req’ts (non-
functional req’s) see Figure 8-7
Work-in-Process versus Throughput
Note: Multitasking (moving from one project to another) adds task switching overhead.
Figures 8-8 and 8-9
DAYS
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52
Project1
Project2
Project3
Analysis
Design
Programming
DAYS
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36
Project1
Project2
Project3
Multitasking
Non-multitasking strategy
Assumes zero time for task switching
"More throughput and less work-in-progress"
Emerging Practices
Kanban is a new technique for managing a software development process in a highly efficient way.
Kanban underpins Toyota's "just-in-time" (JIT) production system.
Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.
A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.
Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we'll assume a simple phased process of: (1) analyze the requirements, (2) develop the code, and (3) test it works.
Handout
Consolidated Development
Background Management approach to staffing… and dealing with conflicting priorities among new development, customization, and maintenance work…
• IT organizations tend to divide into new development and maintenance
• Independent software vendors (ISV) put new development, maintenance & enhancement into a single group with customization for particular clients handled by a separate group.
New developments teams seem to get bogged down in maintenance work and key customers want their customizations work done quickly.
Sutherland
Single organization works on all facets of delivery (new functionality, enhancements, SCRs)
Governed by a strategic prioritization system
Allocating work to three simultaneous, overlapping iterations
Consolidated Development (continued)
Sutherland
Weekly iterations target maintenance or minor enhancements
Monthly iterations target specific enhancements
Quarterly iterations target major new functionality
Prioritization is a strategic organizational process – involving the product manager, the CEO and other key executives.
Approach requires:
Agile delivery is a proven approach & management supports the process
Continuous integration and automated testing is ingrained in the process
Effective functioning and integrated product management, development, and QA
Hyper-development and Release
????
FINAL THOUGHTS
Release planning gives the team a game plan that
compensates for the often short iteration focus of agile
projects and gives product marketing a context in which
to make key priority decisions about capabilities and
stories.
Release planning gives management and executives a
baseline against which to determine the feasibility of
delivering a high-quality, releasable product within the
identified constraints.