February 2018 Archives

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

Blog - requirement vs task 1.jpg

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

Blog - requirement vs task 2.jpg

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. 

Blog - requirement vs task 3.jpg

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? 

Blog - requirement vs task 4.jpg

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.

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.

Over-specialization and waste of potential

Blog - eroding goals 0.jpg

It is natural that people specialize in various things, but when it is too much, it becomes over-specialization. Over-specialization wastes our potential. We shall understand why it happens and how the adoption of LeSS avoids it.

Eroding goals

"Eroding goals" as a system archetype consists of two balancing loops. Think of any problem as the gap between the goal and the actual. There are two types of solutions. One is to improve the actual so that the gap is reduced (i.e. problem is solved), the other is to lower the goal. Over time, it evolves to keep "eroding goals". It becomes boiling frog. This is very simple but powerful dynamic, and let's see a few examples at work.

PO specializing in domain

I have described this topic in the article of "team PO as anti-pattern". Here we don't talk about fake POs, who are not responsible for the product. The real PO may still specialize in product domain. This is often a response to the capability gap. 

Blog - eroding goals 1.jpg

The B1 loop illustrates the solution of lowering the goal. By having more POs, the scope of every PO would be narrower, which requires lower capability.

The B2 loop illustrates the solution of improving the actual. By increasing the learning, the available capability improves. However, it will take time, which makes B1 loop dominant - the goal erodes. This is what we have observed. While growing a company, each PO gets narrower and narrower scope to be responsible for. Also note that we get more and more POs in this dynamic.

Team specializing in function, component or domain

Let's look at team. Team may specialize in function, component or domain. They become functional team, component team and specialized feature team, respectively. Specialized feature team here means that it is feature team and able to deliver feature end-to-end, but it has its own product backlog only containing features in the partial product, i.e. specializing in product domain. 

Blog - eroding goals 2.jpg

This is essentially the same dynamic as PO specialization. The B1 loop lowers the goal by having more teams and each team responsible for the narrower scope, be it function, component or domain. The B2 loop improves the capability, which takes time. This is why we observe that teams get more and more specialized, and meanwhile we get more and more teams.

Individual specializing in function, component or domain

Let's look at team members, i.e. individuals. Individual may specialize in function, component or domain too. They become specialists in the team. 

Blog - eroding goals 3.jpg

This is actually the more generic case for PO specialization, and we see the same dynamic. Individuals get more and more specialized and they become single specialists. It causes that we have to create dynamic team to match the work, and this dynamic team is feature group or project in matrix organization. Likewise, we get more and more people.

In short, this is something I have observed in many organizations. Over time, people specialize more and more, and the company grows bigger and bigger in size, while people's potential is not fully realized!

LeSS promotes learning

Interestingly and perhaps accidentally, LeSS avoids "eroding goals".

Blog - eroding goals 4.jpg

Which one is better, being comfortable but waste of potential, or "painfully" growing and realization of the full potential? This gets philosophical and surely everybody has its own answer.

About this Archive

This page is an archive of entries from February 2018 listed from newest to oldest.

January 2018 is the previous archive.

March 2018 is the next archive.

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