Lean Software Engineering

Single-Piece Flow meets the V Model

Single-Piece Flow is what we call the Lean goal of pulling individual work requests through a sequence of value-adding activities quickly and without interruption. Flow addresses the muda of transportation, overproduction, and inventory.

A workcell is a collection of production resources, organized according to the type of product made. This is in contrast to organizing resources by function or department. On the factory floor, functional organization might mean keeping all of the drills together and all of the ovens together. In the engineering office, this means keeping all of the analysts together and all of the testers together. Organizing by project vs function is an old debate in project management, and the resolution usually falls under the category of matrix organization, which combines some features of both functional- and project-oriented structure, usually with one primary and one secondary hierarchy.

The feature team is one approach to matrix organization. It is a situational workcell, where departmental resources are temporarily assigned to a small project team for the duration of that project’s goal. A feature team should contain most of the resources it needs to execute on its goal without requesting or waiting on resources from functional departments. This means that a feature team should be a cross-functional team, with a sufficient variety of expertise to complete its task with competence. At the end of the project goal, the feature team’s resources should be returned to their departments for redeployment. Scrum and Microsoft’s feature crew are explicitly feature team methods, but other Agile and iterative methods imply or at least allow for feature team organization.

A strength of the feature team is that it reduces the need for communication artifacts, which are analogous to transportation costs (i.e. documents transport process information between distant endpoints). Feature teams control overproduction by having limited and well defined scope and duration. Feature teams control inventory by making productive resources more available to work when there is work to be done. Feature teams, being workcells, are capable of flow.

The V Model workflow addresses the muda of rework by emphasizing prevention over correction of defects. The V Model improves on the waterfall by coordinating verification and validation activities across early and late stages in the workflow. The V Model’s greater scrutiny of requirements reduces the rework associated with ambiguous or untestable requirements. The traditional interpretation of the V Model still suffers from the other three wastes of a waterfall process (transportation, overproduction, and inventory), but we already have a remedy for these three wastes! If the V Model reduces rework, can it be combined with Flow in order to reduce the wastes of transportation, overproduction, inventory, and rework? Yes, of course it can. If the feature team has a balanced skill set, uses pull scheduling internally, and follows a V workflow, then these four wastes can easily be minimized.

Flow requires a little bit of slack, but too much slack is waste

Feature teams address many types of waste, but they may introduce a new type of waste of their own: delay.

A feature team workcell improves availability of functional resources by including that resource directly on the team. A balanced team will have a skill set in proportion to the time spent on each activity in that skill set. So, if a feature spends an average of two hours in development for every hour in test, then you could have two developers and one tester on your team and come out roughly in balance, assuming that 2:1 proportion stays somewhat uniform for the duration of the project. Since feature teams ought to be small in order to best realize their function, some ratios will be harder to realize. What if the average dev/test ratio is 5:2? Should your feature team now include 5 developers and 2 testers in order to be balanced? That efficiency might come at the expense of efficiency elsewhere on the team or in the business at large. Should you starve other projects of resources just so that you can hit your optimum resource ratio?

One solution is to redefine the functional boundaries of tasks so that their durations work out to more convenient ratios. So if 2 developers will overproduce with respect to 1 tester, then give the developers more responsibility for executing testing tasks before transferring the work to the testing resource. Lean thinking is generally far more concerned that the right work is being done at the right time than who is doing the work. Lean teams should think less rigidly about their roles than traditional departmentally-organized teams. That most certainly doesn’t mean giving up the division of labor entirely. It only means thinking pragmatically about roles and realizing that having people with some overlapping skills is a good thing.

A Kanban token is a signal to pull value through the workflow

In a pull system, an upstream processing state does not deliver work until the downstream state asks for it. In order for work to really flow, intermediate work products should be ready for delivery immediately upon request. If the upstream process simply produced work at its own pace in anticipation of future demand, that would be inventory and possibly overproduction, which are waste. So there has to be a way for the upstream state to produce just enough work for the downstream state to keep busy without accumulating inventory.

The Kanban token is a common technique for managing the transfer of work between steps in a workflow. Kanban just means sign, and it is usually some kind of token that is used to replace a work product with a request to make another work product. It might be a card, or a ping pong ball, an electronic message, or in our case, a post-it note. A feature team can use Kanban tokens to synchronize production rates, so that downstream states are rarely waiting for upstream states to complete something. That still leaves the possibility of upstream states idling while waiting for the Kanban token, but we have to take one more step to address that issue, which is…

A Kanban system for regulating workflow can be so effective that it obviates the need for the feature team entirely. At Corbis, work requests are pulled directly through functional departments who have made capacity commitments to the workcell, but have not dedicated any particular individuals. The development manager might commit 4 developers to the workcell at any time, but not any specific developers, and not always the same developers. So there is a workcell of a defined size, but there is no team.

Kanban scheduling of a Single-Piece Flow V Model workcell can reduce the wastes of rework, inventory, overproduction, transportation, and delay. Not bad for a process that’s also fun to use in real life!