Joanie, a new VP Engineering, joined the company a couple of weeks ago. Her boss, the CEO, wants to know how long it will take engineering to finish all the projects.
Joanie asked the various leaders these questions for every project in progress:
- When did you start this project?
- Are you still working on this project? If so, how long do you think this project will take?
- How many other projects did you finish since you started this project?
(You can use features instead of projects, but this is the organization view.)
Joanie received this data:
Notice that the teams all have different start dates, durations, and predicted end dates. Let's walk through the data for Team 1.
Team 1 started this project on Jan 1, 2020. They've been “working on it” for the past 27 months. In the meantime, they completed five other projects.
They have no idea how long this project will take them because the world has changed since they started and restarted this project. The rest of the code base changed, the environment has changed, and the team has changed.
While their lead time (from start to release) for the other projects was relatively close to Joanie's suspicions, they don't know about this project.
In contrast, Team 2 started “this” project back in 2018, almost four years ago. They don't have a prediction for this project because they're not sure anyone needs this project any longer. They're not really working on this project. Instead, they prefer to work on new projects.
Team 3 has not had interruptions, so Joanie has no suspicions about their work.
Team 4 started this project this year, but they just finished the other project. Joanie suspects their prediction is too optimistic.
And Team 5? Their data is inconsistent with the other teams' data. They keep taking a long time. Joanie suspects she will have to intervene somehow, and she's not yet sure how.
Little's Law explains why things work this way.
Little's Law
In Conway Is Killing You And Little Is Helping, we see that if we want to understand Lead Time (when will the projects be done), the calculation is:
With the exception of Team 5, and in the absence of more data, we can use an average lead time of 4-6 months per project.
Team 5 blows all our assumptions out of the water. Why has Team 5 has completed just 2 projects in the last 4 years? Joanie asked and heard these answers:
- We kept multitasking between this project and the other one for the first two years until we decided to finish the other project. (Their project WIP was only 2, but their throughput was zero. With more questions, the people multitasked with other projects in the organization, and between these two projects.)
- Once we returned to this project, the requirements shifted and we couldn't get clarity on the requirements or the real customer. (These are delays due to management decision time.)
- We did the other project and when we returned to this project, the world had changed. Marketing needed to change what they wanted, the code changed, our entire team changed. We had to restart everything. (All the time they spent before was useless because they didn't use what they learned before.)
When I think of Little's Law, I also think of these sayings:
- Murphy's Law: Anything that can go wrong will. (And the corollary: At the worst possible time.) Team 5 experienced Murphy's Law and all possible corollaries.
- Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. (That's related to the 90% Schedule Game.)
- The longer things take, the longer they will take. (What I say to my clients.)
What can you do? Manage your environment or culture.
Manage Your Environment
Organizational WIP
I much prefer to start with organizational WIP (Work in Progress), to manage the project portfolio. (See Manage Your Project Portfolio.) When organizations manage the overall WIP, we have many fewer starts and more finishing. Or, the portfolio team decides there's no point in doing this work any longer. They stop the project. Team 5 needs that kind of decision-making as support for their work. So do Teams 1 and 2.
Team-Based WIP
Once each team only works on one project, the team can look at their “local” WIP. I'm not sure how much WIP any given team should have. However, I know this: they should have just one project at a time. I'm also a fan of working in flow efficiency, so the team can finish more features faster.
My suggestion for team-based WIP is the floor of the number of people on the team/2. That means at least two people work on every feature, so they can finish it. (See Create Your Successful Agile Project for more details.) Also, see the Pairing, Swarming, Mobbing post so you can see how people might work together, keeping the team's WIP low.
In addition, when managers reward flow efficiency, people tend to collaborate more, not just cooperate.
Personal WIP
Are you multitasking? If so, ask if your personal WIP is too high for you? If it is, learn these lessons from Manage Your Project Portfolio:
- Stop starting new things. If you feel you “must” commit to new things, kill the previous work. Don't return to it. Kill it. Good ideas come around again.
- Decide what you will commit to. Commit to that until you finish. (Do NOT offer a duration until you finish enough of the work to measure your cycle time and see where you are with forecasting. Even then, always offer a confidence level or a range of dates.
- Do you need to transform your current work, so you can learn how long it will actually take? If so, do that, so you can finish.
The more WIP you have, the less predictability you have. And, know that the longer the work takes, the longer it will take. Use Little's Law with your data to predict how long your work will take.
Little's Law Helps People Understand
Joanie took the time to explain Little's Law to the teams. She used the words, “The longer things take, the longer they will take.” Everyone understood that. But starting at the personal or team level wasn't enough.
She met with the project portfolio team and said, “Only one project per team, ever. No multitasking. We need to make the difficult decisions. And if we want a project faster, we can put two teams on it, and stop a different project—as an experiment. We don't know if more people will help us finish faster.” She reminded them of Brooks' Law: adding people to a late project often makes that project later.
At the same time, Joanie talked to the CEO and her peers. The reason the teams worked on so many projects was that senior leadership was not clear on the strategy. Those strategy discussions needed to happen and now.
Six months later, the teams had finished all in-progress work. The strategy wasn't set in stone (why would it be?), but the teams worked on useful work that would offer customers value. And, they reduced their average lead time to between four-five months.
If you wonder when work might be done, use Little's Law with your historical data to learn how long your work will take. If your data is unreliable, fix that problem first. But Little's Law is much more useful than trying to estimate forward.