- Why do cats love boxes so much?
- How do dolphins sleep?
- Where did the missing footage from the Zapruder film go?
- How on Earth should we scale Scrum?
Science and conspiracy has answers to all of these. Personally, I have a few questions about the last issue.
Scaled Scrum
There are multiple approaches to scaling agile projects "out there". I'm not going to talk about any of them in detail. But feel free to take 10 minutes to educate yourself by clicking the links below. You'll come back, right?
- SAFe
- DAD
- LeSS
- Spotify Model
- SSwS
- and, the new kid on the block, Nexus (definitely read this before reading on, it'll take you 10 minutes).
Back? OK.
I'm particularly interested in LeSS, SSwS and Nexus (and somewhat in the Spotify approach) because these are, in particular, approaches to scaling Scrum. Of course each has its ups and downs. Nexus, however, has some particularly down-y downs. They bother me.
Getting Down With Nexus
 |
| The Nexus Framework from Scrum.org |
So. Nexus. This is the official approach to scaling Scrum from the nice folks at scrum.org. It only landed very recently so it is kinda late to the party. I get the feeling it is a somewhat rushed reaction to all the other approaches coming into use first. Why do I think this? Because of two gaping holes:
- Nexus does not actually scale (very well).
- It will kill the culture of your existing Scrum project.
Nexus is very workable because it is so simple. It takes all the same principles of Scrum and simply add some bits. No major overhaul. No demanding concepts in addition to Scrum. But these problems of scale and culture are big problems.
Scaling With Nexus
Why do I think Nexus does not scale very well? Simple. The authors of the framework say so themselves! Take a look at what it says on page 2 of the guide:
Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.
Three to nine teams. THREE. TO. NINE. So between 15 (bare minimum) and 81 (absolute maximum) developers. Not very scale-y. Spotify with its 1200 developers laughs in the face of Nexus.
Why does it not scale so well? Simple: take a look at the image above. See that "Nexus Integration Team"? There's your problem. This team is constructed from the Product Owner, the ScrumMaster and the Nexus Integration Team members, who may or may not be members of the Scrum teams. For me, it makes sense for the NIT members to also be representatives of the Scrum teams. But a combination of Brooks' and Conway's laws limit the size of the NIT to about 8 or 9.
I have yet to see anything official on the matter but I have heard rumour of Nexus+ as a means for bringing greater scale. A Nexus of Nexuses. Holy Moly. No.
Culture Vulture
The one is subtle. And little hard to explain to anyone who has never "done agile". But I'll give it a try.
Scrum teams are self-organising. This is a big deal. They work together to solve their problems as best as they can. The most "senior" team members humble themselves and the most "junior" have the chance to shine. Everyone pulls together and does their best using their skills. No specialists.
I call this the "egalitarian social contract" of Scrum.
You will not find any Scrum guide telling you that this is a feature of Scrum. It isa natural result of being self-organising (something which the guides will tell you to do). "I hate being in a team of equals" said no Scrum team member ever. This attitude to teamwork is something that is just expected of a Scrum environment with decent values.
Nexus kinda breaks this. Hard. And explicitly.
Go back to that guide again and take a look at page 5:
Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary. If this is the case, priority must be given to the work for the Nexus Integration Team. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. This preference helps ensure that the work to resolve issues that affect many teams has priority.
Priority must be given to the work for the Nexus Integration Team. Priority. "Sorry guys, I need to do some stuff for the NIT. I'm not going to be able to help with backlog item X today." Not. Cool.
All That Bad?
If I am being honest, this is a little bit of nit-picking on my behalf. Scaling up to 81 is still more scale than the vast majority of development companies need to scale to. Cultural problems can always be tackled somehow. I guess my issue is that these problems were built in to the framework.
I'd love to see Nexus in action. I suspect it is so new that nobody is really doing it yet. Is anyone out their seriously wanting to give this a try? I hope so. Please shout if you are. I'm really curious to see it in action.
No comments:
Post a Comment