Any dev who is asked to give “deadlines” then cried about how it’s “waterfall” and you cannot produce business requirement deadlines in agile methodology needs to stop being dependent on terminology and learn that part of programming is proper estimation.

Milestones, business deadlines and agile can go-exist. Anyone who says they don’t, then cries “waterfall” when asked to produce deadlines greater than 4 weeks out, please never work with me

I agree that dev projects have to be conducted in the context of real world-business planning.

However, programme managers need to start accepting probability distributions as estimates. Using a single point as as estimate for a complex project is the definition of insanity.

@platypus absolutely agree on a large scope. On feature deliverables it’s entirely reasonable for a manager and Dev lead to sit down, go over user stories, then the dev lead can produce estimates for the most desired feature

The dev manager could say “we can have identity login in 2 months the time”

The manager will smile and say sure I’ll give you 2.5 months to finish it

——

What really infuriates me is when dev managers refuse to give estimates like the above example, they call it “waterfall” and worse these types of people DO make estimates and notoriously miss it every time

Stay away from developers who shiver at the notion of milestones or business deliverables. Your business will suffer and your product will be late

Go-exist 😊

@electrineer what?

Have you, personally made the feature, in the tools/language/framework you are using for the current project?

How long did it take you before?

Only way to accurately estimate is from past performance on a per function point basis. If there are any outside variables different from last time, all bets are off.

This is one of the true measures of value, how experience gives a developer the ability to give delivery estimates based on past performance.

It's also why portfolio work is the single best predictor of performance (on similar projects).

For something people have never worked on, or isn't similar, estimates are going to utterly worthless. Better to allocate a percentage of time for exploratory work to learn about the problem domain and requirements.

@Wisecrack couldn’t agree more 🙌.

@champion01 ah co-exist haha. Autocorrect Apple

Actually agile includes a notion of estimates. It's called scrum poker and the cool thing is that it is a group effort so everybody estimates "points" and there is a consensus formed. That makes sure that many people think about how they would tackle the implementation and about possible problems. The average over everybody and learnings from wrong point estimates over time makes it more accurate. Points are relative (not bound to a fixed amount of hours) so in the beginning everyone has their own formula like needed effort, time or difficulty and can only do an ordering like "task A is worth more than B in my metric" and over sprints you slowly adapt to a common point level. Then you measure how many points were achieved in the sprints and you can estimate in which sprint a specific feature is likely to be started. The thing is that scrum is often badly understood and therefore wrongly used by managers and if they then ask for time estimate you cannot reasonably answer...

@irene Agile has its place but what became good organisation has become neurotic and rigid. Software is organic and shit happens.. that’s why the entire premise was to ‘estimate’ and what was over estimated and unfinished moves into the next sprint. Business managers and sales people always fuck shit up because they don’t understand the word estimate. They take it as gospel the wankers.

@faibk

developer estimates are never fungible though.

@badcopnodonuts

"Business managers and sales people always fuck shit up because they don’t understand the word estimate. They take it as gospel the wankers."

You're alright guy.