I don’t like writing… but I love storytelling…
At the end of the software development project, everyone was happy that it is over. From now on the team of developers could sleep well (or sleep at all). But, just as it happens in real life – the ending didn’t mean “finito”.
Prince Maintenance appeared at the developers office door – he was invited to be a part of the team to develop and improve the software. From the beginning he warned everyone politely but strongly that he is a rather difficult guy to work with. He loves bugs difficult to solve. He loves making surprises and bringing new features and bugs at any time, even at night… especially at night, and at the end of a working day. Also, he doesn’t believe that developing software may be so time-consuming and difficult. Once he wrote a program “Hello world” and it was easy-peasy. Moreover, everything for him is high-priority and has to be ready in no time at all. Generally speaking – he is unpredictable, unstable and demands to be loved and adored.
The team was devastated – besides King Business, who, coming from holiday in Japan announced his decree “Constant improvement and enhancing quality of the software is a top priority for everyone. That is why Prince Maintenance is in charge. Everything depends on him: satisfaction, profit, even the life of the team. You must listen to Prince Maintenance carefully.”
Black clouds appeared over the head of developers in spite of the fact that they were in the roofed office.
From that day their life became hard. Everything what PM said was true. The developers tried to change their situation by planning, prioritizing and supporting each other. Unfortunately, their whole effort was pointless. Every time they planed something, PM came up with the most urgent task in the world. When strange bugs appeared he yelled at everyone pointing that profits have just plummeted because of that. Few developers left to move to the wilderness.
The PM’s rules could last for a long time and life of the team could be still hard. But just as it happens in real life – there is always hope.
One day Japanese General showed up in the office. His name was Kanban. The truth was that he wasn’t a real General but a seller of signboards – he lied to earn respect of PM. he introduced new order straight away, saying:
First, we must limit your work at the time so to eliminate overload. Everything needs to be transparent and ordered so we start to visualize the workflow. Your workflow will be measured and managed to improve your performance.
The PM’s reaction was immediate. First, he turned pale, then he choked with a buttery biscuit and finally he fell off the throne. General Kanban was a gentleman and helped PM to get up, assuring him that this is not the game of thrones and that he is still very important and doesn’t need to change. General knew that changing people might cost breaking agreements and war in the best scenarios.
So how should we start? –the team asked.
First, we should eat lunch, as working on an empty stomach is unhealthy and makes me aggressive.
After lunch, General Kanban decided to show everyone the board. He took out one from his briefcase.
Dude, do you really think that we will work on this offline piece of wood?
No, this is only a board with a warning sign – “Bad dog” Real Kanban’s board is here.
He logged in to the online software and presented the board.
This is the Kanban’s board. You might call it Kanban or whatever you want. There will be also cards that represent your features or bugs.
You put them on the board. There are stages reflected by your flow of tasks. For example, if your work with Maintenance you can divide your work into following stages:
- Backlog – the stage where you gather all new features or bugs
- Requested – the step when you plan which features and bugs will be released
- Suspended – the stage where all feature withdrawals are put
- Development – the stage of developing features or fixing bugs
- Test – the time for features and bugs testing/retesting
- Deploy – the stage when tasks and bugs will be deployed in production systems
Obviously there is a cycle: plan, execute, finish. What about unplanned defects that PM constantly brings during our development stage? – the team asked
It’s ok. They can appear – replied General. The decision about bugs is either fix it or drop it. The important thing is that there is limitation. Every stage has defined work-in-progress limitations, meaning how many tasks can be done at a given time. This is the number on top of the columns. So, if bugs that have to be resolved appear, move tasks from the Development In Progress stage with the last priority to the Suspended stage. See below. The goal is to get a new task as soon as capacities are available, instead of overloading team’s stages with work-items. After fixing the bug the suspended task is moved to its previous stage.
Hey Prince – General Kanban turned to PM – I lied telling that you don’t need to change. From now on you have to cooperate with the team, and accept that no one can work more than we agreed. However, you still rule. You are responsible for managing tasks. Let’s look…
- From Monday to Wednesday you plan tasks and priorities, by putting the cards on the board in the column named Requested.
- Since the development team has the capacities available they pull the cards into the Development In Progress column and start working on the tasks defined on them. This allows you to put new cards on the board.
- When the developers finish the card, the tests might start. Only then they can pull a new card. Everyone should remember about priorities defined during the planning phase.
- After the testing stage, the deployment might start. It’s good to deploy more features or fixes than one at a time. Such set of work items we might call a fix pack. It flows through the stage.
The steps are easy, but what to do when someone is slower than the others? For example, the development team is blocked due to a problem with the deployment team –one of the programmers complained.
In such a situation, you should merge for solving the problem faced. As soon as the issues have been resolved, the team returns to the normal schedule, pulling in cards as capacities become available. You have to support each other – General replied
Ok. What about SLA and tasks that are super high priority? – the senior developer was concerned.
It is similar to defects fixing. However, you could adapt Kanban board and create an SLA lane with tasks that have higher priority than in the other lane. Remember – you cant apply above for planned currently assigned tasks before these have been accomplished. If, for example, they are faced with some problems, these need to be addressed immediately. It’s good if you cross your skills to handle bottlenecks.
Hooray, we won’t be overloaded! – the developer team exclaimed.
Yes, but your goal is to reduce the amount of time an issue takes to move through the entire process. You must analyze the report with the cycle time charts that shows how much it took for a card to make it to Done. Look below on the task with id 109 which was in the requested stage for 231 days which is about 105 day more than the mean time. You should also look at blue dotted curve which presents the trend over time. If it shows decrease, you are doing well.
Otherwise … you likely know the answer J Generally, you should balance the work of each phase to achieve even flow.
Hooray, performance will be improved! – PM exclaimed
Yes. But there are a few more things you should do to make the process successful. First, an everyday stand-up meeting in front of the board must be organized during which you analyze:
- What tasks everyone is working on
- What blockers are there
Second, you must have regular review meetings to analyze the current process. Because what I presented was only the example of a process. You should adjust it to your real Maintenance Cycle. Does everyone agree to what I have said?
Yes, Cool, Ok, Fine – the team and PM exclaimed