Evolution of Software  Development Lifecycles:  Waterfallacies and Agile Methods Jorge Boria
A Claim <ul><li>I am concerned, not with an unattainable objectivity, but with an attainable honesty. </li></ul><ul><li>Jo...
A Second Claim  <ul><li>I am going to describe my personal views about managing large software developments.  </li></ul><u...
Our Purpose Tonight <ul><li>Answer the questions: </li></ul><ul><li>Where does Agile come from?  </li></ul><ul><li>What Li...
Agenda <ul><ul><li>Ancestors </li></ul></ul><ul><ul><ul><li>Royce’s waterfall </li></ul></ul></ul><ul><ul><ul><li>Spiral <...
Remember the 60’s? <ul><li>“ methodology”    = methods + processes + semantic modeling languages </li></ul><ul><li>Centra...
The Meaning of Life (Cycles) <ul><li>Arriving at an operational state, on-time, and within costs, using what others have d...
The Underlying Premise <ul><li>The quality of a system is preeminently influenced by the quality of the processes used to ...
The Infamous Waterfall Royce, ibid
And Royce’s Comment On It… <ul><li>I believe in this concept, but the implementation described above is  </li></ul><ul><ul...
Royce’s Real Waterfall Royce, ibidem
Initial Solutions – Spiral Model (Boehm) <ul><li>Scaled down prototypes built to preliminary design </li></ul><ul><li>Risk...
Initial Solutions - JAD ( Silver and Wood) <ul><li>One of the first successful application of time-boxing: </li></ul><ul><...
The Problem Changes <ul><li>Accommodating faster and faster business cycles </li></ul>
A Transition Moment <ul><li>The Rational Unified Process ( Jacobson, Booch, Rumbaugh et al) </li></ul><ul><ul><ul><li>Deve...
The RUP Lifecycle <ul><li>Implementation of the spiral model.  </li></ul><ul><li>First break of waterfall sequence </li></...
Initial Solutions - RAD ( Martin) <ul><ul><li>Prototyping using tools and environments (RAD Tools) </li></ul></ul><ul><ul>...
The Problem Accelerates <ul><li>Accommodating faster and faster business cycles: Internet Time!!!! </li></ul>
Agile Life Cycle Models - 1 <ul><ul><li>Shared characteristics  </li></ul></ul><ul><ul><ul><li>software development proces...
Agile Life Cycle Models - 2 <ul><ul><li>Shared characteristics (continued) </li></ul></ul><ul><ul><ul><li>small teams  </l...
Agile Life Cycle Models - 3 <ul><ul><li>Agile Alliance (source)  </li></ul></ul><ul><ul><ul><ul><li>Kent Beck (XP, TDD) </...
Agenda <ul><ul><li>Ancestors </li></ul></ul><ul><ul><ul><li>Royce’s waterfall </li></ul></ul></ul><ul><ul><ul><li>Spiral <...
The X in XP <ul><li>If code reviews are good…  </li></ul><ul><li>If testing is good… </li></ul><ul><li>If design is good… ...
eXtreme Programming - 1 <ul><ul><li>Exploration phase </li></ul></ul><ul><ul><ul><li>developers establish tools and techno...
eXtreme Programming - 2 <ul><li>Iterations to First Release </li></ul><ul><ul><li>1-4 week cycles of building and verifyin...
eXtreme Programming - 3 <ul><li>Maintenance </li></ul><ul><ul><li>normal state of an XP project </li></ul></ul><ul><ul><li...
eXtreme Programming - 4 Productionizing Iterations (each 1-4 weeks) Planning Exploration Verify Stories (Requirements Scen...
XP Practices - 1 <ul><ul><li>The Planning Game  –  </li></ul></ul><ul><ul><ul><li>quickly determine the scope of the next ...
XP Practices - 2 <ul><ul><li>Simple Design  –  </li></ul></ul><ul><ul><ul><li>The system should be designed as simple as p...
XP Practices - 3 <ul><ul><li>Refactoring  –  </li></ul></ul><ul><ul><ul><li>Programmers restructure the system without cha...
XP Practices - 4 <ul><ul><li>Continuous integration  –  </li></ul></ul><ul><ul><ul><li>Integrate and build the system many...
XP Practices - 5 <ul><ul><li>Coding Standards  - Programmers write all code in accordance with rules emphasizing communica...
XP Practices <ul><li>What you are  not  allowed to do: </li></ul><ul><li>PICK AND CHOOSE </li></ul><ul><li>among the pract...
Refactoring <ul><li>Disciplined technique for restructuring existing body of code,  </li></ul><ul><ul><li>altering its int...
Test Driven Development <ul><li>Also known as “Son of XP”    ( Beck, 2000) </li></ul><ul><li>Two simple Rules: </li></ul>...
Four Interpretations of TDD <ul><ul><li>1) Test Driven Development:  </li></ul></ul><ul><ul><ul><li>the idea of writing ne...
Test First Design (TFD)  <ul><li>add a test,  </li></ul><ul><ul><li>just enough code to fail.   </li></ul></ul><ul><li>run...
TDD = TFD + Refactoring <ul><li>Requires great discipline: it is easy to “slip” and write functional code without first wr...
Implications for Developers  <ul><li>Developers need to learn how to write effective unit tests.  </li></ul><ul><li>Good u...
Shortcomings <ul><li>Equating “goodness” with passing a test </li></ul><ul><li>Test suites are also code </li></ul><ul><ul...
Scrum ( Schwaber and Beedle ) <ul><ul><li>Scrum is a framework within which the game of product development is played. </l...
Companies Using Scrum <ul><li>Bottom Up </li></ul><ul><ul><li>Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, Sta...
Scrum Characteristics <ul><ul><li>Self-organizing teams </li></ul></ul><ul><ul><li>Product progresses in a series of month...
Scrum Model used under permission of the Scrum Alliance
Sprints <ul><li>Scrum projects make progress in a series of “sprints” </li></ul><ul><ul><li>Analogous to XP iterations </l...
Product Backlog <ul><li>A list of all desired work on the project </li></ul><ul><ul><li>combination of  </li></ul></ul><ul...
Sprint Planning Meeting Sprint Planning Meeting Sprint Backlog Product Owner Scrum Team Management Customers Sprint Goal u...
Sprint Backlog during the Sprint <ul><li>Changes </li></ul><ul><ul><li>Team adds new tasks whenever they need to in order ...
Sprint Burndown Chart used under permission of the Scrum Alliance
Daily Scrum meetings <ul><ul><li>Parameters </li></ul></ul><ul><ul><ul><li>Daily </li></ul></ul></ul><ul><ul><ul><li>15-mi...
Sprint Review Meeting <ul><li>Team presents what it accomplished during the sprint </li></ul><ul><li>Typically takes the f...
The Origin of Religious Wars <ul><li>One faith, one law, one king   </li></ul><ul><li>French royalists, circa 1562 </li></...
Agility vs. Discipline <ul><li>If one has strong discipline without agility, the result is bureaucracy and stagnation. </l...
Requirements for Success - 1 <ul><li>Waterfall-based projects need: </li></ul><ul><ul><li>management support </li></ul></u...
Requirements for Success - 2 <ul><li>Agile projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul>...
Why Go Agile <ul><li>Right reasons </li></ul><ul><ul><li>we have CRACK customers </li></ul></ul><ul><ul><li>our projects a...
When Not to Go Agile <ul><li>Product is mission-critical </li></ul><ul><ul><li>requirements of traceability very strict </...
So, Maybe… <ul><li>There is no silver bullet </li></ul><ul><li>There is no one-size-fits-all </li></ul><ul><li>It is bette...
Final Conclusion <ul><ul><li>Follow the six key principles for business-driven development: </li></ul></ul><ul><ul><ul><li...
Any Questions? thank you for your time [email_address] www.liveware.com
Acknowledgements <ul><li>We have used terms like: </li></ul><ul><ul><li>Scrum Alliance  (SM)  </li></ul></ul><ul><ul><li>A...
Backup Slides
Back to Basics <ul><li>Let there be Deming… </li></ul><ul><ul><li>reduce waste,  </li></ul></ul><ul><ul><li>rework,  </li>...
Deming’s 14 Points for Management <ul><li>1.&quot;Create constancy of purpose towards improvement“ </li></ul><ul><li>3.&qu...
Agility vs. Discipline <ul><li>If one has strong discipline without agility, the result is bureaucracy and stagnation. </l...
Requirements for Success - 1 <ul><li>Waterfall-based projects need: </li></ul><ul><ul><li>management support </li></ul></u...
Requirements for Success - 2 <ul><li>Agile projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul>...
Why Go Agile <ul><li>Right reasons </li></ul><ul><ul><li>we have CRACK customers </li></ul></ul><ul><ul><li>our projects a...
When Not to Go Agile <ul><li>Product is mission-critical </li></ul><ul><ul><li>requirements of traceability very strict </...
The Agile Manifesto - 1 <ul><li>Principles behind the Agile Manifesto </li></ul><ul><li>We follow these principles:  </li>...
The Agile Manifesto - 2 <ul><li>4. Business people and developers must work together daily throughout the project.  </li><...
The Agile Manifesto - 3 <ul><li>8. Agile processes promote sustainable development. The sponsors, developers, and users sh...
Scrum <ul><ul><li>One of the “agile processes” </li></ul></ul><ul><ul><li>Self-organizing teams </li></ul></ul><ul><ul><li...
Project Noise Level Source:  Strategic Management and Organizational Dynamics  by Ralph Stacey   in  Agile Software Develo...
Scrum Model used under permission of the Scrum Alliance
The Scrum Master <ul><ul><li>Represents management to the project </li></ul></ul><ul><ul><li>Typically filled by a Project...
The Scrum Team <ul><ul><li>Typically 5-10 people </li></ul></ul><ul><ul><li>Cross-functional </li></ul></ul><ul><ul><ul><l...
Sprints <ul><li>Scrum projects make progress in a series of “sprints” </li></ul><ul><ul><li>Analogous to XP iterations </l...
Sequential vs. Overlapping Development Source: “The New New Product Development Game”, Hirotaka Takeuchi and Ikujiro Nonak...
No changes during the sprint <ul><li>Plan sprint durations around how long you can commit to keeping change out of the spr...
Product Backlog <ul><li>A list of all desired work on the project </li></ul><ul><ul><li>Usually a combination of  </li></u...
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 u...
The Sprint Goal <ul><li>A short “theme” for the sprint: </li></ul>Database Application “ Make the application run on SQL S...
From Sprint Goal to Sprint Backlog <ul><li>Scrum team takes the Sprint Goal and decides what tasks are necessary </li></ul...
Sample Sprint Backlog used under permission of the Scrum Alliance
Sprint Backlog during the Sprint <ul><li>Changes </li></ul><ul><ul><li>Team adds new tasks whenever they need to in order ...
Sprint Burndown Chart used under permission of the Scrum Alliance
Daily Scrum meetings <ul><ul><li>Parameters </li></ul></ul><ul><ul><ul><li>Daily </li></ul></ul></ul><ul><ul><ul><li>15-mi...
Questions about Scrum meetings? <ul><li>Why daily? </li></ul><ul><ul><li>“How does a project get to be a year late?” </li>...
Constraints <ul><li>A complete list of constraints put on the team during a Sprint: </li></ul><ul><li></end of list> </li>...
Sprint Review Meeting <ul><li>Team presents what it accomplished during the sprint </li></ul><ul><li>Typically takes the f...
Stabilization Sprints <ul><li>During “regular” sprints target  friendly first use </li></ul><ul><ul><li>Beta customers and...
Where to go next? <ul><li>Scrum </li></ul><ul><ul><li>www.mountaingoatsoftware.com/scrum </li></ul></ul><ul><ul><li>www.co...
Xbreed  - 1 <ul><li>Goal of XBreed is to support multiple projects, reusing components such as </li></ul><ul><ul><li>archi...
XBreed  - 2 <ul><li>Leverage XP practices with some differences </li></ul><ul><ul><li>planning game replaced by Scrum </li...
Components of XBreed <ul><li>Uses design patterns in defining products </li></ul><ul><li>Uses &quot;Shared Services&quot; ...
Feature Driven Development  (more shape than content) An object model + informal features list + notes on alternatives Cat...
FDD vs XP Similarities <ul><ul><li>E nable teams to deliver results  </li></ul></ul><ul><ul><ul><li>quicker  </li></ul></u...
FDD vs XP Differences - 1 <ul><li>XP: </li></ul><ul><ul><li>Team sizes </li></ul></ul><ul><ul><ul><li>teams of two to ten ...
FDD vs XP Differences - 2 <ul><li>XP :   </li></ul><ul><ul><li>Collective Ownership or Class Ownership </li></ul></ul><ul>...
FDD vs XP Differences - 3 <ul><li>XP :   </li></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><ul><li>unit and functional ...
Dynamic System Development <ul><li>DSDM is a variant of RAD </li></ul><ul><ul><li>developed in the UK by a consortium </li...
DSDM Lifecycle <ul><li>Tailorable generic process </li></ul><ul><li>Iterates as needed through </li></ul><ul><ul><li>Funct...
DSDM Principles <ul><li>Active user involvement </li></ul><ul><li>Empowered teams </li></ul><ul><li>Frequent product deliv...
Upcoming SlideShare
Loading in...5
×

Waterfallacies V1 1

1,339

Published on

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

Published in: Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,339
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Waterfallacies V1 1"

  1. 1. Evolution of Software Development Lifecycles: Waterfallacies and Agile Methods Jorge Boria
  2. 2. A Claim <ul><li>I am concerned, not with an unattainable objectivity, but with an attainable honesty. </li></ul><ul><li>John Dominic Crossan </li></ul><ul><li>The Historical Jesus, 1992 </li></ul>
  3. 3. A Second Claim <ul><li>I am going to describe my personal views about managing large software developments. </li></ul><ul><li>Dr. Winston W. Royce </li></ul><ul><li>Managing the Development of Large Software Systems </li></ul><ul><li>August 1970 </li></ul>
  4. 4. Our Purpose Tonight <ul><li>Answer the questions: </li></ul><ul><li>Where does Agile come from? </li></ul><ul><li>What Lifecycle will work for me? </li></ul>Do we give up on lifecycles before we should? Are we stuck on searching for a silver bullet?
  5. 5. Agenda <ul><ul><li>Ancestors </li></ul></ul><ul><ul><ul><li>Royce’s waterfall </li></ul></ul></ul><ul><ul><ul><li>Spiral </li></ul></ul></ul><ul><ul><ul><li>JAD </li></ul></ul></ul><ul><ul><ul><li>RUP </li></ul></ul></ul><ul><ul><ul><li>RAD and RAP </li></ul></ul></ul><ul><ul><li>Examples </li></ul></ul><ul><ul><ul><li>eXtreme Programming </li></ul></ul></ul><ul><ul><ul><li>TDD </li></ul></ul></ul><ul><ul><ul><li>Scrum (and CMMI) </li></ul></ul></ul>
  6. 6. Remember the 60’s? <ul><li>“ methodology”  = methods + processes + semantic modeling languages </li></ul><ul><li>Centrally, Hierarchical decomposition </li></ul><ul><ul><li>HIPO, Structured Design, Jackson, Nassi-Shneiderman </li></ul></ul>
  7. 7. The Meaning of Life (Cycles) <ul><li>Arriving at an operational state, on-time, and within costs, using what others have done before </li></ul>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
  8. 8. The Underlying Premise <ul><li>The quality of a system is preeminently influenced by the quality of the processes used to develop, acquire, and maintain it. </li></ul>you should already have the best available you should already have the best available PROCESS PEOPLE TECHNOLOGY
  9. 9. The Infamous Waterfall Royce, ibid
  10. 10. And Royce’s Comment On It… <ul><li>I believe in this concept, but the implementation described above is </li></ul><ul><ul><li>risky and invites failure . […] </li></ul></ul><ul><ul><li>in effect the development process has returned to the origin </li></ul></ul><ul><ul><li>one can expect up to a 100-percent overrun in schedule and/or costs. </li></ul></ul>Royce, ibid
  11. 11. Royce’s Real Waterfall Royce, ibidem
  12. 12. Initial Solutions – Spiral Model (Boehm) <ul><li>Scaled down prototypes built to preliminary design </li></ul><ul><li>Risk guides iterations </li></ul><ul><li>Customer can abort </li></ul><ul><li>Partial waterfall in every step </li></ul><ul><li>Complete waterfall at the end, if needed </li></ul>
  13. 13. Initial Solutions - JAD ( Silver and Wood) <ul><li>One of the first successful application of time-boxing: </li></ul><ul><ul><li>JAD’s were restricted to a week, development to a few months </li></ul></ul><ul><li>Based on some “modern” premises: </li></ul><ul><ul><li>those who do the job have the understanding </li></ul></ul><ul><ul><li>software products affect the business as a whole </li></ul></ul>http://www.utexas.edu/ecs/trecs/hris/pub/jad.php
  14. 14. The Problem Changes <ul><li>Accommodating faster and faster business cycles </li></ul>
  15. 15. A Transition Moment <ul><li>The Rational Unified Process ( Jacobson, Booch, Rumbaugh et al) </li></ul><ul><ul><ul><li>Develop software iteratively (sashimi*) </li></ul></ul></ul><ul><ul><ul><li>Manage requirements </li></ul></ul></ul><ul><ul><ul><li>Use component-based architectures </li></ul></ul></ul><ul><ul><ul><li>Visually model software </li></ul></ul></ul><ul><ul><ul><li>Verify software quality </li></ul></ul></ul><ul><ul><ul><li>Control changes to software </li></ul></ul></ul>*Takeuchi and Nonaka
  16. 16. The RUP Lifecycle <ul><li>Implementation of the spiral model. </li></ul><ul><li>First break of waterfall sequence </li></ul><ul><li>Organizes tasks into phases and iterations. </li></ul><ul><li>Four phases: </li></ul><ul><ul><li>Inception </li></ul></ul><ul><ul><li>Elaboration </li></ul></ul><ul><ul><li>Construction </li></ul></ul><ul><ul><li>Transition </li></ul></ul>
  17. 17. Initial Solutions - RAD ( Martin) <ul><ul><li>Prototyping using tools and environments (RAD Tools) </li></ul></ul><ul><ul><li>Increasingly Functional Iterative Development </li></ul></ul><ul><ul><li>Time Boxing </li></ul></ul><ul><ul><li>Small Teams </li></ul></ul><ul><ul><li>Active and Involved Management Approach </li></ul></ul>
  18. 18. The Problem Accelerates <ul><li>Accommodating faster and faster business cycles: Internet Time!!!! </li></ul>
  19. 19. Agile Life Cycle Models - 1 <ul><ul><li>Shared characteristics </li></ul></ul><ul><ul><ul><li>software development process is inherently chaotic </li></ul></ul></ul><ul><ul><ul><li>engineers can thrive in the chaos </li></ul></ul></ul><ul><ul><ul><li>embrace change, not manage change </li></ul></ul></ul><ul><ul><ul><li>short iterations between product deliveries </li></ul></ul></ul><ul><ul><ul><ul><li>less than two months </li></ul></ul></ul></ul><ul><ul><ul><ul><li>goal of four weeks </li></ul></ul></ul></ul><ul><ul><ul><li>YAGNI: don’t code it until the customer requests it </li></ul></ul></ul>http://www.agilemanifesto.org/
  20. 20. Agile Life Cycle Models - 2 <ul><ul><li>Shared characteristics (continued) </li></ul></ul><ul><ul><ul><li>small teams </li></ul></ul></ul><ul><ul><ul><li>strong supporting environment </li></ul></ul></ul><ul><ul><ul><li>product manager role setting firm priorities for each iteration </li></ul></ul></ul><ul><ul><ul><li>developers define tests prior to coding </li></ul></ul></ul><ul><ul><ul><li>small effort on planning, large effort on control </li></ul></ul></ul><ul><ul><ul><li>daily builds of the software </li></ul></ul></ul>
  21. 21. Agile Life Cycle Models - 3 <ul><ul><li>Agile Alliance (source) </li></ul></ul><ul><ul><ul><ul><li>Kent Beck (XP, TDD) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Mike Beedle, Scrum Alliance (Scrum, Xbreed) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Alistair Cockburn (Crystal) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Ken Schwaber (Scrum) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Peter Coad (FDD) … </li></ul></ul></ul></ul><ul><ul><li>How the models differ </li></ul></ul><ul><ul><ul><li>degree of up-front design of the product, before coding </li></ul></ul></ul><ul><ul><ul><li>size of project for which they are useful </li></ul></ul></ul><ul><ul><ul><li>team size that works best </li></ul></ul></ul>
  22. 22. Agenda <ul><ul><li>Ancestors </li></ul></ul><ul><ul><ul><li>Royce’s waterfall </li></ul></ul></ul><ul><ul><ul><li>Spiral </li></ul></ul></ul><ul><ul><ul><li>JAD </li></ul></ul></ul><ul><ul><ul><li>RUP </li></ul></ul></ul><ul><ul><ul><li>RAD and RAP </li></ul></ul></ul><ul><ul><li>Examples </li></ul></ul><ul><ul><ul><li>eXtreme Programming </li></ul></ul></ul><ul><ul><ul><li>TDD </li></ul></ul></ul><ul><ul><ul><li>Scrum (and CMMI) </li></ul></ul></ul>
  23. 23. The X in XP <ul><li>If code reviews are good… </li></ul><ul><li>If testing is good… </li></ul><ul><li>If design is good… </li></ul><ul><li>If architecture is good… </li></ul><ul><li>If integration testing is good… </li></ul><ul><li>If short iterations are good… </li></ul>...do it all the time!
  24. 24. eXtreme Programming - 1 <ul><ul><li>Exploration phase </li></ul></ul><ul><ul><ul><li>developers establish tools and technologies </li></ul></ul></ul><ul><ul><ul><li>customers develop stories (scenarios, requirements) </li></ul></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><ul><li>developers estimate effort, balance load </li></ul></ul></ul><ul><ul><ul><li>commitments established with customer </li></ul></ul></ul><ul><ul><ul><li>during development: </li></ul></ul></ul><ul><ul><ul><ul><li>record progress </li></ul></ul></ul></ul><ul><ul><ul><ul><li>rearrange work as needed </li></ul></ul></ul></ul>Source: Beck, eXtreme Programming Explained
  25. 25. eXtreme Programming - 2 <ul><li>Iterations to First Release </li></ul><ul><ul><li>1-4 week cycles of building and verifying </li></ul></ul><ul><ul><li>first iteration establishes architecture </li></ul></ul><ul><li>Productionizing </li></ul><ul><ul><li>shorter iterations, certifying the software </li></ul></ul><ul><ul><li>may tune performance </li></ul></ul>Source: Beck, eXtreme Programming Explained
  26. 26. eXtreme Programming - 3 <ul><li>Maintenance </li></ul><ul><ul><li>normal state of an XP project </li></ul></ul><ul><ul><li>simultaneous addition of functionality and supporting system </li></ul></ul><ul><ul><li>each release has exploration, planning, iterations to release </li></ul></ul><ul><li>Death </li></ul><ul><ul><li>when no further features are needed </li></ul></ul><ul><ul><li>if system doesn’t deliver as needed </li></ul></ul>Source: Beck, eXtreme Programming Explained
  27. 27. 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
  28. 28. XP Practices - 1 <ul><ul><li>The Planning Game – </li></ul></ul><ul><ul><ul><li>quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan. </li></ul></ul></ul><ul><ul><li>Small Releases – </li></ul></ul><ul><ul><ul><li>Put a simple system into production quickly, then release new versions on a very short cycle. </li></ul></ul></ul><ul><ul><li>Metaphor – </li></ul></ul><ul><ul><ul><li>Guide all development with a simple shared story of how the whole system works. </li></ul></ul></ul>
  29. 29. XP Practices - 2 <ul><ul><li>Simple Design – </li></ul></ul><ul><ul><ul><li>The system should be designed as simple as possible at any given moment. Extra complexity is removed as soon as it is discovered. </li></ul></ul></ul><ul><ul><li>Testing – </li></ul></ul><ul><ul><ul><li>programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished. </li></ul></ul></ul>
  30. 30. XP Practices - 3 <ul><ul><li>Refactoring – </li></ul></ul><ul><ul><ul><li>Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility. (“ Smells ” ) </li></ul></ul></ul><ul><ul><li>Pair Programming - All production code is written with two programmers at one machine. </li></ul></ul><ul><ul><li>Collective Ownership - Anyone can change any code anywhere in the system at any time. </li></ul></ul>
  31. 31. XP Practices - 4 <ul><ul><li>Continuous integration – </li></ul></ul><ul><ul><ul><li>Integrate and build the system many times a day, every time a test is completed. </li></ul></ul></ul><ul><ul><li>40-hour Week – </li></ul></ul><ul><ul><ul><li>Work no more that 40 hours a week as a rule. Never work overtime a second week in a row. </li></ul></ul></ul><ul><ul><li>On-site Customer – </li></ul></ul><ul><ul><ul><li>Include a real, live user on the team, available full-time to answer questions. ( CRACK ) </li></ul></ul></ul>
  32. 32. XP Practices - 5 <ul><ul><li>Coding Standards - Programmers write all code in accordance with rules emphasizing communication through the code. </li></ul></ul>
  33. 33. XP Practices <ul><li>What you are not allowed to do: </li></ul><ul><li>PICK AND CHOOSE </li></ul><ul><li>among the practices. </li></ul>XP IS ALL OF THEM
  34. 34. Refactoring <ul><li>Disciplined technique for restructuring existing body of code, </li></ul><ul><ul><li>altering its internal structure </li></ul></ul><ul><ul><li>no change to external behavior </li></ul></ul><ul><ul><li>use small “behavior preserving transformations” </li></ul></ul><ul><ul><li>keep system fully working all the time </li></ul></ul>http://www.refactoring.com/ Smells Patterns
  35. 35. Test Driven Development <ul><li>Also known as “Son of XP”  ( Beck, 2000) </li></ul><ul><li>Two simple Rules: </li></ul><ul><ul><li>write new business code only when an automated test has failed </li></ul></ul><ul><ul><li>eliminate any duplication that you find. </li></ul></ul><ul><li>Consequences (Beck): </li></ul><ul><ul><li>design organically, running code provides feedback </li></ul></ul><ul><ul><li>write your own tests (no time to wait for someone else to write them for you) </li></ul></ul><ul><ul><li>development environment must provide rapid response </li></ul></ul><ul><ul><ul><li>fast compiler, regression test suite </li></ul></ul></ul><ul><ul><li>highly cohesive, loosely coupled components </li></ul></ul>
  36. 36. Four Interpretations of TDD <ul><ul><li>1) Test Driven Development: </li></ul></ul><ul><ul><ul><li>the idea of writing new code in a test first manner. </li></ul></ul></ul><ul><ul><li>2) Test Oriented Development: </li></ul></ul><ul><ul><ul><li>write unit tests or integration tests for your code either before or immediately after you write the code. </li></ul></ul></ul><ul><ul><li>3) Test Driven Design(the eXtreme Programming way):  </li></ul></ul><ul><ul><ul><li>drive full design from little to no design whatsoever. You design as you go. Tests guide your design process </li></ul></ul></ul><ul><ul><li>4) Test Driven Development and Design: </li></ul></ul><ul><ul><ul><li>evolve your design from tests. </li></ul></ul></ul>http://weblogs.asp.net/rosherove/archive/2007/10/08/the-various-meanings-of-tdd.aspx
  37. 37. Test First Design (TFD) <ul><li>add a test, </li></ul><ul><ul><li>just enough code to fail.  </li></ul></ul><ul><li>run tests </li></ul><ul><ul><li>often the complete test suite </li></ul></ul><ul><ul><li>sometimes only a subset </li></ul></ul><ul><ul><li>ensure that the new test does in fact fail.  </li></ul></ul><ul><li>update your functional code to make it pass </li></ul><ul><li>run your tests again.  </li></ul><ul><ul><li>if they fail update your functional code and retest.  </li></ul></ul><ul><li>Once the tests pass start over or refactor your design and then start over. </li></ul>
  38. 38. TDD = TFD + Refactoring <ul><li>Requires great discipline: it is easy to “slip” and write functional code without first writing a new test. </li></ul><ul><ul><li>write your test code before your functional code </li></ul></ul><ul><ul><li>do so in very small steps </li></ul></ul><ul><ul><ul><li>one test and a small bit of corresponding functional code </li></ul></ul></ul><ul><ul><ul><li>no new function without a test that fails because that function isn’t present </li></ul></ul></ul><ul><ul><ul><li>no code until a test exists for it </li></ul></ul></ul><ul><ul><ul><li>ensure that the test suite now passes </li></ul></ul></ul><ul><ul><ul><li>refactor it to ensure high quality. </li></ul></ul></ul><ul><li>Use pair programming to help stay on track. </li></ul>
  39. 39. Implications for Developers <ul><li>Developers need to learn how to write effective unit tests. </li></ul><ul><li>Good unit tests: </li></ul><ul><ul><li>Run fast (have short setups, run times, and break downs). </li></ul></ul><ul><ul><li>Run in isolation (can be reordered). </li></ul></ul><ul><ul><li>Use data that makes them easy to read and to understand. </li></ul></ul><ul><ul><li>Use real data (e.g. copies of production data) when they need to. </li></ul></ul><ul><ul><li>Represent one step towards your overall goal. </li></ul></ul>
  40. 40. Shortcomings <ul><li>Equating “goodness” with passing a test </li></ul><ul><li>Test suites are also code </li></ul><ul><ul><li>more code to maintain </li></ul></ul><ul><ul><li>could be buggy itself </li></ul></ul><ul><ul><li>might mean longer and longer runtimes for testing </li></ul></ul>
  41. 41. Scrum ( Schwaber and Beedle ) <ul><ul><li>Scrum is a framework within which the game of product development is played. </li></ul></ul><ul><ul><li>Your team plays and how good or not-good it is becomes highly visible. </li></ul></ul><ul><ul><li>Your team gets to continuously improve itself. </li></ul></ul>used under permission of the Scrum Alliance
  42. 42. Companies Using Scrum <ul><li>Bottom Up </li></ul><ul><ul><li>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 </li></ul></ul><ul><li>Top Down </li></ul><ul><ul><li>IDX, Siemens Medical, Gestalt, Wildcard Systems, Primavera, Yahoo, Conchango, BMC, Lexis-Nexis, Bentley Systems, Bose, CapitalOne, Federal Reserve Bank, ClearChannel, Xerox, Nokia, Motorola </li></ul></ul>
  43. 43. Scrum Characteristics <ul><ul><li>Self-organizing teams </li></ul></ul><ul><ul><li>Product progresses in a series of month-long “sprints” </li></ul></ul><ul><ul><li>Requirements are captured as items in a list of “product backlog” </li></ul></ul><ul><ul><li>No specific engineering practices prescribed </li></ul></ul><ul><ul><li>Uses generative rules to create an agile environment for delivering projects </li></ul></ul>used under permission of the Scrum Alliance
  44. 44. Scrum Model used under permission of the Scrum Alliance
  45. 45. Sprints <ul><li>Scrum projects make progress in a series of “sprints” </li></ul><ul><ul><li>Analogous to XP iterations </li></ul></ul><ul><li>Target duration is one month </li></ul><ul><ul><li>+/- a week or two </li></ul></ul><ul><ul><ul><li>But, a constant duration leads to a better rhythm </li></ul></ul></ul><ul><li>Product is designed, coded, and tested during the sprint </li></ul>used under permission of the Scrum Alliance No changes during the sprint
  46. 46. Product Backlog <ul><li>A list of all desired work on the project </li></ul><ul><ul><li>combination of </li></ul></ul><ul><ul><ul><li>story-based work </li></ul></ul></ul><ul><ul><ul><li>task-based work </li></ul></ul></ul><ul><li>List is prioritized by the Product Owner </li></ul><ul><ul><li>Typically a Product Manager, Marketing, Internal Customer, etc. </li></ul></ul>used under permission of the Scrum Alliance
  47. 47. 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
  48. 48. Sprint Backlog during the Sprint <ul><li>Changes </li></ul><ul><ul><li>Team adds new tasks whenever they need to in order to meet the Sprint Goal </li></ul></ul><ul><ul><li>Team can remove unnecessary tasks </li></ul></ul><ul><ul><li>But: Sprint Backlog can only be updated by the team </li></ul></ul><ul><li>Estimates are updated whenever there’s new information </li></ul>used under permission of the Scrum Alliance
  49. 49. Sprint Burndown Chart used under permission of the Scrum Alliance
  50. 50. Daily Scrum meetings <ul><ul><li>Parameters </li></ul></ul><ul><ul><ul><li>Daily </li></ul></ul></ul><ul><ul><ul><li>15-minutes </li></ul></ul></ul><ul><ul><ul><li>Stand-up </li></ul></ul></ul><ul><ul><ul><li>Not for problem solving </li></ul></ul></ul><ul><ul><li>Three questions: </li></ul></ul><ul><ul><ul><li>What did you do yesterday </li></ul></ul></ul><ul><ul><ul><li>What will you do today? </li></ul></ul></ul><ul><ul><ul><li>What obstacles are in your way? </li></ul></ul></ul><ul><ul><li>Chickens and pigs are invited </li></ul></ul><ul><ul><ul><li>Help avoid other unnecessary meetings </li></ul></ul></ul><ul><ul><li>Only pigs can talk </li></ul></ul>used under permission of the Scrum Alliance
  51. 51. Sprint Review Meeting <ul><li>Team presents what it accomplished during the sprint </li></ul><ul><li>Typically takes the form of a demo of new features or underlying architecture </li></ul><ul><li>Informal </li></ul><ul><ul><li>2-hour prep time rule </li></ul></ul><ul><li>Participants </li></ul><ul><ul><li>Customers </li></ul></ul><ul><ul><li>Management </li></ul></ul><ul><ul><li>Product Owner </li></ul></ul><ul><ul><li>Other engineers </li></ul></ul>used under permission of the Scrum Alliance
  52. 52. The Origin of Religious Wars <ul><li>One faith, one law, one king </li></ul><ul><li>French royalists, circa 1562 </li></ul><ul><li>even some people who call God God </li></ul><ul><li>worship God in a way that's odd </li></ul><ul><li>We have to kill them, it's a shame </li></ul><ul><li> Austin Lounge Lizards, </li></ul><ul><li>&quot;One True God&quot;, The Drugs I Need </li></ul>
  53. 53. Agility vs. Discipline <ul><li>If one has strong discipline without agility, the result is bureaucracy and stagnation. </li></ul><ul><li>Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit </li></ul>
  54. 54. Requirements for Success - 1 <ul><li>Waterfall-based projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul><li>organizational infrastructure </li></ul></ul><ul><ul><li>engineers that understand, value and follow processes </li></ul></ul><ul><ul><li>process assets </li></ul></ul><ul><ul><li>customer representatives that are collaborative, representative, authorized, committed and knowledgeable </li></ul></ul>
  55. 55. Requirements for Success - 2 <ul><li>Agile projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul><li>organizational infrastructure </li></ul></ul><ul><ul><li>engineers that understand, value and follow processes </li></ul></ul><ul><ul><li>leads that can break the rules and make new ones as needed </li></ul></ul><ul><ul><li>full-time customer representatives that are collaborative, representative, authorized, committed and knowledgeable </li></ul></ul>
  56. 56. Why Go Agile <ul><li>Right reasons </li></ul><ul><ul><li>we have CRACK customers </li></ul></ul><ul><ul><li>our projects are small to medium </li></ul></ul><ul><ul><li>criticality is low to medium </li></ul></ul><ul><ul><li>we have experienced people that have succeeded with it </li></ul></ul><ul><li>Wrong reasons </li></ul><ul><ul><li>we don’t have the time for process </li></ul></ul><ul><ul><li>we don’t have the time to document the system </li></ul></ul><ul><ul><li>our engineers are young and inexperienced </li></ul></ul>
  57. 57. When Not to Go Agile <ul><li>Product is mission-critical </li></ul><ul><ul><li>requirements of traceability very strict </li></ul></ul><ul><li>No CRACK users </li></ul><ul><ul><li>customer is reluctant to commit a valuable player to the team </li></ul></ul><ul><li>Architectural concerns are high </li></ul><ul><ul><li>non functional aspects are dominant </li></ul></ul><ul><ul><li>YAGNI does not apply </li></ul></ul><ul><li>Project demands large team </li></ul>
  58. 58. So, Maybe… <ul><li>There is no silver bullet </li></ul><ul><li>There is no one-size-fits-all </li></ul><ul><li>It is better to build your method up than to pare it down </li></ul><ul><li>Potential silver bullets are elsewhere </li></ul><ul><ul><li>people </li></ul></ul><ul><ul><li>values </li></ul></ul><ul><ul><li>communication </li></ul></ul><ul><ul><li>expectation management </li></ul></ul>
  59. 59. Final Conclusion <ul><ul><li>Follow the six key principles for business-driven development: </li></ul></ul><ul><ul><ul><li>A dapt the process </li></ul></ul></ul><ul><ul><ul><li>B alance stakeholder priorities </li></ul></ul></ul><ul><ul><ul><li>C ollaborate across teams </li></ul></ul></ul><ul><ul><ul><li>D emonstrate value iteratively </li></ul></ul></ul><ul><ul><ul><li>E levate the level of abstraction </li></ul></ul></ul><ul><ul><ul><li>F ocus continuously on quality </li></ul></ul></ul><ul><ul><li>In short -> [ABCDEF]  </li></ul></ul><ul><ul><li>Steal with pride but do not lie to yourself: </li></ul></ul><ul><ul><li>A Monkey In A Silk Suit Is Still A Monkey ! </li></ul></ul>
  60. 60. Any Questions? thank you for your time [email_address] www.liveware.com
  61. 61. Acknowledgements <ul><li>We have used terms like: </li></ul><ul><ul><li>Scrum Alliance (SM) </li></ul></ul><ul><ul><li>Agile Alliance </li></ul></ul><ul><ul><li>CMMI </li></ul></ul><ul><ul><ul><li>® Capability Maturity Model, CMMI, and CMM are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University </li></ul></ul></ul><ul><li>Some slides are used under copyright agreement with the Scrum Alliance. </li></ul><ul><li>Monty Python is credited for intellectual inspiration and art work in most of the Holy Wars material </li></ul>
  62. 62. Backup Slides
  63. 63. Back to Basics <ul><li>Let there be Deming… </li></ul><ul><ul><li>reduce waste, </li></ul></ul><ul><ul><li>rework, </li></ul></ul><ul><ul><li>staff attrition and </li></ul></ul><ul><ul><li>litigation while </li></ul></ul><ul><ul><li>increasing </li></ul></ul><ul><ul><li>customer loyalty </li></ul></ul>
  64. 64. Deming’s 14 Points for Management <ul><li>1.&quot;Create constancy of purpose towards improvement“ </li></ul><ul><li>3.&quot;Cease dependence on inspection&quot; </li></ul><ul><li>5.&quot;Improve constantly and forever&quot; 7.&quot;Institute leadership&quot; 9.&quot;Break down barriers between departments&quot; 11.&quot;Eliminate management by objectives&quot; 13.&quot;Institute education and self-improvement “ </li></ul><ul><li>2.&quot;Adopt the new philosophy&quot; </li></ul><ul><li>4.&quot;Move towards a single supplier for any one item&quot; 6.&quot;Institute training on the job&quot; </li></ul><ul><li>8.&quot;Drive out fear&quot; 10.&quot;Eliminate slogans&quot; </li></ul><ul><li>12.&quot;Remove barriers to pride of workmanship&quot; 14.&quot;The transformation is everyone's job&quot; </li></ul>
  65. 65. Agility vs. Discipline <ul><li>If one has strong discipline without agility, the result is bureaucracy and stagnation. </li></ul><ul><li>Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit </li></ul>Boehm and Turner Balancing Agility and Discipline
  66. 66. Requirements for Success - 1 <ul><li>Waterfall-based projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul><li>organizational infrastructure </li></ul></ul><ul><ul><li>engineers that understand, value and follow processes </li></ul></ul><ul><ul><li>process assets </li></ul></ul><ul><ul><li>customer representatives that are collaborative, representative, authorized, committed and knowledgeable (CRACK) </li></ul></ul>
  67. 67. Requirements for Success - 2 <ul><li>Agile projects need: </li></ul><ul><ul><li>management support </li></ul></ul><ul><ul><li>organizational infrastructure </li></ul></ul><ul><ul><li>engineers that understand, value and follow processes </li></ul></ul><ul><ul><li>leads that can break the rules and make new ones as needed </li></ul></ul><ul><ul><li>full-time customer representatives that are collaborative, representative, authorized, committed and knowledgeable </li></ul></ul>
  68. 68. Why Go Agile <ul><li>Right reasons </li></ul><ul><ul><li>we have CRACK customers </li></ul></ul><ul><ul><li>our projects are small to medium </li></ul></ul><ul><ul><li>criticality is low to medium </li></ul></ul><ul><ul><li>we have experienced people that have succeeded with it </li></ul></ul><ul><li>Wrong reasons </li></ul><ul><ul><li>we don’t have the time for process </li></ul></ul><ul><ul><li>we don’t have the time to document the system </li></ul></ul><ul><ul><li>our engineers are young and inexperienced </li></ul></ul>
  69. 69. When Not to Go Agile <ul><li>Product is mission-critical </li></ul><ul><ul><li>requirements of traceability very strict </li></ul></ul><ul><li>No CRACK users </li></ul><ul><ul><li>customer is reluctant to commit a valuable player to the team </li></ul></ul><ul><li>Architectural concerns are high </li></ul><ul><ul><li>non functional aspects are dominant </li></ul></ul><ul><ul><li>YAGNI does not apply </li></ul></ul><ul><li>Project demands large team </li></ul>
  70. 70. The Agile Manifesto - 1 <ul><li>Principles behind the Agile Manifesto </li></ul><ul><li>We follow these principles: </li></ul><ul><li>1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><ul><ul><li>short feedback loops </li></ul></ul></ul><ul><li>2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><ul><ul><li>include the customer </li></ul></ul></ul><ul><li>3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul><ul><ul><ul><li>feedback based on real product </li></ul></ul></ul>
  71. 71. The Agile Manifesto - 2 <ul><li>4. Business people and developers must work together daily throughout the project. </li></ul><ul><ul><ul><li>feedback should happen daily </li></ul></ul></ul><ul><li>5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><ul><ul><li>trust your developers </li></ul></ul></ul><ul><li>6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul><ul><ul><ul><li>continuous knowledge improvement </li></ul></ul></ul><ul><li>7. Working software is the primary measure of progress. </li></ul><ul><ul><ul><li>continuous visibility </li></ul></ul></ul>
  72. 72. The Agile Manifesto - 3 <ul><li>8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><ul><ul><li>no iterative death marches </li></ul></ul></ul><ul><li>9. Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>10. Simplicity--the art of maximizing the amount of work not done--is essential. </li></ul><ul><li>11. The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  73. 73. Scrum <ul><ul><li>One of the “agile processes” </li></ul></ul><ul><ul><li>Self-organizing teams </li></ul></ul><ul><ul><li>Product progresses in a series of month-long “sprints” </li></ul></ul><ul><ul><li>Requirements are captured as items in a list of “product backlog” </li></ul></ul><ul><ul><li>No specific engineering practices prescribed </li></ul></ul><ul><ul><li>Uses generative rules to create an agile environment for delivering projects </li></ul></ul>used under permission of the Scrum Alliance
  74. 74. 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
  75. 75. Scrum Model used under permission of the Scrum Alliance
  76. 76. The Scrum Master <ul><ul><li>Represents management to the project </li></ul></ul><ul><ul><li>Typically filled by a Project Manager or Team Leader </li></ul></ul><ul><ul><li>Responsible for enacting Scrum values and practices </li></ul></ul><ul><ul><li>Main job is to remove impediments </li></ul></ul>used under permission of the Scrum Alliance
  77. 77. The Scrum Team <ul><ul><li>Typically 5-10 people </li></ul></ul><ul><ul><li>Cross-functional </li></ul></ul><ul><ul><ul><li>QA, Programmers, UI Designers, etc. </li></ul></ul></ul><ul><ul><li>Members should be full-time </li></ul></ul><ul><ul><ul><li>May be exceptions (e.g., System Admin, etc.) </li></ul></ul></ul><ul><ul><li>Teams are self-organizing </li></ul></ul><ul><ul><ul><li>What to do if a team self-organizes someone off the team?? </li></ul></ul></ul><ul><ul><ul><li>Ideally, no titles but rarely a possibility </li></ul></ul></ul><ul><ul><li>Membership can change only between sprints </li></ul></ul>used under permission of the Scrum Alliance
  78. 78. Sprints <ul><li>Scrum projects make progress in a series of “sprints” </li></ul><ul><ul><li>Analogous to XP iterations </li></ul></ul><ul><li>Target duration is one month </li></ul><ul><ul><li>+/- a week or two </li></ul></ul><ul><ul><ul><li>But, a constant duration leads to a better rhythm </li></ul></ul></ul><ul><li>Product is designed, coded, and tested during the sprint </li></ul>used under permission of the Scrum Alliance
  79. 79. 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
  80. 80. No changes during the sprint <ul><li>Plan sprint durations around how long you can commit to keeping change out of the sprint </li></ul>used under permission of the Scrum Alliance Sprint Inputs Tested Code Change
  81. 81. Product Backlog <ul><li>A list of all desired work on the project </li></ul><ul><ul><li>Usually a combination of </li></ul></ul><ul><ul><ul><li>story-based work (“let user search and replace”) </li></ul></ul></ul><ul><ul><ul><li>task-based work (“improve exception handling”) </li></ul></ul></ul><ul><li>List is prioritized by the Product Owner </li></ul><ul><ul><li>Typically a Product Manager, Marketing, Internal Customer, etc. </li></ul></ul>used under permission of the Scrum Alliance
  82. 82. Sample Product Backlog used under permission of the Scrum Alliance
  83. 83. 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
  84. 84. The Sprint Goal <ul><li>A short “theme” for the sprint: </li></ul>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
  85. 85. From Sprint Goal to Sprint Backlog <ul><li>Scrum team takes the Sprint Goal and decides what tasks are necessary </li></ul><ul><li>Team self-organizes around how they’ll meet the Sprint Goal </li></ul><ul><ul><li>Manager doesn’t assign tasks to individuals </li></ul></ul><ul><li>Managers don’t make decisions for the team </li></ul><ul><li>Sprint Backlog is created </li></ul>used under permission of the Scrum Alliance
  86. 86. Sample Sprint Backlog used under permission of the Scrum Alliance
  87. 87. Sprint Backlog during the Sprint <ul><li>Changes </li></ul><ul><ul><li>Team adds new tasks whenever they need to in order to meet the Sprint Goal </li></ul></ul><ul><ul><li>Team can remove unnecessary tasks </li></ul></ul><ul><ul><li>But: Sprint Backlog can only be updated by the team </li></ul></ul><ul><li>Estimates are updated whenever there’s new information </li></ul>used under permission of the Scrum Alliance
  88. 88. Sprint Burndown Chart used under permission of the Scrum Alliance
  89. 89. Daily Scrum meetings <ul><ul><li>Parameters </li></ul></ul><ul><ul><ul><li>Daily </li></ul></ul></ul><ul><ul><ul><li>15-minutes </li></ul></ul></ul><ul><ul><ul><li>Stand-up </li></ul></ul></ul><ul><ul><ul><li>Not for problem solving </li></ul></ul></ul><ul><ul><li>Three questions: </li></ul></ul><ul><ul><ul><li>What did you do yesterday </li></ul></ul></ul><ul><ul><ul><li>What will you do today? </li></ul></ul></ul><ul><ul><ul><li>What obstacles are in your way? </li></ul></ul></ul><ul><ul><li>Chickens and pigs are invited </li></ul></ul><ul><ul><ul><li>Help avoid other unnecessary meetings </li></ul></ul></ul><ul><ul><li>Only pigs can talk </li></ul></ul>used under permission of the Scrum Alliance
  90. 90. Questions about Scrum meetings? <ul><li>Why daily? </li></ul><ul><ul><li>“How does a project get to be a year late?” </li></ul></ul><ul><ul><ul><li>“One day at a time.” </li></ul></ul></ul><ul><ul><ul><ul><li>Fred Brooks, The Mythical Man-Month. </li></ul></ul></ul></ul><ul><li>Can Scrum meetings be replaced by emailed status reports? </li></ul><ul><ul><li>No </li></ul></ul><ul><ul><ul><li>Entire team sees the whole picture every day </li></ul></ul></ul><ul><ul><ul><li>Create peer pressure to do what you say you’ll do </li></ul></ul></ul>used under permission of the Scrum Alliance
  91. 91. Constraints <ul><li>A complete list of constraints put on the team during a Sprint: </li></ul><ul><li></end of list> </li></ul>used under permission of the Scrum Alliance
  92. 92. Sprint Review Meeting <ul><li>Team presents what it accomplished during the sprint </li></ul><ul><li>Typically takes the form of a demo of new features or underlying architecture </li></ul><ul><li>Informal </li></ul><ul><ul><li>2-hour prep time rule </li></ul></ul><ul><li>Participants </li></ul><ul><ul><li>Customers </li></ul></ul><ul><ul><li>Management </li></ul></ul><ul><ul><li>Product Owner </li></ul></ul><ul><ul><li>Other engineers </li></ul></ul>used under permission of the Scrum Alliance
  93. 93. Stabilization Sprints <ul><li>During “regular” sprints target friendly first use </li></ul><ul><ul><li>Beta customers and similar can use immediately after sprint </li></ul></ul><ul><li>During “stabilization sprints” </li></ul><ul><ul><li>Team prepares a product for release </li></ul></ul><ul><ul><li>Useful during </li></ul></ul><ul><ul><ul><li>active beta periods </li></ul></ul></ul><ul><ul><ul><li>when transitioning a team to Scrum </li></ul></ul></ul><ul><ul><ul><li>if quality isn’t quite where it should be on an initial release </li></ul></ul></ul><ul><li>Not a part of standard Scrum, just something I’ve found useful </li></ul>Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 1 Sprint 2 Sprint 3 Stabilization Sprint used under permission of the Scrum Alliance
  94. 94. Where to go next? <ul><li>Scrum </li></ul><ul><ul><li>www.mountaingoatsoftware.com/scrum </li></ul></ul><ul><ul><li>www.controlchaos.com </li></ul></ul><ul><ul><li>[email_address] </li></ul></ul><ul><ul><li>Agile Software Development with Scrum </li></ul></ul><ul><ul><ul><li>Ken Schwaber and Mike Beedle </li></ul></ul></ul><ul><ul><li>Agile Project Management with Scrum </li></ul></ul><ul><ul><ul><li>Ken Schwaber and Mike Beedle </li></ul></ul></ul><ul><ul><li>General information </li></ul></ul><ul><ul><ul><li>www.agilealliance.com </li></ul></ul></ul>used under permission of the Scrum Alliance
  95. 95. Xbreed - 1 <ul><li>Goal of XBreed is to support multiple projects, reusing components such as </li></ul><ul><ul><li>architectural services </li></ul></ul><ul><ul><li>workflows </li></ul></ul><ul><ul><li>units of work </li></ul></ul><ul><ul><li>services </li></ul></ul><ul><ul><li>transactions </li></ul></ul><ul><ul><li>business objects </li></ul></ul><ul><li>Xbreed uses most Scrum practices, plus </li></ul><ul><ul><li>using chief programmers as team leads </li></ul></ul><ul><ul><li>uses hierarchies of teams </li></ul></ul><ul><ul><li>uses Scrum practices at each level of hierarchy </li></ul></ul>
  96. 96. XBreed - 2 <ul><li>Leverage XP practices with some differences </li></ul><ul><ul><li>planning game replaced by Scrum </li></ul></ul><ul><ul><li>some YAGNI, only in known domain &quot;hot spots“ </li></ul></ul><ul><ul><li>Classes, Responsibility, and Collaboration (CRC) stories used for representing requirements </li></ul></ul><ul><ul><ul><li>eliciting requirements </li></ul></ul></ul><ul><ul><ul><li>discussing design </li></ul></ul></ul><ul><ul><ul><li>Supplement with use case for complex functionality </li></ul></ul></ul>
  97. 97. Components of XBreed <ul><li>Uses design patterns in defining products </li></ul><ul><li>Uses &quot;Shared Services&quot; teams to handle several increments concurrently </li></ul><ul><li>Includes a rchitect roles on the teams </li></ul><ul><li>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. </li></ul>
  98. 98. 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
  99. 99. FDD vs XP Similarities <ul><ul><li>E nable teams to deliver results </li></ul></ul><ul><ul><ul><li>quicker </li></ul></ul></ul><ul><ul><ul><li>without compromising quality </li></ul></ul></ul><ul><ul><li>Hi ghly iterative results-oriented processes </li></ul></ul><ul><ul><li>P eople focused , not document focused </li></ul></ul><ul><ul><li>D ismantle traditional separation of domain and business experts/analysts from designers and implementers </li></ul></ul><ul><ul><ul><ul><li>analysts are dragged out of their abstractions and put in the same room as developers and users </li></ul></ul></ul></ul><ul><ul><ul><ul><li>enabling and encouraging analysis, design, code, test and deployment to be done concurrently </li></ul></ul></ul></ul>
  100. 100. FDD vs XP Differences - 1 <ul><li>XP: </li></ul><ul><ul><li>Team sizes </li></ul></ul><ul><ul><ul><li>teams of two to ten programmers </li></ul></ul></ul><ul><ul><li>Metaphor and Model </li></ul></ul><ul><ul><ul><li>Business writing stories on index cards </li></ul></ul></ul><ul><ul><ul><li>analogous to driving a car - continual little course adjustments </li></ul></ul></ul><ul><li>FDD : </li></ul><ul><ul><li>Team sizes </li></ul></ul><ul><ul><ul><li>team of 16-20 developers , designed to scale to much larger team sizes </li></ul></ul></ul><ul><ul><li>Metaphor and Model </li></ul></ul><ul><ul><ul><li>adds development of an overall domain object model </li></ul></ul></ul><ul><ul><ul><li>analogous to using the domain object model as the map to guide the journey </li></ul></ul></ul>
  101. 101. FDD vs XP Differences - 2 <ul><li>XP : </li></ul><ul><ul><li>Collective Ownership or Class Ownership </li></ul></ul><ul><ul><ul><li>collective ownership of code </li></ul></ul></ul><ul><ul><li>Inspections and Pair Programming </li></ul></ul><ul><ul><ul><li>pair programming provide s continuous design and code inspection. </li></ul></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><ul><li>XP : unit and functional tests </li></ul></ul></ul><ul><ul><ul><li>FDD : unit testing part of Build By Feature </li></ul></ul></ul><ul><ul><li>Reporting </li></ul></ul><ul><ul><ul><li>XP : tracking by project managers </li></ul></ul></ul><ul><ul><ul><li>FDD : Tracking By Feature low-overhead, highly accurate progress measuring </li></ul></ul></ul><ul><li>F DD: </li></ul><ul><ul><li>Collective Ownership or Class Ownership </li></ul></ul><ul><ul><ul><li>individual code ownership </li></ul></ul></ul><ul><ul><li>Inspections and Pair Programming </li></ul></ul><ul><ul><ul><li>formal inspections by feature teams </li></ul></ul></ul>
  102. 102. FDD vs XP Differences - 3 <ul><li>XP : </li></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><ul><li>unit and functional tests </li></ul></ul></ul><ul><ul><li>Reporting </li></ul></ul><ul><ul><ul><li>tracking by project managers </li></ul></ul></ul><ul><li>F DD: </li></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><ul><li>unit testing part of Build By Feature </li></ul></ul></ul><ul><ul><li>Reporting </li></ul></ul><ul><ul><ul><li>Tracking By Feature low-overhead, highly accurate progress measuring </li></ul></ul></ul>
  103. 103. Dynamic System Development <ul><li>DSDM is a variant of RAD </li></ul><ul><ul><li>developed in the UK by a consortium </li></ul></ul><ul><ul><li>very successful since 1995 </li></ul></ul><ul><ul><li>has not crossed into mainstream yet </li></ul></ul><ul><ul><li>focuses on short cycles and changing requirements </li></ul></ul><ul><li>Claims of DSDM </li></ul><ul><ul><li>users have ownership </li></ul></ul><ul><ul><li>risk of building the wrong system is minimized </li></ul></ul><ul><ul><li>users are trained </li></ul></ul><ul><ul><li>smooth implementation through cooperation </li></ul></ul><ul><li>Applies only when all users are identified and few </li></ul>
  104. 104. DSDM Lifecycle <ul><li>Tailorable generic process </li></ul><ul><li>Iterates as needed through </li></ul><ul><ul><li>Functional model and </li></ul></ul><ul><ul><li>Design and build </li></ul></ul><ul><li>Implementation can end with </li></ul><ul><ul><li>a finished product </li></ul></ul><ul><ul><li>more feasibility studies </li></ul></ul><ul><ul><li>more functionality </li></ul></ul><ul><ul><li>changes to the design prototypes </li></ul></ul>
  105. 105. DSDM Principles <ul><li>Active user involvement </li></ul><ul><li>Empowered teams </li></ul><ul><li>Frequent product delivery </li></ul><ul><li>Fitness for business purposes </li></ul><ul><li>Iterative and incremental development </li></ul><ul><li>Reversible changes </li></ul><ul><li>Baselined high level requirements </li></ul><ul><li>Testing integrated throughout the lifecycle </li></ul><ul><li>Stakeholder collaboration and cooperation </li></ul>

×