There are only a few places on the internet that can teach you what you can read on this page. In fact, this may be the only article out there combining this know-how in a free version, available to everyone. If you want to be a part of a team that really knows how to build software, it’s your lucky day!
There are things that work consistently in every context and every team. In fact, this is why Kanban is so widely adopted today – it asks you to do things that simply work all the time, no matter what you’re working on, where you do it or how you do it. If done right, Kanban works every time.
This article is a unique guide (derived from the real practice) that explains the HOWs and the WHYs. After reading it you will able to find all the answers to the question “How Lean software development works with Kanban?”.
Enjoy.
Kanban Mythbusters
Implementing Lean software development with Kanban will help your team achieve great results. However, before we dive into the details, it’s important to bust some of the myths that we know about Kanban because people often accept them as the holy truth.
Kanban Is only for QA, Developers Should Use Scrum
This is probably the most ridiculous of all the myths. We are living proof that you can build high-quality software with Kanban, and it is by far not the only example. Actually, Kanban is so universal that you can literally do ANYTHING with it as long as you keep a few rules in mind.
Kanban Is only for Support Teams
It may be true that support teams benefit a great deal from applying Kanban to their work, but it is definitely not true that only support teams can do it. Kanban is almost a commodity for 30-40% of the software development world nowadays, and we’ve seen dozens of companies implementing amazingly good software with a set of visualization and management techniques that we essentially call Kanban.
There Is No Planning and Estimation in Kanban
While Kanban does not explicitly define planning and estimation, it does not explicitly define the lack of such either. No company out there does Kanban without some sort of planning and probably there are no exceptions to this at all. When we talk about estimation, we do something similar, but we just use different tools. So, managers, don’t be afraid that you will lose control over what’s happening and when you’re getting things released. There is a way to do things and it’s a very neat way.
Kanban Board for Software Development
Now let’s get down to business. Based on our experience, there are three categories of software development teams:
1. Software development teams working on new development as well as on support issues (most common scenario)
2. Software development teams working on support issues only (typical for internal support teams or newly formed teams learning a new product)
3. Software development teams working mainly on new development (early-stage start-ups, outsourcing companies, and a few other lucky guys)
Initially, we wanted to cover all three scenarios in a single article, but that would turn into a whole book, so we’ll only tackle the most common scenario – software development teams that work on new features as well as support issues.
Kanban for Software Development Teams that Work on New Features and Support
The first natural thing to do to get things started is to set up your Kanban board. Since we work on new features and support ourselves, it makes a lot of sense that we just share our own board and let you know what six years of learning have resulted in. This is what our RnD board looks like:
Kanban board in R&D department
We started with three columns six years back, and look what we’ve got now. It’s a real Kanvolution (the evolution of a Kanban board, a term that we’ve created). Now let’s get the columns and swimlanes explained:
Columns from left to right:
Backlog – Ideas that we may or may not implement.
Requested / Business Requirements – Ideas that are going to be developed. The business need of the work item is listed on the card.
Requested / Ready for Tech Design – Things that have been clarified and agreed to get to In Progress.
In Progress / Tech Design / Tech Design – The assignee of any card that is started writes in the technical design of what they’re about to start developing.
In Progress / Tech Design/ Ready for Review – The card is waiting to be reviewed.
In Progress / Tech Design/ Tech Design Review – A fellow team member reviews the tech design and suggests changes (if necessary).
In Progress / Tech Design/ Ready for Coding – After the tech design is finalized, the card remains here until the assignee can start coding.
In Progress / Development / Coding – Code is written.
In Progress / Development / Ready for Code Review – Cards are waiting for code review.
In Progress / Development / Code Review – The actual review stage where the code is checked.
In Progress / Ready for Production – Cards ready to be deployed on production.
Production / To be Tested on Production – Cards deployed onto production, pending a final verification by the QA team.
Done / Possible to Return – For special features requested by the customer that may be returned for rework.
Done – Done pile for non-production related items like research, meetings, etc.
Swimlanes from top to bottom:
Expedite – Super urgent cards. Everyone helps to get the item expedited. Usually, a critical customer defect, security-related issues, etc.
Customer Issues – Defects reported by customers. The customer is always first, remember?
Bugs – Internal bugs found by somebody on the team
Technical Debt – Things that we should have done :-/
Customer / Business Features – New features to be introduced in Kanbanize
Technical Features – Usually DevOps tasks, deployment-related activities, database schema changes, etc.
It’s important to note that all swimlanes represent priority. The top swimlane is the highest priority, and the bottom one is the lowest priority. You may wonder why Customer Issues, Bugs, and Technical Debt are higher on the list than Customer Features, but that’s how we keep users happy. You would be a fool to develop new features if you have a dozen major customer issues open. We never do that, and we rarely have more than one or two customer issues open.
One of the main principles of Lean software development is build-in quality. In other words, you shouldn’t allow defects to occur. This is why you need to fix any issues that you find immediately. That’s only achievable with great focus and dedication (and a great support team, of course). This is why it is worth trying Kanban in software development. Because it shows you everything and helps your team stay focused.
Let’s give a bit more details about the process involved in each of the swimlanes, as it’s important to note the actual behavioral differences related to the separate groups.
Expedite is pretty much the most critical area on the board. In fact, it is treated with such priority that everyone stops doing what they’re doing and helps to get the issue expedited. A sample expedited item would be a production-down situation, significant performance degradation, a hacker’s attack, key customer escalation, board-level escalation, etc.
What is special about this swimlane is that we allow it to exceed the WIP limits because these are almost always issues outside of our control, and we cannot predict when and how many of them will occur. However, whenever we get an item to expedite, there’s always a post-mortem analysis to reflect on why things happened the way they happened. Expediting things all the time is a terrible idea, and you should do your best to control the amount of work that flows through this swimlane.
Customer Issues are the real health indicator of your product or service. If you get huge amounts of issues piling up in the “Requested” area of your Kanban board, you have a very urgent problem to solve. Never ever allow that to happen. Otherwise, you’ll soon be in serious trouble.
Customer issues are the single most important thing on your Kanban board, no matter how minor they are and how stupid they may seem. If someone cared enough to report them to you, you must fix them as fast as you can. Yes, sometimes you have to make compromises with issues like “This image should be one pixel to the left”, but generally speaking, customer issues must be the #1 priority for your team. Period.
Bugs (internal issues) are not as critical as customer issues, but that’s a trap that most of the teams fall into. There’s a widespread saying, “If the customer hasn’t seen it, it doesn’t exist”, which is partially true, but not the preferred line of thought as far as we’re concerned.
Usually, you could divide internal bugs into two categories: old ones sitting there for ages and new ones that we created a few days back. While you could compromise on the former, you MUST hunt down and relentlessly fix the latter. That’s how you achieve a big win.
First, when you stop piling up issues, they don’t grow old, and you control the size of the backlog for open issues.
Second, at some point in time, the old issues will be too old to fix, which would give you the holy right to simply discard them, which, combined with the fact that you’ve continuously prevented new issues from aging, would result in emptying your bugs backlog. Can you imagine zero issues on your backlog? Can you?
Technical Debt (TD) is a somewhat abstract term. You could Google its official definition, but, to us, this is a flaw in the product design/architecture that would eventually lead to longer cycle times and high complexity in development and support. In fact, some product architectures are so bad that companies simply decide to ditch them and re-create the product from scratch.
This is a monstrous form of waste that is not that uncommon, especially in contexts where the communication between business and technical people is not good. You can think of TD as a mortgage – you skip your monthly payments long enough, and TA-DA, you’re suddenly homeless.
Business Features is the fourth swimlane, which makes it less important than the other three above, but it’s definitely very important. This is where value gets generated, and since we’re usually paid to generate value, it’s crucial that we flow work through this swimlane in a fast and predictable manner. In fact, the swimlanes above are a sort of investment that we make for the sake of being able to consistently produce value without being swarmed with customer complaints, escalations, and firefighting activities in the long run.
Unfortunately, very few people out there understand these priorities, and the development teams are usually forced to work on business features while dozens of customer defects are piling up, while architecture is getting worse, the complexity and the maintainability of the code are becoming a spaghetti nightmare.
When that happens, development becomes slower, and the business folks start throwing blame on the developers for being lazy: “How come you were able to produce 10 features last year, and now you only produce 4?”
Being behind schedule forces the business folks to throw new developers on the team and, following the belief that 9 mothers give birth in 1 month, they sit and wait for the results to come. “Amazingly”, results are even worse because new folks on the team always mean a delay in the short run and even more technical debt due to the lack of experience.
With the increased levels of technical debt, we become even slower, and we get even more new people on the team, which is an obvious vicious cycle already. Unfortunately, common sense is not that common in software managers these days.
The conclusion is clear: keep your customer issues, internal issues, and technical debt under control, and you will have enough time to work on new business features. It requires a lot of discipline, but it’s worth getting there, and that’s a promise.
Technical Features are lower on the list of priorities, but again, it doesn’t mean they’re unimportant. As a matter of fact, technical features may often make it to the expedited swimlane if we have an automation piece that blocks the release.
The main purpose of this swimlane is to visually separate technical features from business features and to allow better tracking of the given work type.
Theoretically, you could merge this swimlane with the business features one, but we prefer to have it on its own because the team members that operate in it are usually different from the ones that work on the business features.
Basically, this is how Kanban works for software development teams.
Now let’s check how to limit your work in progress.
How to Limit Work-In-Progress?
The next big topic is what makes the Kanban board a PULL system – the work-in-progress limits. Remember, a system is not a PULL system unless it has WIP limits. Actually, this is one of the most common misconceptions about Kanban. People frequently confuse a visual-only system with a Kanban system, which is unfortunate because you only see the benefit of Kanban if you establish the pull principle. That’s how you get statements like “Kanban is for QA only”
So how do you set the WIP limits at first place? We have a tip that you may choose to apply unless you have a better formula: team members multiplied by 2. So if you have 20 developers, you would set 40 for the entire In Progress area. If you’re really good at establishing flow through your system, you could go to 1 per person or even below that. There are a few rules to keep in mind when setting your WIP limits.
Try to lower the limit as long as it makes you faster. Generally speaking, higher limits lead to longer cycle times, and lower limits reduce cycle time (we’ll talk about cycle time later). That is why you should always try to decrease your limits (and gain speed). However, at some point in time, lowering the limits would hurt your performance, and you should be careful not to blindly follow guidelines but to actually measure your cycle times and take the necessary steps to prevent negative trends.
Start with what you’ve got. Even if you have a million cards in progress, start with that number as your limit. A limit would only make sense if it reflects reality. Otherwise, it’s just a number that people blame for global warming, world hunger, and all their problems at home.
If you have a limit, never ever exceed it. If you regularly exceed the limits on your Kanban board, you defeat the whole purpose of using Kanban for your software development team. It’s better to temporarily increase a limit and take measures to decrease it again in the future than to regularly exceed that limit and ignore the fact that this happens.
Let’s analyze the WIP limits for the RnD board that we shared above.
Theoretically, you could impose a limit on each column and sub-column, plus each cell. It’s different from team to team, but what works for us is that we have three limits on our board. We have one general limit on the main In Progress column, which controls the maximum allowed work in all of the sub-columns cumulatively.
Additionally, we want to make sure that not more than 16 cards are being worked on simultaneously by the developers. Since we don’t usually get issues with the QA team, we haven’t put any limits there.
Technically speaking, our Kanban board at Kanbanize is not a PULL system end-to-end, as we do not have a limit on the Ready for Production column. This is because we’ve chosen to work with a Takt time of one month, which essentially means that we do monthly releases, and whatever is in that column gets pushed to production.
If we don’t have this Takt time, we would pile things in that column forever, and that wouldn’t be optimal for our process. Also, the ideal approach would be that you release something to production as soon as it’s in the Ready for Production column, but this requires transaction expenses that we are not ready to pay now. If you are in the position to deploy changes as soon as they are tested by QA and there’s a real need to do so, it would be better to put a limit on that column too.
Planning and Estimation
Alright, we’ve talked about the workflow definition in a Kanban board, we scratched the surface of some theory about what should be more important and why, and now it’s time to get a bit more concrete about how things should be done. Two areas that sometimes pose difficulty are planning and estimation.
Planning in Kanban software development is not what you do with Scrum or Waterfall. In Lean and Kanban, you only “nominate” things to be worked on, and you make sure they’re in the correct column and position. Usually, the top-most Kanban cards in a column are more important, and when you pull a new card, you should take the first one. This is not enforced in any way, and it’s up to the team to decide it.
How Do We Plan the Different Classes of Work?
Expedited items and customer issues are something that we do not usually plan. They just arrived, and we work on them ASAP.
For internal bugs, we plan with two rules in mind. New issues are fixed no matter what. Old issues should be less than what they used to be last month.
We pay technical debt with each release. Approximately 10% of the time in development is dedicated to paying off the debt we’ve accumulated.
We invest all the remaining time in Business and Technical features with a ratio of 90% to 10%, respectively. The total RnD time that we invest in new features is anywhere between 40% and 70% of the total, depending on the load coming from the support channel.
How Do We Calculate the Ratios?
It’s simple, we don’t. We just work on the most important items from each swimlane, but we keep the priorities, which guarantees that, with time, the ratios will be sustainable. That might sound strange, but it’s what happens if you consistently fix all items on the first three lanes and invest in paying off technical debt. In fact, the time that you are able to spend on features gradually grows.
Who Decides What Goes in?
Our system is pretty standardized, and there’s no need for somebody to decide things, with the exception of the business features, which are the product managers’ responsibility. All other cards have the “Priority”, “Severity,” and “Complexity” fields, which point to the correct order to go by when tackling the issues. These fields are configured by the team with the participation of at least one senior member/manager. You can see what a Kanban card looks like with the fields highlighted below:
Priority, complexity, severity
First, we tackle high-priority/high-severity issues, then come high-priority/medium-severity issues, and so on. The Complexity field points out whether we should have a senior engineer working on that particular issue or not.
How Do We Estimate Work Items?
Estimation is not what Kanban is famous for, and there is a reason for that.
In Lean software development and Kanban, estimation and planning are considered as a form of necessary waste and we agree with that definition. That’s why we consider estimation in a slightly different way. We don’t care how many hours a feature will take, but we only care to know if it can be broken down into smaller pieces that would bring value to the customer.
This is so important that we’ll repeat it: Start work only on features that cannot be broken down further without losing their value to the customer.
If you do that, you’ll soon realize that estimation in story points and hours is no good.
Someone would ask, “How can we plan if we don’t know how much time work items usually take?”. Well, that’s why people use software like Kanbanize.
These tools collect all metrics for you out of the box and when you want to know how much time a feature of size X usually takes, you can just go ask the system. How do you know the size without estimation? Simple, you just log time while you work on that feature, and at the end, you will know. Not only that, but you will know the efficiency of that feature, which is the ratio between cycle time and logged time:
Kanban metrics
So we’re actually suggesting that you track how much time it takes to complete different work items by logging time to each card. When you have that information, you will know how big cards of a given type usually are and what their average cycle time is based on that size. So much more convenient than spending a day calculating story points, isn’t it?
The only disadvantage is that you won’t know this information until you have some stable history with the team, but let’s admit it, if you don’t have a history with the team, your planning and estimations would be far off anyway.
Scheduling Work
One of the common issues in a software development team (using Kanban or not) is the process of scheduling work. Scrum has a good framework for this (sprint planning), but it’s not quite optimal. It requires a lot of preparation and time, which people usually don’t have, and since what’s being worked on during the sprint depends on that meeting, we get less-than-perfect results in the end.
The lean world talks about JIT (just-in-time), which is a concept you could apply to any work that’s being scheduled. The underlying principle of JIT is do things at the right time, not earlier and not later. In the context of software development, that would translate to “replenish your TO DO columns only when you have the capacity to start new work”. There’s absolutely no sense in having sprint planning meetings if your IN PROGRESS columns are full and you cannot get new work in.
So, how do you achieve JIT with your team? First, you should agree on a minimum number of items that should be present in the READY TO START column. Anytime when you go below that number, you should pull the respective number of cards out of your REQUESTED or BACKLOG columns (in Kanbanize, this is implemented as the Card Count Business Rule). This would prevent waste from people being idle and waiting for work. Not that people being idle is always bad, but it’s bad in this particular situation.
If your work requires strict deadlines, it makes a lot of sense that you track these dates in the corresponding cards and use runtime policies to move cards across the board.
For example, if you have START DATE and END DATE custom fields, you can program the system to move the card out of the backlog when the START DATE comes and send you an email when the END DATE comes. This solves two problems, first, you don’t have to manually go and pull the card out of the backlog, and second, you’re automatically warned if the deadline is not being kept.
Scheduling work on a Kanban board
Scheduling work with run-time policies
Improve Collaboration with Kanban
Delivering results on time depends on multiple factors, one of which is the effective collaboration internally, between the team members and externally, between the team and the customer or business analyst. Relying on motivation and self-discipline does not always produce the best results, so it’s good to have a software buddy to help you out.
With Kanbanize we heavily rely on email to synchronize work across team members and external stakeholders. The subscription-based notifications scheme allows you to receive notifications in your inbox whenever certain events on the board happen. This is pretty much the standard for each of the tools out there, but what is special for us is the ability to track emails directly in a card.
A stakeholder could create a card in the RnD Kanban board by just sending an email to a special address, then developers can ask questions from within the comments tab of a card and all the replies get tracked automatically in the card. This saves a lot of time waiting for people to reply and apart from that you prevent issues from miscommunication from occurring.
Email integrations
Notifications in Kanbanize
Apart from the built-in notifications, you could also use the runtime policies module in Kanbanize to get custom notifications to be delivered to your inbox when certain events happen. For example, if you want to get an email when cards are being moved to the Business Review column, you could achieve it with a simple runtime policy:
Custom notifications in Kanbanize
Ensuring Continuous Flow
One of the Lean principles states that you should establish a balanced flow through your system. Easy to say but so hard to achieve, flow is indeed a key instrumental for high-performance software teams.
One way to establish flow is through WIP limits, which we’ve already discussed in a separate section.
Another approach you can follow is monitoring the average cycle time and acting if it grows (something which we will discuss in the next section).
A third option is to track the age of work items and take the necessary measures to complete them within a reasonable/contracted time frame.
Again, the runtime policies in Kanbanize can help you with that. All you need to do is set up a policy to detect aging cards and move them to the expedite swimlane, or send a notification, or change their color to red, or whatever works for you. A great benefit of this approach is that you are able to detect abnormalities quickly, without having to wait to see a deviation in your average cycle time. Below is a screenshot which suggests a possible runtime policy implementation:
Ensuring flow with Kanbanize
Lean Metrics for Software Development
And here it is, our favorite section – the analytics. Powerful analytics can provide you with insightful lean metrics that will help you acquire a better understanding of your work process. If you want to dig deeper into the Kanban analytics, we would suggest checking the following articles out:
Cumulative Flow Diagram for Best Process Stability
Using Scatter Plot to Measure and Forecast Cycle Time
Monte Carlo Simulations for Lean Management
Aging Work in Progress (WIP) in Lean Management
Lean Management Basics – Monitoring Flow Efficiency
Blocker Clustering for Process Improvement
Okay, that’s a lot of reading and we won’t take it personally if you don’t take the time to digest everything. That’s why we’ll try to summarize the content into a few paragraphs, just so you don’t miss the critical stuff.
The Metric of all Metrics: Cycle Time
If you should measure one thing, that should be the cycle time of the cards on your Kanban board. Ideally, you would slice the cycle time in at least two dimensions: Type (class of work) and Size (how big the item is). A third optional dimension could be Complexity, but you could start with the first two. How do you track this? With the cycle time scatterplot or histogram in Kanbanize:
Cycle time scatterplot
Another option, which gives you a lot more flexibility is the advanced search, which also provides the opportunity to draw charts out of the generated results:
Cycle time chart in advanced search
Block Resolution Time
Measuring the time a card was blocked is important because this is the most obvious indicator for sources of waste in your system. If you discover that your cards spend 30% of their cycle time being blocked, removing the root-cause for blockages would immediately result in 30% shorter cycle times.
This is huge! To get this data out of the system, you need to follow a super simple rule: whenever a card cannot proceed to the right of the board, you block it and when the card is able to proceed, you unblock it. If you only do that, going to the block resolution chart will show you this:
Block resolution time chart
Go find that chart in your Kanbanize account and start removing waste now!
These two should be able to get you started fairly quickly with the Kanban analytics. When you’re hungry for more, refer to the seven links above and you will know everything that you will ever need.
Version Control, Automation and Integrations
Since this article is about software development teams using Kanban, we must cover the topic about version control and how it works with Kanban (and Kanbanize in particular). It’s mostly a technical question related to tooling, so we’ll share how we integrate with Subversion (SVN) and GitLab.
Integration with GitLab
Check a blog post on the subject here: Kanbanize to GitLab Integration
Integration with Subversion (SVN)
The integration between Kanbanize and Subversion is similar to the one with GitLab and you can get more details here: Kanbanize to SVN Integration. One cool thing that we’ve done is to create pre-commit and post-commit hooks in our SVN repository to check the commit message and only allow the commit if a valid card ID is present. That’s how we track all commits and know which changes are related to which Kanban card, which is super useful if you want to check what happened with a bug that was fixed 3 months ago.
Additionally, Kanbanize is integrated with various other tools for your convenience. Find out more here.
Standardization
Each book about TOYOTA and Lean in general talks about standardization being the foundation for KAIZEN (the culture of continuous improvement). If you’ve been using a Kanban board to implement a big project, you would know that keeping things in order is one of the primary challenges that people have.
There’s always someone who will forget to move a card, change the card type, or put the wrong color in and what not. To tackle these kinds of issues Kanbanize offers a great arsenal of templates and runtime policies, which help you keep your board in good shape.
Using templates is as easy as one click. Once you’ve defined the templates that you need, you can just create a new card and select a template to apply. As shown in the picture below, this can create a very complex data structure with just a click:
Templates in Kanbanize
The most common application of swimlanes is to differentiate the various classes of work that you have on the board. Since you don’t want people to mess them up, which would skew your analytics afterward, you can define a “Recurring update” policy, which would scan your boards each hour and make the necessary changes for all cards that do not comply with your standards.
For example, if you want your EXPEDITE swimlane always to contain red cards with high priority, you can set up a policy to always update cards in that swimlane with the required properties.
Recurring update policy
With these two powerful tools, you can control that things are happening the way they are supposed to and forget about the tedious chores you are used to doing.
Kanban Meetings
Understanding the Lean software development concept is not difficult. Especially when it comes to one of its main principles, “Eliminate waste”, which actually comes from Kanban.
We all know that meetings are one of the major types of waste. Only if there was a way to optimize them.
Well, meetings are not our favorite ritual, but we have a set of recurring events that we recommend to every software development team.
Daily Stand-up Meetings
We’re not big Scrum fans, but we must admit that the stand-up meeting is pure genius and everyone MUST do it. This is one of the things that will never change in Kanbanize (and we almost never say never). If you have trouble getting your team on time for the meeting, do not schedule it for 9:00 or 10:00, but try with 9:07 or 10:03, it helps to stress the point that you should be there on time.
Replenishment Meetings
These meetings serve the purpose of seeding the Kanban board with items to be worked on. It’s a planning meeting of a kind, but without real planning, just prioritizing work to be completed in the next few days/weeks.
At Kanbanize, we prefer short, ad-hoc meetings to discuss which features are to be started or features that are currently being implemented. We find this faster and more productive than long and tiring meetings that generally waste people’s time.
We, as a team, have the advantage of being co-located, which gives us a lot of flexibility with this, but large, distributed teams would benefit from an official replenishment meeting with a strictly defined cadence (every week, every two weeks, every month, etc.).
Kaizen Meetings
Continuous improvement is achieved through observation, analysis, measurement, and standardization. It’s a must to have a dedicated Kaizen meeting to learn from your mistakes and agree on experiments that would trigger learning. We have short Kaizen meetings with the senior staff once a week and a big one with the entire company once a month. At these meetings, we address hot topics, inspect our analytics, collect data for further analysis, and discuss experiments to be tried in the next few months.
What Is the Bottom Line?
This page was supposed to be a short guide about software development teams using Kanban and it turned out to be a small e-book. There’s a lot of material in here, but we hope you’ll get a lot out of what we took the time to compile from our current and previous experience applying Kanban for Software Development Teams. We truly hope that you’ll benefit from what you’ve read above and get in touch if you would like to add something or object to any of the topics above.
Enjoy Kanbanizing your team, and good luck!
Dimitar Karaivanov
CEO and Co-founder of Businessmap
Dimitar is a lean thinker and a Kanban practitioner with a solid background in the areas of software development and process improvement. He is passionate about achieving extreme performance at scale and applying Lean/Agile principles outside IT.
