How we do Scrum

We don’t. Thanks, leave a like, a sub, and click the bell icon. 👋 Continue reading to get the full story.

Project history and context

We started two and a half years ago as a team of three people (an engineer, a designer, and a product owner). We didn’t have a methodology, we didn’t need to. Over time, we improved our workflow:

• Once the engineering team grew to 3 people, we started doing one-week intervals
• We switched from a spreadsheet to Jira, and we started estimating tasks using story points
• At one point we started doing dailies, but only because we weren’t in one room no more, and then we were forced into remote work
• We always deployed continuously, and we have a release process separated from deployment
• The one item work in progress limit was always a sensible default, but we never counted, and surely people had 2 or 3 items a times

The team grew, and at one point we reached a tipping point at which we switched to two-week sprints. Around that time we also started regular retrospectives. Each sprint ended with a demo and started with a list of issues agreed upon by the whole team, that was proposed by measuring velocity.

The closest we got to actual Scrum

At this point, we were almost the closest we’ve ever got to Scrum. We called our workflow Scrum, we had sprints, etc, but none of us were Scrum evangelists, nor did anyone read the scrum guide. My bet is also that nobody worked in a by-the-book Scrum team before.

That changed no soon after, as one of those Scrum enthusiasts joined our team. They previously worked in a team that was immensely improved by an agile coach, and they pushed hard for some changes, but their motivation was explicitly to deepen the methodology, rather than to find solutions for problems that bothered us. Spoiler alert, those were two distinct things.

The most sensible thing that came out of it was to improve our planning process. Instead of dragging a bunch of Jira issues into a sprint to match velocity, and then devising a sprint goal by looking at them: we started with a goal, added issues that were supposed to get us closer to that goal, and then filled up to our capacity.

In other aspects, they were mostly not successful, primarily with hiring someone for a Scrum master role. Their perseverance caused the team to question the methodology and ignited a spark to think about alternate solutions.

Dailies

We’re a team of around 10 at this point, split 50/50 between so-called business and engineering. We do not build silos in our team, and all of us meet every day to answer the three dreadful questions… It turns out most of the time the programmers try to find a euphemism for „look at the fucking Jira board if you want my status”, while non-coders recite their calendars for the previous and the current days. That’s not all there was to it, but a fair 80% if I’d have to guess. It’s clearly not working for us.

The topic is brought up during one of the retrospectives, and we agree on two new rules of thumb:

• Before saying anything, consider if it’s of interest to anybody on the team (eg, I had a meeting with someone unrelated to the project)
• Its ok to stay silent

We iterated on it a bunch of times since, but the main outcome remains: most of our dailies start with an awkward silence. And it’s kind of okay. After some time eventually, someone has a topic that concerns a part of the team and we talk about it, but other times we just start watercooler small talk or wish ourselves a good day and get back to work.

From time to time someone feels obligated to facilitate a discussion, but in my opinion that makes it even more awkward. I think 9/10 of our dailies end within 10 minutes.

Sprints

Then we thought about sprints themselves:

• We don’t have a strict roadmap (rather a prioritized list of topics), hence no smart sprint goals are possible, at least not ones that would leave us with a sense of going towards a common goal
• Usually we fail to deliver a lot of tasks by the sprint end, and they last for 2-3 days more (sometimes longer). Even the sprint goal is often missed, and nobody rushes to deploy at the last minute. That’s not an issue, since there are no external stakeholders that would enforce deadlines, and we release continuously, either way, so missing the date doesn’t have any consequences. It all stays within the team, and as long as POs are ok with it, we run with it
• Retrospectives aren’t focused around the sprint, but are more general and various topics come up
• Refinements happen weekly and are loosely related to the upcoming sprint. Sometimes we just leave the tasks in the backlog for later

At the same time, there are some downsides to having sprints:

• The goals seemed artificial, often unrealistic to complete (we knew that, and we agreed that it’s just a goal we want to get closer to, not necessarily arrive at by the end of the sprint)
• We started to rely heavily on tools (Jira) instead of interactions between team members
• The workflow didn’t fit for long-running exploratory tasks, with loose spec and unclear goals — and we started doing increasingly more of those
• The development pace is uneven. Starting Wednesday, just after the planning, we rush for a bunch of smaller issues, and most of the coders settle on one larger task. The following week is mostly spent on implementation, just to arrive at the tail end of the sprint with a bunch of pull requests, reviews, and fixes. Whoever finishes quicker might end up waiting until the next planning for new tasks.

I wholeheartedly agree that the latter issue could be solved by better planning, splitting tasks, pair programming, and a lot of other stuff. Nonetheless, we saw it as caused by the sprint cycle, regardless of how we could mitigate it.

This is not — by any means — a criticism of Scrum. We’re hardly in a position to do that since we weren’t trying to follow the methodology closely to begin with. We simply half-assed scrum and to no surprise, it wasn’t yielding the expected results.

The change

The topic of how to improve our workflow came up a bunch of times. Some of us were curious about shape up, so naturally, that cargo cult was mentioned a few times. But it was always just loose talks,

We started talking behind the scenes, me and one of the product owners, and it took us less than 15 minutes to figure out that there should be a better way for us. After quickly drafting some ideas, we confronted our ideas with some of the team members. The feedback was overwhelmingly positive. It was one of those moments: both the problem and the solution seemed obvious in retrospect, but nobody spoke out or was motivated enough to act on it.

We decided to forgo sprints, sprint plannings, and sprint goals. And at this point, we no longer claim to have Scrum, nor any other established methodology (we don’t want to fall into a cargo cult), but instead:

• We meet every week to decide what’s our main focus. Those meetings are similar to plannings and have the same outcome: to have a bunch of new issues on the board. But we also review what’s already there, go a little deeper with the status so everyone’s updated, showcase what’s already done (followed by clearing the done column), and sometimes remove tickets if they are no longer a priority.
• Instead of sprint goals, we have team goals. We build those teams on the spot, around each feature/task. This way we wanted to shift the accountability — we do not answer to Jira, we answer to Paula or Michał (our product owners). We also talk about deadlines, or rather expectations if they are relevant. Not every issue has a goal or a team. We’re flexible.
• The estimations are no longer necessary for planning, but we keep them anyway to keep POs in the loop, and to have a sanity check if we refined the feature correctly (if there is a lot of variation during estimation, then something might be off)

This did two things for us. Firstly, it solved some of the ad-hoc problems we were facing. After a few weeks with this workflow, we believe it reaches our expectations. But most importantly it gave us the confidence, that we can react to new circumstances, and introduce change. We don’t need to feel that our workflow is perfect, nor that it will pass the test of time. I’m positive that once something starts bothering us, we won’t just be stuck with a methodology that limits our moves, but rather we’d tackle it head-on and adapt.