Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reality Driven Development: Fixing Project Management in Software

brightball.com

Post reply on HN
Print view View original

1–10 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#4

Post by giulianob »

brightball wrote: post #2

Author here if anybody has any questions.

I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is to give an estimate the less time they want you to spend researching the work. To increase the accuracy of an estimate, you need to do more research and if you take that to its logical conclusion then the best estimate is given after the work is completed. So there is some area in between of extremely inaccurate guess with little effort to actually doing the work and knowing the time it took. It's best to accept that estimates are near useless (unless you want to spend a lot of time basically doing waterfall to come up with requirements/design/etc...) and instead just try to find out how to chop up the work into smaller pieces that each deliver value and plan how the feature will be delivered. This way the team can be focused on actually getting value out the door instead of spending time doing a futile exercise (estimating).

Re: Reality Driven Development: Fixing Project Management in Software

#5

Post by jrs235 »

brightball wrote: post #2

Author here if anybody has any questions.

You put my same thoughts into words.

" Those principles actually do work extremely well in many, many industries. PMP focuses almost entirely on Waterfall methodology and gaining the certification is largely driven by terminology and math.

But software is a special snowflake in the project management world and this is why countless books around managing software continue to be written."

Thanks.

I highly recommend you read the book I asked about in a sister comment. I wish the business people would read it. The issue I think is it correlates and requires an understanding of other "techie" and STEM subjects like queues, math (related to queues), network protocols, and traffic flow. Until the business people understand the maths and tech topics that book appeals to, friction will continue to exist.

Re: Reality Driven Development: Fixing Project Management in Software

#7

Post by cellis »

brightball wrote: post #2

Author here if anybody has any questions.

This was a great write up! I’ve been thinking about this problem A LOT while building a project/team planning software startup. What do you think about having every engineer estimate one task for the upcoming sprint? Also, I’ve found that the estimation process ( I.e voting ) in my experience is better if blinded, otherwise there will be extreme peer pressure to over or under estimate.

Re: Reality Driven Development: Fixing Project Management in Software

#8

Post by brightball »

jrs235 wrote: post #3
brightball wrote: post #2

Author here if anybody has any questions.

Have you read "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen?

I have not but I just ordered it. From the description, it looks like we're on the same page.

Re: Reality Driven Development: Fixing Project Management in Software

#9

Post by brightball »

cellis wrote: post #7
brightball wrote: post #2

Author here if anybody has any questions.

This was a great write up! I’ve been thinking about this problem A LOT while building a project/team planning software startup. What do you think about having every engineer estimate one task for the upcoming sprint? Also, I’ve found that the estimation process ( I.e voting ) in my experience is better if blinded, otherwise there will be extreme peer pressure to over or under estimate.

That pressure can be very real. Personally, I don't see a tremendous amount of value in overthinking estimates as much as re-evaluating estimates once the task starts.

The methodology I mentioned calls for exactly that, estimating best case, realistic and worst case...and then re-evaluating once the work starts.

You never really know until somebody dives into the work and it's rare to actually get time before an estimating meeting to individually look into each story. Treat the estimate as a best guess and then re-evaluate when you have better information.

Post reply on HN