HC SVNT DRACONES*

*here be dragons scaling agile

An unofficial set of tips and insights

into how to implement Scrum well

ScrumSense

Written by Certified Scrum Coach & Trainer Peter Hundermark

Do Better Scrum

Version 3

Completely Revised

& Updated

peter hundermark!peterhundermark

frame

1. why do we scale? 2. laws of scaling 3. scaling patterns 4. digestion and feedback

1. why do we scale?

surveyturn to your neighbour: ๏ how many people in your organisation are currently

involved in a scaled agile product development or project delivery effort?

๏ how successful have your scaling efforts been so far?

prepare for a call-out in 2 mins

??successes?

fewer people more people

worse outcomes

better outcomes

a) big product

we are building and sustaining a product that needs

more than 9 people

b) portfolio of products

we are building and sustaining a portfolio of

products and projects that involves many people

c) many customer projectswe have lots of customer <projects>

that do not each need a full-sized team

just put them all into one backlog!not a scaling problem

d) multiple locations

we have a distributed team

this is a communication

problem!not a scaling problem

2. laws of scaling

1st law of scaling

do not scale!

2nd law of scaling

when you scale, you scale everything— the good and the bad1

1 courtesy marius de beer

3rd law of scaling

the only way to go fast is to go well2

2 uncle bob martinhttp://programmer.97things.oreilly.com/wiki/index.php/Speed_Kills

3. scaling patterns

conway's lawOrganizations which design systems are constrained to produce designs which are copies of the communication structures

of these organizations

Organizations which design systems are constrained to produce designs which are copies of the communication structures

of these organizations

larman's laws1. organizations are implicitly optimized to avoid

changing the status quo...positions and power structures

2. as a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo

3. as a corollary to (1), any change initiative will be derided as purist, theoretical...which defects from addressing weaknesses...

4. culture follows structurehttp://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior

scaling anti-patterns?SAFe DAD other snake oil...

Rather consider: LeSS (Larman and Vodde) ScALeD (scaledprinciples.org) Enterprise Transition Framework (agile42)

10 scaling patterns that work (for me)

1) feature teams

minimise cross-dependency between teams therefore— form long-lived feature teams rather than component teams. ensure each team is cross-functional

This requires organisational restructure!

2) one backlog

shorten queuing times for the waiting work therefore— feed multiple, synchronised teams from a single backlog managed by an empowered product owner/manager

3) synchronised sprints

exploit scale economies of multiple teams therefore— synchronise sprints for multiple teams. use joint planning and reviews

4) fast feedbackkeep feedback loops short therefore— ensure all teams' outputs are tested and integrated into the increment every sprint. work to eliminate constructs like 'integration' or 'hardening' sprints

5) slack

retain slack to achieve flow therefore— allow teams to pull from the backlog, based on their observed capacity. challenge teams to finish early

6) no silos

reduce skill silos and dependencies within teams therefore— use osmotic communication and pairing to grow empathetic T-shaped people

7) optimise the whole

optimise your entire portfolio therefore— visualise and manage your product and project portfolio. measure outcomes at the highest possible level and let teams seek on their own local solutions

Try using Portfolio Kanban

http://www.klausleopold.com/2013/07/kanban-and-its-flight-levels.html

8) qualitypay attention to quality therefore— ensure 'technical debt' is reducing, not increasing. fix errors as soon as they are found

9) communication

pay attention to communication therefore— institute formal meetings to synchronise teams

SoS is NOT a meeting of Scrum Masters!

10) learning

pay attention to learning therefore— form communities of practice for different disciplines to share learning. hold large group retrospectives on a longer cadence (e.g. for releases). read books. get professional help

ten scaling patterns1) feature teams

2) one backlog

3) synchronised sprints

4) fast feedback

5) slack

6) no silos

7) optimise the whole

8) quality

9) communication

10)learning

๏ what resonates with me? ๏ what could I apply?

digest input in small groups each group provides two sentences of feedback

4. digestion and feedback

7'

takeaways

➡ be clear what you are scaling and why ➡ the only way to go fast is to go well ➡ don't be lured by scaling snake oil ➡ understand and apply the 10 scaling patterns ➡ read some books ➡ get professional help

gerald weinberg's second law of consulting:

no matter how it looks at first, it's always a people problem

Ambler, Scott M. and Lines, Mark (2012). Disciplined Agile Delivery: A Practitioners’ Guide to Agile Software Delivery in the Enterprise. IBM Press.

Anderson, David J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.

Conway, Melvin (1968). Conway’s Law. http://www.melconway.com/Home/Conways_Law.html.

Coplien, James O. and Harrison, Neil B. (2005). Organisational Patterns of Agile Software Development. Pearson Prentice Hall.

De Beer, Marius (2012). Data-driven Agility: An analysis of Agile adoption in North American Organisations. http://www.scrumsense.com/downloads/data-driven-agility.pdf.

DeMarco, Tom (2001). Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Dorset House Publishing.

Hackman, J. Richard (2002). Leading Teams. Harvard Business School Press.

Hackman, J. Richard (2011). Collaborative Intelligence. Berrett-Koehler.

Hundermark, Peter (2014). Do Better Scrum (Version 3). http://www.scrumsense.com/resources/do-better-scrum/

Kniberg, Henrik (2008). Multi-Team Sprint Planning. http://www.scrumalliance.org/system/resource_files/0000/0871/Multi-Team-Sprint-Planning.pdf.

Kniberg, Henrik and Ivarsson, Anders (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify.

Kniberg, Henrik (2014). Spotify Engineering Culture (Part 1 of 2). http://vimeo.com/85490944.

Kniberg, Henrik (2014). Spotify Engineering Culture (Part 2 of 2). http://vimeo.com/94950270.

Larman, Craig and Vodde, Bas (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig and Vodde, Bas (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig (2013). Larman’s Laws of Organizational Behavior. http://www.craiglarman.com/wiki/index.php?title=Larman's_Laws_of_Organizational_Behavior

Larsen, Diana (2004). Team Agility: Exploring Self-Organizing Software Development Teams. http://www.futureworksconsulting.com/resources/TeamAgilityAgileTimesFeb04.pdf.

Leffingwell, Dean (2013). Scaled Agile Framework. http://scaledagileframework.com/.

Manns, Mary Lynn and Rising, Linda (2004). Fearless Change: Patterns for Introducing New Ideas. Addison Wesley.

Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.

Rothman, Johanna (2009). Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. Pragmatic Programmers.

Schein, Edgar H. (2010). Organisational Culture and Leadership. Fourth Edition. Jossey-Bass.

Spielhofer, Thomas (2014). More than LeSS. http://www.infoq.com/articles/more-than-less.

Tabaka, Jean (2006). Collaboration Explained | Facilitation Skills for Software Project Leaders. Addison-Wesley Professional.

Weisbord, Marvin; Janoff, Sandra (2007). Don’t Just Do Something, Stand There! Ten Principles for Leading Meetings that Matter. Berrett-Koehler Publishers.

selected references

the end

!peterhundermark #sgza

www.scrumsense.com