Leading Agile Product Development

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

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 ﬁnd their own views of Agile and Lean best practices, possibly with the help of concepts presented herein. 2Saturday, November 19, 2011

MOVING TO AGILE & LEANSaturday, November 19, 2011

"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

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

Agile is about understanding the problem and ﬁnding 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

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

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

Functions learn to collaborate Effectiveness with development and take beneﬁt 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. Efﬁciency 9Saturday, November 19, 2011

Customers, Partners Intimacy Focus on value Functions Collaboration Project / Project / Development Development Transparency Organization Organization Team Team Team Team Cadence 10Saturday, November 19, 2011

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

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

Command & Control FAIL Motivation Skill Efﬁciency Focus Agile Leadership Style 13Saturday, November 19, 2011

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

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

DIFFERENCE OF AGILE & WATERFALLSaturday, November 19, 2011

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

Traditional Development Project Agile Development Project The things we’re The whole big thing we Level 1: Vision identiﬁed 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

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

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

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

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

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

Planning Planning activity itself is iterative & incremental. Changes during development are Release 2 Release 3 Release X reﬂected 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

CONTINUOUSLY IMPROVING (BY ELIMINATING WASTE)Saturday, November 19, 2011

Waste As listed by Mary & Tom Poppendieck: Extra steps Information ﬁnding 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

Wall of Waste Wall of Improvements Waste € Waste Improvement Improvement € Visualization and radiating both waste and improvements help the organization to collaborate on development. Quantiﬁcation in monetary impact gives correct weight and priority. 27Saturday, November 19, 2011

CREATING A FLOWSaturday, November 19, 2011

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 beneﬁt of the product. Adopted from Donald G. Reinertsen, The Principles of Product Development Flow 29Saturday, November 19, 2011

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

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

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

PLANNING PRODUCTSSaturday, November 19, 2011

Lefﬁngwell’s product abstraction deﬁned 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

Optimization towards (Epic) value context provides maximum product development potential. Epic (=business value) € Features (=investment to gain business value) € Value efﬁciency = Maximized epic value delivered with optimal feature cost. 35Saturday, November 19, 2011

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

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

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

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

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

OPTIMIZING BACKLOGSaturday, November 19, 2011

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

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

Solution needs to be deﬁned 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

Sensitivity analysis on changing problem and solution deﬁnition may reveal better opportunities. Bigger Original Original Problem Problem Problem Value : Cost Ratio Smaller Solution Original Slightly Bigger Solution Solution 45Saturday, November 19, 2011

time PDCA-cycle Original Better Problem-Solution Problem Deﬁned Correct deﬁnition 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

PLANNING RELEASES AND ROADMAPSSaturday, November 19, 2011

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

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 ﬂow 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

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

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

AGILE ROLES & OWNERSHIPSaturday, November 19, 2011

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

Upholds Scrum Process Sprints Demos Scrum Master Retrospective Daily-standup Promotes Agile Culture Protects the Team Team 54Saturday, November 19, 2011

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

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

CREATING AGILE TEAMSSaturday, November 19, 2011

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

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

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

Self-organizing is an agile principle in which the team ﬁnds 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

Self-organizing Team Autonomy Mastery Purpose Craftsmanship Adopted from “Drive” by Daniel H. Pink 62Saturday, November 19, 2011

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

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

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

AGILE DEVELOPMENT PROCESSESSaturday, November 19, 2011

Product Owner Deﬁnition of Workable Deﬁnition 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

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

Work progress is monitored in a form of a burn-down chart Remaining effort Start of Sprint End of Sprint 69Saturday, November 19, 2011

Scrum of Scrums (2nd level) Scrum of Scrums (1st level) Daily Scrum Team Team Team Team Team 70Saturday, November 19, 2011

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

SCALING AGILESaturday, November 19, 2011

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

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

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

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

QUALITY IN AGILESaturday, November 19, 2011

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 deﬁnition of done. 78Saturday, November 19, 2011

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

Found issues Resolved issues Total number of issues Three critical quality effort 60 trends: (1) how many issues we ﬁnd (2) how many we resolve 45 (3) how many there’s in total in inventory 30 Three focus areas: (1) ﬁnd 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

AGILE GOVERNANCE (COMING UP)Saturday, November 19, 2011

AGILE LEADERSHIP STYLE (COMING UP)Saturday, November 19, 2011

METRICS IN AGILE (COMING UP)Saturday, November 19, 2011

Arto Saari LinkedIn: http://ﬁ.linkedin.com/pub/arto-saari/b/b03/546 Blog: http://improvementstory.net Twitter: http://twitter.com/#!/ImprovStory 84Saturday, November 19, 2011

Leading Agile Product Development

by Arto Saari on Nov 19, 2011

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Leading Agile Product Development Presentation Transcript