Kanban for Software Development Teams: The Ultimate Guide

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 real practice) that explains the HOWs and the WHYs. After reading it, you will find all the answers to the question, “How does Lean software development work with Kanban?”

Enjoy.

What Is Kanban in Software Development? Backstory and Trends 

Since its birth, Kanban has served as a tool to help teams enhance work visibility and manage the flow of work to improve their efficiency and productivity. While it was born in the automotive industry, its benefits have not gone unnoticed by other industries. Without question, the sector that is closely related to this method is software development. 

Long story short, it was not that long ago when a group of industry leaders realized the potential of this method. In a relatively short span of time, Kanban has made significant inroads into software development, and ever since, it has witnessed a remarkable expansion in this dynamic sector. 

Looking at some statistics provided by the State of Kanban Report, software development continues to be the primary area of a business that adopts this method, with a quarter of all respondents. Among the main reasons software development teams rely on Kanban are complete project and process visualization, reduced cycle time, accelerated time to market, better predictability, and less risk. 

Common Kanban Myths to Ignore

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.

Myth #1: 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. In fact, Kanban is so universal that you can do ANYTHING with it if you keep a few rules in mind. 

Myth #2: Kanban Is Only for Support Teams

It may be true that support teams benefit greatly from applying Kanban to their work, but it is definitely not true that only support teams can do Kanban. It is almost a commodity for 30-40% of the software development world nowadays, and we’ve seen dozens of companies implement amazingly good software with a set of visualization and management techniques that we essentially call Kanban.

Myth #3: 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 there are probably 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 very neat.

How to Use Kanban 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 Board for Software Development Teams that Work on New Features and Support in Businessmap

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 the results of our experience. This is what our RnD board looks like:

Kanban board in R&D department in Businessmap

We started with three columns, and look at what we have 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:

How to Configure Your Board Columns (Left to Right)

• Backlog – Ideas that we may or may not implement.

• Requested / Business Requirements – Ideas that will 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 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.

How to Set Your Swimlanes (from Top to Bottom)

• Expedite – These are super urgent cards. Everyone helps to get the item expedited. They are usually critical customer defects, 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 Businessmap (formerly Kanbanize)

• Technical Features – Usually DevOps tasks, deployment-related activities, database schema changes, etc.

It’s important to note that all swimlanes represent priority. Their role is to organize and control the competing priorities of the current and unexpected work items.  

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.

How to Read Each Swimlane on Your Kanban Board? 

Let’s provide a bit more details about the process involved in each of the swimlanes, as it’s important to note the actual behavioral differences between the separate groups.

Expedite Swimlane

Expedite swimlane 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 expedite the issue. 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 sets this swimlane apart is its allowance to surpass the WIP limits. This flexibility acknowledges that these issues are often beyond our control and unpredictable in frequency. 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 Swimlane

Customer issues swimlane is the real health indicator of your product or service. If you have a large number of issues piling up in the “Requested” area of your kanban board, you have a very urgent problem to solve. Never 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 or stupid they may seem. If someone cared enough to report them to you, you must fix them as fast as you can. 

Bugs (internal issues) Swimlane

Bugs are not as critical as customer issues, but most teams fall into this trap. 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, internal bugs can be divided into two categories: old ones that have been sitting there for ages and new ones that we created a few days back. While you can compromise on the former, you have to 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) Swimlane

Technical debt is a somewhat abstract term. You could Google its official definition, but to us, it is a flaw in the product design/architecture that eventually leads 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 Swimlane

This 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 quickly and predictably. In fact, the swimlanes above are a sort of investment that we make to consistently produce value without being swarmed with customer complaints, escalations, and firefighting activities in the long run.

Unfortunately, these priorities are often misunderstood. Development teams are pressured to focus on business features while neglecting mounting customer defects. Consequently, code architecture deteriorates, leading to complexity and maintainability issues.

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.

This cycle of technical debt and team expansion leads to decreased productivity, highlighting the importance of managing customer issues, internal problems, and technical debt effectively. Discipline in this regard promises ample time for new business features—a worthwhile pursuit despite its challenges.

Technical Features Swimlane

Technical features rank lower on our list of priorities, yet they remain significant. They might even enter the expedited swimlane if an automation component obstructs the release process.

This swimlane serves to distinguish technical features from business ones, aiding in more precise tracking of each type of work. While it's plausible to merge it with the business features lane, we opt to keep it separate. This separation accommodates the distinct team members typically involved in each type of work.

Basically, this is how Kanban works for software development teams.

Now, let’s move on and check on the other kanban practices for developing teams that help them optimize and improve their overall process. 

Introduce WIP Limits to Optimize Flow

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 а visual management – 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 in the 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 remember when setting your WIP limits. 

Rule #1: 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.

Rule #2: Start with what you’ve got. Even if you have a million cards in progress, start with that number as your limit. A limit will 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.

Rule #3: 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.

Visualization of exceeding WIP limit on a kanban board in Businessmap 

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 ensure that the developers don't work on more than 16 cards simultaneously. Since we don’t usually have issues with the QA team, we haven’t set any limits there.

Technically speaking, our kanban board at Businessmap is not an end-to-end PULL system, 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 will pile things in that column forever, and that wouldn’t be optimal for our process. Also, the ideal approach would be for you to 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.

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 instrument 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 take is monitoring the average cycle time and acting if it grows (something we will discuss in another 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.

The Runtime Policies in Businessmap can help you with that. All you need to do is set up a policy to detect aging cards and move them to the expedited swimlane, send a notification, or change their color to red, or whatever works for you. A great benefit of this approach is that you can detect abnormalities quickly, without waiting to see a deviation in your average cycle time. Below is a screenshot which suggests a possible runtime policy implementation: 

Ensuring flow with Businessmap

Optimize 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. If only there were a way to optimize them.

Well, meetings are not our favorite ritual, but we have to admit that they ensure knowledge sharing between stakeholders so teams can quickly respond to changes. Having said that, 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 should do it. This is one of the things that will never change in Businessmap (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 seed the kanban board with items to be worked on. They’re a kind of planning meeting, but without real planning; they just prioritize work to be completed in the next few days/weeks.

At Businessmap, 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.

The optimal duration of this type of Kanban meeting depends on factors such as team size, context, and discussion topics. Large organizations with distributed teams worldwide, for instance,  would greatly 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.

Improve Collaboration with Kanban

Delivering results on time depends on multiple factors, one of which is effective internal collaboration between 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 Businessmap, we heavily rely on email to synchronize work among team members and external stakeholders. Our platform allows you to track emails directly in a card, and with a proper setup, you can turn your board into a ticketing system.

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 it also prevents issues from miscommunication from occurring.

Email integration

Apart from the built-in notifications, you could also use the runtime policies module in Businessmap 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 Businessmap

Prioritizing Work Items: Key Considerations in Kanban Planning 

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 on your kanban board. You should remember that the workflow stage of “Not Started” or the “Backlog” works on the principle of a reversed timeline. This means the work items most likely to be delivered first are in the rightmost column. In contrast, the leftmost column stores the future work. 

The image below will give you a better perspective of the kanban planning. 

As is clear, the planning in Kanban entails minimal upfront preparation and is not a heavy step-by-step process. Its essence lies in rearranging work items (kanban cards) within the appropriate column based on their priority (urgency, importance, and value to the customer). Usually, the top-most kanban cards in a column are more important and are ready for execution when capacity becomes available. 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 according to two rules: New issues are fixed regardless, and old issues should be less than they were last month.

We pay technical debt with each release. Approximately 10% of development time is dedicated to paying off the debt we’ve accumulated.

We invest all the remaining time in Business and Technical features in a ratio of 90% to 10%, respectively. The total RnD time that we invest in new features is anywhere between 40% and 70%, 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” field, which points to the correct order to tackle the issues. The field is configured by the team with the participation of at least one senior member/manager. 

Prioritizing work may seem challenging, but with the correct configurations on your kanban board, you can be sure that the most urgent tasks will be tackled as soon as possible. You can use different tools, such as columns, swimlanes, or color indicators, to prioritize your work optimally. Many modern software solutions feature customizable fields that enable you to create your own card attributes to reflect your unique use case. Incorporating these fields into your workflow system will enhance your ability to prioritize tasks effectively. 

Prioritizing tasks with kanban swimlanes 

To Estimate or to Forecast: Which One Is Better?

Estimation is not what Kanban is famous for, and there is a reason for that.

In Lean software development and Kanban, estimation is considered a form of necessary waste and we agree with that definition. That’s why we consider estimation in a slightly different way. Let’s elaborate on why that is. 

Estimation is a subjective process that mainly relies on opinions, experience, or presumptions to determine when a certain work item or project will be delivered. Estimating fits well in processes with defined steps and projects with clear requirements and outcomes. 

So far, so good. However, in knowledge work where unpredictable events occur regularly, and teams have to respond promptly to these changes, is estimating the best method to predict when something will be done? We don’t think so. 

For companies seeking more reliable predictions, the answer lies in stable data, not assumptions. Kanban offers a solution that leverages historical data and a wide range of insightful metrics. This is where forecasting and software like Businessmap come into play, providing a more data-driven approach than estimation.   

Fortunately, these platforms are equipped with analytical tools that help teams observe their workflow performance and collect crucial Lean and Agile metrics to make better data-driven decisions. For example, when you want to know how much time work items spend in each phase of a project, you don’t guess, you just go and ask the system.  

How to Foster Project Management Forecasts? 

Since we're discussing forecasting, there is only one powerful tool to foster project management forecasts besides Monte Carlo Simulations. Monte Carlo charts offer project managers a valuable tool for realistic data-based forecasting by running multiple probabilistic scenarios. Thus, project managers can rely on various potential outcomes for making decisions rather than solely on precise estimates. The key to successful forecasting with Monte Carlo simulations lies in the availability of historical data, with greater data accumulation leading to more accurate forecasts. 

When integrated into a kanban board, Monte Carlo analysis becomes a powerful tool for project planning. It simulates various scenarios, helping to determine the number of work items achievable within a given timeframe or estimate the duration to complete a set number of items in the future. This practical application can significantly enhance project planning and decision-making.   

The Monte Carlo How Many chart predicts the minimum number of tasks attainable within a specified period, which helps schedule product updates or meet deadlines. 

Similarly, the Monte Carlo When chart estimates the time required to complete a predetermined number of items, aiding in long-term planning and resource allocation. 

Why Estimation in Story Points and Hours May Not Be Ideal? 

We don’t care how many hours a feature takes; we only care 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. 

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 Businessmap.

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 to 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 Businessmap, 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 sense to track these dates in the corresponding cards and use runtime policies to move cards across the board.

How to Schedule Work in Businessmap? 

For instance, if you use custom fields for START DATE and END DATE, you can set the system to automatically move the card from the backlog when the START DATE arrives and to notify you by email when the END DATE approaches. This approach addresses two issues: it eliminates the need for you to manually retrieve the card from the backlog, and it alerts you automatically if the deadline is at risk of not being met.

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 suggest checking the following articles out:

Cumulative Flow Diagram

Cycle Time Scatter Plot

Monte Carlo Analysis in Project Management

Aging Work in Progress (WIP)

Monitoring Flow Efficiency

Blocker Clustering

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 into at least two dimensions: Type (class of work) and Size (how big the item is). How do you track this? With the cycle time charts such as the scatter plot or histogram in Businessmap:

Cycle Time Scatter Plot

Measuring the time a card was blocked, understanding the most common blockers, and understanding how often that happens is important because this is the most obvious indicator of sources of waste in your system. Regularly monitoring the root cause of blockages enables teams to assess and address impediments promptly, ultimately enhancing flow efficiency. 

In Businessmap, we use the Blocker Clustering chart to measure blocked time. Let’s see what it tells us.

If you discover that the blocker “Priority Override” is responsible for almost 5 days of blocked time and was used 19 times, the system will highlight this area in the deepest color. Looking at this, you immediately know that this part of your process needs extra attention to remove this bottleneck from your system. 

Block Clustering chart

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. 

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 Businessmap 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: Businessmap to GitLab Integration

Integration with Subversion (SVN)

The integration between Businessmap and Subversion is similar to the one with GitLab and you can get more details here: Businessmap 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, Businessmap 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, Businessmap offers a great arsenal of templates, runtime, and process 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. You can watch the video below to embrace the full power of the template feature:

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

Kanban policies are an agreed-upon set of internal rules that outline what needs to be done in every stage of the workflow/ process. Consider them a checklist or guidance that everyone should follow in their work. Implementing them into your kanban system will create a shared understanding of the processes, reduce rework, and leave the workflow clean and not cluttered with unfinished work items. 

Visualizing process policies on a board in Businessmap

With these three 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.

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 Businessmap and good luck!