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! You only have to read this article once (or maybe twice) and you’ll know it all.
Statements like “there’s no such thing as a silver bullet”, “there’s no one-size-fits-all approach”, “it always depends on the context” are a popular banality. However, there are things that consistently work 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 and this article explains the HOWs and the WHYs.
Before we dive into the details, it’s important to bust some of the myths that we’re so used to hearing and probably accepted as the holy truth.
Kanban is only for QA, developers should use Scrum
This is probably the most ridiculous of all the myths. Kanbanize is the 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.
Set Up your Kanban board
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 four years of learning have resulted in. This is how our RnD board at Kanbanize looks like (as of 09 July 2015):
We started with three columns four 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.
To Do – What we want to accomplish in the near future, but it’s not yet refined and decided.
Ready to Start – Things that have been clarified and agreed to get to In Progress
In Progress / Waiting on 3rd party – Sometimes we use external libraries. If we wait for a new version of a library, we would put the card in this column.
In Progress / Development – This is where the dev team operates
In Progress / Development / Waiting – Things that have been started but cannot be worked on due to other priorities
In Progress / Development / Coding – Things actively being worked on
In Progress / Development / Biz Review – When an item is ready for QA, we first run a business review to make sure the work item complies with the business requirements
In Progress / Development / Ready for Testing – Cards ready to go to QA
In Progress / QA – This is where the QA team operates
In Progress / QA / Waiting – Cards entered the QA area of the board, but not being worked on at the moment
In Progress / QA / Testing – Cards currently being tested
In Progress / QA / Ready for Sign Off – Cards ready for a final review by a senior manager / team member
In Progress / Sign Off – Cards currently being signed off
In Progress / Ready for Production – Cards ready to be deployed on production
Production / To be Tested on Production – Cards deployed on to production, pending a final verification by the QA team
Production / Ready to Archive – All work is done, cards can be archived
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. 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.
Mobile – iOS/Android-related work
It’s important to note that excluding Mobile, all swimlanes represent priority. The top-most swimlane is highest priority, the bottom-most is 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. That’s only achievable through great focus and dedication (and a great support team, of course).
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 expedite 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 #1 priority for your team. Period.
Bugs (internal issues) are not as critical as customer ones, 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’ve 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. Monstrous form of waste, but 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, 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 and worse and while 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 means 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 expedite 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.
Mobile is a separate swimlane for the same reason – visualization of work items that make it easy for the corresponding team members to work with the board.
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 for the first time? 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 a Kanban board. 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 15 cards are being worked on by the developers. Since we don’t usually get issues with the QA team, we haven’t put any limits there. The limit on the Sign-off column is required, because quite often the PM and business guys are too busy to review what the RnD team has worked on and the limit is how you force them to do what they have to do. It’s a convenient leverage to use with people who you report to without making them hate you… “It’s the Kanban board that asks you to do your job, not me.”.
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 so because we’ve chosen to work with a Takt time of one month, which essentially means that we do monthly releases and whatever is on that column gets pushed to production. Had we not had 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, 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 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?
-Expedite items and customer issues are something that we do not usually plan. They just arrive and we work on them ASAP.
-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 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:
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. Lean thinkers tend to consider estimation and planning 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:
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 would 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 history with the team, your planning and estimations would be far-off anyway.
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 plannings), 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 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 Runtime Policy). 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 you work with strict start/end dates, 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.
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 subscripton-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 occuring.
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:
One of the lean principles states that you should establish 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 act 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:
And here it is, our favorite section – the analytics. It’s amazing how many (Kanban) tools out there don’t have the notion of charts or graphs of some sort. Not that the world doesn’t need simple tools to just visually track something, but serious software teams should care about analytics A LOT. If you want to dig deeper into the Kanban analytics, we would suggest checking the following blog posts out:
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 of this short book 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 chart in Kanbanize:
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:
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:
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 and automation
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 GitHub.
Integration with GitHub
No words needed here. Just watch the video below to see how Kanbanize integrates with GitHub:
You could also check a blog post on the subject here: Kanbanize to GitHub Integration
Integration with Subversion (SVN)
The integration between Kanbanize and Subversion is similar to the one with GitHub 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.
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:
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 afterwards, 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 to always contain red cards with high priority, you can set up a policy to always update cards in that swimlane with the required properties.
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.
Although meetings are not our favorite ritual, we have a set of recurring events that we recommend to every software development team.
Daily standup meetings
We’re not big Scrum fans, but we must admit that this 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 troubles 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.
These meetings serve the purpose to seed 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 to be 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.).
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 meeetings, we address hot topics, inspect our analytics, collect data for further analysis and discuss experiments to be tried in the next few months.
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 to 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!