I want to go through the experience gained from switching from a pure Scrum process to Kanban.

Changing the focus from purely focusing on sprints and sprint planning to a pull-based constrained Kanban board driven approach gave us some truly revolutionary insights into our own process. This has allowed us to further constrain work in progress and really put the focus on implementing more ideas from Lean.

Plan to spend a couple of minutes introducing the key concepts of Kanban and the rest talking about the experiences.

We are terribly concerned about being done with things. But are we really ever done with things? Done is an ambiguous term. Why else would we need a Definition of done? Definitions of done normally includes quite a few activities, but why are they concealed in a definition? Sometimes “Done” is at the same time so desirable and ambiguous that teams have two or even three versions of it - “Done Done” and “Done Done Done”.

Teams should discard the notion and need of being “done” and instead find the real states that their tasks have and make them visible.

Flow-based software development (FSD, aka “lean”, pull-based, or kanban) is software development paradigm that can have a profound effect in certain software development projects, e.g. maintenance projects. This experience reports shows one project team’s experience when moving from a timebox-based development process (scrum) to a flow-based process.

Flow-based software development (FSD, aka “lean”, pull-based, or kanban) put focus on improving flow of work items (normally software features) through a software development work process. But what does it mean in practice? We show the nitty-gritty of how to set up a project to run flow-based instead of timebox-based, and when it makes sense to do so. We show a simple KPI model to better capture the state of a project using FSD, and how it can be used as a basis for conducting experiments aimed at process improvements.