Upload
peter-hundermark
View
331
Download
4
Embed Size (px)
DESCRIPTION
Scaling agile in organisations is not a trivial thing. It is not only about process but also about leadership and organisational culture. I share 3 laws and 10 patterns that have found helpful.
Citation preview
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