Yes, we do Scrum. And…

Publish date:

Scrum is simple, yet not easy. Scrum Binary test The Scrum Guide describes the basic rules of the game of Scrum. You can easily detect whether you are doing Scrum. It takes no more than 9 questions. If you can answer every question with a ‘Yes’, you are doing Scrum. Congratulations. We got rid of […]

Scrum is simple, yet not easy.

Scrum Binary test

The Scrum Guide describes the basic rules of the game of Scrum. You can easily detect whether you are doing Scrum. It takes no more than 9 questions. If you can answer every question with a ‘Yes’, you are doing Scrum. Congratulations.

We got rid of the “ScrumBut” expressions. We’ve moved to “ScrumAnd”. You are doing Scrum when you live up to the above expectations, and that opens up a wide range of “Yes, and” options.

Don’t feel blamed if you can’t answer all questions with a ‘Yes’. You may have an approach that works for you, that helps you build better software, that you can be proud of. However, the parts of Scrum that these 9 questions refer to have a specific objective and as a whole form the base framework that Scrum is. Doing less is not doing Scrum.

Out of personal experience, let me highlight 2 difficult ones:

  • Shippable Increment. The goal of Scrum is to produce an Increment that can be released to your users every Sprint. The ability to have all skills in the Development Team to do so often requires a profound organizational change (at least in larger organizations). This change may go beyond the power of the Scrum Master to remove this as an impediment. My advise is to get up your discipline voluntarily, truly live your professional pride and create Increments up to a supreme level of Done. Don’t hesitate to step outside of your formal responsibility by adding release work as you know will be done anyhow (even if not by you and even if you are not expected to). It will help other parts of the organization see that this work can indeed be done in every Sprint again. And do keep in mind that a less-than-shippable Increment does not have the transparency you would want. You have no clear indication on what work will still have to be done, and the delay (waste) it will take to get it out the door. The Product Owner is limited in the ability to quickly respond to market changes, business opportunities or cause change to competitors. This decreases your agility. (note: You can help stakeholders understand the problem by showing criteria at the Sprint Review that you would like to add to the Definition of Done; work that you feel belong to your software craftsmanship, but are not authorized to perform.)
  • Stakeholder involvement at the Sprint Review: stakeholders may be tempted to come to the Sprint Review, just check whether the expected scope was completed (or not), and request your past actuals (hours, estimates). It’s how they used to work, it’s how they used to seek control. But this is another world. This is no longer an industrial, algorithmic world. This is a heuristic, empirical world where we try to give stakeholders insight into reality as a base for decisions for the future. Do not call this meeting a ‘demo’. Not only because it is not a demo, it is a working meeting at which to gather feedback and have a better Product Backlog as outcome. But avoid this term also because it invokes the wrong behavior. A ‘demo’ might be very useful to keep a number of people informed about what the Scrum Team is achieving. My advise is to organize such a meeting separately. It is not a Scrum meeting, but can be seen as part of stakeholder management (by the Product Owner).

Scrum Spectral Evaluation

Beyond the mere crossing the line of ‘yes/no’ doing Scrum there is a myriad of possibilities to play Scrum.

The mandate of the Product Owner influences the level of performance you achieve with Scrum. The co-location of people influences it. The energy and joy of people influence it. The level of self-organization influences it. The fact whether people have to multi-task influences it. The availability of engineering and testing automation, tools, platforms and practices influences it. There are numerous variations in applying the base Scrum framework. And there are numerous elements that you can add to the base Scrum framework.

You can measure the way you use Scrum. Our “Scrum Improvement model” can help you identify improvement areas.

Continuous Improvement

The basics of Scrum (reflected in the 9 questions) provide a profound base upon which organizations can relentlessly and continuously improve. Use Scrum as a framework for Continuous Improvement, and look for ways to measure it. Our “Scrum Improvement model” is one step to help you.

While adopting Scrum you are likely to encounter additional needs in different areas anyhow. You start playing Scrum in a more advanced way organically and add practices to answer different needs, as you address these needs.

The following is a common adoption path:

  1. Bottom up & stealth or isolated experiments: Scrum is probably already being used without explicit permission or management even knowing about it. It helps teams to have more control over their work and enjoy their work more. The structural benefits and advantages though are kept hidden for the wider organization.
  2. PRN* Scrum for selected or critical projects or releases (* Pro Re Nata: take as needed): Scrum is used in critical circumstances, e.g. under time pressure. Or you might decide to apply Scrum for selected projects only.  The benefits of Scrum are limited to the selected projects, and seldom lead to insights in organizational improvement areas.
  3. A Scrum Studio in a contained area of the organization. An organization sets up a separate software studio that implements Scrum, and offers metrics, reports and measurements upon Scrum, its principles and its artifacts. It is a highly creative environment that fully implements the empirical approach of Scrum, its respect for people and the preference of observing actual outcomes, delivered value and customer satisfaction. The studio and its clients accept the simple truth that scope, time and budget cannot be fixed at the same time. Only projects that accept Scrum are directed to the studio. The other projects keep being done according to the existing processes. The studio provides the organization with figures on ROI, TCO, efficiency, quality, etc. in order for the organization to compare this to the non-Scrum tracks.
  4. Enterprise adoption for profound and persistent change. An organization decides to fully adopt Scrum and gradually move towards enterprise agility. A top-down change layer is connected to the bottom-up enthusiasm that thrives the existing Scrum Teams. The organization goes through a cultural change upon a sense of urgency, a change vision and a guiding coalition. The organization applies a ‘Scrum qua Scrum’ approach in using the Scrum framework as a change management framework. The organization applies John P. Kotter’s 8 steps of ‘Leading Change’ to increase its chances of success, but embeds these steps in an iterative-incremental process via change Sprints. The adoption of the change is the working Product.

The choice to which level to adopt Scrum will determine your ability to improve.

Related Posts


Agile and architecture – lessons from the trenches

Ben Kooistra
Date icon April 28, 2020

Scaling agile teams is a necessity to stay agile and keeping up business value. The agile...


Architecting the ecosystem: Five challenges for 2020 and beyond

Date icon April 8, 2020

Being agile, both in business and technology, is rapidly becoming the standard.


Industrial and agile: How to be both?

Arnaud Balssa
Date icon February 27, 2020

Distributed Agile allows companies to benefit not only from Agile methods, but also from the...