We don’t. Thanks, leave a like, a sub, and click the bell icon. 👋 Continue reading to get the full story.
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:
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.
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.
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:
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.
Then we thought about sprints themselves:
At the same time, there are some downsides to having sprints:
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 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:
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.