It's really simple. To succeed you need to look good in person and on paper. Under estimate and it can blow up in your face. Over estimate and you start to look incompetent. Fail to walk the tight rope and you'll soon be laid off. Succeed and you'll survive long enough to get laid off anyway when the next recession hits.
When did estimates turn into deadlines?
161–170 of 237 posts
Re: When did estimates turn into deadlines?
#162I often see takes on this topic from the engineering side. "It's hard!". "Managers just don't understand". It feels like as a community, it would be useful to get more articles seeing things from the other side and exploring functional approaches beyond provide-a-worst-case-scenario-estimate. There's a reason this dynamic is so pervasive. In order for everyone in an organization to do their job well, people do often…
This is it. I'm a hardcore engineer at heart who has a lot of these sales, marketing, and product folks as friends, and can attest to the fact that they also have constraints. The whole world runs on deadlines and timelines. Even a president is elected for a specific duration. If you're in a B2B setting, the customer demands (sometimes even contractually binding) at least the Quarter when something will be delivered.…
Presidents are technically timeboxed, at least in the US.
Re: When did estimates turn into deadlines?
#163> When did estimates turn into deadlines? In my personal experience: the first time I gave what could be construed as an official estimate.
The deadline portion come in when someone expects to pay for the work or to pay for the opportunity cost for the work not being completed...
And yet Deloitte continues to exist and overcharge and overrun deadlines, and the economy, I'm told, is still doing quite well. Maybe this is all kayfabe and it doesn't actually matter.
Re: When did estimates turn into deadlines?
#164Earlier quoted context omitted.
What helped me was to track Sprint Volatility in addition to Sprint Velocity. We had our over all capacity, let's say 40 points and that would go up or down some based on people leaving the team, joining the team, etc. It's just an average of how much a team can get done in a given sprint. Velocity was gauged as points per person per day. Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket ou…
> Volatility is how much the sprint changes. Sure you can pull one 5 pt ticket out and add in a 3 point and 2 point, but if you do that 12 times in a two week sprint, we will not finish the sprint even if total capacity stays under 40 points. Isn't the entire point of a sprint that, once planning at the start of the sprint is over, you can't change what's in it by reprioritizing? All of product's reprioritizing shoul…
In official scrum, the development team could choose to accept substitution. It looks like the GP's case, they are obligated to accept substitution.
Re: When did estimates turn into deadlines?
#165When managers refused to accept that we just can't predict the future of the creative work that is software design and implementation. And that's because their entire existence is based upon money, not results. I've only ever had one good manager, and that was because he knew what he didn't know and accepted that we do and are trying our best.
I was asked to estimate a major project after a month of onboarding and such, and despite being lied to that the deadline was flexible, management decided the estimate was a suicide pact. Best part is: we all got laid off right as we finished up most of the work.
So yeah. Predicting the future is hard.
Re: When did estimates turn into deadlines?
#166Working in smaller steps is how you should build software. Constantly get feedback and re-evaluate what you're working on with other members of the team. Instead of giving an estimate, use t-shirt size. With constant feedback, the whole team is participating in the emergent complexity, instead of being passive and just annoying you with "is it done yet"?
I don't need constant feedback, I mostly need to be left alone to do the actual work. Problem is, the Cult of Agile gets nervous by the third daily standup where you just say you're still working on the same thing, because everyone knows no programming activity ever takes more than a large t-shirt's worth of days, however many that is.
Re: When did estimates turn into deadlines?
#167My estimation technique is to completely ignore the nature of the task, and instead just try to figure out the highest number the person asking will accept.
Re: When did estimates turn into deadlines?
#168My estimation technique is to completely ignore the nature of the task, and instead just try to figure out the highest number the person asking will accept.
Funny, their technique is to completely ignore the nature of the task and ask for the smallest possible number you will accept.
Re: When did estimates turn into deadlines?
#169When incompetent management who scam their sorry asses to the top for a lick of the brass ring before getting their asses kicked to the curb became the norm.
This is a problem people and we're not impressed.
Re: When did estimates turn into deadlines?
#170I've gone through times when management would treat estimates as deadlines, and were deaf to any sort of reason about why it could be otherwise, like the usual thing of them changing the specification repeatedly. So when those times have occurred I've (we've more accurately) adopted what I refer to the "deer in the headlights" response to just about anything non-trivial. "Hoo boy, that could be doozy. I think someone…
In my experience, super large estimates don’t make you look good in the long run, they make you look incompetent. The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks. Maybe this is a good strategy for dealing with people who aren’t going to judge you for delivering slowly, or for managers who don’t know what the fuck is going on. For managers who…
> The engineers who are most likely to be under-performers are also those who give super inflated estimates for simple tasks.
Definitely did not seen this. Under performers are underestimating or just do wild random guesses. Under performance is most likely to be in the form of "making small estimate, try to make it technically, but then it has about millions of problems".
Big estimates require courage and confidence - under performers usually do not have either. They are too scared to estimate high.