Towards the end of 2016, our team’s old manager left. Together with him gone was our bi-monthly Scrum Sprint planning for project management. In the meanwhile, my team decided to try out Kanban. Our new manager came in, let us continue with our experiment, and finally we ourselves decided Kanban is not the thing for the team, and switched back to Scrum Sprint planning. This post discusses some of what we found out during the process.
What was the Pain Point for Scrum?
Since I joined the team till when our team’s old manager left, Scrum Sprint planning meetings were held twice a month. The meetings were a major tool our manager got to keep everything under control. More importantly, when closing each sprint, he’d gather a summary sentences from each team member so that he is able to properly report to his manager / customers about our achievements in that sprint. That worked well for him, but the pain points of running sprint meetings were gradually seen.
- The value of running spring planning meetings weren’t seen by team members. Our sprints were mostly used by our managers for project management / reporting purposes. We were using JIRA at the time, but were only limited to write down the story short description–in a lot of cases, we don’t even write anything in the details section of a story, not to mention that we were supposed to keep updating the stories while we work on them during the sprint. Simply put, as team members, we didn’t make good use of the Sprint methodology / tools to keep track of our work progress, and this gap was mysteriously overlooked.
- Because of the value wasn’t apparent to team members, we came to the meetings without enough preparation. Then, when describing each story, not all of us were able to succinctly finish. Other members had to ask follow-up clarification questions in order to poker. Occasionally, story telling even became a team discussion on some unclear topic. The sprint planning meetings hence often run over time. Some team members occasionally don’t have time to discuss their stories at all within the allocated meeting time slot. This lead to a negative feedback loop, where the value of sprint planning meetings were even less seen by these members.
- In addition to people less and less willing to come to sprint planning meetings, the organization level of discontinuing contract for using JIRA also played a role in our team’s decision to abandon Scrum sprint planning at all. We were supposed to move to an in-house implementation of issue tracking system that no one liked. The reason we don’t like it was somewhat ironic: the system was way too feature rich that people felt lost when using it.
So we had to find a way out.
Why We Thought Kanban Was Promising?
It turned out that the team felt burned out by the Scrum approach and wanted to move away from it. And Kanban seemed to be the next choice.
One senior member shared his story of always using Kanban for his personal task management, and managed to have obtained a couple buy-ins from other teammates. We still had to manage our projects, so yeah, why not give it a try?
We bought a few copies of Agile Project Management with Kanban because of the senior member’s praise of the author Eric Brechner. The whole team also attended a full day Kanban workshop.
We mashed up a quick Kanban board and our Kanban journey started sailing!
Why Kanban Failed Too?
In retrospect, the switch to Kanban wasn’t a quite choice, but more an escape–an escape from the burden brought about by using Scrum when we didn’t understand its value, and when the only person on our team (our old manager) deeming it valuable had left the team.
In our experiment with Kanban, we followed advice here and there that we felt we should follow, for example
- Set WIP limit for the “implementation” column
- Clearly define “done” criteria for each column
- Actively review tasks in each stand-up, and move the post-it notes around when their statuses change update
We also fell short on some other best practices when we followed the approach, such as
- Not actively computing our team throughput after having adopted the approach
- Not strictly following WIP limit even though we set it up
- Not properly decomposing / defining tasks so that they could easily switch owners
- Not having continuous improvements to our Kanban board, but only with one huge “update” to it, which essentially combined three boards together (the project research / design board, the implementation board, and the daily Ops board).
The team gradually lost track of what we should do in Kanban approach, and going over team mate’s tasks in daily stand-ups became a dull routine.
The Kanban promise of delivering value continuously wasn’t seen in our team, and in the meanwhile, it seemed that we were all lost in what we should do. We even saw slower delivery of our projects as outlined in our roadmap. (Our new manager came and kindly respected our “choice” to try Kanban and see how it went.)
Another reason that expedited our decision to abandon Kanban, besides not seeing value from it as a team, was that our team grew into a multiple-located one. Doing a video stand-up each day is probably fine, but letting remote colleagues see contents on our Kanban board wasn’t easy.
Ultimately the Kanban journey among our team stopped about half a year later, when our new manager asked us how it went, and when our remote colleagues requested some sort of electronic representation of the board, which we couldn’t easily find a tool support.
Switching Back to Scrum
We were back to Scrum, back to sprint planning, and back to that in-house issue management system that everyone hates. Not too much to complain about. There are things in a corporate world that we’ll have to do. To make things worse, our team had grown bigger during the course that we now have three conceptual sub-teams, three major products to deliver, and three sprint planning meetings every two weeks. Some teammates were on more than one project, so they would attend more than one sprint planning meetings each time. Every other Tuesday is basically a meeting day for our whole team; the day is scattered meetings that make it hard for us engineers to find focused time.
What I Kept For Myself From Kanban?
Truth to be told, I personally felt that Kanban is a better system for individuals, even though it didn’t bring much value for our team. The Kanban approach is really good at visualizing things, and it also helps me focusing on one thing at a time (because when using it for managing personal tasks, the WIP limit is by definition 1, and you cannot really ignore it).
I had set up a Kanban board directly on the whiteboard behind my seat, and it had worked pretty well for a good amount of the period of time that my team was experimenting with Kanban. I’d duplicate each item on the team Kanban board that I own, put it on my personal board as a story, and drill it down and create even smaller sub-tasks. I also additionally added when the task started, ended, and blocked/unblocked as I work on the item. When the story post-it note was about to move place my personal board, it was also a good time to take a quick break, walk up to the team board, and move it as well.
I never ran over the WIP limit, because I’d have to work over time for that to happen. More importantly, it helped me focus on each task because when I was facing difficulties in the current task I was working on and wanted to switch to a simpler task, I had to move the current task out of the “implementation” column and find a place for it–this made me think whether that’s what I should do in the first place. In the end, I might just take a walk to the kitchen and have a cup of water to refresh my mind, and come back and continue the task.
The personal Kanban board also helped me clearly realize that, I sometimes cannot easily make commitment to random tasks that came to me without me knowing. For unplanned tasks that I cannot avoid, I had to find a place on the Kanban board, which made me think more on the priority of the new request.
I Thought You Were Using OmniFocus?
Yes. And I am still using it daily. And I found that it doesn’t actually conflict with any of the Kanban ideas; the OmniFocus folks didn’t impose on how you should be using their product either. I’ll elaborate on how I made OmniFocus play well with the Kanban ideas in a separate post. Among many other things, OmniFocus excels my physical Kanban board in that I can still use it when I am working from home–remember, lack of mobility / good online tool support is one of the big reasons that our team killed the Kanban experiment.