I spent the last week of April in Karlsruhe, Germany with the wonderful and talented Scrum.org community. During that time, we worked through The Nexus Framework as part of the new Scaled Professional Scrum training. It was a come-together of some of the world’s leading agile thinkers, reviewing Scrum.org’s approach to the challenge of “scaling Scrum”. It was a profound experience I am grateful for. This post shares some of my experience.
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 based on the assumption 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 in order 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 Scrum.org’s training is all titled “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 team’s best work together?
Again, let’s start with some principals:
- 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 principal.
- When multiple teams work together on the same product, the technical work that was difficult before becomes monumental now. Significant is pressure is placed on the engineering approach and standards, such a source control, branching strategies, code integration, test automation etc.
- When multiple teams work together on the same product, coordination between teams becomes very difficult. Brooks 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 use 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.
Even more importantly, Nexus puts engineering excellence front and center – at the heart of Nexus is an integrated increment. The Nexus Daily Scrum happens before the teams individual Daily Scrums and among other things asks “do we have an integrated, working increment of software?” If not, then the priority of all teams is addressing that. Otherwise, without being able to understand the true state of the software, how can we inspect and adapt? We have integrated software daily at scale. 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.
Interesting, unlike Scrum, a lot of The Nexus is not mandatory. It isn’t about compliance – it is about trying different patterns to find what what works in your organisation and adapting accordingly. Not hardening sprints, no relegation of Scrum teams to mere delivery factories for upper hierarchy’s decisions, no top down enforcement of a prescribed “solution” to scaling. It is agile, adaptive, empirical & evidence based. It delivers a working increment every Sprint and delivers integrated software daily.
Have a look at some of the information on the Scrum.org site and a look at Ken’s video.
Special mention needs to go to Rob Maher who was 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.