Love the graphic, mind sharing how you made it?
Sure! It's in Sketch, and the assets are here if you want to play:
https://github.com/davestewart/davestewart-site/tree/main/co...
The work is never just “the work” (2022)
31–40 of 77 posts
Re: The work is never just “the work” (2022)
#32Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
Fantastic points!
Re: The work is never just “the work” (2022)
#33Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
Note that asymptotically, believing that work is worthless is the same as ignoring it. I think this is interesting because in theory there is an infinite amount of potential work that everyone is ignoring at any given point.
Re: The work is never just “the work” (2022)
#34Timeboxing (simplifying designs and eliminating requirements) is a far more important skill than estimation. Shrinking a schedule has much more impact than predicting it correctly
Re: The work is never just “the work” (2022)
#35Timeboxing (simplifying designs and eliminating requirements) is a far more important skill than estimation. Shrinking a schedule has much more impact than predicting it correctly
Why
Re: The work is never just “the work” (2022)
#36The author seems to argue that estimates are off because of "unknown knowns", and can be improved by adopting an estimation framework that makes these items more explicit. While this is certainly valid I would add that in my experience the most influential causes of major shedule disruption were the "unknown unknowns", wich are inherrent in any new creation, but which are exacerbated in software because of the extrem…
Yes! I have raised several times across several teams that task estimation is a variant of the coastline paradox[0]. You'd do well to consider determining the fractal dimension of your problem domain and "sandbagging" according to the dimension.
Re: The work is never just “the work” (2022)
#37Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
Note that asymptotically, believing that work is worthless is the same as ignoring it. I think this is interesting because in theory there is an infinite amount of potential work that everyone is ignoring at any given point.
[deleted]
Re: The work is never just “the work” (2022)
#38Why is estimating hard? 1. You haven't done it before. Not exactly the same thing. You think you've done it before, but you haven't. If you had actually done it before, you would probably be faster this time, not slower. 2. Other things besides you have changed, or will change. Coworkers, company, customers, tools, economic realities, the weather. Either it's already changed, or it's going to change. That has an impa…
I have a story about the boss: years ago the boss walks over to me and describes a straightforward change with priority that it should start right away. I said it was a two or three day job and that considering testing and other internal process could be confidently delivered in two weeks. "That's too long, never mind". I then overhear him asking a coworker about the same project. He says: "Easy, that is a two or three day project", "great!".
What happens next? The project was delivered after two weeks due to back and forth testing and integration, debugging, etc.
Re: The work is never just “the work” (2022)
#39This is actually a really good summary of how projects should be estimated. A lot of people I know just focus on the core task or the minimum viable product, ignoring everything around it. I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. In reality, the post-go-live support can take…
As a PM of a large ML team, articles like this and comments like yours keep reminding me of why I should push back when I get asked for estimates and if I really need to give one, then at least I can empathise with my team and ensure that either estimate is large and roomy
Re: The work is never just “the work” (2022)
#40This is actually a really good summary of how projects should be estimated. A lot of people I know just focus on the core task or the minimum viable product, ignoring everything around it. I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. In reality, the post-go-live support can take…
> I especially find it frustrating that many PMs think that the instant a system goes into production, the project is finished and everyone should be putting tools down and walking away. This mentality and Agile mixed together creates monster technical debts. A team is rushed to create an MVP. Since it’s an MVP, things are skipped, rushed and riddled with edge cases. This is fine if the team can now use the customer…
As a PM I feel seen. So many past experiences in companies with poor product culture where this happens. Companies like to say they’re hot on agile and have a strong product culture involving mvp, test, learn, iterate frameworks but in reality so many are just; mvp, test, learn, release, move on to the next different mvp
Leadership often say they want agile processes and iteration but at the end of the day they just want releases of new features