Everyone who works with software development knows that when we talk about methodology, the discussion is always a problem. Each one has a preference but we have to find a balance and start the project.
Scrum won a lot of adepts because it’s the easier way to start to use an agile method. To make a sprint, a daily meeting and some other ceremonies are much easier than to adopt all XP practices, especially the engineering ones like tests, pair programming, small versions etc.
But when we talk to a client that wants to apply Scrum in maintenance, we need to talk about the elephant in the room:
- How do you plan a sprint if you don’t know what you will need to do by the end of the week?
- When do I estimate meetings? Do I stop all team when a new task come in?
- The software will work only at the end of the sprint?
Is it hard to answer these questions, isn’t?
For maintenance and others cases, we believe that you shouldn’t worry about doing a sprint, negotiate tasks for the next weeks and wait some weeks to have the software running in production. Too many activities and meanwhile your user suffering from problems.
Much better than set your demands according to some method is to adopt one that fits your routine, allow you to see what’s wrong and stimulate continuous improvement. Had you taken a look at Kanban?
What is Kanban?
Kanban is a methodology invented by Toyota’s engineering team at 1950. It’s a visual project management and works according to the demand.
A lot of developers are adopting ideas from the factory line of production to the software development. From this, emerge the kanban method, created by David Anderson.
Why use Kanban in maintenance ?
Just like the Toyota’s factory, maintenance depends on the demand. An external factor determines what needs to be done. Doesn’t make a lot of sense to think that X number of bugs and user’s problems must be done in Y amount of time.
Some other questions are harder to answer when you use, for example, scrum in maintenance:
Why wasting energy planning something that is more effective when is just done?
Isn’t better to know how much time you need to solve a problem than to know how much are done in a week or 15 days?
In software development, special in maintenance, Kanba fits perfectly. Talking about that, the first two chapters of David Anderson’s book are about the explanation of Kanban in this context.
just to quote:
… but a kanban system form seemed to fit well with the functional problems of maintenance work. I didn’t go to Corbis with the intent of “doing kanban”. I did go there with the intent of improving customer satisfaction with the software development team. It was a happy coincidence that the first problem to be addressed was the lack of predictability concerning delivery form IT software maintenance.”
Efficiency is the better way to measure results in maintenance. The faster you solve a problem, better to everyone. The client/user is happy to see the problem solved fast. The team stays more time in execution than at meetings and the company becomes more effective and lucrative.
With Kanban it is possible to see where you are having problems. What problems are wasting your time. The size of your team for each kind of problem. And the most important: what are drowning your money in this operation. After all, without this information it is more difficult to know what part of your team have more work that can handle and what part have less than it should.
Kanban helped Toyota out of a near bankruptcy to become one of the largest automakers in the world. Was implemented for better use of ressources and efficiency. In our world, it has been adopted for the same reasons and with success.
We think that Kanban fits perfectly for your maintenance team. Suit the existing process, encourage continuous improvement, reduce the time spent in ceremonies and ensure delivery rate. All this will make better results, value and improve trust between team and business areas.
At last, but not least, use Kanban not only for maintenance!