Agile Engineering Practices


Published on

Agile engineering practices from XP and FDD focusing on FDD. (Based on cultural challenges that XP faces.)

Published in: Technology

Agile Engineering Practices

  1. 1. Agile Engineering Practices Hangzhou Scrum Forum 2009 May 2009
  2. 2. Agenda <ul><li>Ground rules </li></ul><ul><li>Purpose and expected outcomes </li></ul><ul><li>About the presenter </li></ul><ul><li>Agile – concepts and methodologies </li></ul><ul><li>Agile and Engineering Practices </li></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><li>XP </li></ul></ul><ul><ul><li>FDD </li></ul></ul>
  3. 3. Ground Rules <ul><li>Mute your cell phone </li></ul><ul><li>Participate – ask and answer questions </li></ul>Do Don’t
  4. 4. Purpose and Outcomes <ul><li>Purpose: </li></ul><ul><ul><li>Review key Agile principles </li></ul></ul><ul><ul><li>Discuss Agile Software Engineering Practices </li></ul></ul><ul><li>Outcomes: </li></ul><ul><ul><li>Gain an understanding of key Agile Software Engineering Practices </li></ul></ul><ul><ul><li>Recognize there are multiple sources from which to learn and implement Agile Engineering Practices </li></ul></ul><ul><ul><li>Develop a basic understanding of Feature Driven Development as an Agile alternative to XP practices (which are often challenging to implement) </li></ul></ul>
  5. 5. About Me <ul><li>Vernon Stinebaker ( 史文林) </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li>Director of Technology/Principal Architect </li></ul></ul><ul><ul><li>20+ years software development and process experience </li></ul></ul><ul><ul><ul><li>CMMI, SDLC/waterfall, and agile methodologies </li></ul></ul></ul><ul><ul><li>Certified ScrumMaster/Certified Scrum Practitioner </li></ul></ul><ul><ul><li>9+ years experience with Feature Driven Development </li></ul></ul><ul><ul><li>Founding member of the open source FDDTools project </li></ul></ul>
  6. 6. Agile Manifesto
  7. 7. Agile Manifesto Principles <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Deliver working software frequently , from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul><ul><li>Business people and developers must work together daily throughout the project. </li></ul><ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul><ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul><ul><li>Working software is the primary measure of progress. </li></ul><ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul><ul><li>Simplicity -- the art of maximizing the amount of work not done -- is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
  8. 8. First things first… <ul><li>The most important contributor to the success of projects is… </li></ul><ul><li>People! </li></ul>
  9. 9. <ul><li>Scrum </li></ul><ul><li>eXtreme Programming (XP) </li></ul><ul><li>FDD </li></ul><ul><li>DSDM </li></ul><ul><li>Crystal </li></ul><ul><li>Perficient’s Enable-M </li></ul><ul><li>… </li></ul><ul><li>But they share the same objectives -- those described in the Agile Manifesto </li></ul>No “one” Agile
  10. 10. Today’s Focus <ul><li>XP </li></ul><ul><li>FDD </li></ul>
  11. 11. First let’s talk about <ul><li>Scrum </li></ul>
  12. 12. Scrum <ul><li>3 Roles </li></ul><ul><ul><li>Product Owner </li></ul></ul><ul><ul><li>ScrumMaster </li></ul></ul><ul><ul><li>Team </li></ul></ul><ul><li>3 Ceremonies </li></ul><ul><ul><li>Sprint Planning </li></ul></ul><ul><ul><li>Daily Stand-up </li></ul></ul><ul><ul><li>Sprint Demo </li></ul></ul><ul><li>3 Artifacts </li></ul><ul><ul><li>Product Backlog </li></ul></ul><ul><ul><li>Sprint Backlog </li></ul></ul><ul><ul><li>Burn-down Charts </li></ul></ul>
  13. 13. Scrum in one slide Mountain Goat Software, LLC Product Owner Team ScrumMaster
  14. 14. Scrum is… <ul><li>Simple, but not easy! </li></ul>
  15. 15. Characteristics <ul><li>Self-organizing teams </li></ul><ul><li>Product progresses in a series of month-long “sprints” </li></ul><ul><li>Requirements are captured as items in a list of “product backlog” </li></ul><ul><li>No specific engineering practices prescribed </li></ul><ul><li>Uses generative rules to create an agile environment for delivering projects </li></ul><ul><li>One of the “agile processes” </li></ul>Mountain Goat Software, LLC
  16. 16. <ul><li>OMG! No specific engineering practices prescribed! </li></ul>
  17. 17. Sequential vs. overlapping development Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test Mountain Goat Software, LLC
  18. 18. So… <ul><li>We still have to do </li></ul><ul><ul><li>Requirements gathering </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Coding </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><li>But how? </li></ul>
  19. 19. <ul><li>I like XP! </li></ul>
  20. 20. XP Practices <ul><li>eXtreme Programming describes engineering practices </li></ul><ul><ul><li>On-site Customer </li></ul></ul><ul><ul><li>Metaphor </li></ul></ul><ul><ul><li>40 Hour Week </li></ul></ul><ul><ul><li>Planning Game </li></ul></ul><ul><ul><li>Refactoring </li></ul></ul><ul><ul><li>Simple Design </li></ul></ul><ul><ul><li>Pair Programming </li></ul></ul><ul><ul><li>Testing </li></ul></ul><ul><ul><li>Short Releases </li></ul></ul><ul><ul><li>Coding Standards </li></ul></ul><ul><ul><li>Collective Ownership </li></ul></ul><ul><ul><li>Continuous Integration </li></ul></ul>
  21. 21. Which practices have you implemented? <ul><li>On-site Customer </li></ul><ul><li>Metaphor </li></ul><ul><li>40 Hour Week </li></ul><ul><li>Planning Game </li></ul><ul><li>Refactoring </li></ul><ul><li>Simple Design </li></ul><ul><li>Pair Programming </li></ul><ul><li>Testing </li></ul><ul><li>Short Releases </li></ul><ul><li>Coding Standards </li></ul><ul><li>Collective Ownership </li></ul><ul><li>Continuous Integration </li></ul>
  22. 22. What does the project process look like? <ul><li>Is this simple? (Easy or not?) </li></ul><ul><li>What happened to those practices? </li></ul>
  23. 23. <ul><li>Scrum doesn’t prescribe engineering practices. </li></ul><ul><li>XP is great! But are their alternatives? </li></ul>
  24. 24. <ul><li>Feature Driven Development </li></ul>
  25. 25. FDD in a slide <ul><li>Simple? </li></ul><ul><li>YES!!! </li></ul><ul><li>But not easy  </li></ul>
  26. 26. The whole process in one slide <ul><li>ETVX. Really simple. Not one book. One slide. </li></ul><ul><ul><li>(Well, OK. 10 pages actually.) </li></ul></ul>FDD Process copyright Nebulon 2009
  27. 27. Develop an Overall Model <ul><li>What’s this? Modeling? </li></ul><ul><li>Yes. Agile modeling! </li></ul>
  28. 28. Build a Feature List <ul><li>User valued, user verifiable functionality </li></ul><ul><li><action><result><object> </li></ul><ul><ul><li>Calculate the total value of a sale. </li></ul></ul><ul><ul><li>Display the result of a translation. </li></ul></ul>
  29. 29. Plan by Feature <ul><li>Features must take less than two weeks </li></ul><ul><ul><li>Can be much less </li></ul></ul><ul><li>Features are collected into Work Packages </li></ul><ul><ul><li>Which are released within two weeks </li></ul></ul><ul><li>Resources are the only challenge to scalability </li></ul><ul><ul><li>Used successfully on projects with team size of 500+ </li></ul></ul><ul><ul><li>An unlimited number of Work Packages may be under simultaneous development </li></ul></ul>
  30. 30. Design by Feature <ul><li>More Design? </li></ul><ul><ul><li>Conversations happen! </li></ul></ul><ul><ul><li>Inspection – bench testing (TDD?) </li></ul></ul><ul><ul><li>Communication is the second key to successful projects </li></ul></ul><ul><li>People are the first! </li></ul>
  31. 31. Build by Feature <ul><li>Class ownership </li></ul><ul><li>Code inspection </li></ul><ul><li>Unit Testing </li></ul><ul><li>Promote to Build </li></ul>
  32. 32. What? Traditional Software Engineering Activities? <ul><li>Design </li></ul><ul><li>Inspections </li></ul><ul><li>Testing </li></ul><ul><li>Builds </li></ul><ul><li>Can you implement these? </li></ul>
  33. 33. What? Traditional roles? <ul><li>Customer </li></ul><ul><ul><li>SMEs </li></ul></ul><ul><li>Project Manager </li></ul><ul><li>Architect </li></ul><ul><li>Chief Programmer </li></ul><ul><li>Developers </li></ul><ul><li>Testers </li></ul><ul><li>Easier for some organizations to accept </li></ul>
  34. 34. FDD is… <ul><li>Evolutionary, not revolutionary </li></ul><ul><li>Builds on software engineering best practices </li></ul><ul><li>Makes sense to ‘traditional’ engineers and managers </li></ul><ul><li>Agile! </li></ul><ul><li>Simple. But not easy. </li></ul><ul><li>Can be used to complement Scrum by providing familiar and implementable engineering practices </li></ul>
  35. 35. Summary <ul><li>Scrum doesn’t prescribe engineering practices </li></ul><ul><ul><li>so we go looking elsewhere </li></ul></ul><ul><li>XP provides engineering practices </li></ul><ul><ul><li>But they’re eXtreme. </li></ul></ul><ul><li>FDD provides engineering practices </li></ul><ul><ul><li>Simple </li></ul></ul><ul><ul><li>Evolutionary, not revolutionary </li></ul></ul><ul><ul><li>Can augment Scrum with proven, best practice practices (And can also be used on independently of Scrum) </li></ul></ul>
  36. 36. Q&A <ul><li>Thank you! </li></ul>