But I’m going to skip past these frameworks today and focus on the Manifesto for Agile Software Development with one question in mind: Does it make sense to scale these practices outlined in the manifesto? Can they even be scaled to hundreds or thousands of people?
Spoiler alert! I don’t believe so.
But let me explain why, by pointing out the elements of the agile manifesto which cannot be scaled to large groups:
Individuals and interactions over processes and tools
Individuals and interactions… this requires operating at a scale where individuals and interactions are visible. That’s a bit fuzzy, but it probably at least means working in groups of people below Dunbar’s number. It likely means working in groups of 12 or fewer.
Customer collaboration over contract negotiation
Can hundreds or thousands of engineers collaborate with customers? I don’t really think so. Collaboration needs to happen between individuals, or small groups.
Let me now look at some of the principles behind the agile manifesto:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Good luck having a face-to-face conversation with hundreds or thousands of people. This principle alone puts an upper bound on how large a group can be and still be “agile” according to the manifesto.
The best architectures, requirements, and designs emerge from self-organizing teams.
1,000 engineers cannot be self-organizing. At best, they’ll self-select a leader (i.e elect a union president) who does the organization for them.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Here it is, in black-and-white: The unit of agile software development is “the team”. If you have two teams, you have “two agiles” (yes, I know that’s a grammatical stretch…).
So in my view, the Agile manifesto makes it pretty clear, although not entirely explicit, that agile software development happens at the team level. As such, it cannot be scaled beyond the boundaries of a single team.
Obviously, it’s possible to have more than one agile team in a company, though. I’ll talk about that in the coming days, so be sure to subscribe so you don’t miss it.