Some Lessons I Learned on Scrum

I've learned a lot along the way, not least that some things in Scrum shouldn't be messed with. Here's the scoop:

Like most teams we want to do lots of great stuff and deliver tons of value. We're smart, motivated engineers and we want to attack the problems the business faces. Unfortunately the real world also hands us a solid mix of support and toil tasks, features and fixes (small and medium), alongside these Big Cool Things.

If you pour all this onto a Jira board it can be a context-switching hell.

Also we don't really do sprint planning properly, and we totally don't do estimation. We do run retros at the end of the sprints and find these very valuable.

So a while back in one of the retros we came up with the idea to address the diverse work by splitting the team into two, where 50% focus only on Big Cool Things against our roadmap and the other half focus on fixes and support work. Context-switching went away, and the team was happier. Essentially we built two teams from one.

One problem was support. We felt we had to deal with all support tickets in a Kanban style, to keep the customers happy. This meant that the whole 50% 'toil' team had to switch-0ut every time a new support ticket landed, to QA it and fill out any details needed and hand it off to the queue. This was stupidly inefficient so we created what we call the 'Showrunner' role. Essentially a person chosen by a wheel of names each week who is responsible for handling the show, covering all inbound requests.

However we soon found another problem. We couldn't leave half the team in the toil role because this is not fair, it's not 'fun' work and moreover the 50% who would know how the Big Cool Things got built aren't the 50% who would have to support it! It fully breaks the Build-Run-Own model.

So to fix this we decided to rotate the teams round at the end of each sprint. This way everyone gets hands-on experience with the Big Cool Things we're doing and everyone does their share of toil. But now we're running not only 2 scrums, but also 2 sprints with 2 retros and 2 planning sessions, which means a 2-week cadence becomes a pain in the ass, so we move to 1-month instead.

So far it's working, but it's clunky. People feel more focussed and are context-switching less, and things are getting delivered and understood pretty well, though the work is mostly individual.

Then COVID-19 happened, and everything changed. Suddenly the team were all isolated, working from home, without the conversations which used to happen in the office. These conversation provide vital input from others on decisions we need to make, problems we may face, just about everything can get talked out this way. This was a huge loss to us.

The team then fell in to pairing on tasks one sprint instead of delivering individually. Pairing worked really well. It wasn't strict pair-programming, but pairing on stories. This meant a constantly available, dedicated source of feedback on each persons work, which in turn meant more things were covered to a higher quality, with an acceptable drop in pace.

Now we've built 3 2-person team-lets and kept our Showrunner (because support doesn't stop) out of one team

But now we find we created 2 more problems. Firstly that the showrunner is still dropping new tasks into the current sprint which can swamp us, and secondly that these 3 pairs were delivering 3 different things, including support, and now we're spreading ourselves too thinly and delivering very slowly. This has hard negative effects on the team's morale, and on our Big Cool Things.

I'm complicit in all this as the product owner. I didn't control priorities and allowed us to fragment the work we deliver in such a way that we couldn't realistically deliver anything in time. I believed we could do it all at once, the reality it seems is that we can't.

So we're going to attack the other end of the problem. We need to be a team to deliver high quality at pace, pushing releases out like our rugby namesakes come together to force the ball over the line. We need to focus all our effort in the right places. We need to Do Scrum Properly.

So:

• We're going back to 2-week cadence.
• We're going to do estimates, and not care that we suck at them in the beginning
• We're going to keep pairing, because this provides clear benefits.
• We're going to handle only P1s and blockers immediately. We'll park non-urgent support requests until next sprint, which is now <= 9 working days away
• We're going to split the points 40/20/20/20 between Big Cool Things / Support / 20% time /  P1s, Blockers & wriggle room
• We're going to spread the tasks in our stories across the pairs where this makes sense, so everyone learns 'how it's done'

Furthermore, from a management perspective:

• I'm going to work with the team on priority, ensuring the developers get what helps them the most, first and ensuring that if we get hijacked we can communicate the impact of it.
• We're going to build a backlog for us, and one for our customers, which will feed into this
• We're going to set 20% time in stone, to make sure people can play with things they think are valuable. We'll book 'playcation' time (needs a better name) in the calendar so we can plan sprints around this and make it transparent

We've changed before, we're changing right now and we'll change again, but I'll keep trying to remember that every problem has 2 ends, and in this case perhaps the work wasn't the problem, but how we were handling it was!

Next up I'll write up what we're going to do when we have to deliver Big Cool Things but we don't have an architecture function in the team!