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

81–90 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#81

Post by pas »

TulliusCicero wrote: post #75

> The moment that story estimating becomes time estimating...stop. That's not what it is there for and you're not trying to assign out every minute for a person. I don't see the distinction here. The whole reason you're estimating things is to guess at how long they'll take. If the story points do not translate to time, what use are they?

it's task sanity checking.

is the task description ambiguous? then estimates will be all over the place, so you'll know you need to spend more time on specifying the task.

and risk minimalization. if the estimated complexity is above some threshold, you need to break down the task.

to get a time estimate you use the historic burn down rate (average story points per sprint completed/delivered)

but it's not something you can do up front.

Re: Reality Driven Development: Fixing Project Management in Software

#83

Post by pas »

commandlinefan wrote: post #33

> knowledge of existing libraries, algorithms, systems, permissions I can't help but notice, also, that no project management "methodology" emphasizes (or even allows for) time spent researching/learning existing libraries, algorithms, systems, permissions, even though I think everybody would agree that this is where you're going to get the biggest payoff.

that's bollocks, and I phrased it nicely.

every pm methodology talks about getting to know the problem domain, risk minimalization (start with the riskiest assumption, do a minmax check on it, the pivot to the next riskiest, and so on).

selecting the right tool for the job is an inherent part of the process.

Re: Reality Driven Development: Fixing Project Management in Software

#84

Post by crb002 »

crb002 wrote: post #82

Kanban + someone technical who understands critical path bottlenecks and prioritizes those tasks so others can keep chugging along in parallel.

I fucked a consultancy once on accident with this. They hired two extra devs and a manager griped at me that I wasn't being productive enough. I sketched the critical path of information flows required, and every morning grabbed a blocker card. Got a four month project done in one, consultancy was screwed because they had no backlog and were billing hourly. Oops.

Re: Reality Driven Development: Fixing Project Management in Software

#85

Post by crb002 »

overgard wrote: post #34

One of the things that drives me crazy about agile is the strawman that is "waterfall". There's this notion that if you're not doing kanban or scrum you're a dinosaur. I've worked at places that didn't have some sort of Methodology, and you know what? It was fine. Things still got estimated, work got done, we just didn't arbitrarily shove things into 2 week windows or have painfully elongated planning sessions becaus…

The waterfall albatross is the absurd amount of up front requirement documentation in a Word file on a share drive.

Modern waterfall where you have documentation in git with references into tests is 10x better than the waterfall of old.

Re: Reality Driven Development: Fixing Project Management in Software

#86

Post by borplk »

mikekchar wrote: post #80
radley wrote: post #77

The biggest flaw in Agile stand-ups is that it was developed before Slack became a standard. For our small team, we created a Team Scrum channel solely for the purpose of allowing devs to check in at the start and end of day with work progress. This reduced a ton of overhead.

Not take focus away from that good idea (and it is a good idea), the biggest flaw in "Agile" is that people think that stand-ups are for reporting work progress/status. A stand-up is for getting clarification on what you are doing, arranging to get help, clearing up misconceptions between people, ensuring that the interfaces for different stories are meshing (and people aren't going off in wildly different directions…

Way too optimistic.

Businesses instantly turn the methodology into a device for exerting power.

What you are describing only exists in books and on manifestos and perhaps in 5% of the businesses.

The rest bastardise and devour the methodology to their liking.

Re: Reality Driven Development: Fixing Project Management in Software

#87

Post by jrs95 »

I highly recommend this video of a Dave Thomas talk about what agile was supposed to be vs what it has become. Most of us are probably stuck working with some sort of Agile methodology regardless of whether or not we'd like to, but it can still be nudged in the direction that Dave talks about.

https://www.youtube.com/watch?v=a-BOSpxYJ9M

Re: Reality Driven Development: Fixing Project Management in Software

#88

Post by wpietri »

brightball wrote: post #63
wpietri wrote: post #55

I really like this, and I'm saving it for next time I need to help somebody with a PMP orientation understand my perspective. But I think it misses the mark a bit on pairing. Having somebody shoulder-surf once in a while is not a bad idea, but it's definitely not pairing. Even if you're only doing it a little, I think it's worth setting up for true pairing, so that both people can easily jump in and work on the code…

I'm not against pairing more but there are some people who are incredibly uncomfortable with it. For a short period of time, you don't need much more than a person having a suggestion and dictating if they want to jump in. I'd have serious reservations about mandating too much of it. There's a gap between, "I need to type in this environment for a few minutes" and "I need to become proficient with this environment so…

Yeah, I've talked with a number of people who've had bad experiences. A while back I wrote up a list of things that can make pairing unpleasant: http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra...

I get the thing with environments, but it got a lot easier for me when I'd just ask people to do the magic I didn't know in their tools. Especially if it's two keyboards and two mice, it's easy enough to say, "Ok, now jump back to the test" and have them seize control for a few seconds.

Re: Reality Driven Development: Fixing Project Management in Software

#89

Post by taberiand »

cabalspecter wrote: post #71
overgard wrote: post #34

One of the things that drives me crazy about agile is the strawman that is "waterfall". There's this notion that if you're not doing kanban or scrum you're a dinosaur. I've worked at places that didn't have some sort of Methodology, and you know what? It was fine. Things still got estimated, work got done, we just didn't arbitrarily shove things into 2 week windows or have painfully elongated planning sessions becaus…

I believe the efficiency got "worse" because it revealed the harsh truth earlier which the Gantt chart hides... until the very end.

It's common for management to think we're making things more difficult when we're just making the difficulties more visible.

Re: Reality Driven Development: Fixing Project Management in Software

#90

Post by andrewflnr »

LoSboccacc wrote: post #12
giulianob wrote: post #4

Earlier quoted context omitted.

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 t…

I’ve got to do a lot of contract software work back in the day and was the one working first draft requirements with clients before the actual contract. It was common to spend a week into planning for every six man/month of project Using that as ballpark we never got an estimate having more than 10% error. Anectodal, I know, but without that kind of effort one is not doing an estimate is doing a guess. That also why…

> It just feel like a sequence of dice rolls hoping you don’t end up at the far tail of the gaussian.

That's exactly, precisely what it is, by design AFAICT. The thing about gaussians is, what with the central limit theorem and all, you provably don't end up on their tail very often.

That said, gathering a bunch more data can make your gaussian even narrower. I think you and (platonically ideal) Agile are just at different spots on the same spectrum of risk tolerance.

Post reply on HN