Reality Driven Development: Fixing Project Management in Software • Hacker News Board

Re: Reality Driven Development: Fixing Project Management in Software

#51

Post by icebraining » Fri, May 25, 2018, 6:53 PM UTC

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…

Agile methodologies are weird. They seem to go directly against the manifesto, particularly "Individuals and interactions over processes and tools"[1]. Yet Scrum was created by two of the manifesto signatories.

Still, a lack of a strict methodology doesn't necessarily make it waterfall.

[1] http://agilemanifesto.org/

Re: Reality Driven Development: Fixing Project Management in Software

#52

Post by maxxxxx » Fri, May 25, 2018, 6:56 PM UTC

Benjammer wrote: post #36

maxxxxx wrote: post #29

Earlier quoted context omitted.

For stuff that's new I always tell management to give us a certain amount of time (weeks or even months) to figure out the major unknowns. After that has been done they can get a reasonable estimate or cancel, whatever they want to do. This seems to be the only realistic way to go about things.

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.

In my company everybody goes over spec sheets and endless meetings to determine the right approach instead of just sitting down and using the time to try things out. A big problem is that there is also no culture of being allowed to say that an experiment has failed and we'll either cancel or try something else.

Re: Reality Driven Development: Fixing Project Management in Software

#53

Post by pentagonpapers » Fri, May 25, 2018, 6:58 PM UTC

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.

I think waterfall can, by having serious scoping discussions.

Re: Reality Driven Development: Fixing Project Management in Software

#54

Post by brightball » Fri, May 25, 2018, 7:07 PM UTC

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’ve seen waterfall work at a VERY high level where entire projects were the tasks.

Within those projects, waterfall was completely removed from the numerous tasks needed to get the project done so the developers never saw it.

Getting waterfall involved at the project level tasks day today has a lot of issues though. It can run a lot smoother if your team has a low expectation of pivoting due to new projects or production support needs.

It’s not without possibilities, but a lot depends on how far removed it is from day to day.

Re: Reality Driven Development: Fixing Project Management in Software

#55

Post by wpietri » Fri, May 25, 2018, 7:09 PM UTC

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 as they're working together. Even as little as adding a second keyboard and mouse can make a big difference. People are just more engaged if they're participating.

Re: Reality Driven Development: Fixing Project Management in Software

#56

Post by wpietri » Fri, May 25, 2018, 7:12 PM UTC

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.

Re: Reality Driven Development: Fixing Project Management in Software

#57

Post by overgard » Fri, May 25, 2018, 7:14 PM UTC

browningstreet wrote: post #42

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…

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 bothers me because it generally aims to commoditize developers, and yet the best places and teams I've worked on always were they opposite: it was about finding the best way for each individual to work, and designing processes around the rhythms around whatever industry they were working in, rather than assuming everything should fit into 2 week sprints.

Re: Reality Driven Development: Fixing Project Management in Software

#58

Post by alasdair_ » Fri, May 25, 2018, 7:26 PM UTC

Benjammer wrote: post #36

maxxxxx wrote: post #29

Earlier quoted context omitted.

For stuff that's new I always tell management to give us a certain amount of time (weeks or even months) to figure out the major unknowns. After that has been done they can get a reasonable estimate or cancel, whatever they want to do. This seems to be the only realistic way to go about things.

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

Re: Reality Driven Development: Fixing Project Management in Software

#59

Post by brightball » Fri, May 25, 2018, 7:26 PM UTC

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…

In the environment that you describe, I imagine if there was a problem with the methodology both parties would be receptive and adapt.

Re: Reality Driven Development: Fixing Project Management in Software

#60

Post by ebiester » Fri, May 25, 2018, 7:26 PM UTC

icebraining wrote: post #51

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…

Agile methodologies are weird. They seem to go directly against the manifesto, particularly "Individuals and interactions over processes and tools"[1]. Yet Scrum was created by two of the manifesto signatories. Still, a lack of a strict methodology doesn't necessarily make it waterfall. [1] http://agilemanifesto.org/

SCRUM predates agile. Though SCRUM has had many changes over the years, the manifesto was responding to problems of the day; that is, a giant statement of work up front, hundreds of pages of design documents, a giant build process where everyone figures out what the product really should do in engineering while product forgets about it except for occasional questions.

Then, that whole steaming pile was thrown over the fence to QA which tried to figure out heads from tails and developers started fixing the issues they already knew about but had to leave in so that they would make their deadline.

THEN came user acceptance testing, where people actually looked at the product at the first time. This is when people realized what the miscommunications 6-12 months ago, and the change request process started.

Finally, over budget and after everyone was finally exhausted and tired of fighting, it was released to users with promises of changes after the release.

From this world, SCRUM and the manifesto makes sense.