Checklist to Safely Abandon Scrum
Here’s what you should address
Scrum might not work for you. That’s perfectly fine. It is not for everyone. For starters, Scrum exists to create value in complex product environments. Your environment isn’t complex? Then Scrum may not be suited for you.
On top of that, Scrum is built around a team and its stakeholders. Don’t you work with a team? Don’t you have stakeholders? Then again, Scrum may not be for you.
These are three reasons why Scrum may not work for you. There could be other reasons. But let’s not aim to be complete. That’s an impossible objective.
Whatever your reason is to abandon Scrum. I advise doing this mindfully. In this article, I will discuss the things you should take into account when you wish to say goodbye to Scrum.
Assess the context of your domain
It is of vital importance to find the best approach for your domain, what works for you. If you don’t do this, you will not be able to build the high-value products that you are looking for.
Most product environments are either complicated or complex. Some may be chaotic, others may be simple. But these are exceptions.
Complicated domain
In a complicated domain “cause and effect relationships are discoverable through analysis” — Cynefin framework, Dave Snowden.
When working on the product, you will not expect many surprises along the way. You can basically analyse, plan and execute the work spanning a longer period.
Should you come to the conclusion your environment is complicated, then you may look for alternatives in the area of traditional project management.
Complex domain
In a complex domain “the only way to understand the system is to interact” — — Cynefin framework, Dave Snowden.
Your product emerges based upon inspecting the product environment and the feedback resulting from the inspection. You don’t only inspect the product itself, but also other factors that may have an impact, like market conditions.
When you assess your environment as complex, you should look into approaches that address this. Scrum is a prime example, but it is by no means the only one.
Assess the need to have alternatives for Scrum’s commitments
Scrum has three different Commitments. All of them have an important role to play in the quest for value.
Product Goal to achieve value
Scrum commits to long term objectives with Product Goals. These Product Goals bring the team focus and commitment. Every Sprint a team chooses to work on the topics that are expected to bring them to the Product Goal fastest. To understand if they indeed do this, they need to inspect their progress regularly and adapt if needed.
Assess if you need an alternative for the Product Goal. I believe almost every endeavour needs a measure of success, translated into a goal or vision.
Sprint Goal to take steps towards Product Goal
Every Sprint, teams commit to meeting a Sprint Goal. These exist as a stepping stone towards the Product Goal. The work a team does during a Sprint is focused on meeting the Sprint Goal.
Especially when working in a complex environment it may be useful to have something similar in place, also when you abandon Scrum.
Definition of Done for quality and transparency
The Definition of Done clarifies when a product Increment is finished and ready for release. It also means the Increment is in the right state to be inspected.
When an Increment is Done, the team and stakeholders have the opportunity to have a conversation. The Definition of Done exists to allow for high-quality feedback to maximise the chances to work on the most important things next.
Quality criteria may be useful for any team creating a product. Not only because it will allow for the best possible user experience, but also for transparency on the status of the product.
The Iron Triangle of constraints
With every product endeavour, you have to balance the iron triangle containing time, cost, scope and quality. You need to be able to manage these effectively.
With the Iron Triangle:
One constraint is constrained by the other three;
You can trade between the constraints.
As an example, when time, scope and cost are fixed then quality is the only variable. So quality will decrease when scope can’t be reduced, costs can’t be increased and time can’t be extended.
Scrum and the constraints
Scrum has its own way to manage these constraints:
Quality is fixed because of the Definition of Done (DoD). The work resulting from the Scrum Team needs to adhere to the DoD.
Time is fixed because Scrum works with Sprints of consistent length. As an example, teams could work in 4-week Sprints. Sprint after Sprint.
Cost is fixed because the Scrum Teams are stable. In general, the teams remain of the same composition for a longer period. This means the costs of the people and their material is stable.
Scope is flexible. There’s no other way. For one, the other constraints are fixed. But more importantly, teams work in a complex environment and therefore will not know exactly what will happen. The scope is bound to emerge during the product journey.
Constraints and moving away from Scrum
When you stop working with Scrum, you may need to find a different way to balance your constraints. Scrum automatically helped you to control quality, time and cost. Now you may need to find new ways to do this.
Scrum also provides you with ways to work with a flexible scope with the Product Backlog and working in Sprints. Should you still wish to work with a flexible scope, you may need to look for similar alternatives.
Stakeholder management
Stakeholders play an important role in Scrum. I always consider stakeholders to be the fourth role, next to Developers, Product Owner and Scrum Master. They are key for providing feedback on your product Increment. On top of that, they bring you vital information on other aspects that may impact what you will do next.
In Scrum, stakeholders are key for a successful Sprint Review. This event is all about the interaction between Scrum Team and their stakeholders. Next to that, stakeholders can play a role during refinements and Sprint Planning.
When you say goodbye to Scrum, you may want to consider if you wish to continue to have similar stakeholder engagement and what this means for your new approach.
Product vs Project
Scrum is a framework to build and sustain complex products. It is an approach to help you out with your Product Management. With Scrum, you consider the complete lifecycle of your product.
Many other approaches are focusing on Project Management. These are about a temporary endeavour to reach a certain goal, like implementing a new user interface. With Scrum, you will typically not only focus on the introduction of the user interface, but also during the other parts of the lifecycle.
This is a vital difference. This means that you should be careful in choosing your approach after Scrum. Don’t simply replace a Product Management framework with a Project Management approach.
Team empowerment
One of the traits of Scrum is how it empowers the Scrum Team. Teams are self-managing. They alone determine WHAT they will do and HOW they do the work. On top of that, they are cross-functional. They have all the skills to create a Done Increment. This allows them to be autonomous.
Teams also adhere to the Scrum Values of Commitment, Courage, Focus, Openness and Respect.
The reason for this is autonomy and the Scrum Values foster creativity and trust. When you stop working with Scrum, you may come to the conclusion you wish to continue having similar teams.
You may also think you don’t need autonomous teams or Scrum Values. Think of the possible impact on the people in the teams. They may be very happy to be autonomous, unwilling to move away from it.
Continuous improvement
One other aspect of autonomy is the Scrum Team’s commitment to improving their effectiveness and quality. They constantly inspect if and how they can do better and take actions to make it so.
When you do away with Scrum, you might want to consider keeping this.
Wrap-Up
When you wish to stop working with Scrum, then take the following into account:
Assess your domain — is it complicated or complex?
Look for alternative ways to incorporate strategic goals, tactical goals and quality criteria.
Look into how you wish to handle cost, time, scope and quality.
Address if and how you wish to include stakeholders.
Consider if you wish to use a product management or a project management approach.
Find out how to apply team empowerment.
Determine if you wish to keep doing continuous improvements.
Scrum consists of many building blocks that are all vital for the framework to work. Taking Scrum apart may not be as easy as you would think. I hope my article helped you with this, allowing you to do this mindfully.