-
We have been practicing #NoEstimates for 8 months. Here are some learnings 👇Permalink On twitter.com
♻️ 8 Retweets ❤️ 46 Favorites Mood +1 🙂
-
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 weeksPermalink On twitter.com
-
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 deliverPermalink On twitter.com
-
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 problemPermalink On twitter.com
-
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 latePermalink On twitter.com
-
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 expectationsPermalink On twitter.com
-
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 ✅Permalink On twitter.com
-
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 teamOn twitter.com
-
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.Permalink On twitter.com
-
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 hadPermalink On twitter.com
-
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 optimisticPermalink On twitter.com
-
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.Permalink On twitter.com
-
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 experimentationPermalink On twitter.com
-
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?Permalink On twitter.com
-
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.Permalink On twitter.com
-
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.Permalink On twitter.com
-
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?Permalink On twitter.com
-
Things that are improving our delivery pipeline: - Pair Programming - Trunk-Based Development - Removed the CODEOWNERS - Introducing mechanisms to make failures cheap and recover fastPermalink On twitter.com
-
Instead of dedicating an hour to estimate work, dedicate that hour to how to improve the team's life on how they are delivering workPermalink On twitter.com