keeping the peace: mixing agile and waterfall dr. matthew ganis, ibm senior technical staff member...
TRANSCRIPT
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.
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 amountof work not done)
Form self-organizing teams.
At regular intervals, reflect on how to become more effective,
then tune and adjust
Key Agile TermsTerm 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
Assuming you knew all the requirements
Time (measured in iterations)Iteration 1 Iteration 2 Iteration 3
Iteration 1 Iteration 2Iteration n
Within an iteration, stories are created
In a planning game, stories are selected by the customer based on value
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
The “promise” of Agile
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 well-known software development "best practices" to their logical extremes
It’s not rocket science!
XP helps define HOW to go about the project
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
Typical Agile Flow
Stories
Velocity
Unfinished Work
New Function
BugFixes
New Velocity
Refactoring
Retrospective
Iteration Planning Development
Latest Version
ReleasePlan
Bugs
CustomerInteraction
Iteration Plan
1-2 days 1 day (meeting)
2 weeks (typical)
Last day of Iteration
How do we marry the two ?Requirements
Analysis
Architecture
Design
Code
Test
Deploy
Time
• Arch•User Design•Development•Customer•DBA•Deploy
Start Finish• Arch•User Design•Development•Customer•DBA•Deploy
• Arch•User Design•Development•Customer•DBA•Deploy
VS.
Waterfall
Iterative
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
IBM.COMCorp.portal
SWG STG
ServicesSupport
The IBM.COM Organization drives or provides:
•Standards
• To Ensure that sites are uniform
• Dynamic capabilities
• Masthead
• Footer
• Personalization
• Page tools
We provide the corporate portal but have several “stakeholders” that
represent various IBM Brands
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 Big upfront design “Big Bang” delivery
Plan as we go No Checkpoints Agile modeling Many small releases
Vs.
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
Pre-planning game
planning game
planning game
Agile Team 1(or other team)
Feature
Agile Team
Set Iteration Goals
Create Supporting Stories
Execution
Integrated Deliverable
Try to combine the two methods
Pre-planning game
Helps in organizational communication Allows dependencies to surface Get’s each “side” used to how the “other”
half lives
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.“
What if my feature doesn’t “make it”
Agile Projects are better with Feature and Function Usage. The traditional “requirements document” is a guess.
Customers often don't know exactly what they
want at the beginning of a project.
Customers often don't know exactly what they
want at the beginning of a project.
[1]
“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 difficultNon-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
RSCRequirement
Database
Stakeholders
RequirementsConvert ApplicableRSC Reqts into Agilestories
RSC
Xplanner
stories
Non-Agile Agile
Common Repository of Requirements used by IBM
Agile Customer
Development Team
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 Capability 3 Capability n
StoriesStory for capability 1
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 1 Iteration 2 Iteration 3
Time
•Marketing talks in terms of Capabilities
•Development talks in terms of Stories
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 timeWe need to get better at incremental deliveryStrictly waterfall teams understand us better,
but still don’t always react fast enough