We run across informative books that tell us just a bit more. Henrik Kniberg and his coauthor Mattias Skarin have just such a publication with Kanban and Scrum – Making the Most of Both. It is a great reference with many examples. When I started having individuals and teams and ask for the differences between Scrum and Kanban, I wanted to help them by explaining the impact of choosing either. Once I was sure that a team didn’t just want to adopt kanban in order to hide from a scrum master, we were ready to explore the impact of going with one, the other or a mixture of both (Scrumban). The 3 columns below were a reminder for making a good comparison. The choice however also included some consideration for the organization and where we ultimately wanted to grow. Hopefully it serves to help the conversation you may have with that team along their agile journey.
Never stop experimenting
- Fear vs. empowered
- Mistakes vs. failures
- Continuous Improvement
Feedback +/- Long vs. Short
- Too Long may make it hard to find a root cause
- Too Short may cause thrashing with no process stabilization
A Short History of Kanban:
1950’s Edward Deming a quality focused statistical process control person form the US is in Japan doing work for the Government. Taichi Ohno who creates the Toyota Production System (TPS) is similarly working on Just In Time (JIT) and Lean Manufacturing methods. Kanban results from this crucible of ideas in time. Both Edward and Taichi die in the 1990’s when Lean Manufacturing is gaining popularity in the US. Kanban means ‘signal board’ in Japanese. It is a tool to help drive out waste. A pull of inventory and work is preferred over a push. The signal board helps to communicate work in progress and the state of this work.
Muda – ‘waste’
7 kinds of waste are identified [They still hold relevance from a manufacturing world to an IT world – Read the book “The Phoenix Project” for more comparisons between the two]
T – Transportation [Today I put this in terms of COMMUNICATION TRANSPORTAION – how many emails, tools notes and days have passed rather than just stopping over or pairing up and getting it straight]
I – Inventory [maybe this is license usage, capacity, ]
M – Motion [meetings that weren’t useful]
W – Waiting [Time, feedback lags, process completion]
O – Over processing [duplication of effort in code, replication in different tools or the organization]
O – Overproduction [producing things the customer didn’t want and didn’t align with expectation]
D – Defects [!!!]
Mura – ‘unevenness’ – [making the peaks and valleys a bit more level with shared resources or load balancing]
Muri – ‘overburden’ – [still speaks to sustainable pace today]
A Short History of Scrum:
In 1986 Ikujiro Nonaka and Hirotaka Takeuchi write a reactionary paper called the “New NEW Product Development”. In it, they note that the team behavior that works best is very scrum-like. This is in reference to the sport of Rugby. In the 1990’s in the US, Jeff Sutherland and then Ken Schwaber, start experimenting with software development teams and keep this inspirational terminology.