Keeping the Peace:
Mixing 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/mganis
Agenda – Keeping the Peace



Overview of Agile Methods
What are some of the components/practices
Issues we’ve run into (solutions we use)
What is Agile

Agile Software methodologies and
practices emphasize:
 Empirical
process control
 Quick delivery of valuable functionality
 Simple designs
 Constant Communication
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/agileSoftwareDevelopment.htm
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
Requirements
Analysis
Architecture
Design
Code
Test
Deploy
Time
Where did Agile come from?
The Agile manifesto specifies:
Continuous delivery of
valuable software.
Working software is the
primary measure of progress.
Welcome changing requirements
(even late in development)
Deliver working software
frequently
Agile processes promote
sustainable development.
Business people and developers
must work together daily
Build projects around motivated
individuals. Trust them
face-to-face conversation.
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
Key Agile Terms
Term
Definition
Stories
A project conducted under an Agile Method is broken up into
a set of very small deliverables called stories.
Velocity
Velocity is a method for measuring the rate at which teams
consistently deliver business value in a software system (at
what rate can they deliver stories)
Iteration
Software developed during one unit of time is referred to as
an iteration, which may last from one to four weeks. Each
iteration is an entire software project: including planning,
requirements analysis, design, coding, testing, and
documentation. Stories are implemented within iterations
Customer
The stakeholder that is responsible (i.e., has money) and
“owns” the requirement
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…

Iterative development
(getting closer to the target)
Further iterations
Iteration 1
Iteration 2 Iteration 3
Time (measured in iterations)
The “promise” of Agile
Iteration 1
Within an iteration, stories
are created
In a planning game, stories
are selected by the
customer based on value
Iteration n
Iteration 2
Releases are composed of
a number of iterations, as
the iterations progress,
stories are completed, and
new ones are introduced
At some point, there exists a
deliverable, that delivers
enough value that the
customer says “stop” since
the remaining stories don’t
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 aren’t needed)
What is Extreme Programming

XP is extreme in the sense that it takes 12 wellknown software development "best practices" to
their logical extremes
XP helps define HOW
to go about the project
It’s not rocket science!
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
Scrum (project management)
Typical Agile Flow
Retrospective
Release
Plan
New Velocity
Unfinished
Work
Velocity
Iteration
Planning
New
Function
Development
Customer
Interaction
Bugs
1-2 days
Iteration
Plan
1 day
(meeting)
Bug
Fixes
Latest
Version
Refactoring
2 weeks
(typical)
Last day of
Iteration
How do we marry the two ?
Requirements
Analysis
Architecture
Design
Code
Test
Waterfall
Deploy
Time
VS.
Start
• Arch
•User Design
•Development
•Customer
•DBA
•Deploy
• Arch
•User Design
•Development
•Customer
•DBA
•Deploy
Iterative
• Arch
•User Design
•Development
•Customer
•DBA
•Deploy
Finish
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

We provide the corporate portal but
have several “stakeholders” that
represent various IBM Brands
SWG
STG
The IBM.COM Organization
drives or provides:
•Standards
• To Ensure that sites
are uniform
IBM.COM
Corp.
portal
Services
• Dynamic capabilities
• Masthead
Support
• Footer
• Personalization
• Page tools
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 it’s weakest link
Do these opposites attract?




Following a strict Plan
Formal Checkpoints
Vs.
Big upfront design
“Big Bang” delivery




Plan as we go
No Checkpoints
Agile modeling
Many small releases
What happens when we
mix the two?
But we need documentation…….
•Create user stories within the
iteration
•Try to understand,we don’t know it
all (yet)
•Try to use what we do have
Try to combine the two methods
Pre-planning game
planning game
planning game
Agile Team 1
(or other team)
Agile Team
Feature
Set Iteration Goals
Create Supporting
Stories
Execution
Integrated
Deliverable
Pre-planning game
Helps in organizational communication
 Allows dependencies to surface
 Get’s each “side” used to how the “other”
half lives

What if my feature doesn’t “make it”
Agile Projects are better with Feature and Function Usage. The traditional “requirements document” is a guess.
ten Used
A “bedrock” Agile principle states:
13%
“Satisfy the customer through early and
continuous delivery of valuable
software.“
Sometimes
Used
16%
Never Used
45%
[1] Customers often don't
know exactly what they
want at the beginning of a
project.
Rarely Used
19%
Lesson: Agile helps you build the right functions
and the best product
“Agile practices focus on intelligent and responsive reaction to
change.” The Laws of Software Process Philip G. Armour- 2004
Managing requirements

Managing requirements in this hybrid
model is difficult
 Non-Agile
teams need answers that aren’t
“soft”
 Agile teams don’t view things as
requirements, thus something being 80%
done is “foreign” to them.

It’s either done or not done
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)
Managing Agile and Plan-driven Requirements
Stakeholders
Requirements
Common
Repository of
Requirements
used by IBM
Convert Applicable
RSC Reqts into Agile
stories
RSC
RSC
Requirement Database
Agile
Customer
stories
Non-Agile
Agile
Development Team
Xplanner
Functional Requirements and
Documentation
We’ve 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.

Capabilities decompose into stories
(Dealing with the marketing problem)
Capability 1
Capability 2
•Marketing talks in
terms of Capabilities
Capability 3
Stories
Capability n
Story for capability 1
Story for capability 3
Story for capability 3
Story for capability 2
•Development talks in
terms of Stories
Story for capability 2
Story for capability 2
Story for capability 4
Iteration 1
Iteration 2
Time
Iteration 3
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

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 don’t always react fast enough
Questions ?
Thank you……
Matt Ganis
(ganis@us.ibm.com)
Tom Hawkins
(hawkins@us.ibm.com)