• Save
Waterfallacies V1 1
Upcoming SlideShare
Loading in...5
×
 

Waterfallacies V1 1

on

  • 1,639 views

This presentation shows the development of methods that have made agile possible and discusses religious positions of CMMI-ers and Agilists

This presentation shows the development of methods that have made agile possible and discusses religious positions of CMMI-ers and Agilists

Statistics

Views

Total Views
1,639
Views on SlideShare
1,625
Embed Views
14

Actions

Likes
0
Downloads
0
Comments
0

4 Embeds 14

http://www.linkedin.com 8
http://www.slideshare.net 3
https://www.linkedin.com 2
https://www.mturk.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Waterfallacies V1 1 Waterfallacies V1 1 Presentation Transcript

  • 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
  • Agenda
      • Ancestors
        • Royce’s waterfall
        • Spiral
        • JAD
        • RUP
        • RAD and RAP
      • Examples
        • eXtreme Programming
        • TDD
        • Scrum (and CMMI)
  • 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
  • Backup Slides
  • 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)
  • 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
  • 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
  • Scrum Model used under permission of the Scrum Alliance
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 &quot;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 &quot;Shared Services&quot; 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