Scrum Solo Considered Harmful

22 April

What is “Scrum solo”? It is the situation in which people think that simply requiring their teams to follow the guidelines of the Scrum Guide is enough to achieve customer delight, engineering excellence, and sustainable continuous improvement.

Scrum is an attractive framework for organising work in situations in which there is sufficient inventory of work items to establish a steady cadence of planning and development. It gives the Product Owner the ability to direct the efforts of the Development Team in order to create product increments assembling the most valuable items from the Product Backlog first.

Scrum provides an effective way of harnessing the energy of self-organising Development Teams, keeping everyone in sync through Daily Scrums, and continuously improving through effective Sprint Retrospectives. The Scrum Master is of service to the Development Team (as chief obstacle remover), the Product Owner (as a coach and facilitator), and the Organisation in which the Team operates (as a leader and ambassador).

Scrum is designed to be lightweight and simple to understand. As a positive consequence, Scrum is directly applicable and has also proven effective in fields other than software-intensive systems development as well.

However, Scrum is difficult to master, and by itself (solo), is not quite sufficient for long-term economic success and effective technical and organisational improvement in a software development context. Other influences must be blended in to complement it.

For example, Scrum is completely silent on the many engineering aspects that provide the foundation for virtually all effective Agile software development teams. Without engineering excellence, Teams can get rapidly mired in technical debt, and customer delight turns into disappointment, leading various people to mistakenly attribute failure to Scrum and by extension Agile methods in general.

The Scrum Guide is mute on topics like Continuous Integration, Pair Work, Test-Driven-Development, and so on. As a result, most of the best Scrum teams also draw inspiration from and practice many of the techniques of Extreme Programming.

Scrum also says nothing about how work might flow through the Team during the bounds of a Sprint. It is assumed that Development Teams will just figure out an effective Sprint plan.

Depending on the level of professional maturity and work habits of the Team members arriving consistently at effective plans is not always a foregone conclusion. To fill this gap, and develop a steady habit of improving the work process, most of the best Scrum teams draw inspiration from Kanban, visualising the flow of work, limiting the batch size of the Team’s efforts, and creating a smooth flow.

As yet another example, as currently defined, Scrum focuses on a single Development Team, with one Product Owner and a Scrum Master. Due to its need for simplicity, Scrum does not tackle the concerns of scaling the use of Agile methods to multiple teams or across portfolios, programs or product lines and many product releases. To address such needs, a range of frameworks have emerged, such as SAFe (Scaled Agile Framework),LeSS (Large Scale Scrum) and DAD (Disciplined Agile Delivery).

The bad news is that in this Universe there can be no “perfect” Agile team, with a “perfect” composition and work process, so even a Scrum+X+Y+Z work process cannot be expected to be the “perfect” answer. The good news is that life is full of change, and there is always room for improvement. Perfecting agility is a journey of continuous improvement, rather than a destination.

Notice how Scrum solo cannot address the full range of concerns involved in effective software-intensive systems development. If you are passionate about creating organisations that delight their customers and at the same time make work joyful for the professionals engaged in them, you cannot be content with just Scrum solo. When pursued exclusively, and especially in Teams and organisations with many inexperienced practitioners, Scrum is harmful, because it leaves too much open to mistakes, false starts and failure.

As an effective countermeasure, consider broadening your learning and practice horizon, embracing and experimenting with ideas, techniques and habits from some of the other sources mentioned above. Strive to develop a habit of identifying promising learning opportunities, run improvement experiments, measure the results, then reflect, adapt accordingly and repeat.

There is no universal “best practice” learning path. There is no single, comprehensive “recipe” for developing high-performance Teams and organisations. What works well for one Team may not be equally suitable for another. People have different attitudes, skill-sets and levels of expertise.

By all means, master the elements of Scrum, strive to use the Scrum Artefacts well, and learn to execute the Scrum Events smoothly. Then, make sure to keep learning and improving, expanding your Teams’ and organisation’s range of capabilities, skills and habits beyond the natural limits of the Scrum framework.

 

Post by Horia Slușanschi 

Thank you!

Your details have been submitted and we will be in touch.

CHAT
CALL