Assessing the challenges in Kanban for software development teams
Why use Kanban for the software development process?
Is your team struggling with inefficiency or unstructured workflows? Kanban can help by addressing these common challenges in software development. Check whether you fall under one of them:
- You want to visualize work and process
- You want to reduce the waste of time and resources
- You want to focus on developing the most needed things
- You want to focus on finishing instead of starting
- You want to switch from a push-based to a pull-based workstyle
- You want to lower or completely get rid of multitasking
- You want to eliminate chaos and establish a more structured, predictable software development lifecycle
- You want to avoid subjective estimates and switch to data-driven/statistical forecasting
- You want to improve but do not want to change your process just because of a new method
Disclaimer: This is not a final and official list of reasons/benefits, but we believe it is a humanized way to consider the reasons for the Kanban method.
If you are relatively new to Kanban, we suggest first reading some theories about the Kanban software development life cycle.
Can Kanban be used for software development?
Kanban really works well for software development. It gives teams a clear view of their workflow, sets a limit on how much work is in progress, and keeps them focused on finishing tasks before starting new ones. This approach also cuts back on multitasking.
It helps everything run more smoothly, reduces bottlenecks, and makes it easier to predict what will happen. Kanban is great for managing software development. It uses metrics to back up decisions with solid data. Plus, it’s flexible and everyone can see what’s going on.
Which tools to use for software development with Kanban?
This is a quick shortlist of the top 3 tools available in the market based on broader research done in the best Kanban board tools post. Read more in that post to find out how tools were compared and where each tool excelled.
- Teamhood – most flexible, visual and modern Kanban system
- Asana – most classical project management with simple Kanban board
- Trello – most suitable for personal use or very small teams
How to organize your process of Kanban for software development?
Kanban usually starts with visual task boards, aka Kanban boards. We will not dive into features or specifics of boards but instead focus on structure and best practices here.
You have few options for organizing everything depending on the size of your project or the number of people.
Small project / Small team
A single board can be quite enough, primarily if the board supports swimlanes for separating task cards into different classes of service.
Medium project / Medium team
At least one board is needed for backlog / refinement and one separate board is needed for task execution. This is a very healthy split between:
- Prioritization, refinement, and planning – you must focus on quality here because once the task leaves this board, it must be finished, meaning you have committed time and resources. Quality delivery is the focus here. If the task is not prepared up front, you will end up with delays and blockers which could have been avoided. Critical policy!
- Task execution, QA, and release – flow through the board to visualize full Kanban for the software development lifecycle. For bigger teams splitting releases or post-dev steps is also an option. So eventually, you would get 3 boards.
Large project / Multiple teams
This one is the most variable. A lot depends on your process for task prioritization, planning, and execution schedule. Do teams take tasks one by one? Do teams have functional roles, and do they take only specific tasks? Such questions can help Kanban adapt to software development in larger organizations.
We recommend starting from this set of boards and then iterating:
- Prioritization, refinement, and planning – same as above, ensure quality work definition
- Design (UI/UX) – board for controlling dependencies of design tasks
- Task execution, QA – one major board for all teams; each team is split as a swimlane or task type for easier grouping/visualization
- Release and post-dev work: One board for all release-ready task cards. If your group/version releases, it can be split into swimlanes.
Metrics and forecasting
The million-dollar question is, when will it be done? Kanban employs flow metrics to answer this. By using cycle time and Monte Carlo simulation, you can achieve forecasting without subjectively estimating and sizing standalone task cards. Less time wasted, more focus on actual work! In our upcoming post, we will write more details about flow metrics and forecasting in Kanban.
Disadvantages of using Kanban in software development
While there are many benefits to look up to, there are also some downsides to the Kanban method.
- No defined roles. You will need to organize that yourself.
- Metrics and forecasting take more time to deliver value.
- Soft policies such as “do not move task cards back once they were committed” are, well… too soft
- Multi-team Kanban requires great tooling support to be
When to go for Scrum and when for Kanban?
When should your software development team choose Kanban instead of Scrum? It’s good to consider a few crucial factors like how experienced your team is, the type of project you’re working on, and how much flexibility you need. For example, Kanban might be the perfect fit if your team often deals with changing priorities and doesn’t require strict deadlines. On the other hand, if your team is working on clearly defined projects with set timeframes, Scrum could be the better choice.
You can read a real-life story of how we moved from Kanban to Scrum and why we did it.
Kanban board example – software product development
Based on our practice, we recommend trying such a structure when doing product and Kanban for software development. The team will have one board for each stage. Each stage will be broken down further into smaller steps. Click on each step for a detailed example of a real-time Kanban board.
- Support – log all bug reports, requests, and inquiries. Level 1 should own this board, while level 2 should be responsible for feedback and MTTR of L2 issues.
- Roadmap – can be used to share the vision and product changes with end users shortly. Input to a backlog.
- Backlog – Categorized items that can be taken from the roadmap, support, and other sources for prioritization.
- UI/UX – design process as a prerequisite for development tasks
- Tasks – actual task development board where the team can work iteratively or use it as an ongoing continuous production line and have only one row for “current scope”
Items can freely travel between stages to ensure scope and the best focus by respective team members. Be aware that this is just one of the examples we have developed and used throughout the years in different teams. One board can be broken down even further to represent preparation steps such as UX/UI work instead of a separate board.
You have the choice here. The bigger the team, the more detailed the process can be. Otherwise, you might feel overwhelmed by that many steps.
Our most important advice is that each board must have a clear owner, a person(s) who can define the board’s structure, coordinate with adjacent process steps, and continuously review the situation on the board to solve blockers or setbacks.
For smaller teams, it can be one person across.
Tips and Best practices for early adopters of Kanban
- Less is more, so start smaller than you want. One board maybe, then evolve. Kanban is true magic for evolution.
- Do not forget to perform recurring retrospectives to discuss improvements and successes of your new initiative.
- Be consistent—Ensure that every team member follows the same process every time they work on a card. Look for ways to make the process consistent and easy to follow.
- Keep it visual – Make sure you have an easy way to track the cards on the board visually.
- Find ways to collaborate. Kanban was designed with collaboration in mind. Look for ways to ensure that you are working as a team.
- Get feedback – Find ways to get feedback on the process and what needs to change. You can use surveys, interviews, or focus groups.
- Be flexible – Don’t get too fixated on the process. Be open to change as you get feedback from team members. Kanban is very easy to adapt.
Learn more about Kanban in the following guides:
Getting started with Kanban
The best way to start is to practice it for at least a month with your team. Then, discuss your first impressions, educate yourself, and improve. Repeat this cycle until you are satisfied with the results. We suggest watching the following video on how to start with the Kanban System using Teamhood.
Summary
In this article, we learned why to use Kanban for the software development process and the pros and cons of Kanban in software development. We also looked at when to go for Scrum and when for Kanban and how to create a Kanban board example software development.
Finally, we explored tips and best practices for early Kanban adopters. Now, it’s time to get your team on board and use Kanban to improve your software development process! Just be fearless and do not expect everything to work from the first day. Kanban is not only about tools; it is mainly about people organizing how they work.
Scalable Kanban System for high performing teams
Swimlanes, WIP limits, metrics, wiki. A true all-in-one solution.
