Last week we celebrated two exciting things on one of my project teams:
- Completing our 100th iteration (having used ScrumBut for most of it).
- Kicking off the switch to Kanban.
Two colleagues and I have been discussing the pros and cons of switching to Kanban for months. After convincing ourselves it was worth the experiment, we slowly got buy-in from the rest of the project team and…here we go!
Why did we switch?
- Our product’s priorities change daily and in many cases users cannot wait until the iteration completes.
- Scrum came with a bunch of processes that never really helped our team. We didn’t need daily standups, we didn’t like iteration planning, we spent a lot of time breaking up stories and arguing about how to calculate iteration velocity. We ran out of problems to discuss in retrospectives and in some cases (IMO) forced ourselves to imagine new ones just to have something to discuss.
- We’re tired of fighting the work gaps at the start and end of iterations (i.e., testers are bored at the iteration start and slammed at the end, programmers are bored at the iteration end and slammed at the start).
- Deploying entire builds, filled with lots of new Features forced us to run massive regression tests, and deploy on weekends, during a maintenance window (causing us to work weekends, and forcing our users to wait for Features until weekends).
- Change is intellectually stimulating. This team has been together for 6 years and change may help us to use our brains again to make sure we are doing things for the right reasons. One can never know if another approach works better unless one tries it.
As I write this, I can hear all the Scrum Masters crying out in disgust, “You weren’t doing Scrum correctly if it didn’t work!” That’s probably true. But I’ll give part of the blame to the Scrum community, coaches, and consultants. I think you should strive to do a better job of explaining Scrum to the software development community. I hear conflicting advice from smart people frequently (e.g., “your velocity should go up with each iteration”, “your velocity should stay the same with each iteration”, “your velocity should bounce around with each iteration”).
When I was a young kid, my family got the game “Video Clue”. We invited my grandpa over to play and we all read through the instructions together. After being confused for a good 30 minutes, my grandpa swiped the pieces off the table and said, “anything with this many rules can’t possibly work”.
Anybody else out there using Kanban?
Good luck! Two important things with Kanban - Cycle Time and Work in Process. You're still going to need to do a good job of sizing the inputs into your Kanban in order to get a Cycle Time that has a low variance. Only then will you get the predictablitly you want. I'm afraid you'll still need to work on that story planning.
ReplyDeleteAlso, WIP means you'll have to inject serious discipline into the process. You'll quickly find, I suspect, that your development team can work on many items at the same time but the test team can work on less, creating a bottleneck. You will have to deal with that!
And remember - there are no silver bullets - you'll have to work to continuously improve.
A couple of times at a couple of places, Eric. Let's talk; maybe it's time to have you back on the podcast? :-)
ReplyDeleteHa ha! Good to see your comment here, Matt. Perhaps we'll wait to see how it goes for a bit. But yeah, I would love to hear about your experiences.
ReplyDeleteAlso, that Alex guy (AKA "Wiggly") seems to talk a pretty good talk.
Heya Eric!
ReplyDeleteWe are using Kanban in my team. I am test leader, we got four developers and one product owner. One of the developers is the team leader (a SCRUM master).
It is working really well for us. We use daily standups cause we find that useful and we have modified our Kanban board over time to include the following columns (in order):
- Analysis
- Selected
- Development
- Ready for test
- In test
- Done
The Selected column can have max 4 items, Development can have max 6 items, Ready for test max 3, In test can have max 3.
We do not use any estimation for managed items (user stories), but we try to size them to around 1 work days worth of work for 1 person.
Its a low-stressful way to work and bottlenecks become visible very quickly. Sometimes testers help out getting testing done if testing starts to bottle up.
I think the best advice is to not expect everything to work at once and keep modifying the process as you go over time. Identify what works and what doesn't and adjust accordingly.
Good luck :)
Stian