Your SlideShare is downloading. ×
Leading Agile Product Development
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Leading Agile Product Development

5,418
views

Published on

My agile product development training slideset. …

My agile product development training slideset.

Please visit http://improvementstory.net

Published in: Business, Technology

4 Comments
14 Likes
Statistics
Notes
  • @MartyW You can download pdf-version from here: http://db.tt/26GA6rD
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • @MartyW Hi Marty, please feel free to use them. If you could promote my blog as part of the training, improvementstory.net, that would be great.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I would like to discuss the use of your materials for educational purposes.
    Marty Wartenberg
    Engineering and Information Technology
    UCI
    mrwarten@uci.edu
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Please visit my blog at http://improvementstory.net
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
5,418
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
4
Likes
14
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. 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. MOVING TO AGILE & LEANSaturday, November 19, 2011
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. Command & Control FAIL Motivation Skill Efficiency Focus Agile Leadership Style 13Saturday, November 19, 2011
  • 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. 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. DIFFERENCE OF AGILE & WATERFALLSaturday, November 19, 2011
  • 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. 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. 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. 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. 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. 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. 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. 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. CONTINUOUSLY IMPROVING (BY ELIMINATING WASTE)Saturday, November 19, 2011
  • 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. 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. CREATING A FLOWSaturday, November 19, 2011
  • 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. 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. 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. 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. PLANNING PRODUCTSSaturday, November 19, 2011
  • 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. 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. 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. 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. 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. 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. 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. OPTIMIZING BACKLOGSaturday, November 19, 2011
  • 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. 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. 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. 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. 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. PLANNING RELEASES AND ROADMAPSSaturday, November 19, 2011
  • 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. 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. 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. 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. AGILE ROLES & OWNERSHIPSaturday, November 19, 2011
  • 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. Upholds Scrum Process Sprints Demos Scrum Master Retrospective Daily-standup Promotes Agile Culture Protects the Team Team 54Saturday, November 19, 2011
  • 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. 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. CREATING AGILE TEAMSSaturday, November 19, 2011
  • 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. 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. 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. 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. Self-organizing Team Autonomy Mastery Purpose Craftsmanship Adopted from “Drive” by Daniel H. Pink 62Saturday, November 19, 2011
  • 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. 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. 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. AGILE DEVELOPMENT PROCESSESSaturday, November 19, 2011
  • 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. 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. 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. Scrum of Scrums (2nd level) Scrum of Scrums (1st level) Daily Scrum Team Team Team Team Team 70Saturday, November 19, 2011
  • 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. SCALING AGILESaturday, November 19, 2011
  • 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. 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. 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. 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. QUALITY IN AGILESaturday, November 19, 2011
  • 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. 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. 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. AGILE GOVERNANCE (COMING UP)Saturday, November 19, 2011
  • 82. AGILE LEADERSHIP STYLE (COMING UP)Saturday, November 19, 2011
  • 83. METRICS IN AGILE (COMING UP)Saturday, November 19, 2011
  • 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