Being part of team that is delivering software is always a journey. During this journey we should always ask fundamental questions about:

• value – are we doing the right thing? is the think that we do valuable?
• flow of work – are we doing it in the right way? how can we improve flow of our work?
• potential – what potential do we have? how are we going to grow the people within our team?

This post is short introduction how to tackle Flow of Work. What to aim for? What practices to try?

Flow of work (assuming we are doing the right thing) is very important, but unfortunately often neglected. What exactly flow means here and why am I using this word? We may imagine software delivery as liquid flow through the pipe. Beginning of the pipe is when requirement is born, end of the pipe is production delivery. Having this in mind we want:

• flow to be as smooth as possible – we aim to minimize rework, stops, bottlenecks, queues.
• pipe to be as short as possible – we aim to minimize lead time (time between creating the requirement and delivery)

All this requires from organization to focus on flow efficiency rather than resource efficiency. Focusing on resource efficiency we simply want everyone to always be 100% occupied with work. That means that we do not have time to retrospective about our flow of work, we are not able to look at it from the outside. Unexpected events are very hard to handle due to lack of time and in long term cause loss of motivation and improvement attitude. Therefore I do recommend focusing on flow efficiency, allow some slack time and agree to lower resource utilization to around 80-70%. This gives us a buffer that can be used to improve and adjust our flow, react to unexpected events and support innovation (hackatons, innovation days)

Assuming flow efficiency is already something we believe in, we can try with few simple steps to start flow improvements, namely

1. Understand process and visualize it to build shared understanding – f.e. build value stream map describing delivery, use Kanban board where every action is followed by state and every state is followed by action – this can simply show queues in the flow
2. Start collecting data about the way work is flowing – f.e. collect information about blockers and impediments and use them to create Pareto diagrams, mark sticky notes to see how much time was required to deliver particular task, finally use CFD diagram to clearly see lead time and work in progress. Later on all gathered data can be used to conduct and facilitate data-driven retrospective meetings where we do not rely on our feelings and memory – we are using hard facts.
3. Start limiting work in progress, batch size, and variability of work – flow theory is giving mathematical proofs that this can easily improve flow (f.e. Little’s Law). Having less work in progress gives great opportunity to pair and more precisely see underlying blockers. Work items with similar size and kind are increasing predictability and estimation accuracy.
4. Experiment a lot – remember that your learn the most when probability of success is 50%

I do encourage You to start seeing the Flow 🙂