Increasing Productivity by Uncovering Costs of Delay - with Jutta Eckstein

Increasing Productivity by Uncovering Costs of Delay

Fred Brooks once stated so wisely "How does a project get to be a year late? … One day at a time." Lean Development and queuing theories offer help so that this won't happen. The suggested remedy is to implement a steady flow in order to achieve maximum productivity.
However, most teams and organizations are far from reaching that goal and moreover it is often unclear which approach leads to what kind of delay. In-depth examination shows how generally accepted concepts such as Definition of Ready, Clean Code, or experts in a team can lead to costs of delay.

In this session Jutta presents simple tools and methods for uncovering hidden costs of delay. These tools and methods can be applied in various contexts: In small and large teams as well as in co-located and distributed teams. Using an agile approach will help to make these cost visible.

Metrics and Measurement

How do we know what our productivity is now? How do we know it is increasing? In order to answer these questions, we have to use metrics. There are a few things to keep in mind when you use metrics:

Transparency without Trust (5:27-8:44)
Measuring something means that you are making it transparent. It is important to understand that, because if you are in an untrustworthy environment, the measurement is not helpful and even has the opposite effect of what you thought you’d learn from it. For example, if a manager said to his team that they need to improve their unit testing and the metric is the number of tests, the testers can run many tests that are not helping the system, and eventually, the measurement won’t help the organization at all.

Velocity is not Productivity (8:45-10:51)
Some people mistakenly think that if they had a higher velocity in one sprint and delivered more story points than a past sprint, it means they are more productive which is incorrect. Story points don’t affect values created and delivered, you will have to think about what makes you more productive, or in other words, outcome vs output. Think about what makes a difference for the customer and measure what brings more value instead of the number of features or tasks that are created.

Average Cycle Time (10:52-14:28)
The average period of time that something enters your to-do list until it’s completely finished and used by the customer. The customer is measuring you on the entire average life cycle from the moment you heard of a certain need until you finished creating the final product. You can use the Analysis of the Value Stream to estimate the amount of time from the beginning of the process to the end of it when it is shipped to the customer.

The Perspective of the User (14:29-16:10)
What makes a differentiation between success and failure is to look at everything from a user’s point of view to discover if we are doing things right. We have to understand that the features we are developing and intended to serve the customers are generating value for them. Working on features that at the end of their development won’t be in use by the customers slows us down and prevents us from going forward.

Analyzing your costs of delay

According to Johanna Rothman, the cost of delay is defined as: ”The way to think about the revenue you can lose plus the cost of continued development.” In simple words that means that the company is losing money on developing the feature and also the feature isn’t generating revenue because it’s not finished and delivered.

Limit Work in Progress (17:20-19:48)
A common mistake is to think that is a good thing when we have many in-progress assignments. However, Every in-progress assignment is costing us money for development and also not producing any revenue. In order to solve this problem, we should limit the work in progress and split our workload more effectively so we could control the assignments.

Multi-Projecting Delays ROI (19:49-22:49)
Another cost of delay is caused when a team works simultaneously on many projects without prioritization. This working method is postponing the ROI from those projects since it’s taking more time to finish them. On the other hand, prioritizing the projects and finishing them one after the other, will allow the company to Return on Investment earlier than non-prioritized projects.

For instance, working on three projects at the same time where every one of them takes two months to complete, Working on them at the same time will give us the earliest ROI after six months given we split our time between the different projects. In contrast, prioritizing the projects will give us the earliest ROI after two months since we are working on them by order.

Stop Multitasking (22:50-24:30)
From the individual perspective, when an employee is working in parallel on a number of tasks it costs a delay of about 30% in the employee production. Multitasking is interrupting the individual to focus on the higher priority projects and causes them to slow down the work pace.

Experts (24:31-26:54)
Working with experts can be very efficient since they are skilled professionals with lots of experience. Despite that, there are cases when the experts are actually a bottleneck within the project since the team is relying only on them and their knowledge, and important tasks are waiting in the backlog till they will be able to work on them. But when every team member knows a little bit of everything, the team can prioritize the assignments and all the tasks taken care of as fast as possible.

Quality (26:55-30:40)
The most important thing to take into account regarding the quality is technical debts. When a team has several technical debts, it will slow them down and will make it difficult to add new features to the system. You’ll have to make sure to reduce the technical debts to lower as possible. To do that you should know what are your customer needs and what is your maximum investment.

Start Right Now (30:41-35:15)
Today, more and more teams are using sprint zero to be more organized and strengthen the team bond. While it can be helpful, in most cases, the teams could also do all the preparation and the setup on sprint one on a real feature.

Another problem teams are facing is when the terms ‘ready’ and ‘done’ are not defined correctly and clearly. The right definition of ready is when the story is in good enough shape that we can start developing it. When the feature is in the hands of customers and they are using it, then it should be defined as done.

Take Time to Improve (35:16-37:30)
Many people don’t dedicate enough time to improving their abilities. It may take some time to improve, and at the beginning of the process it might slow you down, but it will pay off in the future because you learn and get better. For example, it takes time to create a smooth Test Automation Framework, but once you finish you will be able to increase productivity exponentially.

Deliver! (37:31-38:52)
Following the Scrum basic framework in project management is becoming popular. Many teams using Scrum mistakenly think that you have to wait until the end of the sprint (2-4 weeks) in order to deliver a new feature. This perception isn’t true, and the team can release the features as soon as they are done.

In Essence (38:53-40:00)

• Metrics only reliable in a trustworthy environment
• Measure the creation and growth of the value
• Analyze and eliminate costs of delay