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.
Hello 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.
Neueste Artikel von Lukas Heinen (alle ansehen)
- What you need to know about Pushtopics in Salesforce - 12. Mai 2016
- Agile Alternatives: Kanban - 1. Februar 2016
- Salesforce Deployment – Best Practices - 10. November 2015
- The Salesforce Tooling API - 28. Juli 2015
- Breaking up – a short workaround on Salesforce tables to remain scrollable - 19. Dezember 2014