lessons for large scale lean and agile product development - atlassian summit 2012

©2011 Bedarra Research Labs. All rights reserved.

Atlassian Summit 2012

Lessons for Large Scale Lean and Agile Product Management

Dave Thomaswww.davethomas.net

Bedarra Research Labs, YOW and GOTO Conferences Queensland University of Technology

and Carleton University

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


1. Do Lean Assessment to establish a baseline

2. Establish Realistic Expectations for Capacity, Predictability, Quality and Productivity

3. Plan for Systemic Change over 12 -18+ months; Establish a Change Management Plan – Governance, Careers, Communications, Facilities, Transition Team ...

4. Streamline Portfolio Backlogs through Envisioning

5. Implement CI and Automated Measurement Infrastructure; Invest in an inventory of automated tests

6. Implement Lean Organization with a strong Technical Ladder

7. Provide everyone appropriate Training/Mentoring and Tooling

8. Focus on Tangible Acceptance Criteria, Business Value and Estimates

9. Align and resource Feature and Component Teams

10. Learn and adapt from experience, both yours and coaches

Top 10 List for a Large Transition


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 organization needed his leadership

Change Model

Will be greatI’m not sure

This sucks?

aha

It Works!


Relationship between Development Team and ManagementRelationship between Development Team and Management

Agile Commitments

Successful development requires trust and transparency between customer/management and supplier/development

Need to foster a “works with” instead of “works for” relationship

Working With

Management

VisionCommunication

CoordinationCoaching

Managing Scope

Development

PredictabilityQualityVisibility

Discipline


Key Changes in a Typical Transition

1. 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! …



2. 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



3. 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


People over ProcessIt is About Values!


Drive: The Surprising Truth About What Motivates Us

by Daniel Pink

PurposeAutonomyMastery

Leadership Matters... Has integrity and stands by values

Has the wisdom of experienceArticulates the vision (metaphor)

Executes with transparencyLeads by example

Delegates authorityCoaches versus directs

Makes timely consistent decisionsHas a good sense of humour

Says when they are wrongPositively motivates and educates

Judges fairly, promotes trustPromotes constructive diversity

Always tries to find the best wrong answer


“Agile Leadership is Fragile” Nigel Dalton LP

Executive

Technical Director

Team Leader

Individual Contributors…

Individual Contributor…

Management Ladder

Lean Software OrganizationTechnical Ladders, Playing Coaches and Communities

DistinguishedEngineer

PrincipalEngineer

OutstandingContributor

Technical Ladder


ManagementArchitects

Leads

CustomerProduct

MgrTools

ProcessInfrastructure

PlatformsCoaches

ReleaseDeployment

SupportTest

DrivenDevelopment

Products

Learning COIs

Align Compensation with Work Products and Goals

Sustainable PaceIt 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

Visualize Flow – Put It On The Wall You Can Only Improve what You Can Measure

ArtifactStatus ReportingStatus of artifacts such as personas, problems, use scenarios, stories

Subjective ReportingQualitative data entered by teams at retrospectives

CI EnvironmentReportingStatus of stories written, stories completed, tests written, tests passed and tests failed

Query & Reporting

Cumulative Flow

Retrospective Reports

Unit and Story Tests


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


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

....


Requirements?!

Testing?!

It’s All in Backlogs! Evidence for Action Lumpy Stories – sizes, estimates, clarity

Story Rework Due To Changing Requirements

Uncompleted Stories

Story Rework Due to Integration Problems

Missing Important Functionality

Done but not usable, poor performance

Done doesn’t mean acceptance tested?

More stories keep getting added to the backlog

Lack of business Value/Tangibility

Blocked on Another Team

Blocked waiting on Product Owner

All resources 100% + allocated


Lean and Agile Values and Principles

Large-Scale AIL Development Activities At-A-Glance

Envisioning

Product Owner Team Common Work Practices

Definition Development ReleaseEngineering

Prototypes/Models

Requirements Backlog

Risk Backlog

Team… Team…

GUI Guidelines

Architecture

Product Backlog

Release Backlogs

Team…

Team…

Team…

Team…

PotentiallyShippableProduct

TeamReleaseBacklog

ShippableCodeIncrements

SprintReleaseBacklogs

CI&T

CI&T

©2006-2007 Bedarra Research Labs and Object Mentor

10% of overall effort

Envisioning

Competitive DeltaAnalysis

Practices Brainstorming & visioning Competitive analysis (SWOT) Delta analysis QFD Customer studies Hardware, platform & component evals Prototyping/modeling

Deliverables Requirements backlog Risk backlog Analysis & Verification Reports Prototypes/Models Look-and-Feel Guidelines

RequirementsBacklog

RiskBacklog

Customer FieldStudies & Interviews

TechnologyEvaluations

Prototypes& Models

GUIGuidelines

Market & ProductAnalysisBrainstorming

& Visioning

QFDHouse of Quality

Prototyping Deliverables

AcceptanceCriteria

Envisioning develops a clear product vision /roadmap to deliver the right product to the right market using the right technology through consultation with users and choosers.

AIL Portfolio (Backlogs)Program Feature Team

P1 F1 Blue

F2 Blue

F3 Red

F4 Red

F5 Red

F6 Red

P2 F7 Yellow

F8 Green

F9 Green

F10 Purple

F11 Purple

P3 F12 White

F13 White

F14 White

F15 White

Component F16 Orange

F17 Orange

F18 Orange

Company Backlog

Program Backlogs

Team Backlogs

Program

Feature

Epic

Story

Task

MRI Mechanical Control

Table Movement

Horizontal Movement

Medical Imaging

Position w/ Joy Sticks

Estimates – Do Them Fast and Often

Collectively Owned By Team 2 or 3 point estimates to

include uncertainty All items in backlog AIL uses Ideal Days Planning Poker (wide band

delphi)

1 Point

2 point

3 point

Low, Medium, High

RelativePoints

IdealDays

Program and Feature Estimation Planning

ProductBacklog

ProductReleaseBacklog

Scrum 3

ProductReleaseBacklog

Scrum 2

Scrum 1ReleaseBacklog

Sprint 3

Sprint 2

Sprint 1Backlog

Feature Team builds backlog containing list of feature with a first estimate.

Features are allocated to a specific release. A release is a 3-6 sprint time box.

The scrum team refines the features into work items called stories, divides the stories into sprints, and prepares a second estimate. The estimates are compared and consensus is reached thru discussion.

Based on discussion, work items may be moved from one sprint to another sprint, moved from one team to another, deferred to another release.

Dev Estimation, Negotiation, and CommitmentFeature and Program Estimation

Activity Based Estimates – Managing Risk for Large Projects

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

Activity Estimate

Risk Window

Feature and Component Teams Coordination.

ComponentC

ComponentB

ComponentA

Feature Epic

Component Epics

Component 3

Feature A Priority 1

Feature B Priority 2

Feature C Priority 3

Component 1 Component 2

Feature A Work

Feature C Work

Feature B Work

Feature A&B Work

Feature C Work

Feature A Work

Successful Software Development is about a Winning Culture

Software 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.

lessons for large scale lean and agile product development - atlassian summit 2012

Business

last2011 bedarra research

change change

systemic change

agile embracing change

wrong way common vocabulary

lean organization

key changes

large scale lean