Thread by @aleixmorgadas

We have been practicing #NoEstimates for 8 months. Here are some learnings 👇

We started in a legacy code in which the people that created that service left the company some months ago and we needed to deliver some critical features

No business knowledge, no technical knowledge, a mess ahead

Business: Will you be on time?
Me: No clue yet, give me 2 weeks

Should we go for all the work for 2 weeks, analyze the Job to be Done and come back with an estimation?

We had a very tight deadline, 1month and a half to deliver

Investing 2 weeks in trying to give an "accurate" estimate for business might not have been the best move. We all know that would have been a fake estimate

My experience said that we are late, but yet we can mitigate the problem

I had chosen to dedicate the 2 developers and myself to start delivering the first feature. It would provide me:

- Sense of speed
- Sense of complexity
- Dedicating 2 weeks to practical learning on the source code instead of figure it out that we were already late

We focused on the 2 most critical features of 10. The overcast was bad, we wouldn't make it

Yet, we deployed several changes on the Ways of Working

- Pair Programming. They working together to improve knowledge sharing
- Limit WIP to 1
- I deal with Stakeholders expectations

Then measure after 2 weeks of work the team feelings.

Me: Do you feel we can deliver everything by this date?
Team: No way
Me: What do you think we can achieve?
Team: 4-5 of 10
Me: Perfect

Team confidence on delivering more stuff improved, good signal ✅

Back to business.

Me: We have confidence in delivering 4-5 of 10.
Business: How many developers do you need? We can move people here, it's important.
Me: It will make things worse, let's trust them. We are learning a lot about the code in so little time. Cohesive team

Business: We can parallelize
Me: No, it took 2 weeks to onboard and them taking confidence on how to make stuff, we would lose this momentum. We cannot onboard new people here, it takes time, it will reduce our delivery from 4-5 to less or best case scenario same features.

Good decision, after 1month and a half, we delivered 8 of 10 👏👏👏

- Feeling of accomplishment on time
- Team focused on delivery regardless of the estimation
- They knew they had to do tradeoffs and they did go get into the mission we had

If we estimated how much time it took to deliver, we would find that:

- We lost time on estimating something we felt we were already late
- Feeling of the blame for estimating badly something we don't have the knowledge yet to estimate
- Under pressure, we might be optimistic

After surviving that crisis, we moved to what's our current product. We have been here for 4-5 months, we still don't do estimates.

The environment is still hard,we had a legacy and the business knowledge were missing or hard to access. There were a lot of unknowns, and asking for an estimate would have been a fake estimate as well

Instead of giving a date or T-Shirt size estimate, we went on experimentation

We were focusing a lot on what we wanted to accomplish with this feature or hypothesis, and we set the quality bar

- Does this needs to be perfect? Useful? A ñapa?
- What do we want to achieve? Learn? Deliver a known?

We have 3 frontends, 2 client-facing, and 1 internal. We know where we want the quality.

Yet, another way to help the team know where they need to do tradeoff is to share the long-term vision on how their work impacts the future.

This helps them to know when we need to only apply and fix and move on, and where it's good to invest time on refactoring and improving. That's crucial to help them discard work + you, as a manager, need to reinforce that some work needs to be dropped.

I, as a Manager, I'm measuring the 4KM and in specific Lead Time. One of the goals is to reduce them continuously and help the team become faster and faster.

👇👇👇👇👇
Instead of asking for estimates, ask them what's preventing them to deliver value continuously?

Things that are improving our delivery pipeline:

- Pair Programming
- Trunk-Based Development
- Removed the CODEOWNERS
- Introducing mechanisms to make failures cheap and recover fast

Instead of dedicating an hour to estimate work, dedicate that hour to how to improve the team's life on how they are delivering work