Today, let’s dive into the good parts of a Scrum process. I’m taking a limited perspective of the software development team here. There are many reasons organisations choose Scrum that are not listed here. However, those benefits would apply to different parts of the organisation and it’s up to different teams to analyse them.

Scrum basically awards a protection for the team, allowing them to stop chasing moving targets. Starting with the idea of a sprint, where the team takes a chunk of work that’s ready to implement and starts on it. That means priority or scope changes are basically “frozen” for the time of the sprint - scope must be “final” if the tickets are specific enough to go into the sprint and priority doesn’t matter if the team committed to delivering everything that’s in the sprint scope.

Also, in order to get anything into the sprint, the new behaviour needs to be clearly described in a ticket with no loose ends. This means that before the sprint starts, the team must consult all the relevant stakeholders to make sure their needs align and any compromises are reflected in the final form of the ticket. That later protects the team from somebody jumping in with “that’s not what I wanted”.

One of the product owner’s responsibilities is to decide on the priority between different tasks. As they’re usually structured as a prioritised list in the backlog, you can’t have two tasks that are “equally important”. Sometimes it’s hard to weigh whether a particular request from stakeholder A is more important than a different one from stakeholder B, but Scrum points at one person to make this decision - the product owner.

Scrum doesn’t really have a concept of deadlines, but rather milestones. That basically means “stuff will get done when it’s done”. It doesn’t mean that the team can slack off, because there are still many ways (many of them rather poor) of measuring the team’s output, but it does mean that it’s much harder to set arbitrary release dates when “everything” has to be ready.

Now, all of the above is theory. In practise the protections that apply to a given team can range from nothing (where team’s forced to do sprints, but they still have to obey urgent requests to drop everything and release something that isn’t even in their current scope) to everything (where they’re free to respond with “sure, let’s put it in the backlog and we’ll get to it”).

The practical point here is to be honest what advantages does your team really get from sticking with Scrum. You might realise that there are no benefits at all (I feel you), or that actually situation’s not bad and this process does help you deliver more reliably (if not faster).

Have a good one,

Wojciech

​

PS. I have lovingly crafted this email using only the best artisanal keystrokes. If you find come across any typos, feel free to fix them yourself and enjoy this new, unique, kintsugi version.