Basic Principles of Kanban Software Development

Kanban software development is a popular, highly visual framework that falls under the Agile methodology. It requires real-time communication of availability and capacity, allowing full transparency of all work in a team. Tasks are represented visually on a Kanban board by cards. This allows all team members to see the status of every project at any time, including not started, blocked and completed tasks.  

The Kanban methodology helps development teams improve workflow in real-time and complete more work. 

This article will explore the principles of Kanban software development.

What is Kanban?

The name Kanban comes from two Japanese words, ‘Kan’ meaning sign and ‘Ban’ meaning board. It was developed in the late 1940s by Taiichi Ohno, a Japanese engineer, on the shop floor of Toyota. In order to reduce operating costs, they began experimenting with a system that processed small amounts of raw inventory quickly. By matching inventory with demand, the Kanban system helped Toyota achieve higher quality and throughput. 

Today, Kanban software development is used by teams all over the world to complete more work in less time, with a focus on customer value.

Principles of Kanban Software Development 

The methodology is guided by four key principles.

1. Visualize Workflow

Visualizing workflow in Kanban means not only visualizing the process, but visualizing each piece of work (represented by a Kanban card) as it moves through that process. Development Teams find that making the work visible, along with blockers, bottlenecks and queues leads to increased communication, collaboration and problem solving.

Visualizing all work also helps establish accountability and transparency across the team. A blocked work item can be identified with the person or team allocated to fix it. This is invaluable, especially for development teams, which require coordinated efforts to complete their work efficiently.

To begin improving workflows, it is important to visually map the current process. Only then will opportunities for improvement become obvious. For example, the delays of a development team receiving business approval for technical designs are easier to identify and alleviate. Visualization continues once Kanban is implemented and serves as a way to communicate the state of projects and work items.

2. Limit Work in Progress

kanban work in progress

Kanban software development teams can easily get overwhelmed with their long list of work items; such as coding project work, fixing production issues, reducing code debt and maintenance work. So teams often struggle to prioritize work in an organized way.

Therefore, an important concept in the Kanban process is limiting work in process by setting a WIP Limit. By limiting how much unfinished work is in progress, can reduce the time it takes an item to travel through the system. This also avoids problems caused by task switching and reduces the need to constantly re-prioritize items.

Setting a WIP Limit for both individuals and teams can help development teams move faster, reduce errors and collaborate more effectively.

3. Focus on Flow

When the first two principles of Kanban software development are in place, work flows freely. However, you need to focus your attention on interruptions in the flow.

These represent opportunities for additional visualization and process improvements. To assist flow, pull work through the pipeline. Don’t start any new work until a work item is completed. 

Blockers

Sometimes a work item cannot continue to flow through the pipeline due to an unexpected reason, so it becomes blocked. For example, the new project code which is ready for UAT, cannot be deployed to the test environment because of a system failure. Therefore, UAT cannot start. This work item would be marked as ‘Blocked’ on the Board until the issue is resolved. The number of days blocked would be recorded for reporting later. It is a good practice for blockers to be analysed in regular refinement sessions to identify any process improvements.

4. Continuous Improvement

Kanban requires constant monitoring and analysis to look for the next best way to improve development flow and remove waste. Conditions, resources and customer demands change over time, so it is always important to continually assess flow and WIP Limits and look for blockers and bottlenecks that can be removed.

Making small and meaningful changes will help the team perform more efficiently and effectively. 

Kanban Board and Cards

Kanban software development centers on the Kanban board, either a physical one in the office located in a prominent position for the whole team to view and access or as in recent times, a virtual one using software. The main purpose of the board is to create a shared understanding of value flow. However, the board does more than visualize workflow steps, it also highlights where bottlenecks are formed in the process.

To visualize your work, identify distinct steps or stages your work goes through as it moves from ‘To Do’ to ‘Done’. These will become columns on your board. Some boards may just have ‘To Do’, ‘In Progress’ and ‘Done’ columns. For a Kanban software development team, some examples of the columns created on the board include: ‘Design’, ‘Code’, ‘Unit Test’, ‘Code Review’, ‘UAT’ & ‘Prod’.

Each project or initiative should be allocated a horizontal swimlane. 

Pro-tip: If using a physical board, it is beneficial to use a magnetic one so magnets can be used as well as post it notes, which tend to fall off after a while. 

Kanban Cards

Every work item is visualized as a separate card placed on the Kanban board. Cards are moved from left to right to show progress and to help coordinate teams performing the work. The main purpose of the card is to give team members something to track as it moves throughout the workflow. This makes invisible work visible. 

Each card can contain critical information about the work item it represents. If a physical board is being used, then there is a limit of how much information can be displayed on each card. One way around this is for a team to also use issue tracking software like Jira and to raise a digital ticket too for each work item. This method allows for the meaty details to be contained in the Jira ticket and for the bare essentials details to be displayed on the card like Jira id, work item name and an estimate of effort. The advantage of tracking software is the history of a work item is stored for future reference and all team members can access and update the tickets.  

Another advantage is it allows Agile methodology to be performed so epics can be created to group work items, for example, in Jira, an epic is created for each project. Each epic can then be assigned a swimlane on the physical board. 

Avatars and Markers

There are different flavors of Kanban Boards and Cards. One flexible way is to assign Avatars for each team member often chosen by each individual and maybe as part of a theme. The avatars can be attached to magnets and are separate from the Kanban Cards. Each member only has one avatar as they can only work on one piece of work at a time. Their avatar is positioned on top of the card they are currently working on.

Magnetic Markers can also be used to highlight work on a card since the last stand up meeting i.e. a small green marker for any work completed and red markers for any blockers. These quickly allow the presenter at the stand up meetings to identify the progress or lack of progress and any blockers of work since the last stand up meeting for discussion. Once discussed, the green markers are removed from the cards, ready for today’s work to be tracked. 

Meetings

Once a board has been created, it becomes the centerpiece for at least two regular meetings:

  • Daily stand ups: Involves all team members, to discuss progress since the last stand up. These are usually scheduled in the mornings.
  • Refinement sessions: Involves all tech leads to discuss WIP Limits, board policies, blockers, bottlenecks and ‘stale’ work that has had no recent movement. These should be weekly or bi-weekly.

These meetings aim to focus on optimizing the flow that can help development teams stay productive and efficient by moving existing cards off the board. 

Summary

Kanban software development focuses on visualizing the entire project on boards in order to increase project transparency and collaboration between team members. The aim is to control and manage the flow of work, represented by Kanban cards so that the number of work entering the process matches those being completed.

Follow the four principles of the Kanban process for your team to consistently deliver high quality software.

5 Common Distractions that Risk Breaking up Your Product Focus

Maintaining product focus is the best way to guarantee a successful business. As the late great Steve Jobs put it:

 “if you keep an eye on the profits, you’re going to skimp on the product… but if you focus on making really great products, the profits will follow.”

There are a wide variety of statistics available on how much time developers actually spend writing code, anywhere from 25% to 32%. Whichever is true, these studies show that your developers could (and should) be spending more time focusing on actually developing your product. In this post, we’re going to examine some of the common roadblocks developers face, and how you can enable them to overcome them and optimize your IT costs.

Distraction #1 – Sifting Through the Noise

A complex system or product can produce millions of logs a day. Some of them hold important information that may need to be addressed, but for the most part they simply cause a ton of noise. Noise is killer for productivity.  In order to keep things running smoothly, with minimal maintenance from developers, you’ll need a solution that can provide succinct error analysis. 

One way to do this is by clustering common logs based on shared attributes. Automated clustering of similar logs is the first step to giving your developers more time in their day to focus on product development. Coralogix uses new Streama technology to automatically analyze your logs and prioritize the ones that hold the most value for your business.

Distraction #2 – Trying to Understand What’s ‘Normal’

Understanding what constitutes ‘normal’ behavior in complicated systems is tricky. When dealing with multiple releases per day and the multiple factors involved, it gets even more complicated. 

One common way developers are alerted to the effects of system changes is by relying on threshold alerts. Threshold alerts rely on manually set parameters which are time consuming and commonly lead to false positives (i.e. more noise). Replacing these alerts with a machine learning solution that can understand your system and product’s baselines and adjust dynamically, will keep your team on task and only alert them when they’re needed. No more wild goose chases.

Distraction #3 – Staying on Top of Technical Debt

Nobody wants to worry about technical debt, that’s why it exists, but it’s important to recognize that it only becomes more troublesome as time passes. Every known error that’s released to production can mean a week of troubleshooting waiting for your developers. That’s a lot of time being pulled away from product development.

Plus, it’s expensive! If you want to try and quantify the actual cost of remediating technical debt from known errors, it’s between $3.61 and $5.42 per line of code. That cost comes from the time taken to apply fixes to issues caused by known errors in production.

Distraction #4 – Upgrading Supporting Systems

Monitoring and logging systems are incredibly important for any organization. Upgrading, managing and optimizing these systems is equally as important, but is also a huge distraction from your product. 

When your engineers upgrade your ELK stack, they aren’t focused on product development. Your ELK stack forms a powerful part of your technology, but it isn’t your product. Your development team won’t have a product-focused mindset when they are applying a fix to each index following the latest Elasticsearch upgrade. Switching to a managed log and monitoring solution will help. Focus on your product and leave log management to the specialists.

Distraction #5 – Responding to Releases

Once you release a feature, a development team with a product focus ought to be working on the next release. However, releases sometimes have unpredictable or unforeseen impacts on your overall build quality and system performance. 

The ability to carry out post-release reports on overall system performance is key for maintaining product focus. This allows your developers to move onto the next big thing.

Product Focus and Centricity with Coralogix

What’s the bottom line? A strong and independent logging and monitoring system underpins a development team’s ability to do what they do best. Coralogix provides expertise-driven out-of-the-box functional and scalable logging solutions, reducing time spent on activities which detract from product focus.

Loggregation gives your developers a succinct overview of all your log outputs, clustering them based on commonalities and saving them time when troubleshooting. Combine this with an advanced, unified UI and an intelligent open search functionality, and the time your developers spend on tasks not related to product development will reduce dramatically.

Coralogix deals with billions of logs per day for customers big and small through by offering a fully managed service. Using intelligent machine learning, Coralogix can establish performance baselines and identify known error patterns automatically. This scalable solution gives tangible relief on development resources, allowing producthttps://coralogixstg.wpengine.com/docs/user-guides/monitoring-and-insights/anomaly-detection/new-error-and-critical-logs-anomaly/ development to take priority.

Automated benchmark reports give your team total awareness of the impact that new releases will have on build quality. This Coralogix feature means that you’ll always be up to date on your system’s health.

These offering and Coralogix’s overall innovative spirit ensure that your developers will have more product focus.