Waterfallacies V1 1

Evolution of Software Development Lifecycles: Waterfallacies and Agile Methods Jorge Boria

A Claim I am concerned, not with an unattainable objectivity, but with an attainable honesty. John Dominic Crossan The Historical Jesus, 1992

A Second Claim I am going to describe my personal views about managing large software developments. Dr. Winston W. Royce Managing the Development of Large Software Systems August 1970

Our Purpose Tonight Answer the questions: Where does Agile come from? What Lifecycle will work for me? Do we give up on lifecycles before we should? Are we stuck on searching for a silver bullet?

Agenda Ancestors Royce’s waterfall Spiral JAD RUP RAD and RAP Examples eXtreme Programming TDD Scrum (and CMMI)

Remember the 60’s? “ methodology”  = methods + processes + semantic modeling languages Centrally, Hierarchical decomposition HIPO, Structured Design, Jackson, Nassi-Shneiderman

The Meaning of Life (Cycles) Arriving at an operational state, on-time, and within costs, using what others have done before How can I come up with my own lifecycle to accommodate my issues? Which is the label that I need to buy into and impose on the company? NIH Copy Cat

The Underlying Premise The quality of a system is preeminently influenced by the quality of the processes used to develop, acquire, and maintain it. you should already have the best available you should already have the best available PROCESS PEOPLE TECHNOLOGY

The Infamous Waterfall Royce, ibid

And Royce’s Comment On It… I believe in this concept, but the implementation described above is risky and invites failure . […] in effect the development process has returned to the origin one can expect up to a 100-percent overrun in schedule and/or costs. Royce, ibid

Royce’s Real Waterfall Royce, ibidem

Initial Solutions – Spiral Model (Boehm) Scaled down prototypes built to preliminary design Risk guides iterations Customer can abort Partial waterfall in every step Complete waterfall at the end, if needed

Initial Solutions - JAD ( Silver and Wood) One of the first successful application of time-boxing: JAD’s were restricted to a week, development to a few months Based on some “modern” premises: those who do the job have the understanding software products affect the business as a whole http://www.utexas.edu/ecs/trecs/hris/pub/jad.php

The Problem Changes Accommodating faster and faster business cycles

A Transition Moment The Rational Unified Process ( Jacobson, Booch, Rumbaugh et al) Develop software iteratively (sashimi*) Manage requirements Use component-based architectures Visually model software Verify software quality Control changes to software *Takeuchi and Nonaka

The RUP Lifecycle Implementation of the spiral model. First break of waterfall sequence Organizes tasks into phases and iterations. Four phases: Inception Elaboration Construction Transition

Initial Solutions - RAD ( Martin) Prototyping using tools and environments (RAD Tools) Increasingly Functional Iterative Development Time Boxing Small Teams Active and Involved Management Approach

The Problem Accelerates Accommodating faster and faster business cycles: Internet Time!!!!

Agile Life Cycle Models - 1 Shared characteristics software development process is inherently chaotic engineers can thrive in the chaos embrace change, not manage change short iterations between product deliveries less than two months goal of four weeks YAGNI: don’t code it until the customer requests it http://www.agilemanifesto.org/

Agile Life Cycle Models - 2 Shared characteristics (continued) small teams strong supporting environment product manager role setting firm priorities for each iteration developers define tests prior to coding small effort on planning, large effort on control daily builds of the software

Agile Life Cycle Models - 3 Agile Alliance (source) Kent Beck (XP, TDD) Mike Beedle, Scrum Alliance (Scrum, Xbreed) Alistair Cockburn (Crystal) Ken Schwaber (Scrum) Peter Coad (FDD) … How the models differ degree of up-front design of the product, before coding size of project for which they are useful team size that works best

The X in XP If code reviews are good… If testing is good… If design is good… If architecture is good… If integration testing is good… If short iterations are good… ...do it all the time!

eXtreme Programming - 1 Exploration phase developers establish tools and technologies customers develop stories (scenarios, requirements) Planning developers estimate effort, balance load commitments established with customer during development: record progress rearrange work as needed Source: Beck, eXtreme Programming Explained

eXtreme Programming - 2 Iterations to First Release 1-4 week cycles of building and verifying first iteration establishes architecture Productionizing shorter iterations, certifying the software may tune performance Source: Beck, eXtreme Programming Explained

eXtreme Programming - 3 Maintenance normal state of an XP project simultaneous addition of functionality and supporting system each release has exploration, planning, iterations to release Death when no further features are needed if system doesn’t deliver as needed Source: Beck, eXtreme Programming Explained

eXtreme Programming - 4 Productionizing Iterations (each 1-4 weeks) Planning Exploration Verify Stories (Requirements Scenarios) Estimates; Commitments Test Cases; Building, Verifying, Software; Certifying; Tune Performance Build Source: adapted from Beck, eXtreme Programming Explained

XP Practices - 1 The Planning Game – quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. Small Releases – Put a simple system into production quickly, then release new versions on a very short cycle. Metaphor – Guide all development with a simple shared story of how the whole system works.

XP Practices - 2 Simple Design – The system should be designed as simple as possible at any given moment. Extra complexity is removed as soon as it is discovered. Testing – programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.

XP Practices - 3 Refactoring – Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. (“ Smells ” ) Pair Programming - All production code is written with two programmers at one machine. Collective Ownership - Anyone can change any code anywhere in the system at any time.

XP Practices - 4 Continuous integration – Integrate and build the system many times a day, every time a test is completed. 40-hour Week – Work no more that 40 hours a week as a rule. Never work overtime a second week in a row. On-site Customer – Include a real, live user on the team, available full-time to answer questions. ( CRACK )

XP Practices - 5 Coding Standards - Programmers write all code in accordance with rules emphasizing communication through the code.

XP Practices What you are not allowed to do: PICK AND CHOOSE among the practices. XP IS ALL OF THEM

Refactoring Disciplined technique for restructuring existing body of code, altering its internal structure no change to external behavior use small “behavior preserving transformations” keep system fully working all the time http://www.refactoring.com/ Smells Patterns

Test Driven Development Also known as “Son of XP”  ( Beck, 2000) Two simple Rules: write new business code only when an automated test has failed eliminate any duplication that you find. Consequences (Beck): design organically, running code provides feedback write your own tests (no time to wait for someone else to write them for you) development environment must provide rapid response fast compiler, regression test suite highly cohesive, loosely coupled components

Four Interpretations of TDD 1) Test Driven Development: the idea of writing new code in a test first manner. 2) Test Oriented Development: write unit tests or integration tests for your code either before or immediately after you write the code. 3) Test Driven Design(the eXtreme Programming way): drive full design from little to no design whatsoever. You design as you go. Tests guide your design process 4) Test Driven Development and Design: evolve your design from tests. http://weblogs.asp.net/rosherove/archive/2007/10/08/the-various-meanings-of-tdd.aspx

Test First Design (TFD) add a test, just enough code to fail. run tests often the complete test suite sometimes only a subset ensure that the new test does in fact fail. update your functional code to make it pass run your tests again. if they fail update your functional code and retest. Once the tests pass start over or refactor your design and then start over.

TDD = TFD + Refactoring Requires great discipline: it is easy to “slip” and write functional code without first writing a new test. write your test code before your functional code do so in very small steps one test and a small bit of corresponding functional code no new function without a test that fails because that function isn’t present no code until a test exists for it ensure that the test suite now passes refactor it to ensure high quality. Use pair programming to help stay on track.

Implications for Developers Developers need to learn how to write effective unit tests. Good unit tests: Run fast (have short setups, run times, and break downs). Run in isolation (can be reordered). Use data that makes them easy to read and to understand. Use real data (e.g. copies of production data) when they need to. Represent one step towards your overall goal.

Shortcomings Equating “goodness” with passing a test Test suites are also code more code to maintain could be buggy itself might mean longer and longer runtimes for testing

Scrum ( Schwaber and Beedle ) Scrum is a framework within which the game of product development is played. Your team plays and how good or not-good it is becomes highly visible. Your team gets to continuously improve itself. used under permission of the Scrum Alliance

Companies Using Scrum Bottom Up Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, State Street Bank, Philips, BBC, IBM, SAIC, LMCO, APL, Ariba, Federal Reserve Bank, HP, Medtronics, Motorola, TransUnion Top Down IDX, Siemens Medical, Gestalt, Wildcard Systems, Primavera, Yahoo, Conchango, BMC, Lexis-Nexis, Bentley Systems, Bose, CapitalOne, Federal Reserve Bank, ClearChannel, Xerox, Nokia, Motorola

Scrum Characteristics Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects used under permission of the Scrum Alliance

Scrum Model used under permission of the Scrum Alliance

Sprints Scrum projects make progress in a series of “sprints” Analogous to XP iterations Target duration is one month +/- a week or two But, a constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint used under permission of the Scrum Alliance No changes during the sprint

Product Backlog A list of all desired work on the project combination of story-based work task-based work List is prioritized by the Product Owner Typically a Product Manager, Marketing, Internal Customer, etc. used under permission of the Scrum Alliance

Sprint Planning Meeting Sprint Planning Meeting Sprint Backlog Product Owner Scrum Team Management Customers Sprint Goal used under permission of the Scrum Alliance Product Backlog Team Capabilities Business Conditions Technology Current Product

Sprint Backlog during the Sprint Changes Team adds new tasks whenever they need to in order to meet the Sprint Goal Team can remove unnecessary tasks But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information used under permission of the Scrum Alliance

Sprint Burndown Chart used under permission of the Scrum Alliance

Daily Scrum meetings Parameters Daily 15-minutes Stand-up Not for problem solving Three questions: What did you do yesterday What will you do today? What obstacles are in your way? Chickens and pigs are invited Help avoid other unnecessary meetings Only pigs can talk used under permission of the Scrum Alliance

Sprint Review Meeting Team presents what it accomplished during the sprint Typically takes the form of a demo of new features or underlying architecture Informal 2-hour prep time rule Participants Customers Management Product Owner Other engineers used under permission of the Scrum Alliance

The Origin of Religious Wars One faith, one law, one king French royalists, circa 1562 even some people who call God God worship God in a way that's odd We have to kill them, it's a shame Austin Lounge Lizards, "One True God", The Drugs I Need

Agility vs. Discipline If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit

Requirements for Success - 1 Waterfall-based projects need: management support organizational infrastructure engineers that understand, value and follow processes process assets customer representatives that are collaborative, representative, authorized, committed and knowledgeable

Requirements for Success - 2 Agile projects need: management support organizational infrastructure engineers that understand, value and follow processes leads that can break the rules and make new ones as needed full-time customer representatives that are collaborative, representative, authorized, committed and knowledgeable

Why Go Agile Right reasons we have CRACK customers our projects are small to medium criticality is low to medium we have experienced people that have succeeded with it Wrong reasons we don’t have the time for process we don’t have the time to document the system our engineers are young and inexperienced

When Not to Go Agile Product is mission-critical requirements of traceability very strict No CRACK users customer is reluctant to commit a valuable player to the team Architectural concerns are high non functional aspects are dominant YAGNI does not apply Project demands large team

So, Maybe… There is no silver bullet There is no one-size-fits-all It is better to build your method up than to pare it down Potential silver bullets are elsewhere people values communication expectation management

Final Conclusion Follow the six key principles for business-driven development: A dapt the process B alance stakeholder priorities C ollaborate across teams D emonstrate value iteratively E levate the level of abstraction F ocus continuously on quality In short -> [ABCDEF]  Steal with pride but do not lie to yourself: A Monkey In A Silk Suit Is Still A Monkey !

Any Questions? thank you for your time [email_address] www.liveware.com

Acknowledgements We have used terms like: Scrum Alliance (SM) Agile Alliance CMMI ® Capability Maturity Model, CMMI, and CMM are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University Some slides are used under copyright agreement with the Scrum Alliance. Monty Python is credited for intellectual inspiration and art work in most of the Holy Wars material

Back to Basics Let there be Deming… reduce waste, rework, staff attrition and litigation while increasing customer loyalty

Deming’s 14 Points for Management 1."Create constancy of purpose towards improvement“ 3."Cease dependence on inspection" 5."Improve constantly and forever" 7."Institute leadership" 9."Break down barriers between departments" 11."Eliminate management by objectives" 13."Institute education and self-improvement “ 2."Adopt the new philosophy" 4."Move towards a single supplier for any one item" 6."Institute training on the job" 8."Drive out fear" 10."Eliminate slogans" 12."Remove barriers to pride of workmanship" 14."The transformation is everyone's job"

Agility vs. Discipline If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit Boehm and Turner Balancing Agility and Discipline

Requirements for Success - 1 Waterfall-based projects need: management support organizational infrastructure engineers that understand, value and follow processes process assets customer representatives that are collaborative, representative, authorized, committed and knowledgeable (CRACK)

The Agile Manifesto - 1 Principles behind the Agile Manifesto We follow these principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. short feedback loops 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. include the customer 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. feedback based on real product

The Agile Manifesto - 2 4. Business people and developers must work together daily throughout the project. feedback should happen daily 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. trust your developers 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. continuous knowledge improvement 7. Working software is the primary measure of progress. continuous visibility

The Agile Manifesto - 3 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. no iterative death marches 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Scrum One of the “agile processes” Self-organizing teams Product progresses in a series of month-long “sprints” Requirements are captured as items in a list of “product backlog” No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects used under permission of the Scrum Alliance

Project Noise Level Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. used under permission of the Scrum Alliance Simple Complicated Anarchy Complex Close to Certainty Far from Certainty Technology Close to Agreement Far from Agreement Requirements

The Scrum Master Represents management to the project Typically filled by a Project Manager or Team Leader Responsible for enacting Scrum values and practices Main job is to remove impediments used under permission of the Scrum Alliance

The Scrum Team Typically 5-10 people Cross-functional QA, Programmers, UI Designers, etc. Members should be full-time May be exceptions (e.g., System Admin, etc.) Teams are self-organizing What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility Membership can change only between sprints used under permission of the Scrum Alliance

Sprints Scrum projects make progress in a series of “sprints” Analogous to XP iterations Target duration is one month +/- a week or two But, a constant duration leads to a better rhythm Product is designed, coded, and tested during the sprint used under permission of the Scrum Alliance

Sequential vs. Overlapping Development Source: “The New New Product Development Game”, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review , January 1986. used under permission of the Scrum Alliance

No changes during the sprint Plan sprint durations around how long you can commit to keeping change out of the sprint used under permission of the Scrum Alliance Sprint Inputs Tested Code Change

Product Backlog A list of all desired work on the project Usually a combination of story-based work (“let user search and replace”) task-based work (“improve exception handling”) List is prioritized by the Product Owner Typically a Product Manager, Marketing, Internal Customer, etc. used under permission of the Scrum Alliance

Sample Product Backlog used under permission of the Scrum Alliance

The Sprint Goal A short “theme” for the sprint: Database Application “ Make the application run on SQL Server in addition to Oracle.” Life Sciences “ Support features necessary for population genetics studies.” Financial Services “ Support more technical indicators than company ABC with real-time, streaming data.” used under permission of the Scrum Alliance

From Sprint Goal to Sprint Backlog Scrum team takes the Sprint Goal and decides what tasks are necessary Team self-organizes around how they’ll meet the Sprint Goal Manager doesn’t assign tasks to individuals Managers don’t make decisions for the team Sprint Backlog is created used under permission of the Scrum Alliance

Sample Sprint Backlog used under permission of the Scrum Alliance

Questions about Scrum meetings? Why daily? “How does a project get to be a year late?” “One day at a time.” Fred Brooks, The Mythical Man-Month. Can Scrum meetings be replaced by emailed status reports? No Entire team sees the whole picture every day Create peer pressure to do what you say you’ll do used under permission of the Scrum Alliance

Constraints A complete list of constraints put on the team during a Sprint: </end of list> used under permission of the Scrum Alliance

Stabilization Sprints During “regular” sprints target friendly first use Beta customers and similar can use immediately after sprint During “stabilization sprints” Team prepares a product for release Useful during active beta periods when transitioning a team to Scrum if quality isn’t quite where it should be on an initial release Not a part of standard Scrum, just something I’ve found useful Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 1 Sprint 2 Sprint 3 Stabilization Sprint used under permission of the Scrum Alliance

Where to go next? Scrum www.mountaingoatsoftware.com/scrum www.controlchaos.com [email_address] Agile Software Development with Scrum Ken Schwaber and Mike Beedle Agile Project Management with Scrum Ken Schwaber and Mike Beedle General information www.agilealliance.com used under permission of the Scrum Alliance

Xbreed - 1 Goal of XBreed is to support multiple projects, reusing components such as architectural services workflows units of work services transactions business objects Xbreed uses most Scrum practices, plus using chief programmers as team leads uses hierarchies of teams uses Scrum practices at each level of hierarchy

XBreed - 2 Leverage XP practices with some differences planning game replaced by Scrum some YAGNI, only in known domain "hot spots“ Classes, Responsibility, and Collaboration (CRC) stories used for representing requirements eliciting requirements discussing design Supplement with use case for complex functionality

Components of XBreed Uses design patterns in defining products Uses "Shared Services" teams to handle several increments concurrently Includes a rchitect roles on the teams Shares knowledge through weekly brown bag lunches, mixing presentations and workshops on topics like: patterns, refactoring, new technologies, architectural vision exercises, best practices, etc. Scrum holds the whole thing together.

Feature Driven Development (more shape than content) An object model + informal features list + notes on alternatives Categorized list of features Development plan A design package (sequences) (more content than shape) Completed client-valued function Develop an Overall Model Build a Feature List Plan by Feature Design by Feature Build by Feature

FDD vs XP Similarities E nable teams to deliver results quicker without compromising quality Hi ghly iterative results-oriented processes P eople focused , not document focused D ismantle traditional separation of domain and business experts/analysts from designers and implementers analysts are dragged out of their abstractions and put in the same room as developers and users enabling and encouraging analysis, design, code, test and deployment to be done concurrently

FDD vs XP Differences - 1 XP: Team sizes teams of two to ten programmers Metaphor and Model Business writing stories on index cards analogous to driving a car - continual little course adjustments FDD : Team sizes team of 16-20 developers , designed to scale to much larger team sizes Metaphor and Model adds development of an overall domain object model analogous to using the domain object model as the map to guide the journey

FDD vs XP Differences - 2 XP : Collective Ownership or Class Ownership collective ownership of code Inspections and Pair Programming pair programming provide s continuous design and code inspection. Testing XP : unit and functional tests FDD : unit testing part of Build By Feature Reporting XP : tracking by project managers FDD : Tracking By Feature low-overhead, highly accurate progress measuring F DD: Collective Ownership or Class Ownership individual code ownership Inspections and Pair Programming formal inspections by feature teams

FDD vs XP Differences - 3 XP : Testing unit and functional tests Reporting tracking by project managers F DD: Testing unit testing part of Build By Feature Reporting Tracking By Feature low-overhead, highly accurate progress measuring

Dynamic System Development DSDM is a variant of RAD developed in the UK by a consortium very successful since 1995 has not crossed into mainstream yet focuses on short cycles and changing requirements Claims of DSDM users have ownership risk of building the wrong system is minimized users are trained smooth implementation through cooperation Applies only when all users are identified and few

DSDM Lifecycle Tailorable generic process Iterates as needed through Functional model and Design and build Implementation can end with a finished product more feasibility studies more functionality changes to the design prototypes

DSDM Principles Active user involvement Empowered teams Frequent product delivery Fitness for business purposes Iterative and incremental development Reversible changes Baselined high level requirements Testing integrated throughout the lifecycle Stakeholder collaboration and cooperation

Waterfallacies V1 1

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Waterfallacies V1 1 (20)

More from Jorge Boria (20)

Recently uploaded (20)

Waterfallacies V1 1