Don't start with kanban

Don’t Start with Kanban!Marcin Czenko

Eindhoven, The Netherlands

Agile By Example, Warsaw, 15-16 September 2011Marcin Czenko

All team members received an introductory Scrum training.

No prisoners in the teams.

Product Owners selected and empowered.

Scrum Masters selected and empowered.

Pilot project selected.

Scrum - steps you may need to take...


PO and the team received sufficient coaching in writing User Stories, estimating them and grooming the Product Backlog.

Empowerment levels clearly defined.

The team members received sufficient training and coaching in eXtreme Programming engineering practices.

Informative workspace facilitated.Developers directly involved in hiring.

Senior stuff trained in mentoring and coaching.


Common excuses


We cannot have Product Owners authorised to decide about budget...


There is no way to give the team appropriate space to work...


It is impossible for a developer to be associated with one project only...


We have to keep the high reporting level to senior management...


There is no budget for training and coaching...


We cannot align our business with Scrum...


KANBAN


It is a nice book.

“Product Owner role is an especially egregious error that trivializes the problems of product planning, product design, and requirements analysis and hides them behind a black-box role that encompasses at least as much complexity as the development part of software creation process.”


“The Product Owner plays a crucial part not only in bringing new products to life but also in managing the product lifecycle. Having one person in charge across releases ensures continuity and reduces handoffs, and it encourages long-term thinking.”

It is a nice book too!


Workflow


Design Code Review Test Deploy

Workflow


Because there is a false perception that Kanban is all about workflow, many organisations believe they can avoid serious organisational changes by

only optimising their workflow.


Organisation suffers from heavy functional silos - heavy well-defined workflow.

No functional silos

Two most popular cases



CASE 1: Functional silos



Introduce queues

Not Good Problem



Limit the queue sizes



Get Rid of the queues = Perfect Flow


And what then ?


“Sequential development in a short iteration does not work.”


Cross-functional teams

Concurrent engineering

eXtreme Programming (Test Driven Development, Continuous Integration, Pair

Programming, etc).

Acceptance Test Driven Development

Heavy stuff :)


Which means you will have to get through all this Scrum/XP stuff first anyway before

you can proceed to a more Lean process.


For many, however, functional silos is not an issue (ie. they don't have them). So they could start right from the start, right ?

They don't...

CASE 2: No functional silos


Instead they start something best named SrumBUT or KanBUT


Introduction of the sequential workflow in a potentially cross-functional teams.

Even though there is no functional silos

issue.

KanBUT #1


This might be a step back.

KanBUT #1 - consequences

By not working for short sprints, sequential engineering demonstrates its limited efficiency, which means that further improvement will be significantlylimited.


Multiple access points to the team.

No Product Owner.No Scrum Master.

KanBUT #2


Stakeholders are going directly to theteam members.


Tight relation between a developer and a stakeholder leads to further specialization of the developer.


A group of engineers sitting in their proximity but actually working independently from each other.


No code ownership.

It is not important who is doing the job but that the job is being done at a right time - this can be fully explored only in cross-functional teams.


Because there is no team, someone has tosynchronise that. Team Leads will feel very happy.



Lots of Work In Progress.

KanBUT #3


One developer may be working on only one story but looking at the whole system there are multiple changes happening at the same time.


Conflict resolution.


More and more technical debt.


Lower and lower internal quality.

WAY DOWN TO HELL.


Experienced/senior members/architects are the source of impediments.

KanBUT #4

Afraid of being useless.

They may try to convince you that a deeper reorganization is a bad idea.


Often THEY ARE USELESS: their only activity is to keep themselves busy in an everlasting sequence of meetings so that it looks to everyone they do not have time. They are always busy and under strong time-pressure.

Be understanding. Training/coaching in mentoring is the thing. They can be great coaches and mentors for less experienced members.

KanBUT #4


If the organisation would satisfy some standard Scrum constraints, most probably they would be able to avoid most of the problems mentioned.

Observation


Conclusions


Because there is a perception that Kanban is all about workflow, organisations blindly

believe that by hanging a Kanban board they can bypass heavy organisational changes.


Avoid introducing a sequential workflow to your engineering process.

It is a step backward...


Do use ATDD and eXtreme Programming for shortest cycle time.


Don't forget that well-implemented Kanban is Lean.


Scrum can help you getting there.


All these "horrible" constraints that Scrum puts on your organisation is a

safety net that protects you.

Use it...


Most of the organisations we saw (and we saw quite a number of them) are not doing

Scrum well. If you cannot adopt Scrum it may be just unrealistic to expect magic from

Kanban.


FunctionalSilos

Cross-functional feature teams

2 weeksSCRUM

Kanban

Use Kanban here if necessary

Towards a Lean process...


Final Conclusion


Start with Scrum


Refactor to Kanban

(or just Lean)


Acknowledgements

Quantum of Value Ltd.

Thank you !Marcin Czenko

Eindhoven, The Netherlands

Business

Don't start with kanban