100 Releases Later – Is Kanban Still the King?
It’s been 4 years and 100 releases since the very first Teamhood version went live. We released every two weeks back in the day, and we keep doing it today. And it’s almost one year since the most recent post about our process changes – 52 sprints later. So here we are, time for a new, longer read on how we do things at Teamhood and what we have learned over time.
Full chronology and order of articles in the series:
2021 – Moving from Kanban to Scrum
2023 – 52 Sprints later
2024 – 100 Releases later (current post)
💾 Current setup
Team
We run a single product team comprised of product engineers, UI/UX, and myself as a product chief. Alongside the product team, we have a customer success team that handles level 1 support while engineering does level 2. As a small team, our biggest challenge is ensuring a smooth product change delivery process. Mainly because we need to do the following things exceptionally well:
- Be focused – say NO to many things.
- Be smart – being right more times than wrong. Work heavily during the pre-development phase to ensure a high success rate.
- Be efficient – keep multitasking and multi-projecting (should I coin this term or what?) as low as possible.
- Be fast – short time to market combined with short time to learning.
I can only dream of all 4 things to be at peak all the time… It’s a constant limbo. If you lean more towards one area to improve, other areas start suffering. So it’s like a magic quadrant where you must still place a single dot for balance. A never-ending journey for the perfect balance? No. I would say it’s a never-ending journey to find the right balance based on time and context.
Practices
I will not mention all of our practices right here, but only the big ones, which I would not skip if I had to choose what to do and what to abandon.
- Biweekly release – just as a guideline. If need be, we skip a week to ensure quality is met.
- 2-month horizon for a roadmap – overplanning is a waste. A shorter timeframe reduces the risk of over-commitment. Enables on-demand planning.
- Biweekly retrospective – the key engine of progress.
- Daily “Walk the board” standup format.
Work structure
This is how we help ourselves to say NO early and to many things. We look at the product delivery process from a high level and split it into three major steps: Input, delivery, and output.
- Input – consists of multiple topic-based Kanban boards. This is where we go slow.
- Delivery – single Kanban board for daily work. This is where we go fast.
- Output – single Kanban board for things that require follow-on actions. This is where we observe and act if needed.
Support Kanban board is outside of the Input folder because it is more important than other input boards. If we go fast, we tolerate some number of mistakes. But with a commitment to fix them even quicker. Teamhood has 10,000+ active users from 1,000+ companies. On average, we land two issues weekly, requiring level 2 (technical) handling. See the data for 2024 Q3 below.
Tooling
My favorite part. Everything lives in a single system – Teamhood ;)
🚀 What has changed since last time?
This is the most important part, which I am eager to share. Everything we do has been tailored over the years for our team. So, take these points as learning examples, which can be good and bad for your own ways of working.
Team
Project lead (still as an experiment) – in some cases where domain knowledge is less demanding, we assign a single product engineer to lead the development from input to output. I still help with the pre-delivery side more, but I am also not making final decisions. The project lead role gives me the ability to increase idea diversity in the product as well as shield me from my personal biases. Some developments require scientific or engineering thinking, and here, this approach shines. Yet, we are not doing it often enough, and there is still some way left to go if I call it a full-on practice.
Practices
More attention to time in status. By having SLAs, we are even more entitled to watch closely time in status and prioritize finishing stuff before starting new stuff. And we can inspect the board anytime with a neat time in status overlay!!! (This is our personal take on metrics, show them right where the work is).
Input board review. Repeatable and unified prioritization process but done separately for each board. This helps ensure we do only the top-value things.
Use templates for every work item type. Ensure that relevant information is added based on the type of work item—for example, impact level for bugs or evidence of user demand in a feature request.
Measure and observe. Identify measurable product parts early, during pre-delivery. During delivery, ensure measurability is taken into account. After release, monitor and ensure a positive effect is reached or act to improve.
All hands smoke testing. Before every release, I create test cases related to recent developments. These test cases are performed by sales and marketing teams. The product team has its own exploratory smoke testing covering a larger product area. Every time we win, every single smoke test, we find issues that get fixed prior to the release. Easy, efficient, and valuable, everyone gets dogfooding.
Multistage QA:
- Automated unit and integration tests.
- Acceptance level tests for critical product areas (mainly because it is expensive to maintain a larger number for a fast-changing product).
- Engineer pair test before merging into the Test environment.
- Product manager’s acceptance in the Test environment.
- Engineering team smoke test prior to release.
- All hands smoke test prior to release.
- Canary release to early adopters.
Work structure
Input board per work type. Each input Kanban board is tailored for a specific work type. Each input board has an owner and review cadence. During the review, we also run prioritization. This way, we can have realistic SLAs (how long until work gets considered / answer will we do it) for every work type.
For example, the bug board is inspected on a daily basis by a 2nd level support person. The UI/UX improvement board is inspected on a weekly basis for now, but we are still checking on cadence. Such practice also ensures that every item, small or big, goes through a formal prioritization technique (usually, it’s RICE). This prevents queue jumping, a.k.a. shiny object syndrome, and similar biases.
Simplified delivery board. Previously, we had full item lifecycle mapped out in Kanban board statuses. From Idea to Refinement to Design to Re-refinement to Dev to QA to Ready to Release. Crazy…
In essence, there are 3 major steps: idea analysis, UI/UX, and Dev. All of these significant steps require review and QA process on top. With recent change, we visualize different stages as a swimlane and once the item in it gets finished, it moves to another stage and repeats all statuses again.
We have also introduced “Requires improving” and “Improving” statuses, mainly to reduce moving items back to “Do next” when issues are found. Such an approach reflects progress on things better, and we have a policy to focus on finishing items that require improvement first instead of taking completely new items. (This is my personal favorite among work structure improvements). See our board below.
Some inspiration came from this awesome video about defining workflows by ProKanban and the 55 Degrees gang.
Tooling
No changes here, Teamhood is still the best ;)
💡 Key learnings and advice for the readers
✅ Extreme programming practices are the most impactful to code and final product outcome.
✅ Retrospectives keep delivering even after 4 years. The engine of progress.
✅ All hands smoke test value vs effort ratio is unfairly high. It’s like a cheat code for small product teams. In the near future, I will still go for more engineers instead of dedicated QA people.
✅ Divide and conquer work items by type. Far better focus. Less chaos in queueing by priority.
✅ 4 eye minimum principle through out whole work item lifecycle.
✅ Isolate and separate pre-delivery and delivery stages for the best focus.
✅ Ditching sprints and estimations was the best. More time for value creation.
✅ The release schedule is just a guideline, not a prescription to follow blindly. Delaying things to make them better always works.
❌ Canary releases cannot happen less than a day prior to the actual release target. More time for real-life testing. (lesson by fire and pain).
❌ Pair testing cannot be skipped.
❌ The less time in pre-delivery, the more issues later (surprise?). So, spending more time upfront has a shorter time to value in general. Hard to balance, though, with a lean/agile mindset of learning fast. Yet, both moving fast and taking time before moving fast are inclusive, not mutually exclusive.
❓ Of course Kanban is still the King
Visual work management. Queueing. WIP limits. SLAs. Time in status. Cycle time monitoring. Item age. Kanban boards. So much value in every stage of the product development lifecycle.