Scaled Scrum is still Scrum

Explore Assurity 15 June 2015 Edwin Dando

Edwin Dando spent the last week of April in Karlsruhe, Germany with the community, where they worked through the Nexus™ Framework as part of the new Scaled Professional Scrum training. He shares some of what he calls ‘a profound experience’ here…

This was a coming together of some of the world’s leading Agile thinkers, reviewing’s approach to the challenge of ‘scaling Scrum’. We discussed what ‘scaling Scrum’ means. Most of us had very similar experiences – many organisations don’t do the fundamental basics of Scrum well, nor do they tend to invest in improving the underlying technical practices that help enable agility, yet often they seek to ‘scale Scrum’ to many teams. Normally, what they mean by this is that Scrum worked pretty well for some individual teams that have tried it and now they want to roll it out further. The underlying mental model is that because it worked for a few individual, isolated teams, it will work across the organisation.

Then we discussed the heart of Scrum:

  • Scrum is based on transparency. When the work is transparent, we can inspect accurately and adapt accordingly
  • Teams are at the heart of Scrum. Scrum empowers them to focus on regular delivery of usable value
  • Increments of done, shippable software every sprint enables business agility by creating a feedback loop. The increment is sacrosanct. Hardening sprints, re-work, ‘tidy-up’ and ‘catch-up work’ destroy agility
  • Scrum is a bounded environment for action, continuous improvement and learning
  • Scrum is designed to highlight every weakness or deficiency an organisation has so that it can become aware of these and systematically address them to become the leading organisation in its market
  • Scrum promotes bottom-up thinking with top-down support to discover and emerge what works best for you, your organisation and your context

The obvious answer to ‘getting more value’ is to simply address organisational dysfunctions Scrum uncovers – for example, developing features customers don’t value, poor-quality software development environments and tooling, technical debt, teams being interrupted, multi-tasking etc, etc. Surely we should become competent and professional with Scrum at the team level before we attempt to ‘scale’ it across the organisation? In my experience, few organisations have the courage to deal with root problems and instead feel uncomfortable with the symptom highlighted. The brave organisations embrace the opportunity to improve and thus outgrow the former. 

"The iterative, incremental nature of Scrum puts stress on the product development organisation to improve its engineering skills and on the product management organisation to optimize return on investment of every release and project. The phrase “that can’t be done here” really means it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk", Ken Schwaber – Scrum is Hard and Disruptive 2006

This is why’s training is all entitled ‘Professional’ (Professional Scrum Master, Professional Scrum Product Owner etc). Let’s start by doing the foundation well, eh?

So assuming an organisation feels they have achieved a reasonable level of proficiency with Scrum and have developed a culture where impediments to optimal performance are made transparent and addressed, then how could multiple Scrum teams best work together?

Again, let’s start with some principles:

  • Scrum promotes bottom-up thinking with top-down support to discover and emerge what works best for you, your organisation and your context. There is no magic framework or ‘solution’ to scaling Scrum. Each situation is unique and requires care, skill, thoughtfulness and evidence of the impact of small, regular change experiments. I believe the reaction of the Agile community to SAFe is largely based around this principle.
  • When multiple teams work together on the same product, the technical work that was difficult before becomes monumental now. Significant pressure is placed on the engineering approach and standards, such as source control, branching strategies, code integration, test automation etc.
  • When multiple teams work together on the same product, coordination between teams becomes very difficult. Brook's Law applies not just to individuals in teams, but also to teams working together. That is, there is a significant coordination overhead.
  • There are many good patterns coming out of the Agile community as a result of real-world experimentation. For example, Vend uses loosely coupled (concept of connascence) teams to remove some of the core overheads of multiple teams. Spotify changed their product architecture to enabled decoupled releases and minimal dependencies.
  • Scaling is not easy. Each situation will uncover different challenges and we need to be able to draw on a range of different patterns to address each unique situation. 
  • Scaling Scrum is NOT about fitting Scrum into the existing structures, but a bottom-up revision (simplification) of the structures – Gunther Verheyen

When we stepped through the Nexus Framework, I literally let out a loud sigh of relief. Nexus IS Scrum, so naturally supports all of the principles and values. It even goes further by making engineering excellence vital. I believe the spectre of Flaccid Scrum has frustrated many as the potential of Scrum fails to be realised.

At the heart of Nexus is an integrated increment. The Nexus Daily Scrum happens before the teams’ daily scrums and, among other things, asks “Do we have an integrated, passing increment of software?”. If not, then the priority of all teams is addressing that. Otherwise, without understanding the state of the software, how can we inspect and adapt? We have integrated software daily. Hard? Yes. Unachievable? No. Agile? Yes.

Nexus also introduces the Nexus Integration Team – a Scrum Team whose primary work is to coordinate and guide the work of the Nexus Scrum Teams. The Integration Team consists of a Scrum Master, Product Owner and people with other necessary skills. Important to note is that the Nexus Integration Team is accountable for integration, but not responsible. That responsibility still lies with the Scrum Teams.

Interestingly, unlike Scrum, a lot of the Nexus is not mandatory. It isn’t about compliance, it is about trying different patterns about what works in your organisation and adapting accordingly. Not hardening sprints, no relegation of Scrum teams to mere delivery factories for upper hierarchies’ decisions, no top-down enforcement of a prescribed ‘solution’ to scaling. It is Agile, adaptive, empirical and evidence-based. It delivers a working increment every Sprint and delivers integrated software daily.

Take a look at some of the information on the site and a look at Ken’s video.

Also see Gunther Verheyen’s SlideShare.

Special mention to Rob Maher, our trainer for the day. Rob has put in a significant effort into the development of the Nexus Framework and the ‘train the trainer’ course he ran was absolutely top-notch.