To sprint or not to sprint?
Here is a lesson I learned recently: Scrum sprints are excellent if you want to squeeze the maximum performance from your team. Scrum also helps to gain sharp focus on the most important things that you should finish first.
Kanban vs Scrum
Our team started with a Kanban process. We had a backlog of tasks, and we started working with daily standup meetings and biweekly retrospectives. In the beginning, things were looking good, and we started finishing work slowly but surely. Then things began to go downhill.
There had been a recent major release of the system we were assigned to work on. The release was made before our new team inherited the project and the codebase. The release was a bit disastrous, and bugs started pouring in, making our backlog bigger and bigger. As the issues kept piling up, our focus started shifting from one critical problem to another, hurting our ability to concentrate and fix these issues. In a sudden move, our team decided to opt-in to a micromanagement approach for solving these problems. Our boss started assigning every task to individual developers! A lot of focus was put into prioritizing the backlog items, which helped a lot. The best idea I can think of for a situation like this is to use Good Old Scrum Sprints.
Needless to say, I was not too happy with the micromanagement approach and started thinking about what would be the best process to use in our situation. The best idea I have come up with is to use Good Old Scrum Sprints.
- Do some sprint planning: Prioritize the issues, and take the most important ones to your first sprint backlog.
- Make sure that the team commits to completing the tasks in the backlog.
- Release at the end of each sprint.
- The team should self-organize and decide how to accomplish the sprint goal. No need for micromanagement during the sprint.
The duration of the sprints could be one or perhaps two weeks.
This has the following benefits:
- You will have a focused sprint backlog containing all the items that the team needs to finish.
- Your team can concentrate on the work included in the backlog and ignore everything else.
Once the sprint is complete, the team continues with the next one repeating the cycle again.
Final thoughts
I'm now thinking that Scrum works better than Kanban for a new team. It is also a better choice when you have time pressure to finish things urgently.
However, I think pushing your team to its absolute maximum performance cannot be sustained in the long run: people burn out, and you risk losing them. Kanban is an excellent choice if you have a stable product and things are going smoothly.
Here is a great comparison of Scrum vs Kanban from the Scrum Alliance.