From Scrum to Kanban—how we cut task cycle time by half
We reduced the average time each task took from the Open stage to the Released stage from 7.52 days to 3.66 by moving from Scrum to Kanban.
Here is how we achieved it.
Of course, don't expect silver bullets. We just focused more on team work and less on individual plans.
Context: 300 sprints, 13+ years
We had used Scrum for about 300 sprints over 13 plus years. While Scrum was good, it stopped working for us. We thought we should put more focus on cooperating as a team, and we decided to embrace Kanban.
One book changed everything
Months before the final move to Kanban, we read a few books on the subject.
But one really changed everything.
It was "Agile Project Management with Kanban" by Eric Brechner (not his first book in our library).
I'm no longer sure if a book is good or bad, I guess it all depends on when you read it.
For me, it was the perfect time.
Brechner's book takes an analytic and pragmatic approach to Kanban. Exactly what made me tick. Not much "collaboration Buddhism" as in other texts, just straight to the point.
What Kanban is about – in my head
Say the word Kanban and the first image that forms in many people's head is a board with stickers.
Not anymore.
Kanban is about work in progress limits (WIP).
Limit the number of open tasks, and the entire team will focus on collaboration, instead of individual plans.
Cycle time versus lead time
Cycle time is the time that passes once a task opens until it is ready to be released.
We are not counting the time that the new feature or bug waits to be opened since it was reported or suggested. (We do in support, but not for development metrics yet).
Tools
The software tools we require to implement Kanban include version control, issue/task management, and communications.
Version Control
We (obviously) use Plastic SCM as our version control and use "branch per task" to implement every task (more about it in our book "Version Control, DevOps and Agile Development with Plastic SCM" that you can find here.
Issue/task Management
We use an internal issue tracker for every single bug and new feature (no code without an associated task).
Kanban signboard
But, we needed a good tool for the Kanban signboard.
Realtimeboard – now Miro
Well, in the end, we went for Realtimeboard (just renamed to Miro a few weeks ago). It is not a proper Kanban tool and it doesn't provide any of the great features the others I checked into provided, and it was even more expensive than some of them but... we liked it better... for a few reasons.
This is the signboard that the book proposed to use:
As you can see, it recommends to set WIP limits that can affect two columns inside the same phase.
Look at Implement: first column means Open, second means Done, but the WIP of 5 affects both.
This means you might have only 3 tasks open, but since there are 2 waiting to go to the next phase, you can't enter more.
So, the WIP limit affects both Open and Done.
Most of the tools I reviewed were not able to implement this limit. They were all focused on setting limits per column, but then you don't achieve the same effect. A WIP of 3 on Implement-Open and then a WIP of 2 on Implement-Done is not the same as a global of 5 affecting both.
Besides, Realtimeboard gave us lots of freedom. It was the closest to a physical board we had for a heavily distributed team like ours. Yes, no nice automations, we had to drag the stickers ourselves… but that is supposed to be key in Kanban, isn't it?
These are the ones I evaluated:
- Jira. Price: $7/user/month. It has WIP limits. I don't see multiple columns.
- Kanbanflow. Free (limited). $5/user/mo (more features, analytics, integrations). It has WIP limits. I asked them if can do multi-column, but it seems they can't.
- Kanbanize. $148/mo for up to 15. Website is unclear to me.
- Leankit. $19/user/mo or $32/user/mo. I don't like the web interface. It seems it can do multi-column and WIP.
- Kanbantool. $3.5/user/mo or $6.5/user/mo. From screenshot, it seems it can do multi-column. Not sure it can do WIP limit.
- Kanbantree. 7 eur/user/mo. Looks like French small company (good!). But I don't see it has vertical lines.
Communications
A few weeks after jumping to Kanban, we also adopted Basecamp for all of our internal communications. We drastically reduced the use of Slack (interruptions!) and email, and now we have a great place to discuss new features and bugs where everything gets tracked. We can link to conversations in our issue tracker once we decide to implement a new feature or bug. This alone, as simple as it sounds, is huge, because you can't easily do the same with email. We also evaluated Twist, but we finally went for Basecamp.
Our actual Kanban signboard
Here is an actual screenshot of our Kanban signboard in Miro (realtimeboard).
There are a few changes compared to the basic signboard proposed by the book, but in essence it is the same.
- Backlog. We don't set WIP limits for the backlog and we don't split it in Open and Specified. We did it for a few weeks but we weren't happy with it so we removed it. Room for improvement here.
- Implement. Three columns: Open, Locked and Done. Locked should be an exception. Things that can't progress for a good reason stay there; they don't count for the WIP. We abuse it sometimes, as seen in the screenshot. Open and Done are quite clear.
- Review. We review each task, and we divided it into In-progress and Done. They both count for the WIP.
- Validate. Only In-progress counts for the WIP. Basically, it shows which tasks are being validated *right now*.
- Deploy. This one grew a lot. We have an initial column Merged that means a task was already merged but it is not yet part of a release. Cycle time keeps counting. Then, we have a Deploy column for each of the products we maintain: Plastic, the plasticscm.com website, semanticmerge + its website, gmaster + website.
Once a task reaches Validate Done, the next phases go to automatic mode. A mergebot takes care of merging, building, testing, confirming the merge and creating the release.
Any of these automated phases can fail and if so, the task goes back to Implement Open.
All these movements are done manually by us, in a collaborative way (the first one who sees it, moves the card). Yes, it is a pain sometimes, but it forces us to be aware of what is going on at each moment, which is exactly what we wanted.
I won't describe here how we calculated the WIP limits because it is a topic for a blogpost in itself, and it is very well explained in Brechner's book.
One thing that is probably worth explaining is how we use cards:
What motivated us to change
When I founded Códice Software, back in 2005, I was already a Peopleware's true believer. It means we setup the office according to what the book praised. A minimum of square meters per person, silence, no cubicles, limited open spaces and all that.
As it happened with code and everything else, it was my chance to "get things right".
Of course, I made mistakes, but I believe the office space and layout weren't bad.
And one of the key things after Peopleware's mandates was figuring out a good way to work.
Scrum came on the rescue. For a 29-year old with about 5 years of experience and not much planning background it was of huge help. I read Schawer's "Agile Project Management with Scrum" and immediately started applying it. I held two meetings at the beginning, had a list of tasks, daily, review and retrospective. You go from zero to keeping your team busy with things to do in a natural way in no time. I loved it.
We struggled for a couple of years with sprint duration. Four months seemed natural at first, but after the second or third week we were always changing plans. We settled on 2 weeks and we measured time in sprints ever since. For more than 12 years. (We still use bi-weekly intervals as measures of time even after switching to Kanban).
What went wrong? Well, I wouldn't say there's anything fundamentally broken with Scrum. It was us, not Scrum :-).
- One release at the end of the Sprint was always alien to us. We were doing at least weekly releases, and our goal was always to have more than one. That means even during Scrum highs, the end of the sprint didn't mean that much.
- At first, the sprint planning felt good. A few years down the road and different backgrounds and different experience levels in the team meant openly discussing priorities didn't make much sense. Not that not everyone had a voice; they did. It was like explaining again why this thing we were trying to do for months if not years was more important than this other, became harder. (We recently switched back to this mode, which is good, after moving to Kanban).
- Retrospective and review looked good at first. But many months and years later, they all started feeling like bureaucracy. Yes, it might be us, but we just wanted to get more work done, instead of being obliged to discuss about philosophical questions once every 2 weeks. Maybe the sprint size was wrong.
- We never implemented velocity. We measured tasks in "ideal days", never in story points. My fault. My responsibility. I assume it, but we never did it.
- We optimized of individual performance. That's a good thing.
- Minimize noise. (I'm a big fan of "Pragmatic Learning and Thinking" where authors even argue whether wearing headphones is good for productivity or simply kills creativity. That's why I always wanted the shared space to be small and as quiet as possible. Listening to music should be an option, not a way to shield yourself from noise.)
- Minimize interruptions. (Notifications disabled, not wandering through desks.)
- Meeting rooms outside the quite work area.
- Library rules and all that.
Let me go deeper into this "performance topic", because it is probably the root cause for the change.
After a decade in these collaboration battle rules, and we were almost masters of flow. But… then something happened.
"That's not in my plan".
I'm lucky to count on a very collaborative and friendly team that had stayed working together for years. (We still consider a "new" person to be someone who has been here for 5 years, for goodness sake!).
But, I encouraged them to try to be productive, and the rough edges were that we started to consider individual plans over team goals.
At the beginning of each sprint, everyone had a list of tasks. Creating the detailed list of tasks was a pain too (I'll come back to this later). These lists of tasks were the goal. THE goal. Not that finishing the entire list was sacred, we often failed to do so, but it was important.
Then, keeping the focus of what was important as a whole became harder and harder. Split focus, I think they call it.
Of course, you can argue that's not an issue with Scrum, but my fault, and I agree. But, that's what happened.
Something else about the "task lists". In our quest for maximum productivity, we considered meetings waste. But, we probably went too far. We had ad-hoc planning meetings when needed, but compiling the exact list of tasks to do was basically my task, shared with a few people. This saved the others a lot of time. Everyone understood the overall direction and why things were done, and many were safe from non-productive bureaucratic work. Was it good? Well, the downside is that our time spent on planning stuff grew.
Short calculation: max 4 hours planning + 1-hour review + 1- retrospective = 6 h x 10 people = 60 hours spent on planning stuff for a team of 10.
We never hit that maximum, but we had sprints in the 30-40 hours range that we considered terrible. Were we crazy about it? Don't know, it just felt bad.
So, we thought there should be a better way.
Ah! There was yet another thing. Most of the team disliked daily meetings. We started doing them first thing in the morning. But "first thing" varied widely, especially in the first years, when some people used to show up around 10:30. After a few years (we get older), it seems everyone prefers to arrive earlier and leave earlier too. Anyway, we moved from "first thing", to "whenever possible", to standardize on "before lunch". We stuck to that for many years. The "before lunch daily meeting" seemed to work. And, we did our best to restrict it to 15 minutes. There were years where the average was higher, but 2017 and 2018 were especially good, really trying our best to keep them short.
Still, we just kept doing them because... well, because it seemed right. But many times, people were not truly listening, or explanations were vague. We fought that intensively, we tried to share ideas on how to communicate better, everything.
But daily standups meetings were... well, meetings after all. And, it seems nobody really loved mandatory daily meetings.
How the change happened
I read the Eric Brechner's book in detail and prepared a presentation explaining the key ideas of what I considered to be the core of Kanban. I presented the slides to the team and then we worked together in calculating WIP limits. Realtimeboard was already setup.
Then, we simply started using it. The first week was already good, and the second was better than the previous ones with Scrum, and ever since it hasn’t been better than the Scrum days.
What went right
More work done, less meetings, less time spent on "planning stuff" (from 30-40 hours every two weeks to as low as 5 for the entire team, with peaks over 20 that we now consider horrible).
The sense of achievement and teamwork when we move tasks forward together.
What needs improvement
We are not doing the Backlog correctly, yet. (Yes, we have roadmaps and everything, and lots of lists, but the Backlog can be improved in Kanban).
Some numbers
I collected some numbers from the last Scrum sprints before moving to Kanban and then for the Kanban ones.
Here are the results:
"Cycle time" means the time in days it took for a task to move between the Open stage to the Ready to Deploy stage (part of a version ready to be released).
"Net cycle time" is the time in days (skipping weekends, which is more realistic).
Key takeaways when comparing the last 4 sprints (2 weeks each) using Scrum to the most recent 4 sprints.
- We reduced average net cycle time from 7.52 days to 3.66 days. This means twice as fast.
- Considering just the cycle time (counting weekends), we reduced it from 9.38 days to 4.40. 2.1 times faster.
There's another number we were very interested in: time spent on planning. Let's look at the following table for an example of the improvement we experienced:
SPRINT 294 marks the transition from Scrum to Kanban.
- Hours spent on planning in the last 14 Scrum sprints = 440 (average 5% of the total time).
- Hours spent on planning in the next 14 Kanban sprints = 180 (average 3%).
- We basically cut non-productive bureaucracy in half.
- And this doesn't count the time we no longer spent (so far) on daily stand ups.
On average, we were spending 31 hours in planning every 2 weeks. Now, we spend 13.91. That's 17 hours less every two weeks. Since we normally consider 60 hours to be the effective working hours every two weeks for a team member, this is like adding 0.28 extra developers.
(Do not really consider the total hours, because there's vacation, bank holidays, and we added more people to the team in the last months).
In case you wondering what the other columns mean: dev is development time, rev time invested on code reviews, val time invested on validations.
Changing habits is good – and a look into the future
It wouldn't be fair to blame Scrum; it served us well for more than a decade, and it was probably our fault anyways when we used it incorrectly. It seems clear to me now that we missed the point after so many years of practice, and there were things we probably never mastered.
What I now consider important is that making a change is good in itself. We changed our way of working, we found something we liked better, and we met the goal we were looking for: work better as a team.
Sometimes change is good in itself, and the actual change doesn't matter that much. I wouldn't say Kanban is not good; I really like it. But, I wonder if the actual improvement comes just from changing our habits and embracing something new with renewed "illusion".
If you liked the blogpost, maybe you enjoy the following video explaining how we do Kanban:
0 comentarios: