Keeping the Peace: Mixing Agile and Waterfall

1
Keeping the PeaceMixing Agile and Waterfall

• Dr. Matthew Ganis, IBM Senior Technical Staff
  Member
• Tom Hawkins, Program Manager, ibm.com

Westchester Project Management Institute March
13, 2008
Slides available at http//webpage.pace.edu/mgani
s
2
Agenda Keeping the Peace

• Overview of Agile Methods
• What are some of the components/practices
• Issues weve run into (solutions we use)

3
What is Agile

• Agile Software methodologies and practices
  emphasize
• Empirical process control
• Quick delivery of valuable functionality
• Simple designs
• Constant Communication

4
Definition of Agile1
Agile is an iterative and incremental
(evolutionary) approach to software development
which is performed in a highly collaborative
manner with "just enough" ceremony that produces
high quality software which meets the changing
needs of its stakeholders.
1 http//www.agilemodeling.com/essays/agileSoftwar
eDevelopment.htm
5
Plan-driven methods

• Assumes requirements are understood up front and
  are relatively stable
• Assumes software can be manufactured
• Emphasizes Big-Design Up Front (BDUF)
• Step-by-step execution
• De-couple architecture and design from coding and
  testing
• Different teams for different aspects

6
Where did Agile come from? The Agile
manifesto specifies
Continuous delivery of valuable software.
Welcome changing requirements (even late in
development) Deliver working software
frequently Business people and developers must
work together daily Build projects around
motivated individuals. Trust them face-to-face
conversation.
Working software is the primary measure of
progress. Agile processes promote sustainable
development. Simplicity (maximize the amount of
work not done) Form self-organizing teams. At
regular intervals, reflect on how to become more
effective, then tune and adjust
7
Key Agile Terms
8
Exploring - not Big Up-Front Planning

• Agile is a methodology where we come up with a
  solution to a problem not by planning or
  analysis, but by exploratory programming
• This leads us to Iterative development

9
Iterative development(getting closer to the
target)
Further iterations
Assuming you knew all the requirements
Iteration 1
Iteration 2
Iteration 3
Time (measured in iterations)
10
The promise of Agile
Releases are composed of a number of iterations,
as the iterations progress, stories are
completed, and new ones are introduced
Within an iteration, stories are created In a
planning game, stories are selected by the
customer based on value
At some point, there exists a deliverable, that
delivers enough value that the customer says
stop since the remaining stories dont
contribute sufficient value
Agile allows for faster deliverables at a lower
cost (assuming the customer decides, based on
what they see, that a set of stories arent
needed)
11
What is Extreme Programming

• XP is extreme in the sense that it takes 12
  well-known software development "best practices"
  to their logical extremes

XP helps define HOW to go about the project
Its not rocket science!
12
XP Practices

• Planning Game
• Small Releases
• Simple Design
• Continuous Testing
• Refactoring
• 40-hour work week

• Pair Programming
• Collective code ownership
• Continuous Integration
• On-Site customer
• Coding standards

13
Scrum (project management)
14
Typical Agile Flow
Retrospective
ReleasePlan
New Velocity
Unfinished Work
Stories
New Function
Iteration Planning
Latest Version
Velocity
Development
BugFixes
CustomerInteraction
Bugs
Iteration Plan
Refactoring
1 day (meeting)
2 weeks (typical)
Last day of Iteration
1-2 days
15
How do we marry the two ?
Waterfall
VS.
Iterative
16
Why mix Agile and Waterfall

• Existing projects process and tools
• Externally dependant groups using waterfall
• Executives still need to plan for annual project
  funding and resource allocation

17
We provide the corporate portal but have several
stakeholders that represent various IBM Brands

• The IBM.COM Organization drives or provides
• Standards
• To Ensure that sites are uniform
• Dynamic capabilities
• Masthead
• Footer
• Personalization
• Page tools

SWG
STG
IBM.COMCorp.portal
Services
Support
18
What is Whole Team?

• A team working in isolation (i.e., without
  the supporting functions integrated into the
  team) will tend to not fully realize the
  advantages of Agile techniques

The team is only as Agile as its weakest link
19
Do these opposites attract?

• Following a strict Plan
• Formal Checkpoints
• Big upfront design
• Big Bang delivery

• Plan as we go
• No Checkpoints
• Agile modeling
• Many small releases

Vs.
20
What happens when we mix the two?
21

• But we need documentation.
• Create user stories within the iteration
• Try to understand,we dont know it all (yet)
• Try to use what we do have

22
Try to combine the two methods
Pre-planning game
Set Iteration Goals
planning game
Create Supporting Stories
planning game
Agile Team 1 (or other team)
Execution
Agile Team
Feature
Integrated Deliverable
23
Pre-planning game

• Helps in organizational communication
• Allows dependencies to surface
• Gets each side used to how the other half
  lives

24
What if my feature doesnt make it
Agile Projects are better with Feature and
Function Usage. The traditional requirements
document is a guess.
Lesson Agile helps you build
the right functions and the best product
A bedrock Agile principle states Satisfy the
customer through early and continuous delivery of
valuable software.
Agile practices focus on intelligent and
responsive reaction to change. The Laws of
Software Process Philip G. Armour- 2004
25
Managing requirements

• Managing requirements in this hybrid model is
  difficult
• Non-Agile teams need answers that arent soft
• Agile teams dont view things as requirements,
  thus something being 80 done is foreign to
  them.
• Its either done or not done

26
Delays.

• Agile is predicated on fast answers and
  clarifications to questions and issues (sometimes
  the answers are wrong or incomplete)
• However, Doing something wrong is vastly better
  than doing nothing (for an iteration)

27
Managing Agile and Plan-driven Requirements
Common Repository of Requirements used by IBM
Agile Customer
stories
Non-Agile
Agile
Development Team
28
Functional Requirements and Documentation

• Weve modified the concept of a Functional
  Specification to become a Functional Description
• Rather that document to the smallest detail what
  we are going to do, we document at a higher
  level, introducing capabilities over requirements.

29
Capabilities decompose into stories(Dealing with
the marketing problem)
Capability 1
Capability 2
Capability 3
Capability n
Stories
Story for capability 1

• Marketing talks in terms of Capabilities
• Development talks in terms of Stories

Story for capability 3
Story for capability 3
Story for capability 2
Story for capability 2
Story for capability 2
Story for capability 4
Iteration 2
Iteration 1
Iteration 3
Time
30
Stumbling blocks

• Executive team needs end to end plans with
  project milestones and deploy dates
• Business owners want committed/dedicated
  resources for projects
• Limited development resources

31
Success?

• Have we been successful?
• Sort of
• Agile projects complete and ship on time
• We need to get better at incremental delivery
• Strictly waterfall teams understand us better,
  but still dont always react fast enough

32
Questions ?
Thank you Matt Ganis (ganis_at_us.ibm.com) Tom
Hawkins (hawkins_at_us.ibm.com)