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

61–70 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#61

Post by encloser »

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 would argue that many people try to commoditize developers through scrum (edit: and call it Agile). Agile is just a set of principles. Which pretty much state the opposite, "Individuals and interactions over processes and tools." As the article states, scrum can work in some cases, but doesn't in others. If you keep trying to force it where it doesn't work, you aren't following the agile principles anymore. (edit: I'm probably making a "no true scotsman" augment and should've said something like "If someone keeps trying to force scrum where it isn't working they should reflect on the principles and ask themselves if they are putting processes first".)

Re: Reality Driven Development: Fixing Project Management in Software

#62

Post by maxxxxx »

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

Yes, this is how Agile should work but rarely gets done from what I have seen.

Re: Reality Driven Development: Fixing Project Management in Software

#63

Post by brightball »

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 I can work in it just as well as my preferred."

In small doses, the proficiency and work environment preferences don't need to bend much (even to share the keyboard a little).

Re: Reality Driven Development: Fixing Project Management in Software

#65

Post by RandallBrown »

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…

Having worked at a company where we did all pairing, all the time, I think it's absolutely "the right way" to do software development. After doing it enough, I think that most people will get over their dislike of it.

But you're right that it isn't for everyone. You kinda need to build your team around it and have your interview process select the kind of people that will enjoy it.

I really like the idea of pairing with someone for two hours after you finish up a ticket. I think that would be a great way to introduce the team I'm currently on to pairing.

Re: Reality Driven Development: Fixing Project Management in Software

#66

Post by devonkim »

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.

The really terrible part is the de-correlation of management quality with rewards for management. Supposedly management is better compensated than individuals due to their impact upon organizations being greater than individual contributors, but this flies in the face of the modern trend of the "subservient manager" philosophy of management as well as management sometimes just carrying out orders from above that don't require skill (the most common one that we all recognize requiring little insight or talent is "reduce costs"). Managers are sometimes given truly terrible situations that nobody can manage their way out (no budget, bad morale, bad organizational reputation of the group, and no authority to create change to reverse the situation)

If you have a poor individual contributor, they are almost always fired. If you have a poor manager, oftentimes they have worked a relationship with someone that has power that makes it very difficult to fire them, so they're oftentimes "promoted." This kind of nepotism and cronyism exists to some extent among individual contributors but ICs usually disperse more across business verticals throughout their careers while managers and others in primarily soft skill roles tend to be extremely connected (whether through intrinsic personality or due to the nature of their jobs is another question) and seem to act more as cohorts rather than as individuals.

Re: Reality Driven Development: Fixing Project Management in Software

#67

Post by dgreensp »

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.

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 give you any sense of.

Re: Reality Driven Development: Fixing Project Management in Software

#69

Post by IshKebab »

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.

That's a really good way of putting it.

Re: Reality Driven Development: Fixing Project Management in Software

#70

Post by Karrot_Kream »

devonkim wrote: post #66
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.

The really terrible part is the de-correlation of management quality with rewards for management. Supposedly management is better compensated than individuals due to their impact upon organizations being greater than individual contributors, but this flies in the face of the modern trend of the "subservient manager" philosophy of management as well as management sometimes just carrying out orders from above that don'…

I think that really is the rub. Manager performance is hard to measure, and most organizations don't really want to measure management performance because it's costly and easier to cycle through ICs, especially where there is an abundance of IC supply. I worked for a bad manager that caused over 60% of the team to leave (including me), and finally a year later they were "demoted" by being put in charge of a smaller, less-significant team. An IC that dropped 60% of their deliverables would have been on the chopping block in weeks, if not months.
Post reply on HN