Would you agree or disagree to the following statement: A development team with high utilization creates more value than a team with lower utilization? Are you sure?
I have been confronted with this question over and over again: To which utilization limit shall our Department be loaded with? What might be the influence of close to full capacity plans? What happens, if we reduce it? And how do we explain that less utilization might be beneficial even from an economic standpiont? Of Course, the acceptable level of utilization differs between different activities and it seems impossible to give an answer that fits to every circumstances. However, here is my 2ct on this.
100% Utilization in Development
When I recapture my first year in my position as a team leader I remember months were I planned my teams with about 90% or higher utilization. To tell the truth, there were times when I accepted forecasts of above 100% utilization, hoping we might find a way to deal with this extra effort while keeping in mind that the plans will change anyhow when we come closer to the starting dates.
It is important to mention here that since we are in a development department, it’s fair to consider a good percent of intrinsic variability and uncertainty when it come to planning development processes. So the logical consequence might have been to plan with a lower level of loading that would allow us to react flexibly to the unexpected. With this we could have addressed the risks for the upcoming work and have had the chance to decide proactively, which product might have the highest priority.
But – although knowing better – we decided to go with “resource efficiency“. So if you still wonder why the department did not deliver according our committed plans, here is the honest truth: because I took the wrong decisions in that matter! And even when I considered fixing measures to our next utilization plans of adding more buffer the consideration failed! It failed since it did not address the real issue which is: one can not load the system with almost 100% utilization without having a direct dramatic affect on the cycle time of the process.
Stock and Inventory
In a factory it is obvious that visible parts laying in the warehouse or shop floor waiting for delivery or further processing are inventory with its related money that is bound until the parts are finished and shipped to the customer. An overloaded system is quite obvious, since at some place in the production there will be a clearly visible stock of material or products that can be observed. Unfortunately, when we speak about development it is intrinsically inviable information that is stock in the process. In knowledge work it seems to be hard to understand that the same logic can be applied as in manufacuring: Unfinished work is partially-done inventory (of specifications, documentation, …) with an investment of time and money for which there has been no return on investment yet.
Since in development high portions of the work are invisible there is no sign that your development inventory is doubled. This is why all those invisible queues in product development needs to be identified, deemed as waste, and hence have to be removed or reduced. And this is why I love Kanban for Development processes, as it makes all those queues and waste generating behaviors transparent.
It becomes obvious that the introduction of rules for WiP „release“ this money bound in stocks. There is no further investment needed, you can just use this „time“ and invest in something else – but what? Imagine a situation, where in Step 3 there is an issue. They need to wait until a blockage is removed. What shall they do? Waiting and do nothing instead of starting new “productive work” at step 1 or 2?
Each time we decide to start new work while waiting for another task to be continued we have to ask ourselves about the impact. Of cause, if work is blocked, the removal of the blockage shall have the highest priority. However, there are numerous cases where this might not be possible. In those cases we tend to react in a certain way: We start new work! But simply starting some new productive work that will be dropped once the blocker is removed doesn´t help things. In a lot of cases we just “spend time in being busy” – without really adding value to the organization.
“In product development, our problem is virtually never motionless engineers. It is almost always motionless work products.” – Donald G. Reinertsen
The issue with traditional PM
Unfortunately, traditional methods of Project Management mislead developers to simply start activities when some other work is blocked since each estimated progress at a task is deemed to add value to the project. There is no recognition that unfinished and long lasting tasks might get “old” or need significant Revision – sometimes complete repetition. This is such an obvious waste of time and money that it is hard to believe how much people fell day by day the wrong decision, afraid to be postmarked as unproductive worker in an utilization-maximizing environment. And I really feel, that in an article about the economics of slack there must be a mentioning of the uneconomic behavior we force people to apply because we want them to be busy in order to maximize efficacy.
If you think about a department of 100 people, were people just lose 10 hours a month by doing work for being busy instead of creating value, the money lost by this might be about 2 mio € a year bound in stocks (assuming an hour is equivalent to 160€ value). So instead of investing money in stocks what might be a better option?
Rare-Earth Work
I have had the pleasure to be invited to visit REWE Digital in Cologne and shortly exchange on Portfolio Kanban and their approach to Agile Development (Thanks again, Jens Maser and Marco Werner!). And there was one element on their Kanban board that jumped in my eyes: The “Rear-Earth” column (Swimlane). I was told that all Kudos for this expression go to Sebastian Weuthen, Delivery Manager at REWE Digital – so here are mine!
Despite their name Rare-Earth elements are not especially rare, but usually they need extensive processing before they can be used. A lot of Rare-Earth elements are used in modern technology – thus enabling innovation, communication and advancement. I love the methapor that this expression provides: When we invest in Rare-Earth work we might not receive direct value by the archived product itselve, but we invest our time in order to foster the future of our organization and drive improvement and innovation that shall serve us providing more efficiently value to our customers in future. You invest time you get from effective working in order to gain future productivity.
At some point the productivity will be increased to a point where even with lower capacity utilization it will exceed the initial productivity at 100%.
If I understood correclyt at REWE Digital they use the “Rare-Earth” column for activities and tasks that are not directly linked to customer value, but to improve their system and make the overall processes more efficient, and they can pull when Teams are facing Slack Time. The “Rare-Earth” work has less priority than value stream work, and they have some basic rules to work with this kind of work like teams have to be sure that they can finalize a “Rare-Earth” task before a blockage or dependency they face in “production” is removed.
A similar approach can be found in a picture of Håkan Forss were he also explains, that if you plan for less than 100% utilization, there is also “buffer time” that you can use for project work when initial estimations have been too low.
“20 percent time” at Google
In 2004 a developer at Google – Kevin Gibbs – had an idea that lead to the functionality of “Google Suggest”, where words are automatically completed and a drop down menu is shown with suggestions while entering the first letters. This idea is a major support for people performing the search and it saves several seconds during one search. What sounds negligible might get a different view if one knows that in January 2018 Google processed 11.05 billion search queries – just in the Unites States (source: statista.com). Half a second saved in each search engine queries means 5.5 Billion saved seconds or better 175 saved years, just in January 2018, just in the US.
This is just one example of the “20 percent time” rule of Google, that allows developers to spend 20 percent of their time on self-determined projects. Products like Google Now, Google News or Transit are other examples. In the book “How Google Works” Eric Schmidt & Jonathan Rosenberg describe that this rule often is misinterpreted as “just” the time component that matters. The importance of people having autonomy about their time and decisions and that they can work in an area where they feel competent and can co-create with others is the driver of highly innovative ideas. As long as project work is not adversely affected, developers can choose the timeframe and topic they want to spend thoughts on. This “20 percent time” program serves as an antipole against “almighty” Project Managers and hierarchies within Google.
A last but important viewpoint on the “20 percent time” is the personal development and network building that employees casually run through when working on the “20 percent time” projects, since they usually require a lot of more skills as needed in the daily Business.
Take away message
Although a general rule for utilization of teams is hard to give, the imperishable mantra that high productivity is always helpful must desperately be challenged! Companies that still rely on the idea that efficiency is always good while not understanding the economic impact of product development queues will find themselves mousetrapped in a capacity utilization nightmare, made up of high Cycle Times, vanishing Throughput, Meetings, Multitasking, Overtime Work, Meetings, Quality Cutback, Burnout of people and teams, Meetings, Personnel Turnover, Meetings and Innovation inhibiting culture (not sure I already mentioned Meetings). They will simply drive the Innovation securing their future out of their development offices.
Knowing this now, next time you´re asked, would you really decide to go again with “resource efficiency“ and think it is the best for your organization?
“On occasions we do nothing. Or something different. Or something else. Because this means that our teams are more effective. It also means that we are freaking awesome.” – Slack Manifesto (by Pavel Brodzinski), found here
Sources that you might want to check or visit
While studying the impact of Slack I found some interesting sources that you might want to check as well and that I partly reference in my post.
- Yuval Yeret´s post about Slack
- Pawel Brodzinski´s Posts: Slack Time, Economic Value of Slack Time, Slacker Manifesto
- Don Reinertsens Book “The Principles of Product Development Flow”
- Håkan Forss pictures on Lean and Agile, his talk about Red Brick Cancer
- Niklas Modig and Pär Åhlströms book “This is Lean“
- The books “The Goal” and “Critical Chain”
- The book “How Google Works”
- Tom DeMarco: “Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency”
One Reply to “Rare-Earth Work: The economics of Slack”