-a foundational perspective on ‘scaling Scrum’-
Most organizations that have adopted Scrum are caught up in a (mental) race to ‘scale Scrum’. It is worthwhile considering what drives them, and point out the value in understanding and employing Scrum properly first.
A Compelling Desire to Scale?
Organizations that have been around for a while have grown very complicated and extremely interdependent internal structures. IT and software development work is organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required in order to produce and release even the smallest chunks of work.
Growth in volume and quantity is seen as the only way forward. The internal structures make it very difficult to produce more work and allow such growth. The investment to produce additional work is spent mostly on the structures themselves, not on the actual productive work.
The existing structures are the root of the problems organizations seek to resolve by adopting Scrum. It is then fascinating to observe how Scrum is expected to match the existing structures.
The reluctance to touch the existing structures results in twisted adoptions of Scrum. The problems impeding increased business agility remain. The benefits to be gained from Scrum quickly crash against organizational limits. The attempts to scale Scrum reflect the past views in which growth was only achievable through larger numbers. The already twisted implementation of Scrum then needs to be scaled to develop more software, faster. The opportunities for organizational healing are lost.
The Scalability of Scrum
The primary potential of Scrum lies not in enlarging capabilities, in terms of quantity and volume, but in improving existing capabilities and capabilities established through a proper Scrum adoption. Scaling is in the teams, not in adding teams, roles and phases.
Much scaling is possible, even within a single team. There IS value in maximizing Scrum first.
The Scrum framework, and its roles and rules, is only the beginning. A proper adoption of Scrum, preserving simplicity, is a gateway to a myriad of options to deal with complexity.
Once an organization crosses the barrier of actually doing Scrum, each element included in or attached to the Scrum framework can be implemented in a basic or a more advanced way. Each step towards a more advanced utilization of Scrum increases the benefits and achieves the goal of scalability.
From a base, even mechanical, implementation of Scrum organizational beauty comes within reach.
This is the sole base to scale the benefits achieved through Scrum. Otherwise only dysfunctions are scaled and reinforced, the dysfunctions that remain unresolved through broken or overloaded implementations of Scrum.
Here’s a (non-exhaustive) selection of options that can be exploited within Scrum:
- Stop creating low value. Product Ownership in Scrum works better with a mandate to organize, order and minimize the Product Backlog from the purpose to maximize the value
- Enable cross-functional development. A Development Team works better as a feature team. Feature teams face much less complexity — having all skills in the team to work on all technical layers that need being worked on to deliver Increments of software from and end-to-end user perspective.
- Help teams grow their effectiveness through improved collaboration. Teams benefit from stability and respect for their autonomy and self-organization to enter a continuous collaborative flux. Stop focusing on tasks, capacity and past performance, and provide teams with compelling goals and objectives instead.
- Embrace technical excellence. Scrum has no exact prescriptions for development practices. However, the empiricism of Scrum thrives on transparency. Transparency encompasses common standards and agreements against which to inspect and adapt. Engineering standards are a crucial part of that. Engineering standards guide the definition of Done, give focus to a team in getting stuff done, help a team in forecasting Product Backlog for a Sprint, and define quality, create accountability.
Imagine the gain in business agility if, through the above tactical choices, every 2-3 weeks a truly releasable Increment of product is available that can be brought to the market without additional, subsequent cost or work.
Enjoy the scaling effect of maximizing Scrum first. If you run out of such improvements, consider adding teams. Choose wisely where you want to invest in first.