1. Moving to Kanban Tomas Sakalauskas

2. About me Lost 13 years in pursuit of best SW development methodology … … to find out there is none Currently Managing director of Prewise, UAB Product manager of Eylean

3. Disclaimer I have no clue what Kanban is It sounds good, like Agile or Scrum, so people should attend the session ;)

4. Stop starting start finishing

5. Why Kanban? Minimal entry barrier Flexible resource planning and using Sometimes time-boxing doesn’t work Focus on whole value stream, eliminates inessential waste: Artificial work breakdown Estimation, planning and retrospectives for artificial stories Supports integrated processes

6. You have all it takes! Start with what you do now Agree to pursue incremental, evolutionary change Respect the current process, roles, responsibilities & titles

7. Kanban properties Visualize workflow Limit WIP Manage flow Make Process Policies Explicit Improve Collaboratively

8. #1. Visualize workflow Shared understanding of where you are It may be ugly at first

9. The most basic board

10. #2. Limit WIP Less multitasking – less context switching Better quality No WIP limit = queue! Queues increase cycle time, risk and overhead

11. Limits

12. Backlog

13. Lifecycle

14. Queue

15. Day 0

16. Day N

17. Pull not push Work items should be pulled into available spaces If stuck, something should be improved: Help needed in downstream processes WIP limits are wrong for the team The task transitioned too early Don’t miss a learning opportunity

18. Releases Decouple release from development Release whatever has been completed since the last release Regular releases without artificialness that iterations impose Goal oriented releases Release when it’s ready Meaningful releases without the risks of last-nights work imposed by time-boxing

19. Blockers

20. Priority Lane

21. Multiple Projects

22. Multiple Projects

23. Deployment

24. Kanban team Continuous planning Daily standup: What can we do with blockers? What can we do with bottlenecks? How to move WIP items faster? It’s OK to find defect while packing the release. Pull the feature or delay the release

25. #3. Measure and improve flow Velocity could also mean a rate at which defects are produced! Flow metrics: Active WIP vs. buffered WIP Active time / cycle time Blocked time / cycle time Outcome metrics: Bugs in process Failure demand / value demand

26. #4. Make Process Policies Explicit How to improve when no-one knows how it’s actually done? Don’t spend too much time – policies will evolve Example policies: Kanban board columns WIP limits State transition policies

27. #5. Improve collaboratively There is no Kanban Software Development Process orKanban Project Management Method Value stream is built by people for people Improvement actions are agreed by consensus

28. Kanban in Eylean team Two asynchronous processes: Goal oriented JIT planning: Decisions deferred till information is available The only questions to be answered: What should be done RIGHT NEXT and WHY? Production: Do your BEST on current feature Finish before you start! Spontaneous improvements to process and product

29. Product development is complex Self-organizing, non-linear, feedback systems are inherently unpredictable, they are uncontrollable D. Meadows I wish someone told me this 13 years ago ;)

30. Celebrate failures too! Storing avoidance of failure patterns is a more successful strategy for the brain than imitation of success ALE2011 closing keynote by David Snowden

31. Questions? tomas.sakalauskas@prewise.lt