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:
- SAFe as per www.scaledagileframework.com
- Scrum @ Scale as per https://www.scruminc.com/scaling_scrum/
- Large Scale Scrum (LeSS) as per less.works
- Pulse as per http://gopulse.org/
- 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
- Copy, paste & adapt what’s on 2012 Spotify videos as per https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf — two flavours
- Kanban as per www.leankanban.com/guide also including Enterprise Services Planning as gleaned from information in the public domain
- Prince II Agile as per https://www.axelos.com/best-practice-solutions/prince2-agile/what-is-prince2-agile
- Disciplined Agile as per http://www.disciplinedagiledelivery.com/
- WaterScrumFall or Dark Scrum or Zombie Scrum as per https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment
- (Non-Waterfall) Scrum of Scrums as per https://www.agilealliance.org/glossary/scrum-of-scrums
- Flow as per https://www.flow-academy.org/
- 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…
My experience — supporting teams in a major company so they could “fit into” their major client’s SAFe implementation with Kanban.
+ Pros
- case studies at https://www.scaledagileframework.com/case-studies/
- strongest for alignment with non-team roles
- strong at alignment up to 1,000s of people
- Release Train idea under Dunbar number, Solution Train Idea to maintain Dunbar numbers, Supplier narrative
- Lean Finance is going in the Beyond Budgeting(BB) direction, if like BB it’s light in detail
- Scrum/XP/Kanban at team level — interestingly Scrum.org’s PSK is helpful here
- Has a simple version — Essential SAFe
- Is it better than WaterScrumFall? I think so, by a mile.
- 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.
- With Kanban potentially at every level, and XP also at the team level
- SAFe slack in IP iteration helps flow
- 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
- SAFe is evolving, on version 4.5 at the time of writing
– Cons
- Planning for 4 iterations ahead goes against empiricism
- 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
- too many roles, a recipe for clarification of roles & responsibilities over “fuzziness” (imagine that word being said in Yves Morieux’s wonderful French accent)
- Scrum is corrupted by SAFe, the Product Owner is disempowered (a million miles from CEO of the product)
- a tendency to move forward with large bets in progress, less tendency to implement experiments
- system team integrates, hopefully already integrated as Continuous Integration not emphasised strongly enough
- overwhelming
- fails to satisfy Cynefin Sense-Making Framework
- Scrum Masters co-ordinating instead of self-organizing teams
- 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.
- 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
- better respect for optimized Kanban work in progress (WiP) limits would help
- 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
- single Product Backlog
- easy to understand
- no need for combined events as SoS is a Scrum team
- Executive Action Team (EAT) / Executive Meta Scrum (EMS) idea — after all leaders must be coaches — promotion of intent-based leadership and Team of Teams
- useful for organizations with wrongly named team POs who “take orders” and “write user stories” (and typically no real power)
- doesn’t seem bothered by projects, so it’s good for “projectland”
- plays to the hierarchy, perhaps as a “Trojan Horse”
– Cons
- multiple implicit Product Backlogs e.g., filters/ views
- SMs co-ordinate, POs co-ordinate, so much for self-managing teams. Hmmm, I thought this was based on Team of Teams?
- too many meetings — EAT, EMS, MMS, MS, SoSoS, SoS !!
- too many roles — multiple levels of SoSM, multiple levels of CPO
- SMs at SoS, instead of representatives of Development Teams (unless SMs are also on Development Teams)
- 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)
- 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
My experience — none. Ex-colleagues of mine developed this. + Pros
- kind of feeling a little like going back to the Agile Manifesto
- the Product Backlog is colour coded for technical debt, features, defects, innovation, discovery etc. so a nice set of signals there
- No hard and fast rules, just guidance
- No roles
– Cons
- 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?
- Does refinement need to be done more in advance due to the splitting of Product Backlog?
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
- case studies at https://less.works/case-studies/index.html
- autonomy & alignment very high within LeSS instance
- mathematically solid with 1 Product Owner (PO) and 1 Product Backlog (PB) per customer-facing product, huge LeSS Huge maths also works
- multiple teams Scrum instead of multiple Scrum teams, not fractal
- feature teams (“slice of cake teams”) deliver the highest value because they can
- very smart & well-thought-through adoption approach, slow adoption but good (deep and narrow)
- No projects, hence long-term stable teams, with “travellers” to freshen things up and spreads skills, only need product portfolio management
- Scrum with technical excellence
- Co-ordination with “just talk” (“communication through code”, component mentors, scouts, communities, travellers, open space)
- 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!
– Cons
- adoption is slow (deep and narrow)
- 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?
- Scrum only in the sprint, really? Opportunity for Professional Scrum with Kanban surely?
- almost impossible perfection vision
- 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)
- recommends technical excellence and it’s not a rule
- 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.
- 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.
- software/firmware/hardware oriented
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
- technical debt mentioned three times, integration thirty-eight times in the short 2018 version of the guide
- 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
- 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”)
- 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
- 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
- a simple pattern, 11/12 pages
- 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)
– Cons
- 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.
- Without Scrum Studio, it doesn’t “flip the system”
- sometimes dramatic change is needed instead
- software oriented
- No support for 1000s of people
- Not much support for Nexus+
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
- start with what you do now, including current processes, roles & responsibilities
- starts with understanding the wisdom behind the current process, the people who designed it had reasons for that they were doing
- optimize flow
- adds statistical analysis to performance
- scales
- 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
– Cons
- requires huge discipline to optimize work in progress
- can be a bit too loose without cadences
- variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen’s talk on this topic.
- evolution can be in large steps, but sometimes we need to entirely “flip the system” on its head
- Kanban maturity model, maturity models get gamed in my experience, I saw that with agile fluency
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
- aimed at service design
- start with what you do now
- optimize flow
- scales
- comes with example boards, e.g., customer wall
- 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
– Cons
- aimed at service design, usually including Kanban / DevOps but without the statistical analysis of performance
- acceptance of projects
- evolution can be in large steps, but sometimes we need to entirely “flip the system” on its head?
- variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen’s talk on this topic.
- 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
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
- case studies at https://disciplinedagileconsortium.org/Disciplined-Agile-Case-Study
- lots of guidance
- scales
- the flexibility of team approach
- the flexibility of multiple-team approach
- speedy deployment of the framework
– Cons
- it feels like the word “but” appears too often in the DA books to be a genuine attempt at growing good agility
- even if Scrum is used, it gets badly compromised by Disciplined Agile
- too vague, guidance not useful for those who need rules
Prince II Agile My experience — very similar approach over 6 years at a project-oriented-org + Pros
- clear guidance for organizations that need to negotiate stage gates
- project orientation helpful for strongly oriented project organization
- speedy deployment of the framework
- some would argue (I wouldn’t) that sometimes projects are still needed, e.g., regulatory deadline; if needed Prince II is comfortable with projects
– Cons
- feels dated
- project oriented
- potentially corrupts empiricism?
- 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
- speedy deployment
- still “works” as long as org has enough money to throw at it
– Cons
- project oriented
- 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
- simple
- speedy deployment
- high focus on integration
– Cons
- conflicting advice/guidance about who attends and for what
- deprecated by Nexus, Scrum @ Scale, SAFE, and LeSS?
- 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
- the tendency towards Toyota Kata for adaptation
- autonomy with alignment
- simple
- 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
– Cons
- 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
- 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)
- at scale, potentially a pathway to Dark Agile (PMO deciding which teams do what work)
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
- going back to the Agile Manifesto / XP-like
- #NoBacklogs — just talk to the customer about what to do next and stop building massive things
- “Agile frameworks suck, long live agility”
- quick feedback loops
- 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
– Cons
- requires huge discipline and high level of maturity, dangerous to go straight to this if the team/developer needs rules
- 2/3 of people need rules to guide them, not just principles (Leandro Herrero’s HomoImitans)
- 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?
- variability likely without timebox-based periodic resets (that, in theory, reduce variability to zero). See Don Reintersen’s talk on this topic.
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.
Article by channel:
Everything you need to know about Digital Transformation
The best articles, news and events direct to your inbox
Popular Now
Related Articles
