Descaling your Scrum Part 2
Waterfall seemed to be well-suited to developing simple or perhaps complicated systems. Such systems can be master-planned from the outset, with work done by specialised teams. Waterfall has feedback but success does not depend on efficient feedback, because the process presumed to foresee the next steps. Because its stages (analysis, design, implementation, test) were held to be largely independent and simple, the work was partitionable. You could scale each phase independently to achieve maximum throughput.
Scrum is optimised for complex, adaptive systems. In the early days of our Scrum patterns effort we included some scaling patterns. Jeff Sutherland rebuked us with the reminder that Scrum is fractal in nature: that is, it’s a scale.free system. It grows the way an ecosystem grows: by local adaptation and piecemeal growth. It comprises cross-functional teams rather than independent (scalable) teams. Specialisation doesn’t handle this kind of complexity well because a problem in coding in this minute may require testing insight in the next minute and analysis insight two minutes hence.
A Scrum view envisions growth differently. You can grow a team’s learning without adding people — the mind, at this level, is unlimited. Learning in turn increases throughput, better Kaizen and, to quip a well-known book title, to do twice the work in half the time. In terms of human mass, Scrum organisations grow not by simple aggregation but by differentiation — the way an embryo develops. It is this differentiation rather than any notion of “scaling” that should be the business focus — unless you’re building pyramids. That means thinking in terms of federations and partnerships instead of armies.
The goal isn’t to grow one’s organisation, but rather to generate as much value with as few people as you can. Alex Lope-Bello, CEO of Comtrade, says, “Grow your business — not your teams.” Scrum pundits talk about increasing teams’ capacity to do work (called their velocity) by large integral factors or even orders of magnitude. If you can improve the process to realise a ten-fold gain, why would you hire ten times as many people instead? Twice the work in half the time.
Management feels safety in numbers, so de-scaling takes more courage than scaling. Let’s say that you have seen the light of agile and want to convert your organisation. If you have a 70-person development organisation you might be tempted to teach Scrum to everyone on Thursday and Friday and to turn on the Scrum switch Monday morning. First, this is likely to be painful in the sense that Scrum will make it visible that you don’t need many of the roles in your current organisation. Second, it locks the organisation into a local optimum from which it is unlikely to escape. Instead, start over with ten people. If you’re courageous, you’ll start with only five.
Start by cutting people; continue by shortening the work week. Jeff relates a story, about Scott Maxwell at OpenView Venture Partners. Maxwell noticed that increased hours at the office decreased output. Sutherland relates:
The peak of productivity actually falls at just under 40 hours a week. Armed with this data, Scott started to send people home early. "It took them a while to get that I was serious," Maxwell says. (Jeff Sutherland, “The Art of Doing Twice the Work in Half the Time.”)
How about the rest of the workers? Have them innovate new features or new products by building prototypes or talking with end-users. Have them start up a new product or a new business within the company. Grow the business — not the team.