1. 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

2. Agenda – Keeping the Peace Overview of Agile Methods What are some of the components/practices Issues we’ve 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 Agile 1 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

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 TermDefinition 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

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

10. Iteration 1Iteration 2 Iteration 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)

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 It’s not rocket science! XP helps define HOW to go about the project

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 Stories Velocity Unfinished Work New Function Bug Fixes New Velocity Refactoring Retrospective Iteration Planning Development Latest Version Release Plan Bugs Customer Interaction Iteration Plan 1-2 days 1 day (meeting) 2 weeks (typical) Last day of Iteration

15. How do we marry the two ? Arch User Design Development Customer DBA Deploy StartFinish Arch User Design Development Customer DBA Deploy Arch User Design Development Customer DBA Deploy VS. Waterfall 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. IBM.COM Corp. portal SWGSTG Services Support 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

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 it’s 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 don’t know it all (yet) Try to use what we do have

22. Pre-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

23. Pre-planning game Helps in organizational communication Allows dependencies to surface Get’s each “side” used to how the “other” half lives

24. 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. [1] “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 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

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 RSC Requirement Database Stakeholders Requirements Convert Applicable RSC Reqts into Agile stories RSC Xplanner stories Non-Agile Agile Common Repository of Requirements used by IBM Agile Customer Development Team

28. 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.

29. Capabilities decompose into stories (Dealing with the marketing problem) Capability 1 Capability 2 Capability 3 Capability n Stories Story for capability 1 Story for capability 3 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

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 don’t always react fast enough

32. Questions ? Thank you…… Matt Ganis (ganis@us.ibm.com)ganis@us.ibm.com Tom Hawkins (hawkins@us.ibm.com)