This article will discuss: 1) how overloading teams significantly degrades their performance, 2) a principles that can guide the sizing of the features coming out of your product portfolio management process, and 3) why product portfolio management is a critical component of a transition to agile methods.
Effectiveness and Efficiency
Agile organizations need to be both effective and efficient. Effectiveness is doing the right thing and efficiency is doing it without wasted effort. Being inefficient, even if working on the right thing, is like trying to pile boxes up to climb over a wall when a ladder is available. Efficiency without effectiveness is like quickly climbing the ladder that is placed on the wrong wall. Agile organizations have to look both at selecting the right work for teams to do and then using appropriate methods to get teams to do their development faster. We can think of this as a two step processes – selecting and developing, as depicted in Figure 1. Done properly, we call this “fast-flexible-flow” because we can readily select what is needed (effectiveness) and development it quickly (efficiently).
Figure 1. The flow of selected products to the development teams
Also, illustrated in Figure 1, isthe relationship between these two parts of the development process. Consider what happens when too many things come out of the pipeline on the left, forcing their way into the pipeline on the right. Or what happens if these selected items are very large. In both cases, the development pipeline jams up. To achieve flow across the entire pipeline, the organization has to not only prioritize the proper features, but size them appropriately and only allow a certain number to reach the teams at any one time.
Thanks to the spread of Lean-Thinking, software development organizations are talking more and more about the need to “eliminate waste.” It is good to get rid of waste. It may be even better not to create it in the first place!
Unfortunately, software development organizations create new work for themselves without even realizing it. How does this happen? Consider Figure 2,showing two ditch-diggers, one making work for the other.
Figure 2. Creating work due to a bad process
One digger is throwing his dirt into the other man’s hole. Now the second man has to shovel that out in addition to his own dirt. Their system of coordination (or lack of it) has created new work - double the work - for the poor guy! And once created, the work must be done. I call this “induced” work, because the way they are working together is causing it to occur.
Is it absurd? Maybe. You would think the second guy would quickly see what was happening, turn around and change how they are working. This is because in the physical world it is readily apparent what causes induced work. In software development, the act of inducing work is not so apparent and therefore, is more insidious and more difficult to stop. Furthermore, what we often look at to guide our process often increases our induced work under the guise of making us more productive.
To quit shoveling work into each other’s ditches, we have to look at new kinds of measures. Rather than defining efficiency by “productivity,” we have to look at “time.” Consider the following software related example. In an attempt to make themselves more efficient, a testing group decided to batch up the code being tested. The assumption was that this focus would increase their efficiency and therefore, their productivity. The result, however, is that developers subsequently had to wait days