Have you ever been at a company where perhaps Scrum was ’the process’ then suddenly a new process idea comes along that we need to follow? Teams trying to move to the Spotify model is a good example of this.

I don’t like massive process changes at all. Massive changes seem to be driven by frustration with the current situation and an eagerness to just move to something new. By making sweeping changes like this the problems that are hurting your teams right now don’t get analysed and solved. They get swept away. With a massive change comes a whole new set of problems that your teams will have to deal with.

Keep changes small.

If I need to refactor a large piece of code, I would never do it in one go. I would refactor it small parts at a time; otherwise, the risk of introducing unintended defects is much higher. Plus, when you refactor in small parts, you learn more and more as you go. I experiment. It’s not unusual for a refactor to then be refactored again because it didn’t actually fit the case it was expected to.

We should do this with our processes. If your current process isn’t up to scratch, how long has it been this way? If teams aren’t making changes and running experiments every sprint then why is that? That should be the first problem you try and solve. No company out there has a ‘magic process’ that you can copy and paste into your organisation for it to produce results. We’re too different.

Spotify didn’t get the Spotify model by looking it up; they got there by experimenting and finding something that works well for them. By experimenting.

If you want a better process start off by making a small change each sprint with what the team expects to happen. Then, at the end of the sprint compare that to what actually happened. Massive changes aren’t experiments you can validate in this way, they’re shots in the dark.

Record metrics.

I hear a lot about how velocity in scrum is a poor metric. It depends.

In order for you to find out which metrics are useful for your teams in your organisation you need to measure a set of them. Here are some examples:

• Velocity
• Cycle time
• Lead time
• Defects raised
• New stories created from scope increases
• Ticket age
• The happiness of your team
• Code coverage plus mutation testing (the mutation testing part is important)
• Cumulative flow diagrams (which let you visualise your cycle times and lead times)

Not all of those metrics will be useful to every team. But, in order to find out which ones are useful, you need to measure a range of them and compare them. You’ll soon spot the metrics that don’t provide you with any value and stop using them. Remember though, your findings aren’t universal truths that will apply to every agile team out there.