Collaboration at Scale: Distributed Team Release Planning11-Jan-2017

Collaboration at Scale

Designed for Scrum-centric organizations with more than 10 Scrum teams, the Collaboration at Scale webinar series provides focused, outcome-driven solutions to collaboration problems faced by Product Owners, ScrumMasters, and Development Teams.

Produced by the Scrum Alliance and Conteneo, Inc., we’re proud of the many distinguished experts who share their wisdom in our series.

Luke Hohmann

Kevin Rosengren

2-4 WEEK SPRINT

DAILY SCRUM MEETING

(EVERY 24 HOURS)

POTENTIALLY SHIPABLE PRODUCT INCREMENT

SPRINT BACKLOGPRODUCT BACKLOG

3

Common Scrum Challenges

Tech Debt

Release Planning

Roadmap

Retros

Liftoffs

Refining

Value Based

Backlogs

Priorities

Depend-encies

Done, Done

CI/CD

Feb 2017: Identifying

Requirements

4

POLL QUESTION

How often are you releasing?

• Continuously

• Weekly

• Monthly

• Every 3 months

• Every 6 months

• Yearly

• Not sure…

5

POLL QUESTION

How often are you planning for releases?

• Continuously

• Weekly

• Monthly

• Every 3 months

• Every 6 months

• Yearly

• Not sure…

Agenda

1 What is a Release Plan?

2 Release Planning Event: Preparation

3 Distributed Release Planning: Techniques

4 Avoiding Release Planning Pitfalls

5 Case Study

6

Luke Hohmann

Kevin Rosengren

What is a Release Plan?

7

A release plan is a high level plan

for achieving releasable value

(typically across multiple sprints).

Which PBIs will be tackled in which Sprint?

Release Plans are mid-level tactics on the Agile Planning Time Horizon

Daily

Sprint

Strategy

Portfolio

Product

Release

Exec

PM

DevTeam

1-4 wks

2-9 mos

1 – 3 years

years

many years

Sprint Backlog

Portfolio Map

Release Plan

Vision & Roadmap

OrgLevel Planninglevel TimeHorizon Artifact

One Backlog to Rule Guide Them All!

10

Team 2

New FeatureUser story

nnn

Bug FixEnhancement

nnn

User StoryUser Story

nnn

PO Team 3

Team 4

Team 1

Team 5

PO

PO

Team 6

Distributed teams may have local POs but there is one backlog.

CAS Nov 2016: Backlogs

Release Plans emerge from strong product backlogs through Release Planning events

11

Release Planning Meetings are often 1-3 days!

PO

PO

Release Planning is a Contact Sport

12

Release Planning Event: PreparationConfirm VisionPrepare BacklogUnderstand team distribution Schedule the meetings

13

14

POLL QUESTION

What is the nature of your distribution structure?

• PO in one location, Team in another

• Members of teams in different locations

• Whole teams in different locations

Well defined backlogs begin with shared Product Vision

15

Product Box

Cover Story

Try it online:bit.ly/weave-cover-story

A Release Planning Ready Product Backlog

• Well groomed• Prioritized based on value• Ready, Ready• May be sized...

16My Backlog...

PO in one location, Team(s) in another

17

POTrack time zonesConfirm tools

PO in one location, Team Split

18

PO

Track time zonesConfirm tools

All of the Above!

19

PO

ProductManager

PO

Track time zonesConfirm toolsExpect check-ins

Determine “Work Allocation Strategy”

20

Customer CentricFeature Teams

Component Teams

Infrastructure / Service Teams

Making a Distributed Release Planning Event Successful

21

Topics To Cover

22

Share / Confirm Product Vision

Review Top Backlog Items / Cutline

Parcel / Work to Teams / Local POsTeams Engage in Release PlanningConfirm Local Release Plans

Integrate Release Plans & Confirm Windows

Celebrate – and Start Sprinting!

Share Vision and Essential PBIs

23

Distribute PBIs to Teams

24

A. New Feature B. User StoryC. Bug FixD. EpicE. User StoryF. User StoryG. Tech ChangeH. New Feature I. User StoryJ. Bug FixK. EpicL. User StoryM. User Story

…

A. New Feature C. Bug FixE. User StoryH. New Feature M. User Story

B. User StoryI. User StoryK. EpicL. User Story

D. EpicF. User StoryG. Tech ChangeJ. Bug Fix

Teams Estimate Via Planning Poker

25

A. New Feature 8C. Bug Fix 2E. User StoryE.1. -------- 3E.2. --------- 2E.3. ------------ 2E.5. --------- 1E.6. --------- 2E.7. ---------- 3H. New FeatureH.1. ---- 3H.2. ---- 3H.3. ---- 3H.4. ---- 2M. User Story 8

ReleasePlanning Poker

Refine Stories

13

2 5

8

13

21

50

A. New Feature C. Bug FixE. User StoryH. New Feature M. User Story

Add Integration Stories à CI/CD

26

http://devops.com/2015/03/03/i-want-to-do-continuous-deployment/

Normal Backlog Item

Integration Story

CAS Aug 2016: Dependencies

Teams Allocate Work Into Sprints Via Velocity

27

A. New Feature 8C. Bug Fix 2E. User StoryE.1. -------- 3E.2. --------- 2E.3. ------------ 2E.5. --------- 1E.6. --------- 2E.7. ---------- 3IntegrationH. New FeatureH.1. ---- 3H.2. ---- 3H.3. ---- 3H.4. ---- 2M. User Story 8

Sprint Sprint Sprint

A

C

E.1

E.2

E.3

E.5

E.6

E.7

I

Sprint

H.1

H.2

H.3

Sprint

H.4

Remember to Estimate a Release Window

28

• Estimate a low and a high “steady state”

velocity

• Calculate release window

• Add an appropriate buffer

• The difference between low & high is

your market window

• Analyze relative to roadmap & backlog

and adjust accordingly

Attributes of Effective Release Plans

29

Attributes of High-Impact Release Plans

30

1 – 4 months Good!

5 – 8 months - Warning

9+ months? DANGER

Sprint Sprint Sprint Sprint Sprint

Risk

Avoiding Release Planning Pitfalls

31

Pitfall: Deferring Architecture/Infrastructure

Symptoms: • Release plans are “incremental” with no “iteration”• Technical debt appears to be increasing• Architectural improvements continually deferred

Resolution: • Identify architectural improvements

via Prune the Product Tree• Ensure they are added to roadmap• Ensure they are integrated into backlog

32Try it online:bit.ly/ptpt-with-roots

Pitfall: Relentless Releasing

Symptoms: • Scrum is no longer fun• Little or no time for exploration• Little or no learning / experimentation

Resolution: • Schedule a Sprint between releases for:

• Exploration• Learning• Entropy Reduction• “Little Stuff Adds Up”

33

Pitfall: Forgetting Humanity

Symptoms: • One team always bears the brunt of early/late meetings• One team always gets “the same kind of work”

Resolution: • Adjust / alternative timing of Scrum ceremonies• Establish local autonomy• Encourage even more self-organization in release planning

34

Case Study: Conteneo Weave 1.0

35

Our Motivations Were Easy

36

We Design Jammed with Customers

37

We “Design Jammed”With Customers!

We Design Jammed with Customers

38

We Listened and Explored Concepts

39So, just how many things need to be improved in the current project organizer…?

Pinterest for Frameworks?

We Created Entirely New Story Maps

40We covered User Story Maps in the

CAS Nov 2016 Webinar.

Goals

TasksHow we do it now

How we can make it better…

We Developed Goals and Guidelines

• Single Page “App” for smoother, faster loads• Consistent iconography for all actions• Layout guidelines• “Always have something to do”• Separation of framework from forums

(long story short: No framework clones!)• Pinterest-style UI for frameworks • Remove unused public frameworks• Ensure all existing data “just works” while paving the way for even

more future awesomeness

41

Weave 1.0 Original Release plan

42

DashboardFrameworks

SchedulingPart 1

Scheduling& Projects

FrameworkCleanup

FunTune

December 2016

Weave 1.0 Adjusted Release Plan

43

DashboardFrameworks

SchedulingPart 1

Scheduling& Projects

FrameworkCleanup

FunTune

23-Jan-2017

Security Fixes

A routine security audit identified three opportunities for improvements. Enterprise-grade security is important so we immediately allocated 1.5 Sprints to push out these security improvements.

Summary

44

Creating a release plan ishard work.

But it is absolutely worth it!

What do you want for the Mar 2017 webinar?

• Impact Mapping • Distributed Team Liftoffs / Kickoffs• Building Alignment and Empathy• Building a ScrumMaster Community of Practice • Keeping Retrospectives Fresh• Identifying Customer/Stakeholder Requirements• My desired topic isn’t listed – email luke.hohmann@conteneo.co

46

POLL QUESTION

Special Webinar! 18-Jan-2016 bit.ly/2jBNeKp

Collaborating with Thousands to Millions of Stakeholders to Prioritize City Budgets and Grow Communities

Through the last several months, the Collaboration at Scale webinar series has been exploring how you can augment core Scrum practices with frameworks that enable large, typically distributed teams to tackle a wide variety of problems.

In this special session of the Collaboration at Scale webinar series, we are going to explore how these frameworks — when guided by the values of both the Agile Manifesto and Scrum — give us the ability to tackle problems at societal scale. We're going to explore Participatory Budgeting, a process created in Latin America in which ordinary citizens directly control portions of the city budget.

We're also going to explore how cities like San José, CA are adapting frameworks like Prune the Product Tree to solicit feedback from the residents on how all members and stakeholders within the community — residents, companies and others — can help their community, district and city grow.

You'll gain a fresh perspective on how you can use your skills to improve your practice of Scrum and help tackle complex societal problems. 47

Discussions

48

Thank you for attending.

Our next webinar is 15-Feb-2017 on Identifying Customer/Stakeholder Requirements.

http://bit.ly/2iDMbFw

Luke Hohmannconteneo.co

Kevin Rosengrenappliedframeworks.com