Productivity

This blog reflects my learning process, experiments, and personal experience helping software teams. I have worked with a bunch of exceptional professionals who have suffered many of my mistakes and they have replied to me delivering working software, putting more effort on software quality and even more energy to try new things. Several years ago I committed myself to understanding what software development actually is and how to help those professionals do their best. I think this blog is in the right direction, tirelessly, step-by-step I pay back to them and to the agile community what I owe them.

If you are wondering how my personal purpose and my unpaid debt is related to productivity keep reading. I am going to start by describing a team as a

“network of interconnected work”

Team members who are the nodes of the network, transform, exchange and convert raw information into value to customers. An important characteristic of these networks is that “work” has dependencies between nodes. An event or sequence of events must take place before another, however, the sequence is not predictable. It means that my productivity depends on many other nodes of the network.

In my opinion, many organisations have ignored this remarkable characteristic and they assess employee’s productivity individually without considering the environment. These organisations tend to avoid measuring productivity of the network as a whole.

            “You cannot improve what you cannot see.”

The situation gets more and more unfair when employees do not have either control or authority to change how they interact with the network. Edward Deming wrote 14^th principles in his brilliant book Out of Crisis:

Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective (see Ch. 3).

Another side effect of productivity is busyness. As all nodes of the network are busy, the whole system loses responsiveness and effectiveness needed to react to continuous changes happening around. Busyness organisations want to reach high level of capacity utilisation avoiding idle nodes. An exaggeration might be to create a buffer of work to do just before every node in order to avoid starvation. My untested hypothesis about the expected behaviour is in this case, a network with a poorer global performance and longer time to market. Work to do has to wait in a queue until the node has free capacity to work with it and to dispatch it to the next node of the network, which is also be terribly busy. Hence, work must wait in a queue again.

Not long ago a friend of mine told me that his manager had wanted their teams to achieve maximum capacity utilisation and velocity. Then POs began to take features from here and there to prepare an iteration backlog considering number of people, their skills, expertise and calendar days… It was an exaggeration. Wasn’t it?

“Watch the baton, not the runner”

Productivity and Variability

Software development systems are high variability systems affected by external and internal sources of variability. External sources of variability are mostly rules, policies and events at the organisation level:

1. Technology: Using immature technology we are exposed to bugs or changes in our technology. For example, lean companies try to use only reliable and proven technology.
2. Team organisation: Changing team members continuously imply that teams must reorganise and affects negatively their performance. People are not replaceable not exchangeable. Furthermore, space configuration and distance between nodes are barriers to our communication. The likelihood of communicating falls dramatically when distance is farther than 30 meters.
3. Knowledge or business complexity: Lack of domain knowledge to solve the customer’s problems or constant changes in their preferences are also common sources of variability.
4. Customer: Lack of involvement or weak support from the customer. When either feedback is too long or is useless from a proxy persona instead of the real customer we can build the wrong system.
5. Competitors: Competitors’ decisions affect our plans when they bring new products into the market. We should react and inject variability in our project plans.
6. Waiting for availability: is the time that work is idle waiting for other parts or nodes.
7. Dependencies or specialisation: It is a significant self-wounded promoted by organisations that encourage high levels of specialisation. This “culture” lengthens our development time and our time to market. We are more exposed to changes in market preferences or competitors.

On the contrary, internal sources of variability are mostly focused on individuals. Intrinsic factors like motivation, healthy or safety among others are very dependent on how we see the world and affect our individual performance. Variability has an important effect on productivity so we might put strong and direct effort on reducing the bad economic consequences of those variability factors in order to increase productivity of the whole system.

Now, I am going to take a different approach and see how to assess productivity through the eyes of Theory of Constraints (TOC). The only goal of an organisation is to make money. Eddie Goldratt who designed TOC considered that Throughput is a powerful metric to measure organisation’s performance. Throughput is the rate at which the organisation converts its inventory of products into sales.

From the TOC perspective, the performance of the development process is affected by bottlenecks, which impede the organisation to achieve its goal. Performance of the whole system is determined by the capacity of those bottlenecks. System performs at the speed of the slowest link in the chain. Whether you increase the capacity utilisation on non-bottleneck nodes of your network, you are not improving the system at all.

“For any resource that is not a bottleneck, the level of activity from which the system is able to profit is not determined by its individual performance but by some other constraint within the system. – Eddie Goldratt”

TOC encourages you to either increase bottleneck’s capacity through improving its process, removing unnecessary work or deriving it to other areas of the system. Finally, we might add more people or required resources if previous actions didn’t achieve the expected results. In any case, we aim at improving the whole system in order to increase throughput.

This is the sequence of steps required to apply TOC:

1. Identify the constraint
2. Exploit the bottleneck
3. Subordinate everything
4. Elevate the constraint
5. Avoid Inertia

In theory, TOC is a tool to strengthen the view of the system as a whole through implementing a global metric (throughput) and improving flow whereas avoiding local optimisations on resources that are not bottlenecks.

Conclusions

I hope to give you some arguments to discuss about productivity in your organisation.

• Productivity has very harmful side effects for the organisation: longer time to market, waste created by busyness*.
• Culture of busyness reduces responsiveness and effectiveness required to adapt continuously to changes. Network and world around us is not static but dynamic.
• Identifying bottlenecks is the first step of TOC to improve throughput.
• Many opportunities to improve the whole system are manager’s responsibilities.
• Either removing unnecessary work or deriving it to other parts of the system is a good alternative to try to improve throughput.
• Adding more capacity should be our last choice.
• When you prioritise an iteration backlog based on ROI and some team members are idle, take advantage of these visible signals to discuss specialisation, t shape resources availability, team organisation and organisational culture.

This is what I have learnt so far and I wish to write in the future to contradict some of the arguments written here. That would be a signal to indicate that I learnt something new.