Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Leading Agile Product Development

9.684 Aufrufe

Veröffentlicht am

My agile product development training slideset.

Please visit http://improvementstory.net

Veröffentlicht in: Business, Technologie

Leading Agile Product Development

  1. 1. LEADING AGILE PRODUCT DEVELOPMENT By Arto Saari v. 1.0 beta5 It has been my sincere aim to respect all copyrights and reference the authors as appropriate. If however you feel I’ve not succeeded in some aspect of this, kindly contact me and allow to me correct my error. Thank you. Used by permissionSaturday, November 19, 2011
  2. 2. Foreword This is my training course targeted to project and product managers interested in Agile and Lean. It’s a collection of known best practices and personal methods and models that have all been utilized and proven in real-world product development challenges. My guidance to anyone participating the course or reading this material is to explore and find their own views of Agile and Lean best practices, possibly with the help of concepts presented herein. 2Saturday, November 19, 2011
  3. 3. MOVING TO AGILE & LEANSaturday, November 19, 2011
  4. 4. "Dont know what I want, but I know how to get it." - Johnny Rotten, Sex Pistols http://www.agileproductdesign.com/blog/dont_know_what_i_want.html 4Saturday, November 19, 2011
  5. 5. Agile Lean Fit iStock royalty-free photo iStock royalty-free photo Dealing with complexity iStock royalty-free photo Focusing on Value Re-innovating Value 5Saturday, November 19, 2011
  6. 6. Agile is about understanding the problem and finding the right solution via exploration. Traditional Agile Presumed Problem Unknown Problem Understood Right Planned Solution Problem Solution Inspect-Adapt OODA PDCA 6Saturday, November 19, 2011
  7. 7. When making the transition, don’t get off the train at Ad-hoc station. X V Traditional Ad-hoc Agile Linearized Chaotic Complexity-aware Plan-driven Reactive Adaptive Disciplined and Specialized Undisciplined cross-functional Scope-constrained Unconstrained Time-constrained 7Saturday, November 19, 2011
  8. 8. All organizational transformations, including agile, require a combined top-down & bottom-up approach. Top-down provides required alignment for the transition to happen on all dimensions of the Bottom-up creates the organization operative foundation for new product development principle. Agile capability grows bottom-up to the full potential limited only by the incompatible management principle of organization layers. 8Saturday, November 19, 2011
  9. 9. Functions learn to collaborate Effectiveness with development and take benefit of early and regular releases. Functions Development organization learns to exploit change and invest in continuous improvement. Development Organization Teams learn to plan and deliver Team in a steady cadence. Efficiency 9Saturday, November 19, 2011
  10. 10. Customers, Partners Intimacy Focus on value Functions Collaboration Project / Project / Development Development Transparency Organization Organization Team Team Team Team Cadence 10Saturday, November 19, 2011
  11. 11. An inwards-oriented An outwards-oriented organization focus is on control of organization focus is on customer activity and improvement of internal value and market opportunities. performance metrics. It is very possible that majority of the Unnecessary control is replaced by organization is supervising the trust. minority that creates the value. 11Saturday, November 19, 2011
  12. 12. Management has a crucial role in Agile world but it requires to re-innovate itself. Value Creation Enablement Management Old orthodoxy Those who do not create value directly themselves enable the others to do so. 12Saturday, November 19, 2011
  13. 13. Command & Control FAIL Motivation Skill Efficiency Focus Agile Leadership Style 13Saturday, November 19, 2011
  14. 14. Traditionally organizations consider efficiency as ‘best-practices’ like .. Thinking good overall results come from functional excellence (locally optimizing organization) Efficiency comes from Interfacing between large batches stakeholders over non- collaborative documents Competing in the market Optimizing on cost and with exceeding commitments resource efficiency first (utilization etc). 14Saturday, November 19, 2011
  15. 15. My definition of business/organization agility.. Problem scenario: market moves Agile scenario: product development faster than product development cycle as able to fit inside the market cycle Market cycle Market Cycle Product development Product development cycle Cycle Business Agility is the capability of your company to exploit shortening market cycles instead of being victimized by them uncontrollably. Read more about it here: http://improvementstory.net/2011/10/18/what-is-enterprise-agility-my-definitive-answer/ 15Saturday, November 19, 2011
  16. 16. DIFFERENCE OF AGILE & WATERFALLSaturday, November 19, 2011
  17. 17. Whether your next project is a success or a failure is not a matter of change but the matter of choice (Mentioned by Bill Gaiennie as a quote by “Anonymous wise agile coach”) 17Saturday, November 19, 2011
  18. 18. Traditional Development Project Agile Development Project The things we’re The whole big thing we Level 1: Vision identified to be done to have planned to do meet the success Task Task DL Level 2: Product backlog (Feature breakdown) Task Task Level 3: Release plan (Time breakdown) Time-box 1 Time-box 2 Level 4: Sprint plan Story (Work breakdown) Task 18Saturday, November 19, 2011
  19. 19. Waterfall is everywhere.. ..in process models Phase 1 Phase 2 Phase 3 ..in structures ..in organization Requirement Function A Level 1 As waterfall is one- Requirement directional relationship, Function B lacking early and continuous Level 2 co-dependent validation. Requirement Function C Level 3 19Saturday, November 19, 2011
  20. 20. The problem with waterfall is.. Risk is not reduced “Planning” Changeability is reduced over time Development Testing Visibility builds late Learning collected at the end 20Saturday, November 19, 2011
  21. 21. Agile solves this problem by reducing batch size of how the software is developed Changeability much Visibility builds with less if at all reduced each batch “Planning” “Planning” “Planning” Development Development Development Testing Testing Testing Learning collected and used Risk reduced by every batch within the project 21Saturday, November 19, 2011
  22. 22. Schedule and Resources act as constraints (control variables) to Scope. Resources Schedule Schedule controls the delay for expected value. Scope Value Cost of Delay Secondary focus how well Primary focus is on amount of scope translates to value value and the impact of delay Risk Scope is the source of both Risks associates to both value value and risk. expectation and cost of delay as increased uncertainty. 22Saturday, November 19, 2011
  23. 23. We iterate to improve We increment to get the solution based on the solution earlier and be learning and feedback. able to change plans. Feedback Learning Release 1 Release 2 Release 3 Release 4 23Saturday, November 19, 2011
  24. 24. Planning Planning activity itself is iterative & incremental. Changes during development are Release 2 Release 3 Release X reflected in current and future release Development plans. Agile potential is unlocked with interaction between Release 1 Release 2 planning and Release 3 development. 24Saturday, November 19, 2011
  25. 25. CONTINUOUSLY IMPROVING (BY ELIMINATING WASTE)Saturday, November 19, 2011
  26. 26. Waste As listed by Mary & Tom Poppendieck: Extra steps Information finding Handovers Task-switching Defects (not caught) Extra Features Waiting Photo by Crimson (Pieter Janssen), used by Creative Commons license on site www.dreamstime.com 26Saturday, November 19, 2011
  27. 27. Wall of Waste Wall of Improvements Waste € Waste Improvement Improvement € Visualization and radiating both waste and improvements help the organization to collaborate on development. Quantification in monetary impact gives correct weight and priority. 27Saturday, November 19, 2011
  28. 28. CREATING A FLOWSaturday, November 19, 2011
  29. 29. Variability and capacity utilization Manufacturing both impact the queue size: process Variability has linear impact Utilization has exponential impact Variability in (a) “service time” and (b) “arrival time” (a) Product Agile is all about absorbing Development and exploiting this variability (b) process for the benefit of the product. Adopted from Donald G. Reinertsen, The Principles of Product Development Flow 29Saturday, November 19, 2011
  30. 30. Average Cycle time Wait-in- Wait-in- Wait-in- queue development release Product Development process Release Design inventory Feature inventory Adopted from Donald G. Reinertsen, The Principles of Product Development Flow 30Saturday, November 19, 2011
  31. 31. Business value Release Feedback Product value Development Release Feedback effort Effort turns into value only when it is released. Value is understood only by feedback generated of a release. 31Saturday, November 19, 2011
  32. 32. Traditional single-iteration, scope-constrained, large batch project.. A Long Development Project (Late) Value Realization Agile multi-iteration, time-constrained, small batch project.. Release 1 (Early) Value Realization Release 2 (Added) Value Realization Release 3 (Optional) Value Realization Staged delivery realizes value earlier, reduces risk and increases control and agility on all levels. 32Saturday, November 19, 2011
  33. 33. PLANNING PRODUCTSSaturday, November 19, 2011
  34. 34. Leffingwell’s product abstraction defined three abstraction levels: Epics, Features and Stories Each level as co-dependent relationship i.e. one cannot exist without the other Following is my personal adaptation of the structure: Epics are the value-context of development: Epic they are what we want to achieve. Features provide the solution to Epic and are beyond Feature optimal solution a cost-factor. Features we need to do. Stories extend the feature solution and provide link to Story stakeholder value (users, providers etc). 34Saturday, November 19, 2011
  35. 35. Optimization towards (Epic) value context provides maximum product development potential. Epic (=business value) € Features (=investment to gain business value) € Value efficiency = Maximized epic value delivered with optimal feature cost. 35Saturday, November 19, 2011
  36. 36. Prioritization of Epics and Features can be done in a matrix in which vertical prioritization is based on Epic value and horizontal on feature priority. More important towards the Epic Epic 1 F F F F F F Epic 2 F F F F F F More value per Epic Epic 3 F F F F F F Epic 4 F F F F F F Two queues can be formed out of the matrix: Epic queue and internal Feature queue. 36Saturday, November 19, 2011
  37. 37. F Features in top-left are most valuable More important towards the Epic Epic 1 F F F F F F Epic 2 F F F F F F More value per Epic Epic 3 F F F F F F Epic 4 F F F F F F While features in the bottom-right will not F be likely ever done 37Saturday, November 19, 2011
  38. 38. Optimized product plan Unoptimized product plan Epic 1 F F Epic 1 F F F F F F Epic 2 F F Epic 2 F F F F F F Epic 3 F F In unoptimized plan, epics (value) Epic 4 F F is produced in large, slow batches of unnecessary features (waste) In optimized plan, epics are delivered via a core set of features and released in a quick cadence. 38Saturday, November 19, 2011
  39. 39. Level 1: Unorganized backlog Level 2: Prioritized backlog Top-priority Level 3: Groomed backlog loren loren impsum impsum loren loren impsum impsum loren loren loren impsum impsum impsum loren loren loren impsum impsum impsum loren impsum loren impsum 39Saturday, November 19, 2011
  40. 40. Backlog prioritization is an on-going Prioritization model should be both process on all backlog levels, simple and meaningful peaking at the start of a cycle. Must-have Must-have’s we don’t release without. Should-have’s we aim to Should-have Should-have maximize per delivery. Could-have’s are valuable Could-have Could-have Could-have candidates or “extra”. Won’t-have’s we’ve Won’t have decided to left out. 40Saturday, November 19, 2011
  41. 41. OPTIMIZING BACKLOGSaturday, November 19, 2011
  42. 42. We don’t want overly complicated and costly solutions compared to the size of the problem. Problem Problem Solution Solution But instead innovative and effective solutions that solve a more valuable problem. 42Saturday, November 19, 2011
  43. 43. Problem Product structure can be viewed as a chain of Problem-Solution pairs. Solution Epic Each of the abstraction layers Problem contains both a solution to upper layer and poses a problem requiring a Solution solution on lower layer. Feature Problem On top-level there is a business Solution problem that is being addressed with Story Problem production solution. Further down the chain problems and solutions become Solution more technical reaching lowest interest point, tasks a solution. 43Saturday, November 19, 2011
  44. 44. Solution needs to be defined in full to match the problem Part of Part of Part of Solution Solution Solution before it may be optimized reductively. Part of Part of Part of Solution Solution Solution New composition of the solution requires it to be Part of Part of Part of checked for integrity as it was Solution Solution Solution a completely new solution. 44Saturday, November 19, 2011
  45. 45. Sensitivity analysis on changing problem and solution definition may reveal better opportunities. Bigger Original Original Problem Problem Problem Value : Cost Ratio Smaller Solution Original Slightly Bigger Solution Solution 45Saturday, November 19, 2011
  46. 46. time PDCA-cycle Original Better Problem-Solution Problem Defined Correct definition evolves over Problem Problem time and requires full recheck periodically (preferably between Optimal sprints) to validate the Improved Original Solution optimal solution to Solution Solution correct problem. CHECK CHECK CHECK 46Saturday, November 19, 2011
  47. 47. PLANNING RELEASES AND ROADMAPSSaturday, November 19, 2011
  48. 48. The highest level of the backlog in the Product Backlog Time and release oriented level of backlog is know as Release Backlog Within a release the delivery plan is known as the Sprint Plan (or Sprint Backlog) 48Saturday, November 19, 2011
  49. 49. Visual planning helps to identify the constraints and their impact over the expected result. The strongest constraint is time, second resources, as combination Resources Over Time. Prioritized, ordered flow of features FEATURE FEATURE FEATURE FEATURE FEATURE .... R R R R R R R R R Resource constraint to next release Reserve Risk of uncertainty and ability to do incremental change can be achieved by holding some of the R R R R resources in reserve. 49Saturday, November 19, 2011
  50. 50. Epics can be used to model value offering to customers which each require certain Features realized in a set of Solutions. F F Solution Epic 1 Value Offering Customers F F Solution Epic 2 50Saturday, November 19, 2011
  51. 51. V1 V2 V1 Total value: 4 Epic 1 C2 C5 C3 Total High-level road-mapping using Epics complexity: 10 can be done by identifying simple Features value and complexity points to give them comparability and character. V2 V3 Total value: 5 Complexity is elaborated into Epic 2 features at later stages of planning. C1 C2 C2 Total complexity: 5 Features 51Saturday, November 19, 2011
  52. 52. AGILE ROLES & OWNERSHIPSaturday, November 19, 2011
  53. 53. Transfers the product vision Team Product Owner Grooms backlog Plans releases loren loren impsum impsum loren loren impsum impsum Release 1 loren loren loren impsum impsum impsum loren loren loren impsum impsum impsum loren impsum Sprint 1 Sprint 2 Sprint 3 loren impsum 53Saturday, November 19, 2011
  54. 54. Upholds Scrum Process Sprints Demos Scrum Master Retrospective Daily-standup Promotes Agile Culture Protects the Team Team 54Saturday, November 19, 2011
  55. 55. Seeks to maximize the product value Team loren impsum loren impsum loren impsum loren loren impsum impsum loren impsum Continuously analyzes and Self-organizes the tasks to improves the working practices meet Sprint goals Team Team 55Saturday, November 19, 2011
  56. 56. Governs constraints of the project to meet business goals. Project Master Aligns priorities of the Coaches collaboration and organization into the project and ownership of stakeholders (Product Owner, Business Owner, Scrum Masters, vice versa. Teams etc) loren loren impsum impsum loren loren impsum impsum 56Saturday, November 19, 2011
  57. 57. CREATING AGILE TEAMSSaturday, November 19, 2011
  58. 58. Software project is a creative process that takes place in a people-centric system Quality of collaboration greatly impacts the quality of result 58Saturday, November 19, 2011
  59. 59. Putting random people together and calling it “a team” is a management fallacy Also, individual ? competences do not ? Fundamentally, add up to team teams build them selves. competence 1:1 As managers, we create the hot-bed for great teams to emerge. 59Saturday, November 19, 2011
  60. 60. If you wish to be agile, make sure your team is motivated by the challenge itself. Complex Home of Adaptive Intrinsic Agile Predictive Extrinsic Simple Adopted from “Drive” by Daniel H. Pink 60Saturday, November 19, 2011
  61. 61. Self-organizing is an agile principle in which the team finds the necessary tasks and processes to reach the goal. Boundaries (Constraints) Self-organizing Goal Team However, for self-organizing to be effective, clear boundaries in a form of constraints are required to steer the efforts. 61Saturday, November 19, 2011
  62. 62. Self-organizing Team Autonomy Mastery Purpose Craftsmanship Adopted from “Drive” by Daniel H. Pink 62Saturday, November 19, 2011
  63. 63. Why does self-organizing fail so often? Unorganized group of people Autonomy Mastery Purpose Individual and collective Organization culture fails to purpose for the activity is cater intrinsic motivation missing Responsibility of the team performance has not been in the team 63Saturday, November 19, 2011
  64. 64. Prediction of result is derived from team velocity. It tells us how much the team is producing. 42 38 36 38 38 38 Known velocity is better than expected velocity. This is why tracking of performance and estimation accuracy are crucial. Team A 42 ? Team B 32 ? Team C 35 ? And when team composition is changed the velocity changes. 64Saturday, November 19, 2011
  65. 65. Gradual team-driven commitment to growth provides successful on-time delivery from the beginning. 22 25 24 25 20 Whereas non-committed goals result in missed deadlines, failed expectations and bad atmosphere. 28 26 25 24 25 20 22 Funny enough, the team achieves the same result in both scenarios. It’s just a matter of perspective. 65Saturday, November 19, 2011
  66. 66. AGILE DEVELOPMENT PROCESSESSaturday, November 19, 2011
  67. 67. Product Owner Definition of Workable Definition of Done Acceptance criteria that a backlog Acceptance criteria that a backlog item must pass before it can be item must pass before it can be worked on by the Team. delivered to Product Owner. Team 67Saturday, November 19, 2011
  68. 68. Kanban board visualizes the flow of effort towards value. Todo In Progress Done Definition Work in Definition of of Workable Progress Limit Done 68Saturday, November 19, 2011
  69. 69. Work progress is monitored in a form of a burn-down chart Remaining effort Start of Sprint End of Sprint 69Saturday, November 19, 2011
  70. 70. Scrum of Scrums (2nd level) Scrum of Scrums (1st level) Daily Scrum Team Team Team Team Team 70Saturday, November 19, 2011
  71. 71. Between sprints, team shows demonstration of the product based on sprint results & performs a retrospective on working methods. Demo provides a loren loren feedback loop allowing impsum impsum loren loren impsum impsum the product to grow iteratively & incrementally. Sprint 1 Sprint 2 Retro provides a feedback loop allowing Team Team the team to grow iteratively & incrementally. 71Saturday, November 19, 2011
  72. 72. SCALING AGILESaturday, November 19, 2011
  73. 73. Horizontal scaling refers to scaling a larger product backlog to several teams. Product Owner Product Product Owner Product Owner Product Owner Product Product Product Team Team Team Team Team 73Saturday, November 19, 2011
  74. 74. Vertical scaling refers to scaling agile towards higher levels Within clusters individual teams work on a of product management. Flow of Features Team Team Team Team cluster A Epic Epic Epic Team Team Clustering teams Team allows them to work on a Team cluster B Flow of Epics 74Saturday, November 19, 2011
  75. 75. One product = One Product Backlog One product = Synchronized Cadence Team Scrum Master is in the Team Product Owners are close to Business Scrum Master Product Owner(s) Product Team Team Backlog Scrum Master Scrum Master 75Saturday, November 19, 2011
  76. 76. Hierarchical, Separated Nonhierarchical, Separated Product Architecture driven 1 1.1 1.2 1.1.1 1.1.2 1.2.1 1.2.2 Feature Specialists Hierarchical, Joint Nonhierarchical, Joint Top-level driven “Product Council” 1 1.1 1.2 1.1.1 1.1.2 1.2.1 1.2.2 76Saturday, November 19, 2011
  77. 77. QUALITY IN AGILESaturday, November 19, 2011
  78. 78. Product owner is responsible of the product - and its level of quality. Product Owner The expected level of quality is agreed between the product owner and the team. Quality principles may be embedded to Team backlog items in a form of acceptance criteria.. ..and by the team in their definition of done. 78Saturday, November 19, 2011
  79. 79. Bug Bug Bug Bug Collecting an inventory of bugs can be more time consuming than fixing them - and you Bug Bug Bug Bug would still have the bugs. Bug Bug Bug Bug Agile Quality Management principle: ✓ Decide fast per found bug - fix or not Bug Bug Bug Bug ✓ Decentralize decision making ✓ Involve the team and product owner Bug Bug Bug Bug and not only tester or developer ✓ Use economic thinking when deciding Bug Bug Bug Bug - every effort taken is an investment away from something else Bug Bug Bug Bug ✓ Not every bug needs to be fixed - only the necessary ones. Bug Bug Bug Bug 79Saturday, November 19, 2011
  80. 80. Found issues Resolved issues Total number of issues Three critical quality effort 60 trends: (1) how many issues we find (2) how many we resolve 45 (3) how many there’s in total in inventory 30 Three focus areas: (1) find issues early with declining trend of new issues 15 (2) resolve issues (3) keep inventory small and steady 0 Sprint 1 Sprint 2 Sprint 3 Sprint 4 80Saturday, November 19, 2011
  81. 81. AGILE GOVERNANCE (COMING UP)Saturday, November 19, 2011
  82. 82. AGILE LEADERSHIP STYLE (COMING UP)Saturday, November 19, 2011
  83. 83. METRICS IN AGILE (COMING UP)Saturday, November 19, 2011
  84. 84. Arto Saari LinkedIn: http://fi.linkedin.com/pub/arto-saari/b/b03/546 Blog: http://improvementstory.net Twitter: http://twitter.com/#!/ImprovStory 84Saturday, November 19, 2011