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

131–140 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#131

Post by vannevar »

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 agree about the hostility to waterfall. Waterfall put men on the moon, so it can't be such a terrible thing. I don't think there is a conflict, personally---there's no reason that you can't plan sprints in the context of an overall waterfall schedule. In the real world, there are deadlines, and any process, no matter how agile, has to recognize that fact and work within schedule constraints. I think that what agile buys you is the opportunity for near-continuous integration and feedback, so that you know fairly early when you are either going to have to apply more resources, trim functionality, or extend deadlines. Properly applied, agile is better than traditional waterfall at flushing out unknowns and potential architecture issues, because of the focus on working, tested, demonstrable code from the beginning.

Re: Reality Driven Development: Fixing Project Management in Software

#132

Post by hinkley »

giulianob wrote: post #4
brightball wrote: post #2

Author here if anybody has any questions.

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…

“Bitesized” is the only estimate that matters.

Re: Reality Driven Development: Fixing Project Management in Software

#133

Post by eagsalazar2 »

flud wrote: post #129
eagsalazar2 wrote: post #41

Earlier quoted context omitted.

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?

Plumbing is basic project setup, CI, testing, etc but also all core functionality and any technically questionable bits like integrations with client APIs that are frequently not what is advertised. Research is always conducted by one of our "CTO"s (partners who have > 10yrs experience).

Projects vary at the low end from 2 people, 2 months up to 5-7 people for a year or longer. We do smaller stuff like prototypes also, usually as a first step in a longer series of releases. We are local in SF and frequently work in client offices. Budgets are between $100K - $1M.

Re: Reality Driven Development: Fixing Project Management in Software

#134

Post by solatic »

tigershark wrote: post #123
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.

If you want to split the duties of a tech lead and a PM, say because multiple tech leads are required for a large project, managed by a single PM, then the PM still needs to juggle various customer requests and split them into team-sized requirements for the tech lead to split into developer-sized tasks. That you've introduced a higher level of project abstraction over multiple teams does not change the fundamentals - PMs being intimately familiar with the output of individual teams to identify strengths and weaknesses, ensuring that teams are adequately staffed and qualified, monitoring the backlogs of teams so that the PM does not commit to work which the teams do not have the capacity to achieve.

Re: Reality Driven Development: Fixing Project Management in Software

#135

Post by AlexCoventry »

AlexCoventry wrote: post #95
dgreensp wrote: post #67

Earlier quoted context omitted.

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.

^serious^said

Re: Reality Driven Development: Fixing Project Management in Software

#136

Post by dangoor »

tboyd47 wrote: post #49
brightball wrote: post #2

Author here if anybody has any questions.

Hey! Loved the article. I am currently employed as a scrum master in a scrum environment. About your proposed "fix" to management: even with the light pairing you recommend, wouldn't kanban eventually cause siloing? Even using scrum at my job, we have individuals becoming the "Feature X" guy or the "Feature Y" guy. This person then essentially disappears into a hole perfecting that one feature for weeks/months, even…

When using kanban, people take the first card from the top of the pile and work on that. There's no siloing in that, because you're taking whatever happens to be at the top.

You don't estimate in kanban. You'll generally try to break things down into small stories, but the goal is to always be working on the most important thing and focus on improving how quickly work goes from idea to done.

Re: Reality Driven Development: Fixing Project Management in Software

#137

Post by raarts »

regularfry wrote: post #116
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?

In theory, it ought to be "we can't tell you how many increments there will be because you'll have working software in your hands every two weeks, and we don't know enough now to say when you'll ask us to stop. It should be clear whether we are on track after the first 2 or 3, but you can pull out at any time after the first with a usable product." The whole premise is to get the client to buy into a subscription, ra…

Not easy for clients to pick a supplier this way.

Re: Reality Driven Development: Fixing Project Management in Software

#138

Post by regularfry »

raarts wrote: post #137
regularfry wrote: post #116

Earlier quoted context omitted.

In theory, it ought to be "we can't tell you how many increments there will be because you'll have working software in your hands every two weeks, and we don't know enough now to say when you'll ask us to stop. It should be clear whether we are on track after the first 2 or 3, but you can pull out at any time after the first with a usable product." The whole premise is to get the client to buy into a subscription, ra…

Not easy for clients to pick a supplier this way.

Makes it easy to pick clients, though.

Re: Reality Driven Development: Fixing Project Management in Software

#139

Post by nightski »

BoiledCabbage wrote: post #103
Swizec wrote: post #100

Earlier quoted context omitted.

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.

Any client worth working for is going to have an annual budget and the focus won't be so much on how much things cost but rather how soon you can start delivering business value.

Re: Reality Driven Development: Fixing Project Management in Software

#140

Post by TheCoelacanth »

gaius wrote: post #109
alasdair_ wrote: post #58

Earlier quoted context omitted.

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

I couldn't disagree with this statement more.

On projects that are breaking new ground it is even more important to follow XP practices like getting frequent feedback from customers, taking the simplest solution that could possibly work to avoid overengineering before you actually understand the problem, to embrace change because your original understanding of the problem probably isn't right.

There also is plenty of risk involved in cookie-cutter commodity work. Those kinds of projects fail all the time.

Post reply on HN