Continuous Flow Teams delivery value one change at a time.
Pulling work from a prioritized backlog, typically limiting the amount of work in-progress to smooth flow across delivery activities. Continuous Flow teams work towards a pull from customers, releasing continuously as each change reaches a high “Level of Done”.
Continuous Flow can be thought of as the logical extension of agile/iterative workflow where the length of an iterative timebox is reduced to the length of time taken to completely deliver one backlog item.
Waterfall uses a sequential series of stages to deliver the product in one cycle. Iterative development was introduced to provide shorter feedback loops in the development process and facilitate incremental delivery. Taken to the next stage agile shortened the iterations from months to 2-4 weeks. The next step for many teams is to eliminate the iterations entirely and pull work from their backlog as capacity allows.
Often Continuous Flow teams adopt many Lean and Agile principles and so in practice there are many similarities with agile iterative teams as both are normally cross-functional teams using stories as the primary unit of requirements. Continuous Flow models tend to involve the Product Customer setting the priority of work on the backlog and the team simply processing them in order by taking the next one off the top as work travels through the in-team processes.
Work is pulled through a Continuous Flow process towards delivery. When work is “Done” it leaves a gap in the “In Progress” state which is then filled by the next high priority piece of work. Many teams using a “Kanban board” to visualize their flow will use more fragmented states than our example here but we do recommend keeping the number, and definition, of states simple.
If multiple states are used, then we recommend focusing on definitions of done (e.g. “System Tested”) rather than intermediary process steps (e.g. “Analyzed”).
In many cases, “New”, “In Progress” and “Done” are good enough. We recommend thinking about a final “Value Achieved” state which is based on operational delivery of a “Done” change – the highest possible state of “Done” with the added caveat that positive feedback has been achieved. This extra column helps teams to focus on providing Business Value, establishing pull towards customer needs.
Continuous flow teams strive to attain a smooth flow of work through their pipeline and often use lead and cycle time metrics to improve their performance and throughput of work. A useful aid for understanding the team capacity, backlog, bottlenecks and blockages in the workflow is a kanban style board, used to visualize the team workflow, this should be combined with the implementation of Work in Progress (WIP) limits to control the workflow.
Verification and Validation are built into the completion of every work item meaning that Continuous Flow teams almost always require Continuous Integration practices and often Continuous Deployment practices. Although continuous work can be batched into periodic Releases this tends to lead to driving the workflow back into an agile/iterative pattern losing the benefit of Continuous Flow.
Planning with Continuous Flow
Estimating how long it will take to deliver the backlog can be done by extrapolating based on average throughput of the team. As we mentioned when discussing Estimation in the Planning, Programmes and Projectschapter, such estimation shouldn’t be treated with undue accuracy. Extrapolation and estimation can also be used across multiple releases enabling Release planning. Continuous Delivery provides the best possible evidence and feedback for planning.
Continuous Flow teams often implement a rhythm for regular retrospectives to ensure that they implement feedback loops wider than individual work items, otherwise systemic issues can be missed. When Continuous Flow teams must integrate with other teams they may not be able to get continuous feedback if on-demand integration is out of reach for other teams. In these cases, a continuous team can still deliver continuously but may only get integration feedback based on the Releases cycle of other teams. Collectively applying pressure to shorten release cycles will mitigate quality risks.
Creating a “pull pressure” on integration streams across contributing teams aligned to strategic pull can create pull economics throughout an organization and its value streams leading to efficient workflow behaviors top to bottom.
Continuous Flow teams typically do not need a Project Manager to plan their work but may still require one for communication and leadership functions as with agile/iterative teams.