Two-Thirds Effort Shift Rule: How Effort Is Shifting on Large Projects

Author: Alex Yakyma

Why Organizations Fail to Respond to Change

“Responding to change over following a plan” seems to be a clear goal that Agile Manifesto posts among its other core tenets [1]. The reason for it, as we perfectly know, is not because we do or do not like things shifting around; it’s because in the environment of complexity predicting exact outcomes is an inherently unsolvable problem.

It is truly fascinating how old thinking often prevents organizations from embracing this particular aspect of Agile. It turns out to be much easier to adopt such tools as iterative and incremental development or even cross-functional teams, but not the idea of optimizing the development organization for uncertainty and variability. While there are multiple contributing factors to this problem (including different cognitive biases, unconstructive cultural scenarios, etc.), one big and pretty common contributing factor is simply lack of understanding of what really changes in your environment, how impactful is that change and what to do about it.

Research Results: How Much Change Really Is There?

We conducted a thorough research (see more detail in [2]) where we analyzed over a hundred large projects in terms of how the effort shifts over time and empirically confirmed what we refer to as the “2/3 Effort Shift Rule”:

The next timeframe only 1/3 of the effort will overlap with areas of the system affected in the current timeframe. The remaining 2/3 of the effort will affect other areas of the system.

This means, for example, that if in this quarter teams worked on a certain area of the system, in the next quarter they will happen to come back to roughly one third of it; the rest of their next quarter’s scope will affect other system files, components and entities in the code; see figure 1.

Figure 1. Scope overlap across two time periods

Let’s see what this really means to the organization and business as such.

Implications

We need to properly interpret the 2/3 Effort Shift Rule.

First, it does not say that the actual business demand (think: requirements) are changing at a speed of 66% percent. In other words, this rule does not explicitly suggest a measure of requirements variability (that of itself however is a matter of our future research). What the 2/3 Effort Shift Rule suggests is that the affected area in the system shifts at a rate of approximately 66% in every time period. So again, not the business demand but its reflection in the system. These are two different things. So, generally speaking, your demand may be stable or it can be, on the opposite, quite volatile; all we are saying is that in the next period of time you will have only 1/3 overlap with what you were working on in the current period.

Secondly, the actual effect of the 2/3 Effort Shift Rule depends on the scope considered. So, for example, the fact that the next 2-week Sprint there will be certain shift, is something your organization may absorb without much trouble, because the scope of the Sprint does not affect too much of the system in the first place. On the opposite, over the course of a quarter or six months, the shift may constitute a large portion of the system and that will start producing significant effect on the flow. Here’s how.

Significant shift in effort begins to contravene with:

  1. Current team structure
  2. Skill-set profiles and knowledge limitations
  3. Current test coverage, infrastructure support, data management routines, etc.

So, for example, what made sense as a team structure 6 months ago, may no longer be helpful today. This is because the effort may significantly shift in such a way that what was largely contained within each cross-functional teams’ scope, now requires cross-team interaction for virtually anything to be completed. In this case the team structure becomes a significant impediment to the flow of value as the organization will have to maintain lots of cross-team WIP, thus producing a significant amount of waste on a regular basis.

Similarly, a shift may require a different balance of skill-sets across the board as well as knowledge of new areas of code for many people. These are not the problems that can be solved overnight and usually require strong proactive strategy, to be addressed.

Finally, a shift may lead to new and uncharted territory not only in the system, but in supporting domains such as automated testing, deployment, test and production data management and so forth. Simply doing things “as usual” will not be producing results due to the shift.

All of the above implies that over a longer period of time (half a year, a year or more), new and significant challenges will be arising. A thorough approach is needed to address challenges like that.

How to Respond to Constantly Shifting Effort

Let’s see how the implications of the effort shift rule could be dealt with.

Before we go any deeper into specific advice, one thing really matters to properly understand the involved phenomenon. The 2/3 Effort Shift Rule does not imply a “big-bang” shift of any kind. Organizations are often unaware and can’t catch any actual change in effort allocation partly because it happens gradually in a new time period. It is important to remember that there will be no public announcement like “ladies and gentlemen, this quarter there will be a shift in this and this…” For that matter, growing more introspective mindset for organization is key and that will help in effectively applying the suggestions in the following areas:

Team Structure. No matter how perfect your team structure is today, the situation may change very soon. While there is a lot of benefit to the stable team structure, everything matters only in a way it compares to other factors involved. So, for example, stable teams are known for being able to gradually evolve better ways of interacting between the people within the team. Here is a problem though: when your major challenge shifts from the interaction within the team to substantially increasing cross-team dependencies, there’s little actual benefit in having cohesive teams. A hybrid approach is far more effective where the organization is supporting stable team structure whenever it makes sense, but at the same time creates a venue for people from different teams to literally “team up” as quickly and as flexibly as needed. The whole concept is a lot simpler when we don’t look at the organization as a set of “warmed nests” but rather try foster through value orientation and quick response to variation in effort whether it falls within or across current structures.

Skill-set and Knowledge. This is an old story: if you want flexibility and responsiveness to change, you must foster cross-skill education and create venue for effective knowledge exchange. Looking at the actual struggle and effort shift, provides better understanding and visibility of how to adjust to it. This however, needs to be a continuous process as doing anything about it is hardly possible when you actually hit the wall.

Supporting Infrastructure and Other Adjacent Domains. In a sense, when a shift happens and when it affects parts of the system that have low or no test coverage, no data transformation scripts and so forth, it requires similar approaches as those we apply to legacy systems. Not to go into too much detail on this really deep topic, teams have to constantly evolve their skills in refactoring, team-based critical test automation, standardized, automated data and configuration management routines.

Also, important enabling factor is organization’s ability to sustain low WIP as well as work and think in vertical slices of value. Any shift is easier to deal with when everyone is focused on actual value delivery as opposed to producing loads of inventory. A simple rule of thumb is: as the effort shifts, the organization has to adjust. If the organization gets too rigid for that, meeting a challenge of shifted effort with old “configuration” is inevitably going to lead to a lot of waste.

Lastly, the actual nature of each effort shift is impossible to understand unless leaders and change agents spend much time in Gemba. Most organizations remain blind to this problem precisely because they fail to embrace Gemba or because they resort to Gemba surrogates such as various ceremonies and rituals. Working with knowledge workers in the trenches is a reliable way to stay on top of things.

References

  1. The Manifesto of Agile Software Development, http://agilemanifesto.org
  2. The Dynamic Nature of System Areas Affected by New Work, http://orgmindset.com/the-dynamic-nature-of-system-areas-affected-by-new-work/

 

Ⓒ Org Mindset, LLC