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

91–100 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#91

Post by martin_drapeau »

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 wrong and change course rapidly.

Software is usually reproducing human processes. Well guess what, processes change when they don't make sense in a given situation. So its logical that the software change over time as we discover more efficient ways of doing things. As such, you cannot plan for the unforeseeable and even less estimate how long it will take.

I therefore agree that optimizing throughput of a team is the one thing to do. Never commit to a delivery date if you can. Instead, commit to delivering usable increments regularly. With that, project management becomes expectations and change management. Lots of communication with the client on showcasing, and hopefully using the increment and provide feedback for the next iteration.

This is really hard to do. Devs have a tendency to stay cooked up in their ivory tower, and product (read project manager as described in the article) have the reflex to protect them from client distractions. The client may not be available or interested either. Nurturing dedicated time slots for client and devs to meet and interact is crucial. If you get that right, and never miss delivering an increment, good things are sure to come out of the project.

Fortunately, with CI and the Internet, we have all the tools to deliver usable increments at regular (even blazing fast) intervals. Power to the people who can leverage those to deliver successful software projects to their customers.

Re: Reality Driven Development: Fixing Project Management in Software

#92

Post by jacques_chester »

I'm an introvert, I have imposter syndrome, self-doubt, perfectionist tendencies and ADHD-PI.

Fulltime pairing has dramatically helped me with all of these.

Many folks feel that it sounds bad. The thing is that it's not really a skill that's easily learned from a book or a blog post. It's much better to learn from an experienced pair.

Disclosure: I work for Pivotal, so that's a large part of our whole thang.

Re: Reality Driven Development: Fixing Project Management in Software

#93

Post by mescalito »

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?

Re: Reality Driven Development: Fixing Project Management in Software

#94

Post by jaggederest »

PeterFBell wrote: post #79
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.

Especially for remote first teams, standups are as much a social connection as an accountability, information sharing and blocker highlighting opportunity. I'm a huge fan of synchronous standups and really like zoom to get the added connection of video and audio with "async standup checkins" being the exception case if someone is at the doctors or whatever. All of this assumes a team with at least some timezone overl…

Why conflate standup with a social checkin? Why not have a pre-lunch time to hang out and shoot the shit, instead of cramming it in as an ad hoc part of "the process" of standup?

Put your details, questions, concerns, etc in text, where anyone can read it any time they like, and make "social hour" something related to being a better teammate on an interpersonal level, instead of a mandatory part of the process.

Re: Reality Driven Development: Fixing Project Management in Software

#95

Post by AlexCoventry »

dgreensp wrote: post #67
jeremycw wrote: post #24

Earlier quoted context omitted.

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.

I would argue bad management is pretty easy spot if you have any reference point for good management; you don’t even have to be a manager. Sit down with a few employees and ask them a few questions. The effects of bad management are everywhere in an organization. Employees are frustrated, resentful, unheard, and happy to talk. Programming is hard, too, and good code is a much subtler thing that requires an expert to…

In what sense is good code subtler than good management? I would have serious the reverse if anything.

Re: Reality Driven Development: Fixing Project Management in Software

#96

Post by no_identd »

brightball wrote: post #39
no_identd wrote: post #28

Earlier quoted context omitted.

Have you ever taken a look at PRINCE2? Not covered in your article.

Haven't yet. Reading up now.

Nice. It's not the greatest thing in the world either, tho. (Not the worst thing either, tho.) Here, a related conference papers (there does exist a staggering amount of project management science - mode of it little applied, however.):

https://link.springer.com/chapter/10.1007/978-3-319-74310-3_...

Oh and, on an unrelated to this but related to Project Management matter, you might find some use for this very Russian tool & programming language, originally developed for the Buran space project (development continued after the project failed for unrelated reasons), and still to this day used in space flight software development:

https://en.wikipedia.org/wiki/DRAKON

Re: Reality Driven Development: Fixing Project Management in Software

#97

Post by jrs235 »

dgreensp wrote: post #67
jeremycw wrote: post #24

Earlier quoted context omitted.

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.

I would argue bad management is pretty easy spot if you have any reference point for good management; you don’t even have to be a manager. Sit down with a few employees and ask them a few questions. The effects of bad management are everywhere in an organization. Employees are frustrated, resentful, unheard, and happy to talk. Programming is hard, too, and good code is a much subtler thing that requires an expert to…

Go up a layer. Bad leadership is worse and can be the cause of bad management.

Re: Reality Driven Development: Fixing Project Management in Software

#98

Post by aninhumer »

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

One thing I've been thinking lately is that this should be baked into the process for every unit of work, not just those people expect to be difficult.

Instead of estimating by guessing based on reading the requirements, work on an issue for say an hour or so and then estimate it.

It still wouldn't be perfect, but I think this would catch a lot of cases where, for example, a seemingly simple feature ends up requiring an extensive model change.

It would also do a much better job of shaking out cases where the requirements aren't as clear as you thought when you start trying to code it.

Re: Reality Driven Development: Fixing Project Management in Software

#99

Post by PakG1 »

That was five years ago and I have no plans to pursue my PMP at any point in the future. Because what you learn to get your PMP and what you need to manage software projects are not the same set of skills...and nobody seems to realize it.

That could be said for any kind of project in any industry. I speak as a PMP. The only reason PMP is useful to me is to convince employers that I know how to manage projects. It has nothing to do with reality, and so it is unfortunate that employers view it as a positive signal. It's not an effective filter because you still need to fully assess potential employee candidates in order to avoid false positives.

Re: Reality Driven Development: Fixing Project Management in Software

#100

Post by Swizec »

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?

Based on value.
Post reply on HN