Moving from Kanban to Scrum

So this is a story of how we, productivity and collaboration software creators, eat our own dog food. Deciding to move from Kanban to Scrum. Here is how it went.

When we have started developing Teamhood back in 2019, our first goal was to build ourselves a Kanban Board which in essence is the core of Teamhood – a visual collaboration solution for high-performing teams. This way we have solved our chicken and egg problem. We created a chicken first and now it is laying eggs!

Since the release of this post, we have moved to new version of our process. It is quite a fun read to see how our team’s perception changed, read more about what happened 52 sprints later.

Why we chose Kanban?

When you are running purely an R&D process and there are no strict timelines, forecasting has no big value in short term and all you focus on is the flow – the Kanban system works magic. My personal favorite about Kanban is that it makes things visual, and unpacks multitasking problems and blockers. Everyone in the engineering team loves whiteboard sessions, so having our process and tasks as a virtual whiteboard is just a no-brainer. Our workflow was quite simple, example below:

Such a simple structure made all the documentation we needed, we always ensured there is at least one task in the “Next Up” column so engineers who free up can pull it in. We also followed a strict morning standup routine to review progress and talk about impediments. This structure also gave a lot of power to streamline purely technical research work. Keep in mind though, that our pre-alpha version did not look that good and it was a complete wild west of programmer art. But nonetheless already working real-time Kanban Board. Lastly, a very important part of process shaping was our recurring retrospectives once a month.

And we have lived like that until the grand launch in September 2020. With that massive milestone being hit by our team we celebrated and cheered. Though our process started to get chaotic a bit. We got our first paying customers even pre-launch so shifting to development and operations was necessary. This is the moment when we have started moving towards a scrum-like iterative approach…

Why have we decided to move to Scrum?

Decision was simple – we had to start giving reliable forecasts for releases to support our roadmap commitments both internally and externally. We had to ensure support and regular backlog items get along together and have clear time frames. Our marketing and sales teams rely on those time frames to help manage customer expectations.

Easy choice was to go for 2 week sprints, in order to ship twice a month a minor release as well as patches if necessary.

In parallel we also have a support process that is way simpler when using Kanban, so we keep doing it there, though it is also feeding our Scrum process. To support our scope and mix of approaches we ended up having 4 Kanban boards tailored for shaping work items and flowing them into the development pipeline.
The structure looks like this:

• Support – this is where our whole team can register tickets or forward them as emails. The structure is very simple – New tickets, in-progress tickets, awaiting confirmation and resolved. We also use swimlanes for ticket priorities Urgent (must be solved in <2 business days), medium (2-5 business days), low priority (put to the backlog for next sprint).
• Roadmap unplanned – all the ideas, requests, and changes are logged here. The structure is a bit more complicated so I will skip from diving into many details but it still gets a low of transparency on how we prioritize.
• Roadmap committed – it is a board that has Kanban Swimlanes as months and simple columns to track high-level progress (see screenshots below)
• Backlog – this is the place where refinement happens and we use the prioritization structure of 3 levels to feed tasks into sprints during planning (see screenshots below). This is the most crucial board regarding the order of things so we have 3 priority levels and we always pull from P1. After P1 gets cleaned up, we push P2 to P1, and the cycle repeats.
• UI/UX – this is the stage where in parallel our UI/UX professionals work on creating necessary materials for the engineering team. Kanban board is quite detailed and a living organism on its own. We could say that it is a process inside a process 🙂 It is also grouped by UX and UI separate tasks as well as designs tailored for the marketing team to use as materials of product presentation.
• Development – this is the actual implementation board where tasks get pulled in during sprint planning and pushed out to releases after testing and acceptance.

Roadmap committed:

Backlog:

UI/UX:

Development:

To have everything under control we follow these ceremonies to support our workflow and ensure we ship working valuable software:

1. Roadmap planning and prioritization (monthly)
2. Backlog review (bi-weekly)
3. Backlog prioritization (task level) (bi-weekly)
4. Backlog refinement(bi-weekly)
5. Design prioritization and planning (ad-hoc)
6. Backlog planning (bi-weekly)
7. Smoke testing (weekly)
8. Pair testing (ad-hoc when feature ready)
9. Minor version release (bi-weekly)
10. Retrospectives (bi-weekly)
11. Feature freeze and triage (bi-weekly) – this event is used to ensure we stop coding new things and start preparing for the release. I.e. fix outstanding issues or improve non-functional things.

As you see there are 4 steps (Kanban Boards) that feed work items into development. This is an extensive refinement process to allow us outlook into the future as well as ensure we ship value which is needed by our customers.

The last but very important part of our process is estimations, during backlog refinement we estimate and breakdown features by using t-shirt sizes. Our sizing rules are as follows:

T-Shirt estimates guide

So the whole point here is to ensure we do not pull unready and too big things. Also, each work item (feature task) should be valuable to end customer and shippable in one release cycle (matching development sprint).

We still have quite some way to go until we become very good at planning and estimating, but currently, we complete the majority of committed items taking into account support tickets of high urgency. The last worthy mention is that this process is still not the textbook scrum, we call it more like scrumban because of feature triages and less strict estimation approach. But such an approach helped tremendously when switching from pure R&D to development and operations. Moving from Kanban to Scrum can be either drastic or iterative. We like to do things iteratively as we are a lean startup by heart.

Finally, to steer our process and evaluate changes we track Actionable Agile Metrics. Since this is just a dashboard in Teamhood out of the box!!! (Note we have released this feature in December, so only 3 months data is present). But we already shifted towards completing more work items than creating new ones. The weak part is that we finish 70% of items in less than 2 weeks. It has some caveats like items being created way earlier than the start of the sprint, but still, it gives us statistical data to declare if we are getting better or worse.

Key learnings while moving from Kanban to Scrum

There were so many, but I will try to mention the most significant ones.

1. Estimations are necessary to align expectations with capabilities. (T-Shirt sizing works!)
2. Estimation table with guidelines is a lifesaver when aligning or introducing new people to the team
3. Feature triage removes stress from pre-release days
4. Overcommitting is very easy and we need more slack during sprints
5. Tech debt, UX improvements, and technical tasks are a must during prioritization. We agreed to take 2 work items from each category every cycle so we keep moving things on all fronts.
6. Kanban is still the core of our visual work management process
7. Pair testing is the ultimate value producer when we catch logical or technical bugs just right after coding is done. It might sound like an overhead, but seriously – it always pops instant wins!!!

When to use Kanban?

So there are plenty of uses cases for Kanban, I will name just a few here which relate to us a lot:

1. Continuous work on standalone items
2. Support operations
3. Research & Development
4. UI/UX R&D
5. Need to visualize work

When to use Scrum?

Again, plenty of use cases, but with Scrum people usually aim to achieve predictability and ship value fast. Again few examples closely related to our case:

1. Ability to promise something and live up to those expectations with X week precision where X is your sprint length
2. Maintain a sustainable pace when supporting and developing at the same time
3. Need a formal process to organize a cross-functional team

Conclusion

All in all, it is not Kaban versus Scrum or from Kanban to Scrum, it is more like Kanban AND Scrum at the same time. I must emphasize that we continue our journey towards a formal Scrum. We might end up somewhere else, and key factors could be the growth of the team or the quality of surrounding processes which have a significant impact/demand from the engineering process. Lastly, huge thanks to the whole engineering team who are making it fun and keep getting fresh ideas on how things can be better next time. Teamhood for the win!

There are other stories about such a transition so sharing one here.

Update: As our process has evolved for the past 2 years, here are some refreshed insights into this 52 Sprints later.

Vidas Vasiliauskas

Website

2019 - Present Co-founder and CEO @ Teamhood.
2015-2019 Head of software engineering department at Danske Bank.
2017-2018 Partner Associate Professor at Vilnius University. Lecturer of Software Architecture course
2011 - 2015 Managed numerous smaller IT teams at Prewise.
Co-founder of RaveIT, Eylean, No Brakes Games

Certified Agile product owner and practitioner. Managed large scale enterprise projects as well as launch of small startup products.
MSc of Software Engineering at Vilnius University.

Hobbies: Racing, MTB cycling, Windsurfing