This week I wanted to share my thoughts on using Scrum. The aim here is to surface its tradeoffs to help you discuss more easily whether it’s the right fit for your team. Many people have instinctive understanding when something’s not working, but it’s hard for them to put a finger on what the problem actually is. It usually manifests in expressing disappointment with “the process” and requesting to “ditch Scrum”, which often doesn’t really address the issue well.

So, let’s start with clearing up what I mean by “Scrum”. While you can argue many different interpretations, the time I’ve wasted reading agile vs Agile discussions is time I’ll never get back, so for the sake of this argument let’s define Scrum as a set of process that I’ve repeatedly seen across many organisations and teams:

* Work is organised as tickets that form a prioritised backlog

* The team chooses chunks of this work to deliver in sprints

* We measure progress in terms of story points delivered and sprint goals completed

Of course, you can always say “you’re doing Scrum wrong” if you do it this way, but… if I see it over and over again in yet another organisation, doesn’t that mean that’s the practise even though the theory might be different?

As everything else in the software developer world, following Scrum is a tradeoff. You’re introducing processes to protect the team and let them focus on delivery (for two weeks at a time), but at the same time you’re slowing them down with this new meta-work (processes that you need to follow to be able to get anything done).

In the next emails will get into details of this tradeoff, so that it’s easier to see whether your team’s seeing the good parts that were promised, or just paying the cost.

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.