“Kanban and Scrum – Making the most of both” is a very nice lightweight reading – thanks InfoQ – that discusses how Kanban and Scrum are related to each other, how they are different and how to make the best out of both!
Yes, The best out of both! Yes, they can be applied together!
before we go ahead we need to agree on 3 things:
- No tool is complete, any tool will help address some issues and challenges, but we should accept the fact that you might need to tailor multiple tools together to get the job done
- The tool is not the target: we are not managing projects to master Kanban or Scrum. We manage a project to produce outcomes that help the business realize the benefits the aspire for. Quoting from the book They don’t care if we got certified in Scrum if the expected results are not achieved! The focus should be on the project success and not on the tool implementation success.
- Comparing tools should be for the sake of understanding not judgement, the final conclusion should not be always to decide on one single tool, but on how to make the best out of all options.
Kanban is very simple . It’s based on “WIP” or Work In Progress. Value Stream is the steps that any task/request goes through from initiation to delivery. Kanban suggest that something new cannot be started or enter the second step before existing work is delivered or pulled by the next step. This is governed by the amount of “WIP” we allow at each stage. This way, the whole team focuses on making sure that the flow is smooth. Should an issue happen the team will work on unblocking the issue and restore the flow.
What about Scrum? You’ve to read to book or read more about it! I won’t be able to illustrate it here? Why? because SCRUM is more prescriptive than Kanban!. In other words Scrum has more defined rules and practices than Kanban. It’s easy to explain Kanban in few lines, but that’s not the case for Scrum.
Don’t get me wrong! that’s doesn’t mean that Scrum is better. Not at all, quoting from the book
” Kanban seems as a small change yet it changes everything about a business ”
“We come to realize about Kanban is that it is an approach to change management not only software development”
So the conclusion to be use both and to make the best of of both, since they are both Agile and Lean and from practices they can complement each other. How? Read the book! What I can tell you here is you can make the best out of both!
I highly recommend reading this book, for the following reasons:
- It’s very well structured and the approach to ideas is very clear. Whether you’re experienced or fresh, you have the opportunity to understand both approaches at ease.
- Used language is very simple and straight forward, no Jargons. Maybe because both authors are not native English speakers
- The book is full of illustrations that are easy to understand
- Differences are summarized in one sheet. Though I believe more differences can be added like scalability. Kanban, I believe is easier to scale than Scrum.
The book includes some nice quotes, however the one I like most is ” The ideal work planning process should always provide the development team with the best thing to work on next, no more and no more less” by Cordy Lada.
My personal take on this subject is that if you’re working in operational environment, where you release to production very often, lean more toward Kanban, if you’re working in new products or not-very-often releases I believe you should lean more toward Scrum. Quoting from the book, talking about Kanban “The ‘stop the line’ approach to impediments and bugs also appears to encourage very hight levels of quality and rapid drop of rework. It also helps with operational work where no iteration or sprint is defined with the lead time measuring easier to have SLA”.
Also, if you expect resistance from the team i.e. the team are new to Agile and Lean development, start with Kanban as it’s less prescriptive.
Finally, it’s very important to remember, both are empirical, none provides all the answers, they just give you a basic set of constraints to drive your own process improvement. So you need to Plan, Do, Check then Act again and again and again.
Ala' Yasin Abuhijleh 