Planning Iterative Development Projects

1
Planning Iterative Development Projects

• Nancy Fuller, PMP
• Outside the Box, LLC.

2
Outside the Box, LLC

• Provides consulting in process implementation/impr
  ovement across the project lifecycle
• Work with RUP (Rational Unified Process) and
  Rational tools
• Expertise in project management and requirements
  management
• PMP and Rational certified

3
Agenda

• Project Planning-
• Who does it?
• What is it?
• Issues in project planning
• Characteristics and benefits of iterative
  development
• Project plans vs. iteration plans
• Planning objectives
• Planning traps, tips and strategies

4
Project Planning Is a Project Management
Responsibility

5
What is Project Planning?

• Estimation of the scope, cost and effort of the
  project
• Definition of the activities to achieve the
  projects goals.
• Creation of the project schedule
• Creation of the project budget
• Creation of a resource plan

6
The Problems with Planning

• Not sure what your goals really are
• Everyone makes mistakes in execution
• Your target changes
• Stuff happens

7
Project Planning Approaches

• Waterfall

8
Project Planning Approaches

• Iterative

Requirements
Requirements
Requirements
Deploy
Deploy
Deploy
Assess
Assess
Assess
9
Benefits of Iterative Development

• Do the project in chunks (iterations) to
• Mitigate risk
• Accommodate change
• Learn along the way
• Improve quality
• Increase reuse

10
Iterative Development Definitions

• Phase - the time between two major project
  milestones, during which a well-defined set of
  objectives is met, artifacts are completed, and
  decisions are made to move or not move into the
  next phase. A phase is comprised of 1 or more
  iterations.
• Iteration a time period in which a number of
  predefined tasks are performed and results are
  evaluated to feedback to the next iteration. An
  iteration results in a release.
• Release (external) a coherent set of completed
  functionalities (code and other artifacts) that
  is useful to and useable by the intended users of
  the system.
• Release (internal) - a coherent set of completed
  functionalities that is used only by the
  development organization, as part of a milestone,
  or for a demonstration to users.

11
The Project Plan

• A set of start/finish dates for each phase and
  each iteration combined with a staffing profile
• Coarse- grained, little detail
• 1 project plan per project
• The RUP provides a set of unique objectives to
  accomplish for each Phase

12
Sample Project Plan

• Inception Phase 1/5/04-1/23/04
• Iteration 1 1/5/04-1/23/04
• Elaboration Phase 1/26/04-3/26/04
• Iteration 2 1/26/04-2/20/04
• Iteration 3 2/23/04-3/26/04
• Construction Phase 3/29/04-6/18/04
• Iteration 4 3/29/04-4/23/04
• Iteration5 4/26/04-5/14/04
• Iteration6 5/17/04-6/18/04
• Transition Phase 6/21/04-8/13/04
• Iteration 7 6/21/04-7/16/04
• Iteration 8 7/19/04-8/13/04

13
The Iteration Plan

• Consists of
• RUP workflow details/activities needed to
  accomplish the phase objectives and
• milestone dates for major builds, delivery of
  components from other teams, reviews, etc.
• 1 iteration plan per iteration
• A fine-grained, time-boxed plan
• Concludes with a release milestone

14
Iteration Plan (contd)

• Two iteration plans are active at any time
• The plan for the current iteration to track and
  monitor progress
• The plan for the next iteration, built during the
  second half of the current iteration

15
4 RUP Phases

• Inception Objectives
• Establish the project's scope and boundary
  identify the objectives to be met and the users
  acceptance criteria
• Identify and plan to address potential technical,
  funding and business risks
• Describe a candidate architecture
• Create an overall schedule for the entire project
• Verify that the project is viable
• Inception generally has 1 iteration

16
Inception examples

• Publish architectural models or demo a prototype
  to gain acceptance on proposed design.
• Test drive a COTS solution to identify
  problems.

17
Phases (contd.)

• Elaboration Objectives
• Fully describe the requirements that drive the
  architectural and planning decisions
• Use risk, criticality and coverage to prioritize
• Verify the architecture you chose works by
  implementing those critical requirements
• Create detailed plans for construction of the
  product
• Elaboration may have 1 or 2 iterations

18
Elaboration examples

• Create tested code that
• creates 1 record on a client workstation, stored
  on the server, using the UI but not including
  every field and assume no errors.
• undoes a database change

19
Phases (contd.)

• Construction Objectives
• Detail all remaining requirements complete the
  analysis, design, development and testing of all
  required functionality
• Manage resources and control operations to
  optimize costs, schedules and quality
• Decide if the software, the sites, and the users
  are all ready for deployment
• Create detailed plans for the first iteration of
  Transition
• Construction generally has multiple iterations

20
Construction examples

• Create tested code that
• Implements all variations of X function,
  including error handling
• Achieves X transactions per hour
• Fixes all level 1 and 2 defects

21
Phases (contd.)

• Transition Objectives
• Beta testing against user expectations and
  interfacing systems
• Converting operational databases
• Training of users and maintainers
• Tuning activities (bug fixes and enhancements for
  performance and usability
• Achieving stakeholder agreement that system meets
  acceptance criteria
• Can span several iterations

22
Transition examples

• Create tested code that
• Fixes bugs discovered at beta site
• Reduces the number of dialog boxes by 30

23
Iterative Planning Traps

• Too much in the 1st iteration
• New team, techniques, tools, domain
• Be conservative with goals (but not easy)
• Too many iterations
• Dont confuse iterations with builds
• There is overhead in planning and controlling
  each iteration
• Overlapping Iterations
• Too many irons in the fire
• Software not ready to support accelerated
  development
• Need to learn from each iteration

24
Tips and Guidelines for Iteration Planning

• If you have
• a problem domain that is familiar
• risks are well understood
• the project team is experienced
• You could consider
• a short Inception phase (scope, vision, business
  case)
• a single Elaboration iteration (requirements
  defined and architecture established)
• several Construction iterations to realize use
  cases (requirements) and flesh out architecture
• several Transition iterations to deploy the
  system to the user community

25
Tips and Guidelines for Iteration Planning

• If you have
• a problem domain that is new or unfamiliar
• a project team that is inexperienced
• You could consider
• a short Inception phase (scope, vision, business
  case)
• several Elaboration iterations to refine
  requirements and baseline an architecture
• a single Construction iteration to realize the
  remaining requirements and flesh out the
  architecture
• Several Transition iterations to migrate the
  system to the users

26
Tips and Guidelines for Iteration Planning

• A simple project may have 1 iteration per phase
• A moderate complexity project may have 1
  Inception, 2 Elaboration (an architectural
  prototype and an architectural baseline), 2
  Construction (to build up a skeletal system and
  mature it) and 1 Transition iterations
• A complex or large project may need additional
  iterations in every phase
• In general, plan to have 3-10 iterations, with
  most projects having 6-8 iterations

27
Iteration Strategies How to decide what to
examine first

• There are 2 strategies
• 1 Wide and Shallow
• Analyze entire problem domain at a high level.
• Define all requirements and flesh out most.
• Define key services and mechanisms provided by
  the architecture
• Define interfaces but detail only if risky
• Little implemented until Construction

28
Wide and Shallow Strategy

• Use wide and shallow when
• The team is inexperienced in problem domain or
  technology
• Architecture is new and future capabilities will
  depend on it
• Pitfalls
• Analysis paralysis
• Real architectural risks not identified
• Postponing executable releases may impact team
  confidence

29
2 Narrow and Deep Strategy

• Narrow and Deep Analyze a slice of the problem
  thoroughly
• Define use cases in great detail
• Define the supporting architecture
• Design and implement this slice of the system
• Subsequent iterations address designing and
  implementing other vertical slices

30
Narrow and Deep Strategy

• Use narrow and deep when
• Early results are needed to overcome a dominant
  risk or gather support
• Requirements are continuously evolving
• A deadline is mandatory requiring an early start
  on development
• A high degree of re-use is possible which helps
  enable incremental delivery
• Pitfalls
• Stovepipe development difficult to integrate
  horizontally
• Not applicable for totally new development which
  needs a broad perspective to achieve a balanced
  architecture

31
References

• Articles on the Rational Edge
• Iterative Development, Oct. 2002
• Planning an Iterative Project, Oct. 2002
• Managing Iterative Software Development with Use
  Cases, Mar. 2003

32
Planning Iterative Development Projects

• For help with planning or other project
  management or process problems contact Nancy
  Fuller at Outside the Box, LLC
• NFuller_at_OutsidetheBoxllc.com
• www.OutsidetheBoxllc.com
• Thank You!