That is not at all what the article was about! It was never stated that you should be late or take too much time in doing tasks… it was about using more wisely your time (if the sizing claimed the task needed 5 days to be done and you are done in 2 maybe you could have spent more time thinking about the design or if everything is ok try to using the extra time to generate value in other ways instead of rushing towards the next task)
Who establishes that sizing? I’ve yet to see anyone who can accurately estimate their own tasks let alone someone who can estimate that for others.
In agile, I think a great time for reflection is between sprints.
Also, I’m super fast but I’ll instead take frequent small breaks in the middle of work (read hacker news, write up documentation etc). There are other times to reflect than between tasks.
I had a colleague that can be considered brilliant engineer and I believe could be doing all kinds of exciting hard projects and work in the top tier companies. When our manager decided to leave the company, he went along, for a job which in my view is nowhere near his maximum abilities (although he might argue otherwise), quoting the 'Be as particular as you can in the selection of your supervisor.' rule from the above book (which is relevant to the other thread in this topic).
Concepts like story points and processes like agile sprints are intended to create a more realistic estimate of the work a team can deliver. The process comes with tradeoffs; it won’t work for everyone. So then it’s up to them to bring it up during retrospectives and decide to either change the process or… not.
It’s important to understand that working on a team means that you just don’t get to have all the nice things that you would working individually. You gotta approach it with that mindset.
And you ask the "stakeholders" you are producing for.
If you still want some perfection, ration it out on an easier schedule and use incremental perfection as "treat" for the stakeholders over time while you get something for it at each incremental delivery.
Outsourcing task estimation to the team still doesn't solve the estimates are broken issue. I've not seen estimates get meaningfully better in an environment where the team collaborates on establishing the expected time for a task.
It’s not perfect, and importantly doesn’t claim to be. It’s something in the absence of other ways of estimation. Use whatever works best for your team.
Nit: It’s not “outsourcing” in any meaningful definition of the term to have the team responsible for executing a task come up with estimates.
I’m not a big fan of the term IC since you’re rarely delivering anything truly individually (on the average, yes there will be outliers). IMO “software engineer” is just fine as a role.
