A company I was at 20 years ago did a variation of this for software estimation. It resulted in some good discussions. It wasn't anonymous as mentioned here.
When one person on the team says an element will take one week and another says 8 weeks, there are fundamental differences in assumptions that need to be worked out. That was the good part of the process. The bad was when the Project Manager doesn't let the process play out and simply takes the shortest of the available estimates.
This triggered my PTSD with regards to project managers. People whine about agile and scrum etc. but what they don’t realise is that the biggest benefit of those processes was that they replaced project management led, waterfall based processes.
Waterfall failed for many reasons, but one of them was because you’d get asshole project managers constantly taking minimal estimates exactly as you describe and then applying pressure on individual devs when they overrun the minimum estimates.
One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.
Professional project management (PMI) embraces critical path, iron triangle, risk management. Iteration was always The Correct Answer™.
Kids today conflate "throw it over the wall" with waterfall.
Agile rejects planning, foresight, vision, end goals. Agile was explicitly concocted to manage upwards, in those organizations unable or unwilling to do proper planning. Unfortunately, the originators wrote down their survival tips, which were then misunderstood by noobs and embraced by profiteers. Just like every other religious text.
Agile is not the victory of iteration over some imagined dark ages of project chaos. The Agile Methodology is to argue about the Agile Methodology. The cult(ural) spread of Agile is no different than any other vacuous self-help omni-fix content-free dogma.
Any decent project manager know their people,so if Mark says it will take 2 days but in reality takes 5, the PM should see these patterns and either help the person to improve estimations,or adjust project deliverables based on this knowledge.
It's one of the many tools in the efficient tyrannical manager's toolbox, with a motto of "my goal is not to have you do effective work, my aim is to advance my goals and keep everyone below as a non-threat to those goals". Keep em busy and insecure.
Sure nice it doesn't work on competent developers, not with the current job market.
> One of the biggest contributors to developer happiness and productivity over the last 20 years has been to escape this tyranny.
We've only replaced the tyranny of deadline crunch with the tyranny of daily micromanagement. You can't even wipe your own ass without so much as a Jira ticket and half a dozen people signing off on it.
And despite all of the rigmarole and rituals, you still have deadlines. Doesn't matter what the Jira board says. If some upper management dickweasel wants their feature, they will get it. Forget the story points and estimates.
Edit: as I recall from doing estimating using wideband Delphi circa 2004, the main differences with planning poker as I see it practiced today are that estimates were in real time like days or weeks, and votes were collected and displayed anonymously, though as you would expect there was temptation for people to de-anonymize their own votes.
PM should always work with/as a business analyst to figure out the business requirements. A lot of times it is the ambiguity of business requirements that leads to bad decisions.
Years ago we used this method with a group of neuropsychologists and physicians to develop an algorithm for clinical decision support for traumatic brain injury and PTSD evaluation at the VA. It helped provide validation of a 3 question screener that would get veterans to the right services while not burdening other vets with an hour long evaluation appointment. The screener is still in use today AFAIK. The Delphi process itself was a cool experience and allowed a lot of "cooler" analytical thought whereas committee meetings tend to have problems with egos and hot takes.
That pamphlet is wild. It reads as really paranoid, but I totally agree with it. It seems like Delphi isn't at all resilient to being run by bad intentioned people. This make it terrible for something like setting public policy.
It doesn't make it worthless, though. If you had a 20 person company where ownership was legitimately interested in getting the best answer to the problem, maybe this is an efficient way of doing that.
I got a kick out of the sensational tone. I’ve seen this pattern at many public meetings for spending road improvement budgets and the like. There certainly is no deviation from the plan based on anything that happens in these meetings. However, the participation by the lower level facilitators is more fairly described as work-a-day rather than malicious.
This is pretty funny. It sounds like some governing bodies the author of this document is familiar with have inappropriately used this forecasting procedure as a governance procedure. This is totally something I can imagine some bright-eyed local politics midwit doing.
We do a version of this with our clients, where we use our forecasting software and host a "live" forecasting session. We make people forecast "cold" on something: likelihood of hitting milestones, competitive intelligence, industry trend, whatever, and then have someone come in and give a talk on what we've asked people to forecast. We follow that up with more forecasting and get to see if people were influenced by the expert or not.
Perhaps the most valuable part is the discussion after making that second forecast. We identify a lot of bias and assumptions people were making that they then learn from the next time they have to make a forecast like that.
Sounds very much like story point estimation that my team does all the time: “The objective of the method was to combine expert opinions on likelihood and expected development time, of the particular technology, in a single indicator.”
Anonymity is the first “key characteristic” listed and I can’t find any mention on this page that it is optional for this method.
EDIT: Looking more into it, it seems that it went from "Delph method" to "Wideband delphi" to "Planning poker", and it's in the last step that the anonymity requirement disappeared. Very interesting!
I first learned about the Delphi Method from
the book Software Estimation: Demystifying the Black Art.
Although I have not used it in practice yet, I like the concept, especially for some more difficult (bigger) estimation tasks, so I am mentioning it in my book besides other "group estimation techniques".
It is true that this is basically async "planning poker".
I first learned about it when a client hired me to write software to support this method for use in pharmaceutical planning and marketing. Very useful if done correctly.
Could this be the solution to the pain of trying to discuss a complex topic in zoom meetings? I kept thinking we should use parliamentary procedure or something but this sounds like less friction and it is mostly what we are already doing but with a little bit of structure.
When one person on the team says an element will take one week and another says 8 weeks, there are fundamental differences in assumptions that need to be worked out. That was the good part of the process. The bad was when the Project Manager doesn't let the process play out and simply takes the shortest of the available estimates.