Because managers already "know" how long it will take, based on how little budget they have, and they get very upset on anybody who contradicts them.
Why software projects take longer than you think: a statistical model (2019)
31–40 of 178 posts
Re: Why software projects take longer than you think: a statistical model (2019)
#32All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…
> The way anything actually gets done is by initially being overly optimistic (...)
I don't think so. At most, planners plan for the happy path and then add slack to help them manage expectations. Sometimes stuff emerges and projects adapt. Sometimes your slack covers it, sometimes it doesn't and you get delays and extra costs. That's a Project Manager's dish of the day.
> then lock it in via sunk costs
You're presuming that clients are oblivious to issues of delays and cost overruns, and the negotiation stages don't include accountability specifications.
Re: Why software projects take longer than you think: a statistical model (2019)
#33 Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.[1]
(I mean, edge case that are impossible to complete exist and are annoying, but mathematically they are a kludge. Hofstadter already explained why it takes so long. ;)
Re: Why software projects take longer than you think: a statistical model (2019)
#34All this smokes and mirrors, when the reality is: if you gave accurate estimates, you'd get reprimanded, not get the project approved, etc. Same reason that infrastructure project go over budget. The way anything actually gets done is by initially being overly optimistic, ignoring potential future problems, getting the project approved, then lock it in via sunk costs, now as problems turn up, you can claim it could n…
This feels bleak.
I'm not implying you're wrong. Frankly, I wouldn't know enough for or against. And if I had to choose, I'd be inclined to agree.
It just feels bleak.
Re: Why software projects take longer than you think: a statistical model (2019)
#35Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
This doesn't really sound like an Agile problem specifically, more like a broader problem of "your on-call technical support roles shouldn't be shouldered by your core development team."
I've worked in an Agile team on a pre-launch product and after the 10min morning scrum (which served more to cement personal accountability and discover blockers than as the showboating and bikeshedding venue that some people here seem to have encountered) the rest of the day was more or less uninterrupted dev time with a few impromptu soccer games thrown in (for research purposes). It worked pretty well.
I'm currently in a 100% Agile-free environment, experiencing the delightful after-effects of good product-market fit, which means even if I have a clear schedule I never know if I'm going to spend half the day trying to help troubleshoot issues or helping end users integrate our product. I don't mind doing this, I want our customers to have the best experience possible and so far it seems to be working pretty well. It does, however, wreak havoc on my ability to 'get in the zone' because subconsciously I know I'll probably just be interrupted anyway.
Re: Why software projects take longer than you think: a statistical model (2019)
#36What I find ironic is that everyone in the industry knows that estimating is very hard, thus estimations are nearly useless, yet everyone insists on the importance of planning and on basing such planning on void estimates. Nobody has yet had the balls to state the obvious: we have to learn to work without estimations.
Planning and estimating are orthogonal. I don't think inaccurate estimates should prevent you from anticipating the future.
> have to learn to work without estimations.
A closely related, but different time management tool is a budget. Consider the same website but made in: 3 hours, 3 weeks, or 3 years. The methodology and tradeoffs the engineer approaches each of those projects is very different and needs to be known up front.
Part of the goal of estimation should be to create a budget for various key areas of the project, not guess how long it will take to fix 5 critical system bugs.
Re: Why software projects take longer than you think: a statistical model (2019)
#37Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
> in a meeting-heavy agile environment Everytime I see that, I cringe. But sadly, you're not wrong. Agile is anti-meeting, anti-heavy and definitely anti-meeting-heavy. I really don't know what to call this weird thing that was created. Just as an example: why are there standups? Because in XP, meetings are frowned upon . So the idea is not to have meetings whenever humanly possible (better to pair up, talk to indivi…
Don't get me started. The agile manifesto says “individuals and interactions over processes”. So, of course a whole industry popped up of managers (and agile consultants) prescribing scrum.
In practice, it's not unlike waterfall, because requirements and timetables are prescribed from above. But hey, the team has a sprint kickoff meeting every two weeks, so we call it agile.
Re: Why software projects take longer than you think: a statistical model (2019)
#38Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
> in a meeting-heavy agile environment Everytime I see that, I cringe. But sadly, you're not wrong. Agile is anti-meeting, anti-heavy and definitely anti-meeting-heavy. I really don't know what to call this weird thing that was created. Just as an example: why are there standups? Because in XP, meetings are frowned upon . So the idea is not to have meetings whenever humanly possible (better to pair up, talk to indivi…
It’s fun talking about Agile as something different from agile.
If a team practices Agile, they’re not likely to be agile.
Re: Why software projects take longer than you think: a statistical model (2019)
#39Another factor here is in a meeting-heavy agile environment, many engineers can't even give a good forward estimate of the number of "in the zone" hours they will have in the coming week. Will I be on 0 outage calls or 5? Doesn't matter if I am on pager duty rotation or not.. Will I get pulled into 3 calls this afternoon or 0? Is my boss gonna come bother me with some urgent non-ticket task tomorrow morning? Etc. I'm…
> in a meeting-heavy agile environment Everytime I see that, I cringe. But sadly, you're not wrong. Agile is anti-meeting, anti-heavy and definitely anti-meeting-heavy. I really don't know what to call this weird thing that was created. Just as an example: why are there standups? Because in XP, meetings are frowned upon . So the idea is not to have meetings whenever humanly possible (better to pair up, talk to indivi…
>I really don't know what to call this weird thing that was created.
Micromanagement. https://en.m.wikipedia.org/wiki/Micromanagement
It's not a new concept, agile and project management tools around it decided to break things into small enough components that they essentially just streamlined and concretized micromanagement as a normal accepted daily business process. That's all "agile" is in practice in most case. If you see "agile" substitute "micromanagement" and everything that happens will make complete sense.
Re: Why software projects take longer than you think: a statistical model (2019)
#40Earlier quoted context omitted.
> in a meeting-heavy agile environment Everytime I see that, I cringe. But sadly, you're not wrong. Agile is anti-meeting, anti-heavy and definitely anti-meeting-heavy. I really don't know what to call this weird thing that was created. Just as an example: why are there standups? Because in XP, meetings are frowned upon . So the idea is not to have meetings whenever humanly possible (better to pair up, talk to indivi…
It’s fun talking about Agile as something different from agile. If a team practices Agile , they’re not likely to be agile.
On a tangent, a metric I've found strongly inversely correlated to productivity is average-mentions-of-"agile"-per-meeting. I've seen teams with AMAPA scores of 5+, holy crap what a shit storm that was.