Seeing the system dynamic: requirement vs. task

One important leverage in coaching Agile teams is to increase the focus on requirement, rather than task. This article describes the dynamic behind it.

Traditional project tracks the progress at two levels. One level is the milestone, which is often associated with stages such as requirement analyzed, ready for integration, testing done, etc. The other level is the task status often through weekly report meeting. In contrast, Agile development tracks the progress in requirements (note: better to track the value of those requirements, but out of this article's scope). We shall see the dynamic behind different choices, and this understanding helps us make successful change.

Why tasks?

B1-loop: focus on resource to reduce efficiency pressure

The resource efficiency here actually means the resource utilization, and we use it in this article to contrast the flow efficiency. Task focus represents resource focus. When facing efficiency pressure, we try to increase resource focus, then resource efficiency, so as to reduce efficiency pressure.

Task focus means tracking tasks and persons. In fact, when tracking tasks, the sequence is often person by person, asking what tasks each person is doing. This makes sure that every person is busy. When there is no suitable task matching their skills, we create tasks to accommodate their skills, for example, by starting another requirement. This has intriguing impact as we shall see later.

Why requirements?

B2-loop: focus on customer to reduce time pressure

Requirement focus represents customer focus. When facing market time pressure, we try to increase customer focus, then flow efficiency, shorten cycle time, so as to reduce time pressure.

Customer focus means instead of tracking tasks and persons, we track requirements and make sure that they are flowing. The focus is less on who's idle, i.e. resource efficiency, and more on how requirements could flow smoother.

The tension

With two separate balancing loops, both goals regarding efficiency and time could be achieved. However, there is the tension between resource efficiency and flow efficiency.

As we mentioned for resource efficiency, when there is no suitable task for some people in one requirement, we start another requirement with tasks matching their skills for resource efficiency. However, this increases WIP, thus, reduces flow efficiency. While we focus on customer to seek flow efficiency, we limit the number of requirements working in parallel, i.e. reduce WIP. This inevitably creates the situation where some people will have few suitable tasks to do, thus, reduces resource efficiency.

Now, two balancing loops interact. When time pressure gets higher, reduce WIP to improve flow efficiency, while the reduced WIP decreases resource efficiency. Then, B2-loop dominates. When efficiency pressure gets higher, increase WIP to improve resource efficiency, while the increased WIP decreases flow efficiency. Then, B1-loop dominates.

Understanding this tension helps see the resistance in a different way. Even though the customer focus is hard to refute, the underlying systemic structure creates the force against it. The tension also raises an important question about system goal. For your specific organization, which goal do you optimize - resource efficiency or flow efficiency?

The leverage

Is it possible to achieve both, or take one as primary and the other as secondary but still considered?

B1-loop: do familiar work to improve resource efficiency

We could start more work in progress to accommodate the skill, so as to improve resource efficiency, at the expense of flow efficiency.

B3-loop: learn and expand skill to improve resource efficiency

We could also expand the skill breadth via learning, and eventually increases resource efficiency. This does not do any harm on flow efficiency, however, learning also takes time. Not surprisingly, the real leverage lies at how effective we could learn and expand skills.

The above is the efficiency matrix from the book "This is Lean". The blue line shows the evolution path towards "The perfect state", first achieving B1-loop (flow efficiency) then B3-loop (resource efficiency). However, many organization perceives their starting point as "Efficient islands", in which B2-loop dominates, thus the evolution path becomes the red line. The red line is hard from change management perspective, as it means the drop in resource efficiency firstly. You either change the perception to start from "Wasteland" as it often actually is, or make sure that the drop in resource efficiency is manageable.

The choice of focus on requirement vs. task is essentially the choice between customer focus and resource focus.