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

101–110 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#101

Post by PakG1 »

pas wrote: post #83
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.

It is, that doesn't mean that people do it. :D

Re: Reality Driven Development: Fixing Project Management in Software

#102

Post by andrewstellman »

I really like this article, and agree with a great deal of it. But while what he's doing looks a lot like Kanban, it's not. Kanban is a method for process improvement, not a method for managing software projects. We write about this in both Learning Agile and Head First Agile -- here's an excerpt: https://twitter.com/AndrewStellman/status/100022571573903360...

When Jenny Greene and I were working on our book, "Learning Agile: Understanding Scrum, XP, Lean, and Kanban," we were lucky enough to have David Anderson (the guy who adapted kanban for software development) review our chapter on Kanban, and he really helped us nail down this particular issue.

Other than that (and a few things he says about the PMP certification), what he says in the piece is spot on. Nice work -- I'd love to see it expanded into a book!

Re: Reality Driven Development: Fixing Project Management in Software

#103

Post by BoiledCabbage »

Swizec wrote: post #100
mescalito wrote: post #93

Earlier quoted context omitted.

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?

Based on value.

You still need to know how much it'll cost you. If you can't estimate how long it'll take, you may spend more in paying employees than it pay for the project.

Re: Reality Driven Development: Fixing Project Management in Software

#104

Post by lazyasciiart »

alasdair_ wrote: post #58
Benjammer wrote: post #36

Earlier quoted context omitted.

I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.

Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html

Oh, you'd think so. Then you might be unlucky enough to work with some 'senior programmers' who have been 'doing Agile for years' and are able to convince the manager that a spike that doesn't result in code that will go to production is a waste of time. I never worked out whether that was malice or stupidity.

Re: Reality Driven Development: Fixing Project Management in Software

#105

Post by hardwaresofton »

wpietri wrote: post #56
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…

Yeah, I love it when customers can work like that. The way I often explain it is that a product manager can buy software, but they can also buy information . Information like, "Is X possible?" or "What would it cost to build Y?" or "What would the performance be if we switched to Z?". Once they catch on to that, it can be great.

This reminds me of a article on HN from earlier -- this sounds like the core competency of management consulting:

https://www.cbinsights.com/research/disrupting-management-co...

One of companies mentioned, Gerson Lehrman Group (GLG), literally sells the time of vetted experts.

Re: Reality Driven Development: Fixing Project Management in Software

#106

Post by ironjunkie »

DanielBMarkham wrote: post #48

There's a lot here. People have been writing books about this for decades. Two things that need to be succinctly said: 1. Project Management is just another skill , like database management, security, or any one of a hundred other skills a tech team might have. PMs keep trying to take themselves out of the trenches and claim a special place. Every time they do that it is a mistake. 2. He touches on "waterfall" a few…

This hits home.

Wy too many times I have been at places where the Project Manager is seen as the "Boss" or the gatekeeper by management and by himself.

Engineer usually disrespect the project manager as they don't really understand anything and just do stuff based on an Excel sheet.

Re: Reality Driven Development: Fixing Project Management in Software

#107

Post by ianmcgowan »

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?

This is one of the best software books I've read, that's not about strictly about software. The concept of small batch sizes in particular maps really well to prototyping and agile approaches. But it gives a basis for why those approaches make sense and work. It's like quantum mechanics compared to classical mechanics...

Re: Reality Driven Development: Fixing Project Management in Software

#109

Post by gaius »

alasdair_ wrote: post #58
Benjammer wrote: post #36

Earlier quoted context omitted.

I think engineers need to start talking about this concept in a much more official way, and approach it with the business side as another full task type called "Technical Discovery," with clear goals and a clear time-box.

Hasn't this been a core component of doing "agile" in any meaningful way since the beginning? Example: "architectural spikes" in eXtreme Programming: http://www.extremeprogramming.org/rules/spike.html

The irony being that XP and the like are only suited to cookie-cutter, commoditised work that is essentially risk-free anyway

Re: Reality Driven Development: Fixing Project Management in Software

#110

Post by gaius »

jeremycw wrote: post #24
superhuzza wrote: post #20

Earlier quoted context omitted.

It's pretty refreshing to read posts that admit 'management is difficult' on HN. We can get a bit lost in our bubble of tech work, and forget how important management is to actually accomplishing things.

Unfortunately unlike software development there's no simple way to check if the 'output' of management is working correctly or not. This combination of 'hard to do' and 'hard to verify' means that there are many projects humming away with incredibly poor management.

there's no simple way to check if the 'output' of management is working correctly or not.

What an odd thing to say - ask any accountant or banker and they’ll say they’ve had methods for this for literally hundreds of years. Ever since “share price” was a thing, and even before that.

The problem is doing something with the information. Look at IBM for example (one of many). You can see simultaneously that managers are doing a terrible job - zero revenue growth for years - but also see that they are lavishly rewarding themselves for it.

Post reply on HN