7 ms·
I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best a
by ptmcc 3y ago
I agree. In my experience that outside visibility is mostly a mirage.
Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years.
In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on top to satisfy management and/or external parties.
- rightbyte 3y agoYe padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?
- emodendroket 3y agoEstimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?
- gilbetron 3y agoConstructions remains a terrible analogy for software development, as it always has been.
- emodendroket 3y agoWould you agree to pay for any service where not even an estimate of the price could be given? I guess healthcare is the only example I can think of where anyone consents to that.
- deleted 3y ago[deleted]
- davemp 3y agoEstimates you get are what the estimator thinks you will pay (mostly) not how much it costs them. Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.
- emodendroket 3y agoEven to the extent that is true it doesn’t change my argument at all.
- davemp 3y agoMaybe I don't see the relevance of your question then. Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees. Agile is a development process not a contract pricing strategy. If anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.
- emodendroket 3y agoThey don’t have to hire you every two weeks but they are paying for you and do have to decide how to allocate your time and plan various projects with interlocking dependencies. How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? You are, in effect, still asking them to write you a blank check to accomplish something when they might want to change gears if apprised of how difficult it is.
- davemp 3y ago> How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? This is not exclusive to scrum.
- nprateem 3y agoMost companies have already hired the contractor though so this little dance is just pointlessness that kills motivation and velocity.
- emodendroket 3y agoSurely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.
- seanhunter 3y agoIf scrum provided that it might have some value. It’s extremely doubtful if you get even a roughly accurate estimate of effort within one project let alone relative effort across two.
- kqr 3y agoMeh. The time it takes to complete a project is usually somewhat flexible. What really matters is how valuable the project is. That is what needs to be estimated explicitly, and not just "I really like these two ideas lets do the cheaper one".
- emodendroket 3y agoHow can you estimate "value" without any idea what resources are needed or what else you will have to forgo to pursue the project?
- kqr 3y agoValue meaning roughly revenue, not profit.
- emodendroket 3y agoBut estimating revenue is just as much of a shot in the dark as estimating effort, and if the effort is great enough it will cancel out the revenue.
- rightbyte 3y agoAt some point there is a need for time estimates, ye. I don't ask contractors for a detailed breakdown, just the whole thing. And they either do a high padded fixed price or work per hour. A friend who is an elictrician might do 100 similar rooms in a building and they have a detailed breakdown of "time per screw" more or less. So I guess the accuracy depends on the sameness of tasks to do.
- ResearchCode 3y agoWould you hire a mathematician that doesn't "story point" conjectures? Yes. Would you hire one that does?
- emodendroket 3y agoI find this analogy harder to understand. What am I hiring the mathematician to do in this example?
- ResearchCode 3y agoResearch mathematics.
- emodendroket 3y agoDo you get paid to do research or is there a deliverable at the end?
- ResearchCode 3y agoYes, you get paid to do research and there are theorems delivered. Just like software projects, some never get delivered and you don't know when if they're not trivial.
- _heimdall 3y agoUnless the contractor is willing to put in writing a "not to exceed" price, I've never put any faith in build estimates. I'd expect a professional to be able to give a rough estimate based on experience and scope, as well as clear communication as the project progresses. Rough estimate meaning accurate withing something like 20-30%, not a detailed breakdown by ever project and material expense. I try to do the same in software projects. Estimating projects by hours is impossible, fibonnaci numbers are a meaningless abstraction, and spending time each sprint to discuss how it went, what the next sprint plan is and estimate every task is a waste of time. What I can say is whether a task looks like something that could be done in an afternoon, a few days, a few weeks, or multiple months. Accuracy there comes with experience, but no one gets better by chopping the calendar year into 2 week intervals and pouring a ton of process all over it.
- monkpit 3y agoContractors charge you based upon the value they provide you, not their costs and labor. A time estimate is reasonable to expect, though.
- emodendroket 3y agoDepends. Being billed by the hour is far from unheard of.
- lucumo 3y agoIs padding really cheating? I'd describe that as accounting for unforeseen setbacks and correcting for overenthusiastic optimism.
- rightbyte 3y agoPadding estimates is fine. But not when you report actual worked time, which was what we did to make management happy with the burn down charts straightness. If you don't report actual time for the task, the excercise is useless. E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.
- watwut 3y agoImo, padding estimates is not cheating. It is just doing estimation right. Teams that do not pad estimates literally always underestimate amount of time needed.
- JohnFen 3y ago> I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". I was a trained Scrum Master and I knew this very well.
- ResearchCode 3y agoWhat's a trained "scrum master"? I thought the certs don't even have exams.
- Kichererbsen 3y agoTotally with you. But since I'm currently preparing to get certified for Scrum, I'd like to point out that all those things you mentioned above aren't really part of Scrum at all...
- robertlagrant 3y agoAll the estimation stuff is only for your team, not for outside consumption. If you release it and care what people say about it, then that I don't think that's the methodology's fault.