Agile Alternatives: Kanban

What if a Software Engineer is doing Application Support for external customers while the development team uses Scrum-based processes? A great method to organize work load that is not only limited to one project, one customer, or even one topic is: Kanban.

LukasHello everyone and welcome to another conversation about Agile Software Development. I’ll be your guide!


Where it all started

Here at Aptly, we try to react to customer’s technical needs in a fast yet planable way. That is why we use Scrum-based processes in our development team. However, although Scrum itself is already a very flexible process, it still requires hard commitments for the user stories you schedule for the upcoming development cycle („Sprint“).

But what if a Software Engineer is doing Application Support for external customers? Application Support is a very volatile piece of work. One day, you might find yourself panicking, because a critical support case was opened with the short summary of „hey, the server went down and we cannot work at all, can you fix that in like 2 minutes please?“ – and another day, you just sit there, wondering if „42“ is indeed the Answer to the Ultimate Question of Life, the Universe, and Everything because there is absolutely no need for you to actually do work, the business is running fine.

In such an unstable situation, commiting yourself to a story within a Sprint is not possible. Believe me – I tried it, and I ended up either having an oversized work load (because Support cases were coming in high numbers) or an insufficient work load (because, well, everything was fine). However, neither did I want to limit myself to full time Application Support, nor did I want to completely abandon it. I needed to somehow be able to plan my time, take over other development tasks, while also being able to manage my Application Support work load in a decent manner.


Quitting? Not an option for me

The solution I found was Kanban. Originally, Kanban was invented as „a system to control the logistical chain from a production point of view“ but was adapted as another Agile method for Software Engineering. Kanban basically lets you manage your work load in complete disregard of where it comes from. It is a great method to organize work load that is not only limited to one project, one customer, or even one topic. But enough talk. Let’s get started right away!


However, please note that I am talking about a specific situation in which I experienced Kanban being very helpful. The following words will describe a very basic yet non-abstract Kanban setup and will conclude with a list of DOs and DON’Ts. 

But – what do we need to start?


All of them, every single task that is assigned to you. Your task is extensive and cannot be done in one day? Chunk it down in smaller tasks! You should be able to do one task in one day, maximum. I recommend that you keep the size of each task flexible, however there should not be any task that needs more than one day to be done.


Kanban basically consists of different „stations“ your tasks go through. Here is an example to get a feeling for the possible reality:

  • Open – You have not yet started this task.
  • In Progress – You are currently working on this task.
  • In Review – The task has been finished and is currently in review.
  • Done – The task has been reviewed successfully. It is done.

A Kanban board

..which basically is a physical representation of your workload. Start like this:


And put all your tasks in the right columns. It is up to you which representation of your work you choose. I for one prefer a mixture of a physical representation (for the development team, to be able to work very transparently) and a digital representation (using Atlassian JIRA).


The next steps

The most important thing when working with Kanban is: limit yourself! You can only do so many tasks at one time. Set yourself a limit of how many tasks you put in progress. But keep it low! I for one use a maximum of three tasks. I will not start a fourth one; never, ever.

Why? Well, remember what I wrote at the very start of this blog. Support. Unexpected work that needs to be prioritized over everything else from the very moment on the task arrives at your desk. If you have started five, six, seven tasks at this point, you will almost instantly lose control over your work load. And this is only one example of what might come unexpectedly. It does not hurt anyone to not start too many tasks at once.

The next thing is: know your priorities! You need to know exactly which task to start asap and which task to start later. That is why you need to put some effort into the understanding of the task. You need to know what needs to be done before you can accept a task into your Kanban lane. If someone assigns a task to you and you do not fully understand what it is about, you have to talk that person first to get the knowledge you need. Or just plan some more time to understand the requirements.

Then, you need to define what to do in special situations. There is no need to have a strict protocol for everything, however you should at least know roughly what to do in exceptional situations. A task takes way longer to finish than planned? A customer re-prioritizes a requirement in a crititcal manner? A colleague gets ill and you need to take over some of his work? Whatever happens, Kanban should be flexible enough to let you manage your work load in a decent way. After all Kanban is designed to do that.


Some last suggestions

As for me, I managed to combine the commitment to Development tasks with a very volatile Application Support work load – with the help of Kanban. Before you go please take those DOs and DON’Ts with you:


  • Have a (physical) representation of your Kanban board
  • Chunk your tasks down!
  • Keep your Kanban board up to date
  • Stay open minded. Customize the process if needed – adapt it to suit your needs!


  • Put too much In Progress (basically, don’t overcommit and underperform)
  • Be lazy in understanding the tasks you need to do
  • Let your Kanban board get out of sync with your actual, real time work load
  • Panic. You don’t need to, Kanban got your back 😉


I hoped you enjoyed reading, and if there are any questions concerning Agile Alternatives, feel free to comment here or send us a message.

The following two tabs change content below.

Lukas Heinen

Lukas is a Junior Developer at Aptly. Since he's a qualified IT specialist, his blogposts broach the issue of everday as well as special challenges and experiences, which evolve from the usage of webbased cloud-technologies like Salesforce.

2 Kommentare zu “Agile Alternatives: Kanban”:

  1. Great summary, really a good entry point for everybody who is currently suffering from too much parallel and unorganized work.

    I would just add one key element: The idea behind Kanban is flow optimization. So the next step after implementing the board and the Work in Progress-Limit would be to measure cycle- and leadtime (easyily possible by noting created date, work start date and finish date on the card), and then regularly review what is leading to high lead/cylce time.

    After several iterations of improvement you will then end up in a „flow“ state, where work is fun and customers are amazed by agility and response.

  2. Thank you, that is a very good annotation! Indeed, measuring cycle development on a regular basis is a necessary thing to be able to optimize the process. I experienced that several iterations are necessary to reach that optimal flow state you are referring to. Kanban not only allows the user to exactly do that but almost enforces it. Even with a reached flow state, further optimizations can easily be applied since the original work load that is managed by Kanban is very volatile.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.