Introduction to Kanban and how it benefits small IT companies

Visionmate was founded almost 2 years ago. We have always tried to keep implementing new tools and methodologies to help us provide better services and maintain integrity within the team.

The goal is to always improve – otherwise, the quality deteriorates because of entropy.

Why Kanban?

When we started looking for a solution to help us with workload management for our projects at Visionmate, the obvious candidate methods were Scrum and Kanban. After investigating both, it was decided that Kanban approach was more suitable to our organisation’s requirements. This is mainly because we don’t have fixed release dates and sprints wouldn’t be as effective.

The continuous Kanban flow was definitely more appealing. The methods describes here are based on “Kanban: Successful Evolutionary Change for Your Technology Business” by David James Anderson – with modifications to fit our organisation.

Our tool of choice for issue tracking is JIRA, so we use it for our Kanban boards also. It is linked with GitHub, so we can easily track all the branches to make sure that the workflow is correct.

It should be noted that our Kanban implementation is a constant work in progress – we try to identify any issues and keep improving the workflow.

Additionally, since we are spread across 2 locations (luckily in the same time zone), we needed a cloud-based system is easily accessible for all employees and reduces overhead rather than increases it.

Kanban benefits for Visionmate

• – dramatically reduced e-mail, skype and slack communication
• – employees know what to do and pick their own tasks in a given project
• – managers have a better overview of ongoing projects and know what their teams are working on
• – Kanban boards are used to present current project status to customers
• – bottlenecks are quickly identified and can be acted upon
• – Number of work-in-progress issues has decreased, so, consequently, lead-time is also reduced
• – Since all issues are linked with GitHub branches, it’s much easier to track (and revert, if required) introduced changes

Implementation

We have divided the Kanban board mainly into 2 sections – the first one is internal (analysis, development and testing) and the second is external (UAT). We use the Kanban board to track issues accepted by the customer and only release these, while the rest can go back to development.

On a screenshot below you can see the columns belonging to our Kanban board.

Backlog

The first step is always to create a new issue in the backlog. This can be done by developers, project managers or testers. However, only project managers should be able to move issues to the input queue, where they are selected by developers for further work.

Input queue

Developers generally pick the issues based on previous experience with the application (if they worked on similar issues) or what they think will benefits the customer the most. Other criterion is of course how interesting the issues seems to be 🙂

In development

After an issue is selected, it is moved to ‘In development’ column, where is will stay until the development is considered finish. Then it’s moved to the ‘Test queue’ column. We aim to have a maximum of about 1.5 issues per developer in this column.

Analysis

If an issue requires external information from project manager/customer or requires additional research and for example for be split in future, then it is moved to ‘Analysis’ column, where it will stay until it’s ready for development again. Having too many issues in the ‘Analysis’ column is a signal to project manager that they should provide more details to the developers in order to push the project forward.

Test queue

Issue from test queue are picked up by the test team. If the developers are required to to perform testing, it is essential that they don’t pick their own tasks for testing – it’s always better to have another pair of eyes look at at your work.

Testing

Some issue may require more extensive testing and will stay in the ‘Testing’ column until this is finished.

Tested

Items in the tested column have completed internal development and are ready to be released for User Acceptance Tests (UAT).

UAT

This is where we mix Kanban board for development and business purposes. This column can be shown to our customers during progress meetings, where we discuss individual issues and receive feedback. Accepted issues are moved to done and rejected ones go back to backlog or input queue.

Done

Issues in this column are accepted by the customer and ready to be released.

The movement between columns is restricted – it is generally only allowed to move issues forward, but they might go back to the backlog at some points. This prevents chaos, which would be caused by having people move issues freely on the board.

Conclusions

Introducing Kanban boards in our workflow had dramatic (that’s not an overstatement) effect on project control and efficiency. Even the initial basic boards hadpositive impact on team morale and helped reduce chaos.

If you decide to implement Kanban approach, it is vital to try to customise it, so it fits your organisational requirements.

Additionally, especially in the beginning, benchmarking is essential – review the implementation every few weeks to ensure that it is indeed working as intended.

Future work

Of course, there are a few things which we plan to introduce in our workflow in near future in order to further improve efficiency:

• – expedite items (we rarely use them)
• – swim lanes
• – WIP limits (now we only have soft limits)

References

1) “Kanban: Successful Evolutionary Change for Your Technology Business” by David James Anderson