Keeping the Peace: Mixing Agile and Waterfall

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

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

Key Agile Terms

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 Iteration 1 Iteration 2 Iteration 3 Time (measured in iterations)

Iteration n Iteration 1 Iteration 2 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 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!

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 XP Practices

Scrum (project management)

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

Start Finish • Arch • User Design • Development • Customer • DBA • Deploy • Arch • User Design • Development • Customer • DBA • Deploy • Arch • User Design • Development • Customer • DBA • Deploy How do we marry the two ? Waterfall VS. 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 drives or provides: • Standards • To Ensure that sites are uniform • Dynamic capabilities • Masthead • Footer • Personalization • Page tools SWG STG IBM.COMCorp.portal Services Support

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.

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 Create Supporting Stories planning game Agile Team 1 (or other team) Execution Agile 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

[1] Customers often don't know exactly what they want at the beginning of a project. What if my feature doesn’t “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

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)

Stakeholders Convert Applicable RSC Reqts into Agilestories Requirements RSC RSCRequirement Database Xplanner Managing Agile and Plan-driven Requirements Common Repository of Requirements used by IBM Agile Customer stories Non-Agile Agile 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 3 Capability 1 Capability 2 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

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)

Keeping the Peace: Mixing Agile and Waterfall