When we think about the discussion about estimates and #noestimates, I have one big question:
Where do you want to spend your time?
In projects, we need to decide where to spend our time. In agile and lean projects, we limit the work in progress. We prefer to spend our time delivering, not estimating. That’s because we want to be able to change what we do, as often as we can. That is not appropriate for all projects. (See When is Agile Wrong for You?)
In some projects, as in the domain that Glen Alleman has commented on in the first post in this series, it might well be worth spending enough time to generate reasonable estimates and to have an idea about how much the estimate might be off.
In some projects, as in the gather-a-bunch-of-people-across-the-universe that David Gordon discusses in Part 2 of this series, you might need the exercise more of “who will deliver what” first, and then ask “when.”
For both of those kinds of projects (I might call them programs), the cost of people going open-loop is too high. Of course, I would do an everyone-in-the-room planning session for the first month to iron out our deliverables. (When people tell me the cost of that is too high, I remind them about the cost of not delivering.) It’s possible if people understand how to use agile and lean to deliver at least as often as once a month, we don’t need more planning sessions. (If you want to run a program in an agile and lean way, see my program management book.)
In my experience, many people work on one- or two-team projects. The organization has decided on those projects. If you use agile and lean, you might not need to estimate, if you deliver something every day. The delivery builds trust and provides sufficient feedback and the ability to change.
Here’s the way I like to think about #noestimates:
Noestimates is not about not estimating. It’s about delivering value often enough so you don’t have to estimate. You can spend time on different activities, all leading to delivering product.
I don’t buy what some #noestimates people say, that estimation is a sign of dysfunction. I have found the estimation process useful, as I explained in part 3 of this series.
In both Glen’s and Dave’s examples, it’s quite difficult to deliver value often, especially at the beginning of a program. Sure, you might decide to limit work in progress, or work in one- or two-week iterations. But the value you can deliver? Wow, the projects are so large and dispersed, it’s quite difficult to see value that often. You might see pieces of value. One vendor produces a proof of concept. Maybe another integrates two small chunks. That’s probably not enough value for people to see the product evolve.
On the other hand, when I can use an agile and lean approach for programs, I have been successful in delivering working product across the program every day. If you have SaaS, you can do this. I have done this with the software part of the program for a software/hardware product. That was valuable for everyone on the program.
When I think in #noestimate terms, I think of showing value for the entire product.
Here’s an example from my work. I write in small chunks. Okay, these blog posts have been massive. Not what I normally do on a daily basis. Because I write in small chunks, I can make progress on several books in the same week. That’s because I only have to finish a few paragraphs and I can be done with that part.
When I develop new workshops, I often start with the simulation(s). Once I know the activities, it’s even easier to design the debriefs and the material. I might take several days to develop a simulation. I call them drafts. I can do a draft in about an hour. The draft has value because I can ask people to review it. It’s a small deliverable.
In general, I timebox my work to finish something valuable in an hour. That’s because I make my deliverable small enough to show value in an hour. That’s the same idea as having a size “one” story. For you, a 1 might be a morning, but it’s probably not an entire day.
Back when I wrote code for a living, I was not good enough to deliver in hour-long chunks. Maybe if I’d used TDD, I could have. I found estimation helpful. That’s why I worked in inch-pebbles. I could still show value, and it might not be several times a day. It was always at least every other day.
When I was a tester, I was good enough to write very small code chunks to test the product. That’s when I realized I’d been working in too-large chunks as a developer. When I was a manager, I tried to timebox all meetings to 50 or 55 minutes. I didn’t always succeed, but I was successful more often than not. Some meetings, such as one-on-ones, I timeboxed to 20 minutes.
In my work, I want to show value as early and as often as possible. When I work with teams and managers, that’s part of my work with them. Not because delivering something in an hour is the goal. It’s because the faster you deliver something, the more value you show. The faster you can get feedback and know if you are on the right track.
I have found it helpful to create an order of magnitude estimate for a project, so we all understand the general size/cost/duration of the project. Then, I start to deliver. Or, if I’m leading the team in some way, the team delivers.
The smaller the deliverable, the more often you can get feedback and show value. I have seen these benefits from working this way:
- The project ended earlier than we expected. That’s because we delivered “enough” to satisfy the PO/customer. (I’ve seen this many times, not just a couple of times.) If we had spent more time generating a detailed estimate, we would not have delivered as quickly.
- We learned enough about the deliverables that we were able to do more discovery (as Ellen Gottesdiener says) as we delivered. We made the whole requirements process continuous and just in time. We did not require hour-long pre-sprint planning meetings. (Okay, that’s only happened twice. I have hope for more experiences like this.)
- We were able to fix things before they got too large. We’d started in one direction on a feature set, realized we were headed in the wrong direction and replanned what to do and how to do it.
To me, the idea of #noestimates is tied up in small chunks of value.
#Noestimates is not for everyone. Just as detailed estimation is not for everyone. Think about what is right for your context: your team, your project, and yes, your management.
The posts to now:
- Part 1 talked about targets and order of magnitude estimates.
- Part 2 discussed when estimates are not that helpful. I did not include bad management in this post. Managers who treat estimates as commitments are not helping anyone.
- Part 3 is about when estimates are helpful.
- Part 4, this post, is about #noestimates.
I’ll do a summary post, including a pointer to the original article in part 5.
| Reference: | The Case for and Against Estimates, Part 4 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
