The document discusses mixing agile and waterfall methodologies for software development projects. It provides an overview of agile methods and some typical components and practices of agile. It then discusses some of the issues that can arise from mixing the two approaches and provides some solutions that have been used. The document aims to explain how to integrate elements of agile development into projects that also involve more traditional waterfall elements or dependencies.
The document discusses mixing agile and waterfall methodologies for software development projects. It provides an overview of agile methods and some typical components and practices of agile. It then discusses some of the issues that can arise from mixing the two approaches and provides some solutions that have been used. The document aims to explain how to integrate elements of agile development into projects that also involve more traditional waterfall elements or dependencies.
The document discusses mixing agile and waterfall methodologies for software development projects. It provides an overview of agile methods and some typical components and practices of agile. It then discusses some of the issues that can arise from mixing the two approaches and provides some solutions that have been used. The document aims to explain how to integrate elements of agile development into projects that also involve more traditional waterfall elements or dependencies.
The document discusses mixing agile and waterfall methodologies for software development projects. It provides an overview of agile methods and some typical components and practices of agile. It then discusses some of the issues that can arise from mixing the two approaches and provides some solutions that have been used. The document aims to explain how to integrate elements of agile development into projects that also involve more traditional waterfall elements or dependencies.
Download as PPT, PDF, TXT or read online from Scribd
Download as ppt, pdf, or txt
You are on page 1/ 32
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 Requirements
Analysis
Different teams for Architecture
different aspects Design
Code
Test
Deploy
Time Where did Agile come from? The Agile manifesto specifies:
(even late in development) sustainable development. Deliver working software frequently Simplicity (maximize the amount of work not done) Business people and developers must work together daily Form self-organizing teams.
Build projects around motivated At regular intervals, reflect on
individuals. Trust them how to become more effective, then tune and adjust face-to-face conversation. Key Agile Terms Term Definition A project conducted under an Agile Method is broken up into Stories a set of very small deliverables called stories. Velocity is a method for measuring the rate at which teams Velocity consistently deliver business value in a software system (at what rate can they deliver stories) Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each Iteration iteration is an entire software project: including planning, requirements analysis, design, coding, testing, and documentation. Stories are implemented within iterations The stakeholder that is responsible (i.e., has money) and Customer “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
e nts irem u req ll the a new k you m ing Iteration 1 suIteration 3 Iteration 2 s A Time (measured in iterations) The “promise” of Agile
Iteration n Iteration 1 Iteration 2
Within an iteration, stories Releases are composed of
At some point, there exists are created a number of iterations, as a deliverable, that delivers the iterations progress, In a planning game, stories enough value that the stories are completed, and are selected by the customer says “stop” since new ones are introduced customer based on value 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 well- known 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 Pair Programming Small Releases Collective code Simple Design ownership Continuous Testing Continuous Integration Refactoring On-Site customer 40-hour work week Coding standards Scrum (project management) Typical Agile Flow Retrospective Release Plan New Velocity St or Unfinished ies Work New Function Velocity Iteration Latest Planning Development Version Bug Customer Fixes Interaction Bugs Iteration Plan Refactoring
1-2 days 1 day 2 weeks Last day of
(meeting) (typical) Iteration How do we marry the two ? Requirements
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 We provide the corporate portal but have several “stakeholders” that represent various IBM Brands
The IBM.COM Organization
SWG STG drives or provides: •Standards • To Ensure that sites IBM.COM are uniform Corp. portal • Dynamic capabilities • Masthead Services 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 Plan as we go Formal Checkpoints No Checkpoints Vs. Big upfront design Agile modeling “Big Bang” delivery 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 Set Iteration Goals
planning game planning game Create Supporting Stories
Agile Team 1 Execution
Agile Team (or other team)
Feature 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.
A “bedrock” Agile principle states:
“Satisfy the customer through early and continuous delivery of valuable software.“
[1] Customers often don't
know exactly what they want at the beginning of a project.
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
Convert Applicable Requirements RSC Reqts into Agile stories
Common RSC Repository of RSC Agile Requirements Requirement Database Customer used by IBM
stories Non-Agile Agile Xplanner 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
Stories Story for capability 1
•Marketing talks in Story for capability 3 terms of Capabilities Story for capability 3
Story for capability 2
•Development talks in Story for capability 2 terms of Stories Story for capability 2
Story for capability 4
Iteration 1 Iteration 2 Iteration 3
Time 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
