Assessing the challenges in Kanban for software development teams
Why use Kanban for the software development process?
Various reasons or trigger events invoke the need to use the Kanban method for 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
- Do you want to lower or completely get rid of multitasking
- You want to be less ad-hoc and more structured on how the software lifecycle is managed
- 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 why/benefits, but we believe it is a humanized way to look at 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.
How to organize your software development process with Kanban?
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 for Backlog / Refinement and one separate board 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 to adapt Kanban for 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, post-dev work – one board for all releasable task cards. It can be split as swimlanes if your group/version releases.
Metrics and forecasting
The million-dollar question – 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 size standalone task cards. Less time wasted, more focus on actual work! More details about flow metrics and forecasting in Kanban will be written in our upcoming post; stay tuned.
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
Scalable Kanban System for high performing teams
Swimlanes, WIP limits, metrics, wiki. A true all-in-one solution.
When to go for Scrum and when for Kanban?
The best approach is always to use what is suitable for the situation. For example, you may have a team with a high level of skill and experience working on a high-visibility project, such as an internal application that few people use. In this case, it might make sense to use an approach such as Kanban, where the team has more flexibility in how it does work. But suppose you have a new team that is struggling to complete work, or you have an application that must be deployed into production consistently. In that case. In that case, it might make more sense to use an approach such as Scrum where the team has specific and consistent commitments and is following a defined process. You can read a real-life story of how we moved from Kanban to Scrum and why we did it.
Kanban boards example – software product development
Based on our practice, we recommend trying such a structure for Kanban in software product 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 for transparent sharing with end users the vision and product changes 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 which we have developed ourselves and have used ourselves 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. The choice is yours here. The bigger the team, the more detailed can be the process. Otherwise, you might feel overwhelmed with that many steps.
Our most important advice – each board must have a clear owner, a person(s) who can define the structure of the board, 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 – Make sure 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 that you have a way to track the cards visually on the board. You can pick from the best Kanban board tools to do that. Just make sure they have all the necessary features.
- Find ways to collaborate – Kanban was designed with collaboration in mind. Look for ways to make sure 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.
Getting started with Kanban
The best way to start is to practice it for a month at least with your team. Then discuss first impressions, educate yourself and improve. Repeat this cycle until satisfied with the results. We suggest watching the following video on how to start with 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 adopters of Kanban. Now it’s time to get your team on board and start using Kanban to improve your software development process! Just be fearless and do not expect all the things to work from the first day. It is not only about tools, it is mainly about people organizing the way how they work.
Scalable Kanban System for high performing teams
Swimlanes, WIP limits, metrics, wiki. A true all-in-one solution.
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
