• Save
Leading agile product development
Upcoming SlideShare
Loading in...5
×
 

Leading agile product development

on

  • 564 views

My agile product development training set.

My agile product development training set.

Please visit http://improvementstory.net

Statistics

Views

Total Views
564
Views on SlideShare
564
Embed Views
0

Actions

Likes
2
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Autonomy - Self-direction\nMastery - Flow, Learning-Goal, Grittiness,\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

Leading agile product development Leading agile product development Presentation Transcript

  • LEADING AGILEPRODUCT 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 permission
  • ForewordThis is my training course targeted to project and product managers interested in Agile and Lean. It’s a collection of known best practices and personalmethods and models that have all been utilized and proven in real-world product development challenges.My guidance to anyone participating the course or readingthis material is to explore and find their own views of Agileand Lean best practices, possibly with the help of concepts presented herein. 2
  • MOVING TO AGILE & LEAN
  • "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 4
  • Agile Lean FitiStock royalty-free photo iStock royalty-free photoDealing with complexity iStock royalty-free photo Focusing on Value Re-innovating Value 5
  • Agile is about understanding the problem and finding the right solution via exploration. Traditional AgilePresumed Problem Unknown Problem Understood Right Planned Solution Problem Solution Inspect-Adapt OODA PDCA 6
  • 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-functionalScope-constrained Unconstrained Time-constrained 7
  • All organizational transformations, including agile, require a combined top-down & bottom-up approach. Top-down providesrequired alignment for thetransition 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. 8
  • Functions learn to collaborate Effectivenesswith development and take benefitof early and regular releases. FunctionsDevelopment organizationlearns to exploit change and investin continuous improvement. Development OrganizationTeams learn to plan and deliver Teamin a steady cadence. Efficiency 9
  • Customers, Partners Intimacy Focus on value Functions Collaboration Project / Project / Development DevelopmentTransparency Organization Organization Team Team Team Team Cadence 10
  • An inwards-oriented An outwards-oriented organization focus is on control of organization focus is on customeractivity 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. 11
  • Management has a crucial role in Agileworld but it requires to re-innovate itself. Value Creation Enablement Management Old orthodoxyThose who do not create value directlythemselves enable the others to do so. 12
  • Command & Control FAILMotivation Skill Efficiency Focus Agile Leadership Style 13
  • 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 andwith exceeding commitments resource efficiency first(utilization etc). 14
  • My definition of business/organization agility..Problem scenario: market moves Agile scenario: product developmentfaster 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/ 15
  • DIFFERENCE OF AGILE & WATERFALL
  • 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”) 17
  • 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 18
  • 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 19
  • The problem with waterfall is.. Risk is not reduced “Planning”Changeability isreduced over time Development Testing Visibility builds late Learning collected at the end 20
  • Agile solves this problem by reducing batch size of how the software is developedChangeability 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 21
  • Schedule and Resources act as constraints (control variables) to Scope. Resources Schedule Schedule controls the delay for expected value. Scope Value Cost of DelaySecondary 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. 22
  • 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 LearningRelease 1 Release 2 Release 3 Release 4 23
  • Planning Planning activity itself is iterative & incremental. Changes during development are Release 2 Release 3 Release X reflected in current and future releaseDevelopment plans. Agile potential is unlocked with interaction between Release 1 Release 2 planning and Release 3 development. 24
  • CONTINUOUSLY IMPROVING (BY ELIMINATING WASTE)
  • 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 26
  • 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. 27
  • CREATING A FLOW
  • Variability and capacity utilization Manufacturing both impact the queue size: process Variability has linear impact Utilization has exponential impactVariability 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 29
  • Average Cycle time Wait-in- Wait-in- Wait-in- queue development release Product Development process ReleaseDesign inventory Feature inventoryAdopted from Donald G. Reinertsen, The Principles of Product Development Flow 30
  • Business value Release Feedback Product valueDevelopment Release Feedback effort Effort turns into value only when it is released. Value is understood only by feedback generated of a release. 31
  • Traditional single-iteration, scope-constrained, large batch project.. A Long Development Project (Late) Value RealizationAgile 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. 32
  • PLANNING PRODUCTS
  • 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 otherFollowing 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). 34
  • 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. 35
  • 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. 36
  • 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 FMore 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 37
  • Optimized product plan Unoptimized product plan Epic 1 F FEpic 1 F F F F F F Epic 2 F FEpic 2 F F F F F F Epic 3 F FIn unoptimized plan, epics (value) Epic 4 F Fis 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. 38
  • 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 39
  • 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 valuableCould-have Could-have Could-have candidates or “extra”. Won’t-have’s we’ve Won’t have decided to left out. 40
  • OPTIMIZING BACKLOG
  • We don’t want overly complicated and costlysolutions compared to the size of the problem. Problem Problem Solution Solution But instead innovative and effective solutions that solve a more valuable problem. 42
  • 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 withStory Problem production solution. Further down the chain problems and solutions become Solution more technical reaching lowest interest point, tasks a solution. 43
  • Solution needs to be definedin 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 ofchecked for integrity as it was Solution Solution Solution a completely new solution. 44
  • Sensitivity analysis on changing problem andsolution definition may reveal better opportunities. Bigger Original Original Problem Problem Problem Value : Cost Ratio Smaller Solution Original Slightly Bigger Solution Solution 45
  • 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 46
  • PLANNING RELEASES AND ROADMAPS
  • The highest level of the backlog in the Product BacklogTime and release orientedlevel of backlog is know as Release Backlog Within a release the delivery plan is known as the Sprint Plan (or Sprint Backlog) 48
  • Visual planning helps to identify the constraints and their impact overthe 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. 49
  • 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 50
  • V1 V2 V1 Total value: 4 Epic 1C2 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 51
  • AGILE ROLES & OWNERSHIP
  • 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 lorenimpsum Sprint 1 Sprint 2 Sprint 3 lorenimpsum 53
  • Upholds Scrum Process Sprints DemosScrum Master Retrospective Daily-standupPromotes Agile Culture Protects the Team Team 54
  • Seeks to maximize the product value Team loren impsum loren impsum loren impsum loren loren impsum impsum loren impsum Continuously analyzes andSelf-organizes the tasks to improves the working practices meet Sprint goals Team Team 55
  • Governs constraints of the project to meet business goals. Project Master Aligns priorities of the Coaches collaboration andorganization 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 56
  • CREATING AGILE TEAMS
  • Software project is a creative process that takes place in a people-centric system Quality of collaboration greatly impacts the quality of result 58
  • 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. 59
  • If you wish to be agile, make sure your team is motivated by the challenge itself. Complex Home of Adaptive Intrinsic AgilePredictive Extrinsic Simple Adopted from “Drive” by Daniel H. Pink 60
  • 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 TeamHowever, for self-organizing to be effective, clear boundaries in a form of constraints are required to steer the efforts. 61
  • Self-organizing TeamAutonomy Mastery Purpose Craftsmanship Adopted from “Drive” by Daniel H. Pink 62
  • 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 63
  • 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. 64
  • Gradual team-driven commitment to growth provides successful on-time delivery from the beginning. 22 25 24 25 20Whereas non-committed goals result in missed deadlines, failed expectations and bad atmosphere. 28 26 25 24 25 20 22Funny enough, the team achieves the same result in both scenarios. It’s just a matter of perspective. 65
  • AGILE DEVELOPMENT PROCESSES
  • Product Owner Definition of Workable Definition of DoneAcceptance 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 67
  • Kanban board visualizes the flow of effort towards value. Todo In Progress Done Definition Work in Definition ofof Workable Progress Limit Done 68
  • Work progress is monitored in a form of a burn-down chart Remaining effortStart of Sprint End of Sprint 69
  • Scrum of Scrums (2nd level) Scrum of Scrums (1st level)Daily Scrum Team Team Team Team Team 70
  • 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 growiteratively & incrementally. Sprint 1 Sprint 2 Retro provides a feedback loop allowing Team Team the team to grow iteratively & incrementally. 71
  • SCALING AGILE
  • Horizontal scaling refers to scaling a larger product backlog to several teams. Product Owner ProductProduct Owner Product Owner Product Owner Product Product Product Team Team Team Team Team 73
  • Vertical scaling refers toscaling 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 74
  • One product = One Product Backlog One product = Synchronized Cadence Team Scrum Master is in the Team Product Owners are close to BusinessScrum Master Product Owner(s) Product Team Team BacklogScrum Master Scrum Master 75
  • Hierarchical, Separated Nonhierarchical, Separated ProductArchitecture driven 1 1.1 1.2 1.1.1 1.1.2 1.2.1 1.2.2 Feature Specialists Hierarchical, Joint Nonhierarchical, JointTop-level driven “Product Council” 1 1.1 1.2 1.1.1 1.1.2 1.2.1 1.2.2 76
  • QUALITY IN AGILE
  • 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. 78
  • Bug Bug Bug Bug Collecting an inventory of bugs can be more time consuming than fixing them - and youBug Bug Bug Bug would still have the bugs.Bug Bug Bug Bug Agile Quality Management principle: ✓ Decide fast per found bug - fix or notBug Bug Bug Bug ✓ Decentralize decision making ✓ Involve the team and product ownerBug Bug Bug Bug and not only tester or developer ✓ Use economic thinking when decidingBug Bug Bug Bug - every effort taken is an investment away from something elseBug Bug Bug Bug ✓ Not every bug needs to be fixed - only the necessary ones.Bug Bug Bug Bug 79
  • Found issues Resolved issues Total number of issues Three critical quality effort60 trends: (1) how many issues we find (2) how many we resolve45 (3) how many there’s in total in inventory30 Three focus areas: (1) find issues early with declining trend of new issues15 (2) resolve issues (3) keep inventory small and steady 0Sprint 1 Sprint 2 Sprint 3 Sprint 4 80
  • AGILE GOVERNANCE (COMING UP)
  • AGILE LEADERSHIP STYLE (COMING UP)
  • METRICS IN AGILE (COMING UP)
  • Arto SaariLinkedIn:http://fi.linkedin.com/pub/arto-saari/b/b03/546Blog:http://improvementstory.netTwitter:http://twitter.com/#!/ImprovStory 84