In my work as RTE, trainer, and coach, I encountered something I would call a 'misguided strive for optimization'. Managers or team members who believe the project would create more outcomes by optimizing the resource utilization of the dev team. While improvement in short-term results might be possible by increasing the 'utilization rate', in my experience, teams that try to optimize for utilization achieve worse results and deliver fewer outcomes.
Disclaimer: For the sake of keeping this article short(ish), I might oversimplify a bit. For a more nuanced conversation, just contact me. ??
?? What do I mean by 'utilization'?
In this context, a '100% utilized resource' refers to a dev team member with a (minute) work plan for all of his/her available capacity, with no room for slack. Every minute is used for 'productive' work, productive meaning hereby work which has been agreed on upfront.
Please don’t get me wrong, a comparison of the estimated effort and the available capacity is essential for any reliable planning process. It starts to get problematic once an 'optimal utilization' is pursued.
Agile development frameworks promote the concept of Story Points, which represent an imperfect but pragmatic approach to estimating effort and allow for easy matching of required effort and available capacity. Using tools like Story Points in the way they are intended to be used, prevents the trap of over-optimizing the team's utilization rate.
? How does this problem show in practice??
- Very detailed effort estimation is requested, down to a few hours (for large work packages) or even minutes (for small work packages). In my experience units of half a day or less do most likely not make sense. But exceptions confirm the rule ??
- Work is broken down into (very) granular tasks, long before the work is due
- Managers, POs or team members challenge the effort estimation of the (other) team members overly critical, in some cases driven by their personal agenda. E.g. managers who cannot handle unrealistic expectations by higher management and who pass down the pressure to the team
- Managers, PO or other team members encourage dev team members to take on more work than they are comfortable to commit
In general, challenging assumptions and estimations can be very beneficial, as it can provoke out-of-the-box thinking, better approaches, or the revision of false assumptions. So there can be a thin line between constructive challenging and destructive criticism.? It takes empathy and experience to navigate heated discussions.
? Why does optimizing for utilization not work?
In theory, optimizing for utilization is great. More work can be done, as a higher percentage of the available resources is 'utilized', i.e. more work is assigned to the team. While newly formed teams do get more efficient over time and the available resources can be 'utilized to a higher degree', in the sense they can likely realize more Features in one planning interval, the pursuit for an 'optimized utilization' is inherently flawed. This is because:
- If all resources are 100% utilized, all resources are potential bottlenecks. If for whatever reason one team member cannot realize the 100% scope, re-alignment is required. Can the delay be accepted? Should another team member support, putting another work increment at risk? … Additional discussions and re-alignment are needed, which require additional time, possibly leading to even more delay. Some 'spare capacity' within the team, which the team can self-organized invest in emerging challenges,? is the much more efficient approach?
- '100% utilization' would require very minute planning, which is time-consuming by itself and, in many environments, inherently cannot be reliable. As the number of factors potentially affecting the workflow increases, predictability decreases???????????
- Overemphasizing people’s role as project resources, for which the utilization should be 'optimized', can lead to a very unhealthy culture. At the end of the day, the team members are humans, who might have sick kids at home or who might have other very valid reasons to not be 100% productive all the time???????????
- In a healthy culture, team members optimize their utilization naturally. They do this by estimating the effort required to deliver a piece of work more and more realistically. They are aware of the mechanics of the planning process and trust the process. Their objectively available capacity is matched with their subjective estimation of the required effort. They know they could 'cheat' by overestimating the effort required and therefore would get less work assigned. In a heathy team culture, they know discussions about work estimations are led constructively and their expertise gets respected. They come to more realistic estimations over time, which naturally leads to a higher utilization rate.???????????
- In any given project the relationship of scope, time, and budget/resources is as follows: If more scope is requested, also more time and resources must be provided. Otherwise quality will decrease and technical debt will be accumulated as corners will be cut and processes rushed in order to fulfill the increased scope demands. This technical debt might not be visible at first but puts the project at (severe) risk over time???????????
- Higher/100% utilization is often achieved by adding small additional tasks to the backlog. Even if the effort for all tasks is estimated correctly, working on different tasks requires context switching and is very likely not discounted for. The whole is more than the sum of its parts
?? Way forward
So is the solution now to just have less ambitious teams, which just commit to as much work as they are certain they can deliver with ease? No, every company is (luckily for us consumers) in competition with others and must be ambitious to deliver better products more efficiently. Teams need to be ambitious, too. My suggestions include the following:???????????
- Not only measure the delivery volume (in #implented Features/US/SPs, …) but also the planning reliability. Highlight to the team their performance is also measured by the quality of their predictions and possibly provide more context, to why predictability is essential for the project’s success. I prefer to have a predictability target corridor, instead of just saying the team should achieve 100% of the plan. If only 100% of the target achievement is considered as 'good', objectives tend to become less ambitious
- Introduce the concept of 'technical debt' and promote 'build-in quality' (practices). If a team with fixed resources (time & budget) is forced to 'optimize' output/scope, shortcomings in quality are inevitable. Depending on the work contract, it might be possible to simply request more hours must be worked (for some time), but sooner or later quality will suffer. Highlighting the importance of quality and keeping technical debt low, can help to prevent wrong incentives???????????
- Foster a culture of active dependency & risk management. Encourage the team to identify and actively manage dependencies, e.g. in retrospective ceremonies. Install professional risk management and demonstrate the points raised by the team do lead to actual actions. Dependencies & risk management is often seen as one of those 'additional tasks', which get de-prioritized. If the team is requested to invest time in those activities, it must also be visible that this time investment leads to a concrete outcome???????????
- Go Gemba, get a good understanding of the situation 'on the ground'. While dashboards might be one very beneficial tool to get an overview and keep the big picture in mind, no project can be managed successfully by just reading reports. In order to get the 'full picture' you need to get engaged with people's work and demonstrate genuine interest in what they are doing. Discussions about utilization/resource planning become much more fruitful this way.
?More could be added but I suggest, for an in-depth conversation just reach out!
? Conclusion
In my experience, if you ask senior management/business executives, what they prefer …
??1) 10% more deliverables, i.e. features in the planning interval backlog or
??2) a 20% higher confidence the current backlog can actually be delivered
most prefer predictability over (idealized) delivery volume. You can just achieve so much more if you have a reliable base to operate on.?
Therefore, my suggestion for the 5th value of the Agile Manifesto would be:
?? "We value release reliability over delivery volume
This holds especially true for scaled setups, in which the delay of one team's delivery can ripple through the organization.
Prioritizing reliability over volume does not lead to less accountability on the team level but to an accountability shift. From every individual team member being (only) accountable to deliver what has been committed during the planning process to every team member being also accountable the whole team is delivering what has been committed.
This second commitment can only be given if the cumulated utilization rate is below 100%.
