In the last email we talked about the (possible?) benefits of Scrum for the development team. Today, let’s get clear about the costs.

There’s the context switch cost of having meetings in general and Scrum is widely known (hated?) for being meeting rich. While most of them are like any other longer meeting you might have, the worst offender is probably the daily standup with some common anti-patterns. Sometimes it’s done with a team that’s too big and everybody just waits for their turn to speak, disinterested, wasting time. Sometimes it turns into a status update for the manager (“what I worked on yesterday”) rather than an opportunity to sync planned work with other team members. Finally, even done right it can still paralyse the whole team for half an hour (10 mins before - “no point in starting anything now”, 10 mins meeting, 10 mins after - “getting in the groove”), or more, every single day.

Also, there’s a significant amount of meta-work that’s introduced. That’s work that you need to do in order to be able to start the actual work (get things done). Here the worst offenders are the dreaded estimation meetings where a group of developers first discusses what a particular ticket means and later discusses whether it’s 3 or 5 points of some imaginary unit. With this process not helping delivery in any way, just for later reporting. Similarly, sprint planning meetings seem to turn into ticket-shuffling exercises, so that we can somehow align a vague sprint goal with a group of Jira tickets.

Finally, all the ticket-management is a skill of its own. One useful skill is to actually document requirements (or bugs) in a way that’s clear and easily understood for the developer who picks it up, but it needs another skill set to translate all of this neatly into Jira with its milestones, subtasks, priorities and labels. While (obviously) documenting requirements is extremely useful and a necessary part of building things (you always need a plan, even if it’s just in your head and you’re working solo), ticket-management is meta-work.

Why do we go through it then? Well, sometimes it’s useful, sometimes it’s even necessary. But it should always be discusses in terms of particular ceremonies and both their cost and value to the team (or management). How to look at this value is something that we’ll talk about tomorrow.

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.