Introduction

Software development is an industry that is always changing and reimagining itself, be it through disruptors in the Silicon Valley, startups in Colorado, or dreamers working from their home computers.  The software industry is always in flux. Often, when a company looks to move from a traditional project planning release cycle to an Agile one, they immediately think of Scrum. This is natural as it is a buzzword, a word that is used in conversations without much discussion around it. As a result many individuals confuse Agile with a method. Surprisingly many business are looking for Agile Kanban, a process to push completed code out quickly, without the overhead of Scrum. 

Agile is not Scrum.

Agile is a framework and mindset that has different options to select from. Agile is a map, neither a destination nor a method. To that end, there are several methods that work with Agile in many cases, these can be blended together to meet the needs of the company or team. One of these methods is Kanban. This is taken from the lean manufacturing principle originally created by Toyota.

In its simplest form, Agile Kanban is about releasing quality code quickly. Like Scrum, the team is cross-functional, tickets are defined as ready for work, there is a board for managing the process of the team, and everyone is working to release code once it’s ready. Unlike Scrum, there is no sprint, the board is usually simpler, and there are limits to how many things can be worked on at a time. Kanban is excellent for many organizations and even teams within an organization that are not working on a feature or project. It is incredibly well suited for teams that are focused on solving a steady backlog of issues/bugs, because they are well defined and the resolution is precise in nature. The team releases the code when it is tested and the business is ready to release the code.

Prerequisites

Moving to an Agile process requires a few basic items regardless of which method you choose.  Here is the short list of requirements that will help your transition to Kanban:

1. An organized backlog of tickets.
2. A portion of those tickets have already groomed.  These are tickets that have been reviewed by the team to ensure they are complete and ready for work.
3. A board to display tickets and their process.  This can be through a physical board and paper, or a software solution.  (If you are looking for a software solution, look for a tool that combines your needs or integrates well with other tools. Keeping your vendors to a minimum can be very helpful when it comes to maintenance, collaboration, and cost.)
4. A team that is made up of the required skills to complete tickets.  This can include a list of people from other departments who can help answer questions about domain specific areas outside of the department.

Who is part of the Agile Kanban team?

The team is made up from various individuals who each bring a unique set of skills needed to complete the work in the backlog. A development team is usually made of several developers, one or two testers, a product owner, and a project manager.  

• The product owner is someone who owns the backlog of work for the team. They are responsible for making sure that the team understands the nature of each ticket, the work involved to be completed, and the priority of each ticket. They represent the Business/Company to the team.
• The project manager is responsible for keeping the team on track, through regular discussions/meetings (such as standups), and working to resolve team blockers.  
• The developers and testers work to complete the tickets and move them  from “To Do” to “Complete” by working together.  This is through discussion of the tickets, creation of test cases, and creating unit tests.

How does Agile Kanban work?

Kanban is a Japanese word that roughly means “billboard” or “sign board”, it is a location where work is tracked and moved through a process. In a manufacturing sense, an individual will take a card and see what the current status of work is and then begin the next step.  Whether it’s assembling a car, a closet door, or a patch for software, it is about following instructions on the card/ticket and making sure that all the steps are completed before releasing it to the customer.

In a software company, this is done by keeping a maintained backlog of tickets/issues that need to be completed. The product owner controls the backlog and can arrange the priority of tickets on a daily basis to meet the needs of the company.  Priorities for the day should be discussed and fixed before the team meets.  This represents a big difference from Scrum.  In Scrum, the team commits to the workload in a sprint along with the priority.  In Kanban, the priorities can change based on the needs or issues of the business.  

The team meets daily to discuss their status around their board.  They discuss what they completed the previous day, what they are working on, and their issues/blockers.  This is the basic standup that is seen in Scrum.  Here the product owner can let the team know if there’s a change to the priorities for the day and if there are new inputs from the company.

The Agile Kanban board is a simple board that has three or four columns.  A traditionalist approach to the Kanban board would be three columns: “To Do”, “In Progress” (X), and “Done”.  A more common software team would include the column “Test” (Y). When looking at this board, you would know that X and Y refer to the number of tickets that are allowed to be in the column. An example of this is shown in the table below:

To Do	In Progress (3)	Test (4)	Done
ABC-123 ABC-124 ABC-126 ABC-128 ABC-130 ABC-129	ABC-118 ABC-99 ABC-127	ABC-110 ABC-115 ABC-117 ABC-116	ABC-111 ABC-112 ABC-113 ABC-114 ABC-109 ABC-108 ABC-107

 

In the example above, everything is in correct order, the “In Progress” and “Test” columns are at their maximums.  This is an area of potential concern from the team.  If the tickets in “Test” take longer to complete than the tickets that are “In Progress”, the developers can’t take on more work.  The mistake many teams make is adding another column that amounts to “Test To Do”.  This only complicates the work and degrades the code quality.  

The correct answer at this point is to look at how the developers can help the testers or the overall code quality.  The developers could start by ensuring they have completed unit and integration tests that cover all scenarios for the tickets they have already begun or completed.  They could review the test cases created by the testers and offer to help test the tickets that they didn’t code.  The last part of that sentence is very important.  Developers should test their tickets before giving them to the tester, but they shouldn’t test their ticket once it has been moved to the “Test” column.  Once the ticket has moved to “Test”, another developer should test the ticket.  The reasoning is simple, you often miss the mistake that you made.  Once the “Test” column comes out of it’s maximum, new tickets can be moved into the “Test” and “In Progress” columns.

Tickets in the “Done” column represent your Release Candidate (RC). This is your potentially shippable product that is ready for regression testing, integration testing, and release to production.  Once you have completed your RC testing, you can release it to production. Ideally, you would be releasing code frequently to production, such as in a Continuous Delivery model.  If your company is not at that stage yet, you will need to estimate the time you need for completing your RC testing and base your decision on that.   

If a physical board is not possible, be sure to look for an application that allows you to access it when and where you are located. I recommend keeping your applications to a minimum so that transparency can be kept and integration issues be limited.

Why use Agile Kanban?

Agile Kanban is an excellent option for several types of teams and organizations, but is sometimes overlooked by Scrum. So here are two scenarios where Kanban makes a lot of sense:

1. Your organization is new to Agile and wants to start somewhere.
2. Your team is doing mostly production support or maintenance.

Scenario 1 might not seem common for a development company, but not all companies that produce code are development companies.  You might be a large organization that is looking to become more agile and responsive to customer needs. You might be an IT department looking for a better way to make your Service Level Agreements or demands of your company.  In any case, if you are new to Agile, Kanban is an excellent way to move your organization forward.

In the case of scenario 2, if you have an established product and the backlog has more bugs than feature request. If most of your tickets are bugs or small focused changes, then Kanban is a better solution for your team than Scrum.  Scrum would create more overhead to the team when your primary goal is releasing tickets.

Conclusion

Two of the most important aspects being Agile are trying and retrospecting. It is often forgotten or misunderstood that you should try new options and techniques. Your team must be open to new ideas, inputs, and techniques. Your team should be engaged in the process. When they are, they will be proposing solutions to the processes and to problems that you were unaware of.

It is likely that one size does not fit all within an organization or team. A retrospective is a meeting that has the team look back over a period of work and reflect on what went well, what didn’t go well, and where they can improve. With Scrum they happen at the end of a sprint, in Kanban since there are no sprints, you need to schedule them.  Ideally, you should schedule them at least monthly, so that suggestions for improvement are acted on early. Processes should be put in place to help the team develop, test, and release code. When processes get in the way of releasing code or don’t protect the team, they should be reviewed and gotten rid of, when possible. Your retrospectives will help you and the team identify these and empower them to help you resolve them.

Kanban is a useful method of being Agile, but it is only as good as the team’s commitment is.