It’s been nearly 2 months since we implemented Scrum + Kanban at our workplace. In the beginning, we started out strictly on Scrum but we soon found out that for 3 projects running simulteneously with limited amount of people on our team, running 3 different sprints at the same time seems like a bit of overhead.
Fortunately, our friend, agile coach Mike Sutton(@mhsutton) introduced us to a concept he called Scrum-Ban (Scrum + Kanban). Kanban is generally a pull system where we visualize the workflow of our streamline process where we limit work in progress in each workflow state. Essentially Kanban is used to complement our Scrum ceremonies. We still do our user stories, sprint release planning, our daily standup, plot our burndown chart and do our restrospect. But Kanban is what happens around our Scrum.
What I like the most is our development team could work on simulteneous project without much overhead. The product owner just simple prioritize user stories regardless which project it belongs to and the team assigns the user stories themselves and pull the job from the backlog to the work in progress to done. We do a weekly sprint and we track our velocity for each user stories that are done each week. Interesting to note is that our team gets much more motivated to get more points done when we set a target points done for each sprint.
As for the burndown chart, what we do is instead of a sprint burndown chart, we do an overall burndown chart for each project that we’re working on. This is done base on our estimated complexity for each user stories in each project. So this means we had to estimate all the user stories early on before it goes into our product backlog.
Using this system, we now can obviously see what everyone’s doing and not just the development team. With Kanban, we identified each and every single activity in our business process from the marketing and sales right to our development and into our end product. We could clearly see the big picture of what’s happening in each component and make continues improvements from time to time.
What’s most importantly we could limit the amount of job/activity/task/user stories in each workflow state so that we could work at our own capacity. We could easily inspect and adapt to our environment and business demands. Moreover, we could easily identify blockage or things that simply don’t add value to us and implement steps to remove wastage. We could be more agile and implement a total lean management style that make sense to us and bring more business value to our customers.
