Working with Scrumban on a mature project
Choosing an agile way of working is not always straightforward. My team, one of the backend teams working with payments, has chosen to work with a version of Scrumban. It’s a way of working that combines elements from both Scrum and Kanban. In our case, we’ve gotten rid of sprints and replaced them with the continuous flow, and Work in Progress (WIP) limit of Kanban.
Why did we chose to modify Scrum in this way, or why don’t we follow Kanban all the way? The team has been along for many years and tried to use Scrum initially. It was before my time and from what I heard sprints never felt like a good fit.
From my point of view, being a team working on a mature software project, it makes more sense to always work on the thing with the current highest priority, and limit the amount of things we do at a time, rather than committing to a certain set of tasks. If we used sprints we’d need to have a hefty amount of slack to face the ever changing needs of reality.
Our daily work include a lot of moving parts such as integrating with banks and other third parties. This means that we occasionally get incidents of various kinds and those need to be handled with urgency. That means that planning to capacity is out of the window.
Our ceremonies
Stand-up — In the morning, when the whole team has arrived, we have our stand-up. During which we go through our Kanban board.
- First we talk about any emergencies/urgent issues that have come up since the last stand-up.
- After that we talk about tickets that are in review (as in they have an active pull request that needs to be reviewed).
- When we’re done with those we go through the tickets that are in progress.
By going through our work in this way we focus on the tickets that are closest to being done.
We keep it short and to the point, so the whole process is done in about five to ten minutes.
Refinement — When our backlog on the board is running low or when our Product Owner has a bunch of new tickets that he wants us to look at we schedule a refinement meeting. In the meeting we go through the tickets, flesh them out with technical details such as where in the code the change needs to be made, suggested solutions etc. Our part of the code base is about 200,000 lines so it’s paramount for us to take the time to help ourselves by adding this information when everyone’s gathered. Otherwise we might waste a lot of time looking for the place where this piece of logic lives.
Just in time prioritisation — Whenever things change, as they’re prone to do more often than not, we reprioritise our backlog. It could be anything with a high business impact, or something that needs to be handled right away. Some examples from our world are: an urgent issue for a merchant, a need to change a cryptographic certificate that encrypts our communication with a third party, or some issue with a payment file. When that happens we look at the issue, the current items in the backlog, and see where we should slot the urgent issues in. Some issue are of the type where you drop what you’re currently working on to fix this thing. Others are urgent, but can be handled as the next thing in the queue.
Retrospectives — Every two weeks we have a retrospective to look back at the previous fortnight to see what happened and how the team is feeling. I plan and run our retrospectives, and I try to keep them fresh and relevant. To do that I switch them up so that we never do the same exercise two meetings in a row. Exercises we’ve done in the past are Lean Coffee, Liked, Learned, Lacked, & Longed For, pulling something in from Retromat, or just doing a few rounds of Jimmy Cards to make the team reflect on questions we might not come up with ourselves.
Quarterly planning / swagging — On a quarterly basis we plan bigger initiatives that span multiple teams over many specialities and systems. We sit down and work out an understanding on what the feature means for us and our domain, and then we do very rough estimates on the scale of developer weeks to get a rough understanding of how many of these initiatives we can slot into a quarter.
WIP limit
The team consists of five developers, one is our Team Lead, and we’ve chosen to have a Work in Progress limit of four normal tickets and one emergency. That way we try to make sure that we collaborate on issues and that we finish what we start.
We’ve lately been experimenting with using play buttons to visualise what issues we’re actively working on. For example, when your ticket is in the review column of the board, and you might be waiting for reviews from a third party it makes sense for you to work on something new, or pair up with a team mate. To signal this you’d move the play button from that ticket to a new ticket, or if you’ll collaborate with a team mate you remove the play button from the board and add your avatar to that ticket. This way we minimise the time we wait for others. It also sends a clear signal to the team when we are starting to get swamped with unfinished items.
Our Kanban Board
The board has four major parts, which are described in detail below.
Far left — is our backlog with current prioritised and refined tasks. Whenever a team member need to start on something new that person pulls in the top ticket.
Middle left — is for tickets that are in development. Each ticket has a lane where we add smaller post-its for tasks related to the ticket. The lanes are “todo”, “in progress”, and “done.”
Middle right — is for tickets that are in review. A pull request has been created and it is waiting for a successful build in our continuous integration (CI) system, and approvals from at least two team members. Just like the in development ticket there are lanes for tasks that might pop up during the review. The lanes are mostly a legacy from the time when we used Review Board and had to trigger CI runs manually.
Far right — is for tickets where the work is completed.
- The top left is for tickets that have been merged, but are not part of the next release.
- On the top right we have tickets that are in the next release.
- The bottom left is for tickets that are released, and need to be confirmed in production. That means that we’ve checked that it works as the stakeholder wants it to, and that we don’t hit any edge cases that surfaced when the code is exposed to the large volumes we have in production.
- The bottom right is for tickets that have been or didn’t need to be confirmed.
What are your team’s ways of working?
