Too busy to read?

The solution is to design and use a workflow system that does the following five things: Make work visible. Limit work-in-progress (WIP). Measure and manage the flow of work. Prioritize effectively (this one may be a challenge, but stay with me--I'll show you how). Make adjustments based on learnings from feedback and metrics.

Part of the Agile Manifesto mentions "Customer Collaboration". I fully support that notion that our work should involve close collaboration with the customer. However, to me, collaboration means speaking the language of the customer. And that language should extend to cover all the metrics and analytics that we use. Have you ever had to explain what a Story Point is to a customer? How about Velocity? If you do not like yourself very much, march into your CFO's office someday and try to explain what a Story Point is. However, I guarantee all of your stakeholders understand the concept of elapsed time. I guarantee they understand the concept of the total number of features to be delivered in a release. If we truly want to be Agile, we are going to have to adopt the language of our customers. To that end, we must choose words and concepts that they are comfortable with--not force them to learn a new, arbitrary, and unhelpful vocabulary.

Queues form when work items that have been started just get stuck somewhere in your process (without completing). Items may get stuck because: - There are no more resources available to continue working on them. - Some manager mandates that more new work be started before current work has finished. - Resources that are actually doing the work are constantly pulled in multiple different directions and are not allowed to focus on any one thing. - There is a dependency on some external team or vendor.

The customer question "How long to complete?" is best answered by the flow metric known as Cycle Time. The customer question "How many new features am I going to get in the next release?" is a question best answered by the flow metric known as Throughput. The last of the three, Work In Progress (WIP), does not directly answer any particular customer question, but it is the metric that will most greatly influence the other two.

Flow Efficiency is the ratio of the total elapsed time that an item was actively worked on to the total elapsed time that it took for an item to complete (its total Cycle Time).

If work flows only part way through the system and gets kicked out or discarded--for whatever reason--then any effort that was expended on the eliminated item immediately becomes waste.

Lean: Resolving the Efficiency Paradox, they define Lean as, "a strategy of flow efficiency with key principles of just-in-time and visual management."

WIP: All discrete units of customer value that have entered a given process but have not exited.

Average Cycle Time = Average Work In Progress / Average Throughput If you have ever seen Little's Law before, you have probably seen it in the form of the above equation. What few Agile practitioners realize, however, is that Little's Law was originally stated in a slightly different form: Average Items In Queue = Average Arrival Rate * Average Wait Time

The same goes for Story Angles--they need to be really small. In fact, they need to be uniform in size, because this is the Holy Grail of flow: you can estimate cost and timescales with great accuracy from the right breakdown.

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and recovery.

Flow metrics are defined in the language of the customer and are the proper metrics to track in order to be lean and agile. Flow metrics will suggest the actionable interventions needed to make us more predictable.

Stop Starting, start finishing!

notice the emphasis on "elapsed time". The use of elapsed time is probably very different from the guidance you have previously been given. Most other methodologies ask you to measure only the actual amount of time spent actively working on a given item (if they ask you to measure time at all). I happen to think this guidance is wrong. I have a couple of reasons why. First, and most importantly, your customers probably think about the world in terms of elapsed time. For example, let's say that on March 1, you communicate to your customers that something will be done in 30 days. My guess would be that your customer's expectation would be that they would get their item on or before March 31. However, if you meant 30 "business days" then your expectation is the customer would get something sometime around the middle of April. I am sure you can see where that difference in expectations might be a problem. Second, if you only measure active time, you are ignoring a large part of your predictability problem. It is the time that an item spends waiting or delayed (i.e., not actively being worked) that is usually where most of your unpredictability lies. It is precisely that area that we are going to look at for most substantial predictability improvements.

The keys to flow: There's a clear challenge that fully engages your attention; you have the skills to meet the challenge; and you get immediate feedback about how you are doing at each step (the progress principle).

trying to think about what you're doing can quickly interfere, ending the automaticity and high performance level you've enjoyed. The easiest way to get someone to fall off a bicycle is to ask him to concentrate on how he's staying up, or to describe what he's doing. The great tennis player John McEnroe used this to his advantage on the courts. When an opponent was performing especially well, for example by using a particularly good backhand, McEnroe would compliment him on it. McEnroe knew this would cause the opponent to think about his backhand, and this thinking disrupted the automatic application of it.

"According to the cost-accounting rules that everybody has used in the past, we're supposed to balance capacity with demand first, then try to maintain the flow," I say. "But instead we shouldn't be trying to balance capacity at all; we need excess capacity. The rule we should be following is to balance the flow with demand, not the capacity.

The chief method we use in flow is visualisation. By bringing more into the open in a company, we can stimulate more interaction and support people in uncovering more value.

A focus on flow necessitates not only a shift in thinking (away from capacity utilization and estimation and planning) but also a shift in the quantities used to evaluate process performance (away from ideal hours, level of effort, points, velocity, etc.)

We advocate entirely new work conditions: WALLS, not cubicles. WALLS as meeting places. Hypotheses, conversations and open debate should take place in public at Walls.

The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.

The daring nature of Ford's method is revealed when one realizes that a direct consequence of limiting the space is that when the allotted space is full, the workers feeding it must stop producing. Therefore, in order to achieve flow, Ford had to abolish local efficiencies. In other words, flow lines are flying in the face of conventional wisdom; the convention that, to be effective, every worker and every work center have to be busy 100% of the time.

Flow and the Basic Metrics of Flow Simply stated, flow is the movement and delivery of customer value through a process. In knowledge work, our whole reason for existence is to deliver value to the customer. Therefore, it stands to reason that our whole process should be oriented around optimizing flow.

Flow Debt is when Cycle Time is artificially reduced for some work items in progress by "borrowing" Cycle Time from other work items in progress. Some examples of scenarios that lead to the creation of Flow Debt are: Classes of Service Blockers Other order of pull policies in place (whether they are explicit or not)

Flow requires a "do not disturb" ethos.