Maximizing Scrum

When organizations consider or start adopting Scrum, a frequently raised concern is how ‘to scale Scrum’. It is worthwhile investigating this desire, and start exploring the scalability of Scrum.

It seems that many organizations have grown into very complicated and extremely interdependent internal structures over the years of their existence. The implementation of Scrum is expected to fit the existing structures.

Within the existing structures ‘scaling’ is synonymous to increasing volume and quantity, to larger numbers. Hence, the expectation that the implementation of Scrum must be expanded with additional processes, roles, phases, etc.

In order to start thinking about scaling Scrum, there is much value in understanding and employing Scrum fully first. What would you be scaling otherwise, right?

There IS value in maximizing Scrum first.

A Compelling Desire to Scale?

Organizations, certainly if they have been around for a while, seem to have grown into very complicated and extremely interdependent internal structures. These structures are often the root of the problems organizations seek to resolve by adopting Scrum. IT and software development work is, in general, seen and organized as assembly line work. Many bodies, meetings, hand-overs, resources, deliverables, processes and departments are required to produce and release even the smallest chunks of work to the market.

Yet, there is an extreme desire or pressure to grow. The desire ‘to scale Scrum’ is a reflection of the demand to develop more software, faster.

The internal structures make it very difficult to increase the amount of outbound work because the additional internal effort to do so increases not proportionally, but exponentially. The investment to achieve the additional work goes to a large extent to the additional structures and is often much higher than the gains expected from the work increase.

Over the years, the existing way of working has ingrained the belief that growth (i.e. ‘scaling’) is only achievable by increasing volume and quantity. The desire ‘to scale Scrum’ is a reflection of past views in which growth was only achievable through larger numbers.

For obvious reasons, organizations are reluctant to touch the existing structures, and keep operating within them. Hence, they look for an implementation of Scrum that fits. This often results in twisted implementations of Scrum, whereby the foundations and principles of Scrum are broken beyond repair. This limits the benefits to be gained from Scrum upfront. The problems are not really solved, at most superficially touched.

Over the years, the existing way of working has ingrained the belief that structures and processes must be complex, and that Scrum is too simple.

However, to be scalable, Scrum is the beginning; a relentless focus on this will help organizations consider the real scalability of Scrum.

The Scalability of Scrum

The primary potential to scale Scrum is not in enlarging capabilities, in quantity and volume, but in improving existing capabilities. Scaling is in the teams, not in adding teams, roles and phases.

Much scaling is possible, even within a single team.

Organizations overlook that scaling potential. Why not take advantage of these options first? Avoid, or remove, the additional complexity that arises from volume-oriented scaling like adding people, adding teams, adding roles, and adding phases.

We refer to the idea of Scrum being the beginning, and as such, a gateway to a myriad of options as “ScrumAnd”. Yes, you do Scrum if you have the formal elements in place.

And… look what is possible upon that.

Scrum has a wide spectrum of improvements possible without having to add process and other ceremonies not included in the Scrum framework. From a base, even mechanical, implementation of Scrum much more beauty comes within reach. Organizations can take advantage of the choice to start with Scrum, exploit all possibilities and options that Scrum offer, and start enjoying higher benefits, before scaling quantitatively in a traditional way.

If scaling is done upon this base, then -and only then- the benefits will also scale.

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.

Here’s a (non-exhaustive) selection of options that can be exploited within Scrum:

Stop creating low value:

• A Product Owner in Scrum has a mandate to organize, order and minimize the Product Backlog to maximize the value delivered.

Enable cross-functional development:

• A Development Team works better with on-demand available facilities, access, and authorizations for infrastructure, tooling, and environments.


• 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:

• Eliminate multi-tasking, multi-project assignments and frequent team shifts so a team can improve its relationships and enter a continuous collaborative flux.


• Teams and individuals benefit from training, seminars and being part internal and external communities. It helps them achieve mastery, which is far more important than capacity-based thinking in creative and complex work like software development.


• Understand and respect autonomy and self-organization. Stop focusing on tasks, capacity and past performance, and provide teams with compelling goals and objectives instead.

Allow a Development Team to be excellent in software engineering:

• Provide them with standards, guidelines, tooling and automation. Promote modern engineering standards like eXtreme Programming, e.g. TDD, Pair Programming, and Continuous Integration.

Illustrations of ScrumAnd

There are many ScrumAnd possibilities, all having the potential of augmenting the fun, energy, and benefits from Scrum.

Here are 3 illustrations:

The Product Owner role

Yes, you do Scrum if you have a Product Owner. And you will do it even better depending on how the role is fulfilled:

Scrum is often introduced as the new IT-process in organizations that also suffer from the traditional Business-IT dichotomy. IT wants to have control over the delivery, and business comes into play much later; forcing themselves in or being invited to do so.

• An IT-person in the role of Product Owner, often a (business) Analyst, has limited benefit. It’s just a way for the development organization to secure control (‘Can’t trust business people!’). However, for many decisions, the analyst has not enough product management or business development insights and needs to revert to product management. That creates waste, waiting times, frequent task switching – there is no flow, no value.


• An IT-proxy for the business works slightly better. Control remains with IT (‘Still can’t trust business people!’) but a Product Owner that is more connected to the business results in less waiting time, and less hick-ups; although many of those remain.'


• It’s a great improvement to have a representative from product management (‘business’) to fulfill the role. There is more direct availability of functional knowledge and stakeholder expectations. Yet, limitations in autonomy still cause waiting times.


• It works better if the person is not only from business, but also has the trust and the mandate to make decisions on the spot. There are less hick-ups, less context and task switching, and largely improved flow. The Development Team can focus more and get things done.


• It is great if the Product Owner is a mini-CEO of the product -- a real owner of the product (what’s in a role’s name, right?) -- a businessperson with full (functional and budgetary) responsibility and a tight connection to all product management aspects (marketing, competition, users, legal, finance). The person’s professional life is dedicated to the well-being of the product. They don’t come much better than this.

Releasable Software

Yes, you do Scrum if you have a definition of Done. And you will do even better when it reflects ‘releasable’ and all work for it can be done within a Sprint (not post-Sprint):

Scrum has no exact prescriptions for development practices. However, the empiricism of Scrum thrives on transparency. A part of transparency lies in 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.

• Development (here as synonymous to ‘coding’) is quite essential when creating working software, our primary measure of progress. However, although code aspects like clear code, self-explanatory code, naming conventions, and refactoring are highly underrated; it is only the start.


• Code requires testing. And if all testing is to be done within a Sprint, testing skills are required in the Development Team and testing becomes part of the development activities. It gets even better if this part of development can be done first, can be automated and is performed progressively within the Sprint, not just toward the end of the Sprint.


• The releasability of an Increment produced by the end of a Sprint takes a giant leap if all integration, regression testing and alike work is done within the Sprint, and across multiple teams if working on the same product. It does help, additionally, if this work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint.


• Teams work better if they have the skills, access and mandate to perform QA work within the Sprint, and if they are also facilitated by organizational guidelines for quality, designs and architecture. Automation and progressive performance of the work within the Sprint gives another boost to building in quality.


• Many organizations keep foreseeing additional stabilization time to prepare an Increment or a set of Increments for an actual release. Imagine the gain if this work can be done within the Sprint. Every 2-3 weeks a truly releasable Increment of product is available that can be brought to the market without additional cost or work -- a good time to start thinking about continuous delivery.

A Collaborative Team

Yes, you do Scrum if you have a Scrum Team with a Development Team, a Product Owner, and a Scrum Master. And you will do even better when the team can steadily improve its relationships, trust and collaboration:

Self-organized teamwork is the cornerstone of Scrum. Teams cannot be built or constructed like a mechanical object. With support, cherishing and nurturing, a truly collaborative team might emerge.

• A team gets formed by bringing a group of people together, preferably -but not always- in a shared workspace. Most of them are in observing mode and are keeping some distance. Formal arrangements and agreements get made which the team formally starts following. Gradually, people start expressing deeper thoughts, ideas, and concerns.


• A team goes through some storming as the team members start expressing options and ideas that don’t match. They sort their differences out. At first, they might take it personally, but gradually they find a collaborative way to deal with conflicting ideas.


• The group of people jells. The whole becomes equal to the sum of the parts. They become co-operative. They better align the individual work, adjusting individual expectations. They find a productive way to deal with conflicting ideas.


• The team starts to know each other, even share more personal backgrounds. They have confidence in each other. They stop taking comments personal, stop looking for blame and stop covering up. They develop and commit to shared goals and objectives.


• The team has become a smooth, highly collaborative unit. Everyone’s focus is on the whole. The team members have passionate debates, engage on opposing ideas, look for the best possible outcomes and get their satisfaction from the group’s results. What used to take them hours and hours to sort out now only takes them a smile and a wink. 

Enjoy the scaling effect of maximizing. If you run out of improvements, consider adding teams. Choose wisely where you want to invest in first.