My high-performing team struggled with Scrum — but they shouldn’t have done Scrum at all
Scrum is not fit for all environments
Scrum isn’t working for one of the best-performing teams in our company. Scrum feels like a jail for them. They really struggle with it. And I am their Scrum Master.
Does this appear to be contradictory to you? A high-performing team struggling with Scrum? Well, maybe it is. By all measures they do things extremely well. Allow me to give you some examples:
- This team chose their own way to do deployments to production that deviated from standards. However, they made a great case for it and thus were allowed to do so. The new deployment approach makes it possible to expand the Definition of “Done”.
- The team also does brilliant Sprint Reviews. Stakeholders look forward to them. They are fun and there’s a lot of interaction on what was built and what to do next.
- Stakeholders have a big say, not only during the review, but also on a daily basis. Some of the stakeholders also work with other Scrum teams. This team however is by far their favourite. The stakeholders feel respected and see that they are able to influence the direction of the product. This doesn’t happen everywhere.
- The products that they build are very valuable to the company. They even set new industry standards.
- The retrospectives are effective too. This team embraces improvements, even if it means that they have tough nuts to crack. They hate the status quo.
- Also the dailies are great, effectively used to put the dots on the i, to be aligned on what to do next.
But…. the Sprint Planning doesn’t work. This event feels redundant. The team knows exactly what they need to do anyway. It is simply a matter of picking the next item from the Product Backlog. Also, the Sprint Planning rarely comes at the right moment. There’s no distinct rhythm of delivery of the product increments. And the team knows exactly that they can pull a next item from the Product Backlog at all times.
We saw the ineffective Sprint Planning as a problem. To repair the situation we have tried a number of things. We improved our Sprint Goal to determine a theme for the Sprint and selected Product Backlog Items to meet this goal. It did not change anything. Items were still finished ‘when they were finished’ after which a new item was selected from the Product Backlog.
The team also doesn’t see the need to make a plan to complete the Sprint Backlog. They know exactly what they need to do anyway. Hence this second part of the Sprint Planning also doesn’t add any value.
While we have been struggling with the Sprint Planning our stakeholders are very happy with the predictability, the flow of the team as they kept on delivering awesome stuff.
Eureka moment: The product environment isn’t complex
Recently I came to realise why we are struggling with the Scrum framework:
The team doesn’t have a complex product environment!
The stakeholders have a stable wish-list and the team almost always knows how they want to build the next increment. There’s no pressing need to create and to regularly inspect the Sprint Backlog.
Scrum is a framework for complex product environments. This team however doesn’t work in such an environment. Hence the team works with a framework that isn’t optimal for them.
Adapting the way of working
This realisation that we aren’t working in a complex product environment — the environment for which Scrum is created — resulted in the following ideas to advance:
- We are contemplating to drop the Sprint Planning. We have an up-to-date Product Backlog based on input from the Sprint Review and other interactions outside of the Scrum events. The team can simply pull the next item from the Product Backlog when the previous item is done.
- We will look into why we need the Daily Scrum. These 15 minutes a day are used for alignment that would be more effectively done throughout the day. We don’t use it to remain focused on the Sprint Goal anyway as there’s no added benefit to determine this Sprint Goal.
- We will probably continue to do the Sprint Review. We love the rhythm of regularly meeting with our stakeholders to show what we built and discuss what we should do next.
- We almost certainly will keep the Sprint Retrospective. We embrace regular inspection and adaptation of our way of working.
- We are looking at the necessity of the Sprint. We don’t use it to create a “Done” potentially releasable increment of our product anymore. Instead we deliver increments whenever a Backlog Item is “Done”.
- We will continue to have cross-functional, self-organising teams. This has proven to be very effective.
- We will continue to use the Definition of “Done”. We still wish to understand when we see an increment as “Done”.
- Perhaps a logical conclusion already, but we are looking at the necessity of the Sprint Backlog. We may want to go to a simple Kanban board instead which doesn’t include a goal and plan to deliver the increment.
The team plans to escape from jail, but decided to keep some stuff. Not everything is bad!
Scrum is not for all environments
Not all environments are suited for Scrum. This is why you should understand the nature of your product environment. If your product environment is complex, then Scrum is a great framework to build your products. If your product environment isn’t complex at all, be aware that Scrum may not be the framework of choice for you.
By dropping some events and artifacts my team will not be doing Scrum anymore:
“Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety […]” — Scrum Guide 2017
If you are not in a complex environment, you can still learn and use a lot from Scrum, but it’s very doubtful that the framework itself is helping you as you hope it will help you. And if you use parts of the Scrum framework, understand why you wish to use them and if this need is met with this event, artifact or role.
Don’t mindlessly use a framework or methodology without knowing why.
However if you collaborate, deliver, reflect and improve, you uncovered the essence — the Heart of Agile — regardless if you use Scrum.