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?

There is a reason to focus on tasks.

Blog - requirement vs task 1.jpg

Task focus essentially represents resource focus. When facing cost pressure, we try to increase resource focus, then resource efficiency, so as to reduce cost pressure.

How do we increase resource focus? One way is through tasks. 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. What if there is no suitable task matching their skills? We create tasks to accommodate their skills. This has intriguing impact as we shall see later.

Why requirements?

There is a reason to focus on requirements too. 

Blog - requirement vs task 2.jpg

Requirement focus represents customer focus. When facing market pressure, we try to increase customer focus, then flow efficiency, deliver more value, so as to reduce market pressure.

How do we increase flow efficiency? One way is through requirements. Instead of tracking tasks and persons, we track requirements and make sure that they are flowing. The focus is less on who's idle and more on how requirements could flow smoother.

The tension

With two separate balancing loops, both goals regarding cost and market 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. Please note that it is not resource efficient if it involves learning. Therefore, resource focus has negative impact on customer focus.

It works vice versa. When we focus on customer and pursue flow efficiency by limiting the number of requirements working in parallel, it inevitably creates the situation where some people will have less suitable tasks to do, which is not resource efficient. Therefore, customer focus has negative impact on resource focus. 

Blog - requirement vs task 3.jpg

Now, two balancing loops interact. When market pressure gets higher, customer focus increases, and so does flow efficiency. Meanwhile, resource focus decreases, and so does resource efficiency. Thus, B2-loop dominates. When cost pressure gets higher, resource focus increases, so does resource efficiency. Meanwhile, customer focus decreases, and so does flow efficiency. Thus, 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? 

Blog - requirement vs task 4.jpg

Look at how we achieve resource efficiency. We start more work in progress by accommodating the skill at the expense of customer focus. Instead of B1-loop, we could initiate the B3-loop, which expands the skill breadth via learning, and eventually increases resource efficiency. B3-loop does not have negative impact on customer focus, however, learning also takes time. Not surprisingly, the real leverage lies at how effective we could learn and expand skills. 

Blog - requirement vs task 5.jpg

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.

About this Entry

This page contains a single entry by Lv Yi published on February 23, 2018 4:47 PM.

Over-specialization and waste of potential was the previous entry in this blog.

Seeing the system dynamic: narrow vs. broad product definition - part 1 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.