Lessons for Large Scale Lean and Agile Product Development - Atlassian Summit 2012


Published on

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • reduced gap external expertscustomer exposure brings tangible requirementsexecutive exposure brings business tangibilityshort delivery always increases trust put it on the walk – transparency increases trustwhole teams increase trust and break silostimely decision increase trust
  • Lessons for Large Scale Lean and Agile Product Development - Atlassian Summit 2012

    1. 1. Atlassian Summit 2012 Lessons for Large Scale Lean and Agile Product Management Dave Thomas www.davethomas.net Bedarra Research Labs, YOW and GOTO Conferences Queensland University of Technology and Carleton University©2011 Bedarra Research Labs. All rights reserved.
    2. 2. Agenda Ten Point Plan for Transitioning to Agile Embracing Change People over Process Sustainable Pace Improving Backlogs Through Envisioning Estimates in The Large Coordinating Feature and Component Teams©2011 Bedarra Research Labs. All rights reserved.
    3. 3. Top 10 List for a Large Transition1. Do Lean Assessment to establish a baseline2. Establish Realistic Expectations for Capacity, Predictability, Quality and Productivity3. Plan for Systemic Change over 12 -18+ months; Establish a Change Management Plan – Governance, Careers, Communications, Facilities, Transition Team ...4. Streamline Portfolio Backlogs through Envisioning5. Implement CI and Automated Measurement Infrastructure; Invest in an inventory of automated tests6. Implement Lean Organization with a strong Technical Ladder7. Provide everyone appropriate Training/Mentoring and Tooling8. Focus on Tangible Acceptance Criteria, Business Value and Estimates9. Align and resource Feature and Component Teams10. Learn and adapt from experience, both yours and coaches ©2011 Bedarra Research Labs. All rights reserved.
    4. 4. Embrace Change Change is easy if you are not doing it!Change is hard if you want to, impossible if you don’t! A Natural-Born ‘Leader’ Emerges... apparently self Change Model It Works! organization needed his leadership Will be great I’m not sure aha©2011 Bedarra Research Labs. All rights reserved. This sucks?
    5. 5. Agile CommitmentsSuccessful development requires trust and transparency between customer/management and supplier/developmentNeed to foster a “works with” instead of “works for” relationshipRelationship between Development Team and Management Management Development Vision Predictability Communication Working With Quality Coordination Visibility Coaching Discipline Managing Scope©2011 Bedarra Research Labs. All rights reserved.
    6. 6. Key Changes in a Typical Transition1. Accept that there is a “software physics” Finite capacity … You can’t build what you don’t understand or can’t test You can’t do new design/feature in a release time box You can’t build components and dependent applications in the same time box The only hard decision is what you are NOT going to do Done means acceptance tested! … ©2011 Bedarra Research Labs. All rights reserved.
    7. 7. Key Changes in a Typical Transition2. Directing and Managing => Leadership and Coaching Work With versus Work For – Coaching versus Directing Increased self discipline for teams and individuals who own deliverables, quality and schedule Increased individual ownership with associated responsibility and accountability Leadership owns and manages risk Executive and Management Coaching ©2011 Bedarra Research Labs. All rights reserved.
    8. 8. Key Changes in a Typical Transition3. My Way => The Best Same Wrong Way Common vocabulary, practices applied sensibly and metrics aligned with practices Make sure everyone knows one way before fixing it Improve process each release of the company i.e. triage process/practice/tools defects like other defects Encourage teams to have their way which is still consistent with the best wrong way selected ©2011 Bedarra Research Labs. All rights reserved.
    9. 9. People over Process It is About Values! Drive: The Surprising Truth About What Motivates Us by Daniel Pink Purpose Autonomy Mastery©2011 Bedarra Research Labs. All rights reserved.
    10. 10. Leadership Matters... Has integrity and stands by values Has the wisdom of experience Articulates the vision (metaphor) Executes with transparency Leads by example Delegates authority Coaches versus directs Makes timely consistent decisions Has a good sense of humour Says when they are wrong Positively motivates and educates Judges fairly, promotes trust Promotes constructive diversity Always tries to find the best wrong answer “Agile Leadership is Fragile” Nigel Dalton LP©2011 Bedarra Research Labs. All rights reserved.
    11. 11. Lean Software Organization Technical Ladders, Playing Coaches and Communities Management Ladder Learning COIs Executive Technical Ladder Distinguished Management Customer Technical Director Engineer Architects Product Leads Mgr Principal Tools Individual Release Products ProcessTeam Leader Engineer Contributor… Deployment Infrastructure Support Platforms Test Individual Outstanding Coaches Driven Contributors… Contributor Development Align Compensation with Work Products and Goals ©2011 Bedarra Research Labs. All rights reserved.
    12. 12. Sustainable Pace It is all about Flow and What Constrains It Use Common Language Use a Common Tool Chain Leverage Whole Teams Ensure Transparency Ensure Tangibility Manage to your Capacity Identify and Remove Waste Automate and Measure Everything Decide Fast and Consistently Design for Change, Build to Last ©2011 Bedarra Research Labs. All rights reserved.
    13. 13. Visualize Flow – Put It On The Wall You Can Only Improve what You Can Measure Artifact Status Reporting Status of artifacts such as personas, problems, use scenarios, stories Cumulative Flow CI Environment Reporting Status of stories written, Query & stories completed, tests Reporting written, tests passed and tests failed Unit and Story Tests Subjective Reporting Qualitative data entered by teams at retrospectives Retrospective Reports©2011 Bedarra Research Labs. All rights reserved.
    14. 14. Effective Metrics Need to be Visible to the Enterprise Respect the Organization API • Portfolio Process • Program/Project Process • Financial Reporting • HR Processes • Infrastructure and Deployment Process • LDAP... Treat them as customer requirements and ensure the work to support them is visible ©2011 Bedarra Research Labs. All rights reserved.
    15. 15. We love Agile Development BUT ...There are really just a couple of problems Productivity Quality Predictability/Estimates Management of Expectations Product Owners Availability Reduce Owner Burnout Requirements Churn Portfolio Management Reduce Rework Reduce Integration Costs Not Collocated ....©2009 Bedarra Research Labs. All rights reserved.
    16. 16. It’s All in Backlogs! Evidence for ActionLumpy Stories – sizes, estimates, clarityStory Rework Due To Changing RequirementsUncompleted StoriesStory Rework Due to Integration ProblemsMissing Important FunctionalityDone but not usable, poor performanceDone doesn’t mean acceptance tested?More stories keep getting added to the backlogLack of business Value/TangibilityBlocked on Another TeamBlocked waiting on Product OwnerAll resources 100% + allocated©2009 Bedarra Research Labs. All rights reserved.
    17. 17. Large-Scale AIL Development Activities At-A-GlanceLean and Agile Values and PrinciplesProduct Owner Team Common Work PracticesEnvisioning Definition Development Release EngineeringTeam… Team… Team… Team… CI&TPrototypes/Models ArchitectureRequirements Product Backlog Team Sprint ShippableBacklog Release Release Code CI&T Backlog Backlogs IncrementsRisk Backlog Team… Potentially Shippable Product Release Backlogs Team…GUI Guidelines ©2006-2007 Bedarra Research Labs and Object Mentor
    18. 18. EnvisioningEnvisioning develops a clear product vision /roadmap to deliver the rightproduct to the right market using the right technology through consultation withusers and choosers. 10% of overall effort Prototypes & Models Market & Product Requirements Technology AnalysisBrainstorming Backlog Evaluations & Visioning Deliverables Prototyping Competitive Delta Risk Analysis Acceptance Criteria Backlog Customer Field QFD Studies & Interviews House of Quality GUI Guidelines Practices Deliverables  Brainstorming & visioning  Competitive  Requirements backlog  Risk analysis (SWOT)  Delta analysis  QFD backlog  Analysis & Verification  Customer studies  Hardware, platform & Reports  Prototypes/Models component evals  Prototyping/modeling  Look-and-Feel Guidelines
    19. 19. AIL Portfolio (Backlogs)Program Feature Team Company Backlog P1 F1 Blue Program Backlogs F2 Blue F3 Red Team Backlogs F4 Red F5 Red F6 Red Program Medical Imaging P2 F7 Yellow F8 Green Feature MRI Mechanical Control F9 Green F10 Purple Epic Table Movement F11 Purple P3 F12 White Story Horizontal Movement F13 White F14 White Task Position w/ Joy Sticks F15 White Component F16 Orange F17 Orange F18 Orange
    20. 20. Estimates – Do Them Fast and OftenCollectively Owned By Team 2 or 3 point estimates to include uncertainty 3 point All items in backlog 2 point AIL uses Ideal Days 1 Point Planning Poker (wide band delphi) Low, Relati Ideal Medium, ve Days High Point s
    21. 21. Program and Feature Estimation Planning Feature and Program Estimation Dev Estimation, Negotiation, and CommitmentFeature Team Features are The scrum team refines Based on discussion,builds backlog allocated to the features into work work items may becontaining list a specific items called stories, moved from one sprintof feature with release. A divides the stories into to another sprint,a first release is a 3-6 sprints, and prepares a moved from one teamestimate. sprint time second estimate. The to another, deferred to box. estimates are compared another release. and consensus is reached thru discussion. Product Scrum 1Product Sprint 1 Release ReleaseBacklog Backlog Backlog Backlog Product Scrum 2 Sprint 2 Release Backlog Scrum 3 Sprint 3
    22. 22. Activity Based Estimates – Managing Risk for LargeProjects Activity Examples Worst Best Expected Likely Java Code (classes, methods) Interface Pricing Table (table size) Process (steps) Product/Data Definition (Tables/Fields) Rules (Decision Table (conditions/rules) Forms (screens, widgets) Printed Forms (page types, widgets) Story Estimate Risk Window Activity Estimate
    23. 23. Feature and Component Teams Coordination. Feature Epic Component Component Component A B C Component Epics Component 1 Component 2 Component 3 Feature A Priority 1 Feature A Work Feature A&B Work Feature A Work Feature B Priority 2 Feature B Work Feature C Priority 3 Feature C Work Feature C Work
    24. 24. Successful Software Development is about a Winning CultureSoftware is a team sport, and like all team sports practice, constructive peer feedback, and coaching are essential.Winning teams need to implicitly know the moves of each player, as well as the movements of the team as whole.The ultimate expression of process is a culture where building software is more like playing jazz. People Just Do It! Thanks!©2011 Bedarra Research Labs. All rights reserved.