I recently transitioned a team from Scrum to Kanban. Here are some of the things I learned. Those of you experienced in Kanban – I’m really not – will probably find this boring. Many of these items are bread-and-butter for Kanban.
- Kanban has less formality but requires the same degree of rigor as Scrum or even more. This implies a greater requirement in Kanban for discipline, enough so that teams can do it, but are unlikely to do it well, without focused help from a good coach, unless the Kanban Master is quite well-trained. That is, Kanban Master(s) needs to be higher quality with respect to Agile and Kanban techniques than are most Scrum Masters with Scrum techniques, for the team to be successful.
- Kanban is Lean. Start with what you have, keep learning, and feel very free to change and expand your board. More columns, maybe more rows, and make it truly live and visually representative of your current work, state and needs. Be incremental. Experiment, try stuff, continuously improve. Focus on pull in lieu of push. (A good and easy example of pull is inserting a new column in a Kanban board between In Progress and Testing called Ready to Test.) Oh, and read Kanban by David J. Anderson. Don’t argue, just go read it. I found it a challenge to find the board online that I wanted to cite as a good example. Here’s one that is not bad, take awhile to just study it and think about what they must be doing and how it visualizes things for the team.
- Policies. Each column-to-column move made by a work item is a state transition; endow each state transition with a policy. In Scrum, from In Progress or Doing or Testing or whatever to the Donecolumn (state) has a policy associated with it called Definition of Done. Optionally, from Backlog to In Progress has a policy associated with it called Definition of Ready. Each policy specifies the conditions that must be true to allow the state transition, as well as the actions to be taken when the transition is performed. In Kanban, all possible state transitions should be endowed with such a policy. They don’t need to be lengthy, but they definitely should be visible and easily found so that they are quickly referred to during work and updated during retrospectives with new knowledge gained.
- WIP. Going from Scrum to Kanban made the transition from (work in progress naturally limited by 2 week sprints) to (WIP limited poorly and without a strategy) painfully easy to see. Shoring up the WIP limits to enable good flow and predictability became priority almost immediately. Fortunately it’s not difficult as long as the principles are understood. The rule of half got us in the ballpark: Team: “is this about right?” Coach: “try half that”.
- Reviews. In Scrum there is a sprint review every two weeks. Everything forecasted for a sprint is reviewed or thrown back into the backlog if not done. In Kanban there is no such formalism, but every work item should still result in a product improvement that is executable, demonstrable, and demonstrated to a product owner or stakeholder(s) and approved. Visibility is key, so put the appropriate state transition into your Kanban so that you can know that all your work items pass this “it’s done, and it’s approved” policy test. In addition, don’t underestimate the value of cadence; maybe you should keep reviews of your working stuff on a regular cadence. Kanban doesn’t care; if it adds value, do it. Does that make it Scrumban instead of Kanban? Not sure, and not sure it matters, but rhythm is often useful to a team.
- Retros. In Scrum there is a retrospective every two weeks. One must account for this functionally. In Kanban, once again, the retro does not have to occur on cadence, but experience shows it has to occur with similar frequency in order for your team to qualify as a team seriously engaged in continuous improvement. My suggestion: stick with what you did in Scrum, if you can. Set up a convenient time, and do your retrospective every two weeks on cadence. If this is the only thing you do on cadence, I believe it’s the best thing to do on cadence. Retros are the most important event, right? Rhythm is useful to many teams (see previous bullet), and it is a reason Scrum is so easy to like.
- Kanban doesn’t have a Product Owner. I recommend a Product Owner anyway. Bring someone in from the Business who will do the things a Product Owner does. Make that person a full-time member of your team.
- Kanban doesn’t have a Scrum Master. I don’t recommend one, but I almost do. You need a level of effort of approximately a one full-time person to engage the team in continuous process improvement, remove impediments, and facilitate ceremonies/events of importance. In fact, maybe the LOE is higher, because Scrum’s processes are straightforward whereas Kanban is nominally very flexible and dynamic. My suggestion then (falling just short of a recommendation), is to avoid underestimating the value of a single, dedicated person who acts for your Kanban process as your Scrum Master would if you were using Scrum. Call him/her your Kanban Master perhaps, if you as a team decide to leverage this idea. Be sure that person reads Kanban.
- Story pointing or story sizing. Predictability is a major element of growing maturity as a team. In Scrum, we often perform Story Pointing as a part of backlog refinement, to understand the relative size of each work item (many of which are user stories, hence the name). However, in Kanban, one doesn’t measure velocity because there are no sprints. Instead one measures lead time and cycle time. For this to work well, each work item needs to be “about the same size” as its brethren. Story sizing keeps this from being a need, but story sizing only works if you’re on a static cadence like two weeks. If you have some 1s, 2s and 3s floating around, you’ll probably be ok with the assumption that all stories are close enough to the same size to ignore their differences. If you have some 2s, some 3s, but a 13 or three as well, then the assumptions of similar size required by the lead time and cycle time measurements don’t work as well, and those measures won’t help you nearly as much to understand your predictability. Therefore, a significant element of improving maturity with Kanban is to solve this problem by splitting those 13 point user story into stories that are 1, 2 or 3 or so in size, that is, all of similar size. And we don’t do this by explicitly sizing the stories, we just split them until the collection of stories all are “about the right size”.
- Story Understanding. On the other hand, part of backlog refinement is ensuring that the whole team understands the needs represented in the backlog. My experience is that this happens very naturally when stories are routinely sized. If the team stops sizing stories, they often forego exactly what it takes for them to have an adequate understanding of the stories. Quality suffers. Thus, even if the team is not sizing stories any longer, they still need to understand them as well as when the stories were being sized. The team must figure out how to maintain that sufficient level of understanding of the backlog.
Hope that helps! Keep learning and improving.