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

121–130 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#121

Post by erikb »

solatic wrote: post #46

I continue to be unshockingly shocked by accounts which describe project management as something rather low-skilled. How much skill does it require to take feature requests from customers and talk to devs once a week to ask them how long do they think it'll take them, to try to get product out the door quickly, akin to a restaurant shift manager? I really don't see it as taking very much skill at all. Take somebody w…

This!

Sadly most people who care about PM and team leading are of the first category, with zero skill in anything and only a basic set of buzz words from the PM world, which sadly doesn't even give them the opportunity to see how management skill can be a much bigger factor than process.

Re: Reality Driven Development: Fixing Project Management in Software

#122

Post by erikb »

bluesnowmonkey wrote: post #73

Oh, there was a silver bullet after all. Turns out Kanban and 2 hours of pair programming per week is the Right Software Development Methodology.

Which gives a hint about the value of the 200 paragraphs before that conclusion.

Re: Reality Driven Development: Fixing Project Management in Software

#123

Post by tigershark »

solatic wrote: post #46

I continue to be unshockingly shocked by accounts which describe project management as something rather low-skilled. How much skill does it require to take feature requests from customers and talk to devs once a week to ask them how long do they think it'll take them, to try to get product out the door quickly, akin to a restaurant shift manager? I really don't see it as taking very much skill at all. Take somebody w…

You just described a tech lead not a PM.

Re: Reality Driven Development: Fixing Project Management in Software

#124

Post by marcus_holmes »

overgard wrote: post #57
browningstreet wrote: post #42

Earlier quoted context omitted.

Sometimes agile is the right way to exert control back against management, if management is prone to chaos and disorder. I took an organization that couldn't put out two releases a year to one that put out once a month, and the owner/manager complained bitterly and pushed new features into the discussion ON THE DAY OF RELEASE. 2nd level management had to constantly, repeatedly attest to the good that the tempo and st…

It sounds like you had a bad manager, but no methodology can fix that. My entire experience has been: good management + talented developers = success, and bad management or untalented developers and it fails, but it really has nothing to do with the methodology in play. I've seen (and been part of) hard core agile teams burning to the ground, and teams with no methodology be wildly successful. (And vice versa) Agile…

this, completely.

The best places to work adapt the process to the team.

The worst enforce a process on the team because it makes managing them easier.

The number of workplaces I've been in who equate the number of hours that people are in the office with their productivity, because managers could measure attendance easily, and had no idea how to measure actual productivity...

Re: Reality Driven Development: Fixing Project Management in Software

#125

Post by erikb »

jrs95 wrote: post #87

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

I think the big part of every movement is that initially it's done by people who like to do things, and who want the doing part to be more fun for people like them.

But the huge public success comes through people who lead huge businesses or countries, and who are faced with the situation where they have a set of mostly unmotivated, unskilled people who should do something for mostly unmotivated, unskilled customers/citizen. So for them it's not at all about making it more fun for people who love to do it and who have skills, but about making it simple, controllable, and most importantly look successful although they already know BEFORE they start that it won't be successful at all, due to the lack of motivation and skill in their general userbase.

So that "The values have been totally lost behind the implementation" is neither a coincidence, i.e. it doesn't just happen in software dev, nor a surprise, i.e. it was known before it became popular that it couldn't become popular and keep its values.

Sometimes when I watch/listen/read about people explaining this as a surprising and undesired result, I wonder whether they really are so naive, or if they are looking for a way to profit from a younger audience who hasn't experience such a complete popularity loop yet.

Re: Reality Driven Development: Fixing Project Management in Software

#126

Post by erkkie »

mescalito wrote: post #93
martin_drapeau wrote: post #91

Estimates are usually wrong. You can do T-Shirt sizes, that's fine. However days and hours is very hard to estimate even for one person. For a team, impossible. There are too many factors to consider: team understanding of the problem, team experience, technology, etc. Whatever methodology you use, delivering usable increments at regular intervals is the way to go. You can see progress, determine if the direction is…

I agree with pretty much everything and I also advocate for that. However, how do you invoice your clients? Its hard to say: hey I'll charge X for each two weeks increment. Client: Great, how many increments will there be? Me: dunno, we'll figure it out somewhere down the increments. The agile approach is the way to manage projects, but how do you quote them?

Usually just by that, in increments. It helps to time-box something early into a new client relationship and once you're delivering proven value, clients tend to be fine with just incremental delivery and billing.

Re: Reality Driven Development: Fixing Project Management in Software

#127

Post by jarl-ragnar »

zhdc1 wrote: post #111
jarl-ragnar wrote: post #26

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understa…

Yes. Yes. Yes. Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to. For in…

I'm now head of product development at a different company and one of the key activities I instantiated was using internal R&D funding to conduct technical discovery and remove, where possible, software development of new functionality from the critical path of project delivery.

I'm convinced IT project management could learn a lot from civil engineering project management.

Re: Reality Driven Development: Fixing Project Management in Software

#128

Post by flud »

jarl-ragnar wrote: post #26

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understa…

That sounds pretty smart. How did these de-risking studies usually consist of?

Re: Reality Driven Development: Fixing Project Management in Software

#129

Post by flud »

eagsalazar2 wrote: post #41
jarl-ragnar wrote: post #26

A few years ago I was technical lead for a team that worked one of the largest IT systems in the UK that you've probably never heard of. The customer was truely enlightened and would fund short technical de-risking studies to understand and scope challenging tasks before asking the contracting organisations to produce a firm price proposal for delivering the capability. This worked well and was driven by his understa…

At my company projects always start with P1 - research, and P2 - plumbing which are exactly what they sound like. The idea being to uncover and confront risk/unknowns as early as possible before some massive misguided investment has been made.

What's the plumbing part? And what scale are the projects, ballpark?

Re: Reality Driven Development: Fixing Project Management in Software

#130

Post by vannevar »

overgard wrote: post #57
browningstreet wrote: post #42

Earlier quoted context omitted.

Sometimes agile is the right way to exert control back against management, if management is prone to chaos and disorder. I took an organization that couldn't put out two releases a year to one that put out once a month, and the owner/manager complained bitterly and pushed new features into the discussion ON THE DAY OF RELEASE. 2nd level management had to constantly, repeatedly attest to the good that the tempo and st…

It sounds like you had a bad manager, but no methodology can fix that. My entire experience has been: good management + talented developers = success, and bad management or untalented developers and it fails, but it really has nothing to do with the methodology in play. I've seen (and been part of) hard core agile teams burning to the ground, and teams with no methodology be wildly successful. (And vice versa) Agile…

I cringe when I hear people criticize agile for trying to "fit" everything into a two week sprint. Competent developers always chunk their work into small, comprehensible pieces, and if anything, two weeks is actually bigger than most of those chunks, not smaller. Agile never requires that everything be done in two weeks, it only requires that there is demonstrable functionality every sprint (which doesn't even have to be two weeks, it could just as easily be three, or four, or six, if that works better for the team).
Post reply on HN