Mirror mirror on the wall....(preamble to 1 of 4)

John Coleman does an opinion piece on scaling patterns and none

Consider this blog post as background for future posts. It has a lot of detail, and you might need to carve out some time, grab a cup of coffee and get comfortable before reading this.

I can't say I'm any better than anyone else in terms of selecting patterns (or none) for multiple teams that are attempting agility. I hope this opinion piece is based on what I experienced (or similar) as opposed to what I believe. Your experience could be different. If you cast your own views here I can re-post the results for comparison, only answer for the patterns you feel confident to answer, just leave the rest. And while you're at it, maybe you can tell me why you want to grow agility? Starting with why (and how we got here) is important. This post is kicking off a series on the how notwithstanding context.

Assume for all options that trending measures (outcome-based) are available. Assume that something like Scrum.org's Evidence Based Management is being used or that people will find out what's going on by looking "walking the gemba" and/or going to something like sprint reviews. We know that some impossible things are difficult to measure, e.g., cooperation, we can just take a view on it.

I picked some measures. I borrowed from the 3 ways from The Phoenix Project (https://www.infoq.com/news/2013/10/devops-3-ways). I borrowed Right to Left, Outside In, and Upside Down from Agendashift (https://www.agendashift.com/right-to-left). Maybe you can think of other measures. Depending on your preference for particular measures, different patterns look "better".

Make no mistake though, as a mentor of mine told me in 2013, usually something "inferior" done well in the right spirit is better than something "superior" done badly (mechanically at best, was not even half done at worst). Indeed, another wise person told me this week, aiming too high can raise the chances of failure. The words "right" and "wrong" are inappropriate. As Eckhart Tolle says in The Power of Now, "what's good is bad, and what's bad is good".

The goal of this article is to discuss the usefulness of patterns for synchronizing multiple teams. Nail it before you scale it as my PST peer David Dame says. Most agilists worth their salt would say get the best people and let them crack on with it, and if you must get bigger, grow rather than scale. When things grow, some things die away and need to be pruned, some get stronger, and some things grow out of nowhere in a jiffy. As Leandro Herrero says, (me paraphrasing) no revolution waited until all the ducks were lined up and everyone was on board. The graphic below is just my opinion. I have no axe to grind. To my mind autonomy and alignment are great, and other things can be as important.

We are spoiled for choice on how to deal with more than 2 Scrum teams. I'll only list a few that I have been exposed to:

1. SAFe as per www.scaledagileframework.com

2. Scrum @ Scale as per https://www.scruminc.com/scaling_scrum/

3. Large Scale Scrum (LeSS) as per less.works

4. Pulse as per http://gopulse.org/

5. Nexus as per https://www.scrum.org/resources/scaling-scrum and Scrum Studio as per https://www.scrum.org/resources/scrum-studio-model-innovation - two flavours

6. Copy, paste & adapt what's on 2012 Spotify videos as per https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf - two flavours

7. Kanban as per www.leankanban.com/guide also including Enterprise Services Planning as gleaned from information in the public domain

8. Prince II Agile as per https://www.axelos.com/best-practice-solutions/prince2-agile/what-is-prince2-agile

9. Disciplined Agile as per http://www.disciplinedagiledelivery.com/

10. WaterScrumFall or Dark Scrum or Zombie Scrum as per https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment

11. (Non-Waterfall) Scrum of Scrums as per https://www.agilealliance.org/glossary/scrum-of-scrums

12. Flow as per https://www.flow-academy.org/

13. no pattern at all, closest to John Seddon's Beyond Command & Control (or XP) which I summarize as #AgileFrameworksSuck #NoBacklogs (effectively going back to the values and principles of the Agile Manifesto).

I won't explain each option. I'll just comment on the pros & cons as I see them, on the assumption that each option is implemented as the author intended (at least from my mental models). Curious about thoughts out there...

The Scaled Agile Framework (SAFe®) helps businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time. It is a freely revealed, online knowledge base of proven success patterns, for people building the world’s most important software and systems. SAFe synchronizes alignment, collaboration, and delivery for multiple Agile teams. Scalable and configurable, SAFe allows each organization to adapt it to its own business needs. It supports smaller-scale solutions employing 50 – 125 practitioners, as well as complex systems that require thousands of people. Copyright © Scaled Agile, Inc.

My experience - supporting teams in a major company so they could "fit into" their major client's SAFe implementation with Kanban.

(+) Pros	(-) Cons
case studies at https://www.scaledagileframework.com/case-studies/	Planning for 4 iterations ahead goes against empiricism
strongest for alignment with non-team roles	Release train tends to de-emphasise (slice of cake) feature teams, the bias is that the release train is cross-component so why do we need feature teams? a tendency towards large bets
strong at alignment up to 1,000s of people	too many roles, a recipe for clarification of roles & responsibilities over "fuzziness" (imagine that word being said in Yves Morieux's wonderful French accent)
Release Train idea under Dunbar number, Solution Train Idea to maintain Dunbar numbers, Supplier narrative	Scrum is corrupted by SAFe, the Product Owner is disempowered (a million miles from CEO of the product)
Lean Finance is going in the Beyond Budgeting(BB) direction, if like BB it's light in detail	a tendency to move forward with large bets in progress, less tendency to implement experiments
Scrum/XP/Kanban at team level - interestingly Scrum.org's PSK is helpful here	system team integrates, hopefully already integrated as Continuous Integration not emphasised strongly enough
Has a simple version - Essential SAFe	overwhelming
Is it better than WaterScrumFall? I think so, by a mile.	fails to satisfy Cynefin Sense-Making Framework
WSJF is a nonsense formula as it makes a leap from Don Reinertsen's Cost of Delay work with no explanation why make that leap (look looking a mathematical formula with missing steps, because there are no steps), yet it makes sense from a human perspective as we need some sorting that we can fix manually.	Scrum Masters co-ordinating instead of self-organizing teams
With Kanban potentially at every level, and XP also at the team level	The top level of (full) SAFe is its weakest level potentially, which most project portfolio mindset organizations need to be strongest. Business units might need their own instances of SAFe, and there are no known bridges between those. Perhaps, that will come.
SAFe slack in IP iteration helps flow	a Release Train is a group of people, Team of Teams is only implemented though unstable teams "as work requires" rather than deliberate multi-learning with long-term stable teams
The optimist in me says - useful as a "Trojan horse", particularly when the organization is not ready to move away from projects, programs, simplifying the organization	better respect for optimized Kanban work in progress (WiP) limits would help
SAFe is evolving, on version 4.5 at the time of writing	Kanban at team level is de-emphasized, even if it's there. Yet, Kanban at team level helps SAFe (see When is SAFe safe?). Penny game is as far as Kanban training goes in SAFe training as far as I know. If so, this is a missed opportunity. Maybe with PSK, now it's safer?
	software/firmware/hardware oriented

 

Scrum@Scale was created to efficiently coordinate this new ecosystem of teams. It achieves this goal through setting up a “minimum viable bureaucracy” via a “scale-free” architecture.Dr. Jeff Sutherland developed Scrum@Scale based on the fundamental principles of Scrum, Complex Adaptive Systems theory, game theory, and object-oriented technology. Combined with the results of fieldwork with dozens of companies from startups to those in the Fortune 100, this guide was developed with the input of many experienced Scrum practitioners with the goal of the reader being able to implement Scrum@Scale on their own. Scrum@Scale ©2018

My experience - similar approach in a major utility over 18 months, teach-backs to clients of S@S

(+) Pros	(-) Cons
single Product Backlog	multiple implicit Product Backlogs e.g., filters/ views
easy to understand	SMs co-ordinate, POs co-ordinate, so much for self-managing teams. Hmmm, I thought this was based on Team of Teams?
no need for combined events as SoS is a Scrum team	too many meetings - EAT, EMS, MMS, MS, SoSoS, SoS !!
Executive Action Team (EAT) / Executive Meta Scrum (EMS) idea - afterall leaders must be coaches - promotion of intent-based leadership and Team of Teams	too many roles - multiple levels of SoSM, multiple levels of CPO
useful for organizations with wrongly named team POs who "take orders" and "write user stories" (and typically no real power)	SMs at SoS, instead of representatives of Development Teams (unless SMs are also on Development Teams)
doesn't seem bothered by projects, so it's good for "projectland"	two wrong metrics to my mind (productivity, team happiness), missing metrics if we had to pick (+/- impact on the customer, frequency of delivery, #small bets)
plays to the hierarchy, perhaps as a "Trojan Horse"	assumes fractal scaling, a bigger leap than SAFe's Weighted-Shortest-Job-First (WSJF) formula
	doesn't seem bothered by projects
	plays to the hierarchy
	Team Product Owners can lead to the opposite of systems thinking - Team 2 can only do priority 715 and is busy on that by team 1 is working on priority 1 and cant's get help from team 2

Pulse is simply a collection of patterns that have been proven to enable Agility in organisations and a System Flow that uses these patterns to realise value for your customers.

My experience - none. Ex-colleagues of mine developed this.

(+) Pros	(-) Cons
kind of feeling a little like going back to the Agile Manifesto	Confused by single backlog and team backlogs with extra stuff, perhaps it's a technique for de-cluttering the "single backlog" so we can make sense of it?
the Product Backlog is colour coded for technical debt, features, defects, innovation, discovery etc. so a nice set of signals there	Refinement needs to be more in advance due to splitting of Product Backlog?
No hard and fast rules, just guidance
No roles

Large Scale Scrum is essentially customer centric learning. LeSS is a deep strategy for "flipping the system" towards multi-learning, better delivery of customer value, and adaptiveness (to market needs /  jobs to be done). LeSS is multiple-team-Scrum that can scale to thousands of people, is based on volunteering, and is used in a variety of industries. LeSS is underpinned by principles, rules, guides, and experiments. It results in an inverted organization with the customer at the middle. And it's just the start of an experimentation journey to long-term growth.

My experience - several false starts with clients who were unwilling to "pay the price", ready to start another hopefully not false start

(+) Pros	(-) Cons
case studies at https://less.works/case-studies/index.html	adoption is slow (deep and narrow)
autonomy & alignment very high within LeSS instance	No projects, no outsourcing if that's your world (although the most recent case study found a path for outsourcing) , is that really bad? What about regulatory deadlines etc and other temporary work? Just feed it to the current teams?
mathematically solid with 1 Product Owner (PO) and 1 Product Backlog (PB) per customer-facing product, huge LeSS Huge maths also works	Scrum only in the sprint, really? Opportunity for Professional Scrum with Kanban surely?
multiple teams Scrum instead of multiple Scrum teams, not fractal	almost impossible perfection vision
feature teams ("slice of cake teams") deliver the highest value because they can	training inconsistent (recommend Bas Vodde for PB management for huge LeSS Huge and "Just Talk", recommend Craig Larman for system modelling, Specification By Example (SbE), product definition and adoption, recommend Jurgen de Smet for "0/100" system modelling and LeSS principles)
very smart & well-thought-through adoption approach, slow adoption but good (deep and narrow)	recommends technical excellence and it's not a rule
No projects, hence long-term stable teams, with "travellers" to freshen things up and spreads skills, only need product portfolio management	adoption secrets only unravelled for me in Craig's class, not in the books. I guess that's what LeSS coaches are for. After-all, there are no recipes.
Scrum with technical excellence	in a context with a huge appetite for agility for 1000s of people, entropy can prevail for the teams not in the footprint of the LeSS adoption, even with strong communities.
Co-ordination with "just talk" ("communication through code", component mentors, scouts, communities, travellers, open space)	software/firmware/hardware oriented
Embracing the reality of "undone" work & technical debt in LeSS Huge (and huge LeSS Huge), "undone" work sometimes visualized with Kanban
underpinning theory stacks up, also three books with 500+ experiments
almost impossible perfection vision
training inconsistent and maybe that's good as LeSS could take 5 days to teach instead of 3
Product Backlog item un-splitting for LeSS Huge is a touch of genius (keeps the Product Backlog simple to understand)
the only pattern that really applies Team of Teams, through the "traveller" concept and proper self-managing teams who can select/deselect their SMs/line managers - showing my bias now -LeSS is awesome!

 

Nexus - the cleverest backdoor to feature teams - Nexus can be used for fixing problems or for deep change, you decide by adding Scrum Studio or not. My experience - I have been using Nexus since it came out in 2015, with Scrum, Kanban, and The Lean Startup (with permission). My case studies are at scrumcasestudies.com (European bank for example)

(+) Pros	(-) Cons
technical debt mentioned three times, integration thirty-eight times in the short 2018 version of the guide	Nexus Integration Team is not an integration team, it's a coaching team, doing key stuff as needed, so why is it called an integration team? I think that Scrum.org would admit this naming was a mistake.
the Nexus Integration Team (NIT - regrettable name) consists of professionals who are skilled in the use of tools, various practices, and the general field of systems engineering. Even when structure change makes sense, sometimes people aren't ready for feature teams ("slice of cake teams"); the NIT nudges teams along	Without Scrum Studio, it doesn't "flip the system"
can start from where we are in a sense, from component/platform ("layer of cake teams") and also support feature teams("slice of cake teams")	sometimes dramatic change is needed instead
can be used by teams with different Lean/Agile frameworks are long as rhythm aligns, e.g., through supplier narrative of SAFe or as a release train	software-oriented
signals coaching by NIT, to question self-organizing teams about potential periodical re-org to minimize dependencies; the nth degree of this evolution produces feature teams	No support for 1000s of people
a simple pattern, 11/12 pages	Not much support for Nexus+
software-oriented
Nexus+ supports up to 81 teams
can flip the system with Scrum Studio (see https://www.scrum.org/resources/scrum-studio-model-innovation)

 

With Nexus, once you get to Feature Teams you might no longer require the NIT but you might still not be ready for LeSS, so what then? Is it still Nexus when the NIT is essentially just the product owner? The best Scrum Team's have mastery of the Scrum framework and practice perfect self-organization. They don't need Scrum Masters, but the role exists and is staffed by someone who may not spend any time on Scrum Master activities. Steve Porter calls it the 'brake in case of emergency' model of Scrum Mastering. Equally, the NIT exists and is staffed with the appropriate people who can help with integration challenges when/if they arise. They may have zero NIT activities, but they still fill the role. I'm guessing it could be a good home for component mentors/coaches. Prior to understanding this, I gave Nexus a lower score.

Kanban - Kanban is a method of organizing and managing professional services work.  It uses Lean concepts such as limiting work in progress to improve results.A Kanban system is a means of limiting work-in-progress and signalling when capacity is available to start new work. This is known as a “pull system.” Copyright 2018 https://www.leankanban.com

My experience: 3 years of Kanban training & implementation

(+) Pros	(-) Cons
start with what you do now, including current processes, roles & responsibilities	requires huge discipline to optimize work in progress
starts with understanding the wisdom behind the current process, the people who designed it had reasons for that they were doing	can be a bit too loose without cadences
optimize flow	variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen's talk on this topic.
adds statistical analysis to performance	evolution can be in large steps, but sometimes we need to entirely "flip the system" on its head
scales	Kanban maturity model, maturity models get gamed in my experience, I saw that with agile fluency
optional cadences that become more important at higher maturity levels
optional hats that become roles at higher maturity levels
Kanban maturity model, a path to anti-fragile

Flow - a Customer-Centred Framework for Agile Transformation - Flow Is An End-To-End System Of Customer-Focused Innovation, Visualisation And Feedback - Think of the matrix of innovation going on in your organisation. You need that to Flow like a calm, wide, and deep river. My experience - I read the two books, I formally reviewed the 2nd book, and the authors of the books answered my piercing questions.

(+) Pros	(-) Cons
aimed at service design	aimed at service design, usually including Kanban / DevOps but without the statistical analysis of performance
start with what you do now	acceptance of projects
optimize flow	evolution can be in large steps, but sometimes we need to entirely "flip the system" on its head?
scales	variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen's talk on this topic.
comes with example boards, e.g., customer wall	curious if the ageing of in-progress work in avoided due to whack-a-mole management in some contexts, although one could say that of any Kanban system
puts outside in thinking back in place
it's relatively new, yet many case studies are in progress beyond the implementations by Fin and Haydn
reducing the amount of waste that enters the flow of work, stopping many ideas from entering the funnel as it is time-consuming and adds to the complexity
strong focus on customer segmentation upstream to reduce poor projects and increase appropriate innovation
strong emphasis too on discovering assets and partnerships that help accelerate time to the customer.
some would argue (I wouldn't) that sometimes projects are still needed, e.g., regulatory deadline; Flow avoids the project plan by focusing on Flow value goals
coming soon - using a hierarchy of goals rather than a hierarchy of work
just in time events for organization re-design to ensure authenticity in customer focus

 

Disciplined Agile - Teams are empowered to experiment, learn and adopt the practices that work best for their unique context, within an agile control framework, suitable for regulated industries. If implemented with other patterns, my scores would improve significantly. But we could say that for all patterns.

My experience - 18 months at one of the largest case studies

(+) Pros	(-) Cons
case studies at https://disciplinedagileconsortium.org/Disciplined-Agile-Case-Study	it feels like the word "but" appears too often in the DA books to be a genuine attempt at growing good agility
lots of guidance	even if Scrum is used, it gets badly compromised by Disciplined Agile
scales	too vague, guidance not useful for those who need rules
the flexibility of team approach
the flexibility of multiple-team approach
speedy deployment of framework

Prince II Agile My experience - very similar approach over 6 years at a project-oriented-org

(+) Pros	(-) Cons
clear guidance for organizations that need to negotiate stage gates	feels dated
project orientation helpful for strongly oriented project organization	project-oriented
speedy deployment of framework	potentially corrupts empiricism?
some would argue (I wouldn't) that sometimes projects are still needed, e.g., regulatory deadline; if needed Prince II is comfortable with projects	a starting point? as we say in Ireland "I wouldn't start here":).
	the doorway to WaterScrumFall

WaterScrumFall - big design up front, "Scrum" sprints that miss the core essence of Scrum, followed by "stabilization period".

My experience - two majors rescues with the help of others, fired from two others with no appetite for real change (I can't help those clients, not my bag so to speak; also I failed to spot disconnect between actions and words early enough)

(+) Pros	(-) Cons
speedy deployment	project-oriented
still "works" as long as org has enough money to throw at it	corrupts empiricism
	creates technical debt & failure demand - the main reasons for call centres to receive so many calls from irritated customers
	best of both worlds is a myth, Waterfall and Scrum are incompatible

(Non-Waterfall) Scrum of Scrums - co-ordination events with representatives from teams and leadership

My experience - how I rescued the two WaterScrumFalls above along with going back to basics with Scrum

(+) Pros	(-) Cons
simple	conflicting advice/guidance about who attends and for what
speedy deployment	deprecated by Nexus, Scrum @ Scale, SAFE, and LeSS?
high focus on integration	a starting point? as we say in Ireland "I wouldn't start here":).
	the doorway to WaterScrumFall

 

Spotify copy, paste & adapt -

My experience- one organization with consulting firm version, one organization with the original version

(+) Pros	(-) Cons
the tendency towards Toyota Kata for adaptation	let's see......there must be a downside to short term cost cutting of consulting firm version as John Seddon teaches us if your primary goal is to cut costs, (long term) costs can actually go up, also it seems shallow, so is it deep enough to fend off real competition?
autonomy with alignment	re-badging of roles means the matrix still rules, unless like Henrik said in his paper squads are mini-startups, tribes are incubators (copy & paste versions don't feel like that - scored separately below for original idea and copy & paste versions)
Simple	at scale, potentially a pathway to Dark Agile (PMO deciding which teams do what work)
Flexible
Popular
despite imperfections (squad backlogs, squad POs from a systems thinking point of view), big-name companies are using it and still seem to be doing well
copy paste, & adapt can work well, "adapt" being the keyword
for those into Spiral Dynamics Integral, this approach taps into varying basic levels of complexity of thinking at any point in time, helping to achieve a solid core to build on. For example, "tribe" hints it a sense of belonging, a solid base to work from

 

No pattern at all

My experience - my pre-Agile days, the only problem was I built faster horses, I never pivoted and my business failed. Folks these days would pivot I'm sure, we've learnt from the Lean Startup I hope.

(+) Pros	(-) Cons
going back to the Agile Manifesto / XP-like	requires huge discipline and high level of maturity, dangerous to go straight to this if the team/developer needs rules
#NoBacklogs - just talk to the customer about what to do next and stop building massive things	2/3 of people need rules to guide them, not just principles (Leandro Herrero's HomoImitans)
"Agile frameworks suck, long live agility"	I know XP is a framework/method (but it's back to basics - a lot of people forget many methods pre-date the Agile manifesto), but if one chose XP, can scale beyond 200 people unheard of? maybe scaling is not needed anyhow?
quick feedback loops	variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen's talk on this topic.
build only what the customer wants next
1st rule of scaling is not to scale
possibly highest level of maturity
potentially 1-3 developers and the customer, and that's it!
something to progress to after the above options have outlived their usefulness?
pure empiricism, no plans for complexity, let's just see what happens

In summary, it is remarkable that the only two patterns with a true single Product Backlog are Nexus and LeSS. I like John Seddon's inspired #AgileFrameworksSuck #NoBacklogs. It is it most mature of them all to my mind. Some of us need Shu patterns, and that is what most patterns are, Shu patterns, and they get your started.

In my next post, I will come back up to summary level and I will talk about a new strategy for huge contexts with huge appetite for agility. Organizations who (according to the HBR June podcast by Jeff Sutherland and Darrell Rigby of Bain) don't just want to fix problems and go back to the functional organization design; instead a minority within huge organizations want deep change.

Why have to choose between broad & shallow and deep & narrow? We seem to be limited to either or. Deep is too slow. Broad is too shallow and is prone to rollback.

In the next post, let's explore Broad and Deep agility (BaDa). It is a meta-pattern that considers Nexus and Less combined, Nexus+ for Broad & Shallow, Nexus/Scrum Studio or LeSS for Deep & Narrow ....or indeed other broad patterns and LeSS / Nexus Scrum Studio combined. No recipes are included, just potential directions of travel. We have enough frameworks.

Aside, I worry that maybe Flow and #AgileFrameworksSuck are the only options that are potential breeding grounds for Jobs To Be Done, the others either have a product, service, or project orientation. Jobs To Be Done is something I will explore in my own business, inspired by Clayton M. Christensen. Many seen to jump from jobs to products and then lose the plot. Product Backlogs re-emphasize that.

Visualization via Tableau...

If you disagree with my opinion, feel free to enter your opinion on this survey, only for the methods you have experience with please, thank you.

To see how multi-speed agility is possible and maybe even desirable in some cases, check out https://www.ace.works/post/mirror-mirror-on-the-wall-1-of-4

And while we're at it, my view whether patterns or Lean or Agile or a combination of both (feedback welcome):

https://linktr.ee/johncolemanxagility - social and podcast links
https://linkpop.com/orderlydisruption - order training from right here