I went to a meetup entitled An Introduction Into Kanban a couple of weeks back held by the popular Agile Practitioners meetup group and presented by Helen Meek.
Before I go into what I learnt in the meetup I want to mention a couple of things:
It wasn’t the first time I’d been introduced to Kanban,I used this method on a couple of projects while on my UX Immersive course over at General Assembly, but we weren’t using it very effectively, in fact we weren’t using it at all like we should have.
The core tenets of Kanban:
- A method for directly improving service delivery
- A mechanism for catalysing continuous deployment
- Pull based system to manage flow
To embelish on point 3, tasks need to be prioritised at the beginning and any one member of the group needs to take ‘pull’ cards from the top of the priority pile — one at a time — before taking on another task. Our problem was that we delegated cards right off the bat.
We only touched the surface of Kanban on the course so straight after I got involved with reading The Lean Startup by Eric Reis which offered valuable insights into how to grow a business using Lean methodology. There were a few things in the meetup though that didn’t feature in the book and it’s those that I’d like to focus on:
S.T.A.T.I.K
STATIK stands for: System Thinking Approach To Implementing Kanban Because you can’t just start using Kanban straight away in your organisation, you need to first understand how your system works as a whole to make a rational judgement on how you’ll implement it.
So for each service you need to:
• Step 1: Understand what makes the service fit for purpose for the customer
- Step 2: Understand sources of dissatisfaction with the current system
- Step 3: Analyze demand
- Step 4: Analyze capability
- Step 5: Model workflow
- Step 6: Discover classes of service
- Step 7: Design the kanban system
- Step 8: Socialize the design and negotiate implementation
Read more about STATIK on David Anderson’s post on Linkedin.
The sooner you finish, the sooner you finish
This is the mantra of Kanban. Because the team shouldn’t be in the business of starting more work until work has been finished. So you’d ordinarily have a facilitator in place to review the Kanban board daily, with the team where the focus is on the value columns of the board (usually from ‘Test’ onwards) where there might be cards piling up, and need understanding from the team how they can flow through the system more efficiently towards completion.
Drum. Buffer. Rope.
This is a metaphorical example to understand the flow of a supply chain for increasing throughput by adjusting buffers by a rope and controlling speed by a drum. It was taken from the ‘Theory Of Constraints’ (TOC), a production planning process originated by Eliyahu M. Goldratt, an Israeli physicist, in the 1980s.
Further reading on the Theory Of Constraints can be read here
Yaniv Dubur in his article on DBR-Kanban explains how this concept can be applies to Kanban and how it helps:
..the bottleneck becomes the “Drum beat” for order release. The ‘time buffer’ translates due-dates into release dates and the action of choking the release becomes the ‘rope’ that ties the order to the release dates. But because this solution is allowing (and encouraging) WIP to wait before some of the work stations (and always before the bottleneck), the pressure to work on more than the optimal resource allocation in specific work stations is huge and the path to bad multitasking is short.
Little’s Law
Little’s Law derives from queueing theory a discipline within the mathematical theory of probability. It’s objective is to estimate the average items time within a system for it to function at an efficient rate. At a basic level it can be explained by finding out the average number of items in the system and divide this by the average time it takes to complete a task.
Little’s Law works slightly different in Kanban but the premise is the same and is altered to effect WIP (work in progress) limits which are the number of items being worked on by a team, which is extremely important for a team to work as efficiently as possible.
WIP = Throughput * LeadTime
Where
WIP = average number of items in process = L
Throughput = average departure rate = λ
LeadTime = average time an item spends in the system = W
Read more about this on Steve Thomas’ blog
Confirmation
Through Helen’s presentation we were told that many organisations don’t follow up on tasks completed to understand if they’ve actually been measured for success, or to put it simply if the completed task has been tested on the users it was made to serve. Adding a a final column titled ‘Confirmed’ allows the team to ensure that each task has been successfully tested and the learnings fed back into the team.
You can see all the slides of Helen’s presentation on her slideshare here
