My team recently gave up on Scrum.
All four of the product teams at Litmus have been running fairly standard implementations of the methodology: two-week sprints, planning meetings, backlog grooming, demos, retrospectives, and the rest of it. Some teams even hold daily standup meetings despite working remotely across timezones. (Others are text-based and synchronous. My team’s daily updates are text-based and asynchronous.)
Our current focus is improving the product’s trial and onboarding experience, making a bunch of general UX improvements in important feature areas along the way. Working toward this goal means that we have more interdependencies with other departments (growth, marketing, retention) than is typical. We also sometimes act as a service centre team for those departments, further complicating how we balance competing priorities. All of this has been stress testing our rigid processes.
I love taking the incremental approach to product and applying it inwardly at how Agile teams function. Retrospectives are my favourite part of Scrum for that reason. No team is perfect, so there should almost always be at least one thing to tweak, drop, or adopt for the next cycle to see what we will learn.
With that in mind, I was obviously excited when it was proposed that our team adopt Kanban. We’ve committed to the experiment not only for two weeks, but for the entirety of the quarter. Any shorter would feel unfair. Our hypothesis is that, given the constraints outlined above, Kanban will enable us to intake, shape, build, and ship work at a more natural cadence.
2–3 weeks in, we’re slowly drifting from our former way of working. We’ve kept most existing meetings on the books, renamed, but that has more to do with the challenges of booking short-notice meetings between five people who are located eight timezones apart. Our demo schedule is beginning to adjust to our new cadence. Most noticeably so far, not having to plan, start, and end the sprint is a breath of fresh air. You don’t realise how bad incomplete sprints are for team morale until you don’t have to deal with them anymore.
As the designer on the team, I’m interested to see the effects on my relationship with the backlog.
- Will I be able to further reduce the time between my design work and when the engineers build it?
- Will stories bubble up to the top of the list of priorities at a pace that allows a comfortable workload?
- Will we inadvertently invite more “urgent” work from other departments?
Working on B2B SaaS products, I spend most of my time solving problems for teams at other companies, but I find it even more interesting to challenge, rethink, and improve the ways my own company works. The friction when suggesting or implementing even a small change internally is a good reminder of what users might be up against when adopting our tools in their teams.