Working environment Software as a Service Services sold on their reliability and availability Industry is still very young, continual innovation is essential Teams are cross functional All members responsible for design, implementation, deployment and maintenance Easy access to Product Development/Business
Before Kanban we used Scrum (kinda) Scrum practices
What we liked about Scrum A sense of rhythm and points to reflect on our working practices Better visibility over tasks that were dragging on A highly visible feedback loop to help improve our estimations
Scrum was great but we had two problems with it….
The iteration deadline felt artificial No expectation from business of a post iteration demo High dependence on outside parties Frequently over/undershoot due to external dependencies Time box limited choice of tasks in case of undershoot
In Kanban Lead Time is the principle metric, in Scrum it is velocity
Kanban limits Work in Progress directly, Scrum does this indirectly through sprint planning
Why Kanban? Retain our discipline and structure Limit work in progress rather than work per time Improve responsiveness, through reduction in Lead Time Can accommodate unexpected work without modifying the system Always able to work on the next most important or risky task
Represent each work item on a post it and put on the board
Use named columns to express where the work item is in the workflow
Limit Work in Progress
Assign explicit limits to how many items may be in progress in each workflow state, or set of states
Measure the lead time (average time to complete one item)
Optimise the process, aiming to make the Lead Time as small and as predictable as possible
The Board Should reflect your real working practices Placement of the board is crucial Work in progress limits drive behaviour Start with loose, achievable limits and expect to fine tune Expect the board to change state on a daily basis
Our retrospectives are no longer coupled to the period of our iteration.
Is Kanban for you? You may find value in Kanban over Scrum if:- The team has support, maintenance or Dev Ops responsibilities Time boxed iterations make little sense in your work flow Your priorities change rapidly Your organisation is unable to easily support Scrum roles You may also want to consider hybrid approaches such as ‘Scrumban’
Wrapping up Scrum provided us with structure and discipline Kanban provided a better model for our work flow by embracing the unexpected and doing away with iterations Limiting work in progress makes it easier to consider team level task prioritisation Ad-hoc work stacks up, categorise all work items Kanban is a tool, as is Scrum.Use the right tool for the job.