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

111–120 of 147 posts

Re: Reality Driven Development: Fixing Project Management in Software

#111

Post by zhdc1 »

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…

Yes. Yes. Yes.

Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to.

For instance, engineers planning a drainage project have a very good idea of how long a particular type of pipe will last before it needs to be replaced. They also have the tools/software/training needed to estimate how local stresses affect functionality and lifespan, and they're expected to use this information - even if the lifespan of the project exceeds their expected tenure.

IT PMs can't say the same thing about their infrastructure - who knows how long AWS or Azure will be around, for instance, or how long a local server blade or piece of network equipment from (x) company will actually last. When it comes to software development, the prevailing attitude is 'I want (x) by (y) for (z)', without having any justifiable basis for (x), (y), or (z).

Re: Reality Driven Development: Fixing Project Management in Software

#112

Post by duncan_bayne »

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.

People had been using other - and better - mechanisms than Slack for this purpose for decades.

Re: Reality Driven Development: Fixing Project Management in Software

#113

Post by DanielBMarkham »

ironjunkie wrote: post #106
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.

I prefer the U.S. Marines fire team version of a tech team: everybody codes, everybody looks out after everybody, you should be able to do your "boss's" job, it's critical to over-communicate, and ego has no place in a good team. Having said that, sometimes somebody has to make decisions. And somebody always has to go to meetings and report upstairs. Poor schmuck.

Re: Reality Driven Development: Fixing Project Management in Software

#114

Post by kitd »

zhdc1 wrote: post #111
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…

Yes. Yes. Yes. Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to. For in…

I think this is why it is very helpful to use tried and tested tools and tech stacks in an IT project, those with large ecosystems of libraries and communities of people who have solved similar problems in the real world in the past.

The "problem solving" risk is much lower as a result.

Re: Reality Driven Development: Fixing Project Management in Software

#115

Post by erikb »

What a ride. I really disagree with almost everything that's written there. So many things are even factually wrong, or with such a limited perspective that they are very likely missing the point. For instance, what he describes is not project management (limited timeframe, specific end result) but constant, ongoing product development. He describes a development management job (might also be called team lead), not a PM job.

His conclusion seems right to me, though. Team management doesn't need fancy processes. The overview of activity and backlog needs to be there and the manager has the responsibility to enable syncing between activities and to the outside world.

If one calms down after that conclusion, one realizes that managing a single team of developers is trivial. Maybe that's why people are not talking about it so much (in contrast to "nobody gets it")?

The art is in reprioritizing existing tasks when new ones come in (because usually something needs to get dropped), and additionally there's art in handling the meta level when single processors of a team are not just people but subteams.

Re: Reality Driven Development: Fixing Project Management in Software

#116

Post by regularfry »

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?

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, rather than a single deliverable.

Re: Reality Driven Development: Fixing Project Management in Software

#117

Post by erikb »

kitd wrote: post #114
zhdc1 wrote: post #111

Earlier quoted context omitted.

Yes. Yes. Yes. Technical discovery is baked into traditional project management (e.g., civil engineering) in a way that continues to surprised me as a former IT project manager. There is a culture of investigation and research, such as materials research, proof of concept development, and needs-driven public-private academic research in other technical fields that IT project managers just don't get exposed to. For in…

I think this is why it is very helpful to use tried and tested tools and tech stacks in an IT project, those with large ecosystems of libraries and communities of people who have solved similar problems in the real world in the past. The "problem solving" risk is much lower as a result.

At the same time the board will finance the fancy new buzz words though. So combining both requirements I would say the art is in trying to use tried and tested technology to fulfill buzzwords.

Re: Reality Driven Development: Fixing Project Management in Software

#118

Post by erikb »

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'd say the direction you are going is correct. And I would add that the big payoff is in understanding of fundamental problems, not libraries or algos. For instance you should know how TCP/IP works and HTTP works (not just theoretical but hands on, i.e. know when to use curl, when the browser and when tcpdump for debugging). But you don't need indepth knowledge of the currently hip web framework because in 5 years it won't be hip anymore.

Re: Reality Driven Development: Fixing Project Management in Software

#119

Post by erikb »

andrewstellman wrote: post #102

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, "Learni…

Kanban is not a method. Kanban is a way to structure tasks and activities.

Re: Reality Driven Development: Fixing Project Management in Software

#120

Post by erikb »

brightball wrote: post #2

Author here if anybody has any questions.

Please don't put out assumptions like "PM = Psychology + Economics" without an indepth argument about it. I completely disagree with such statements and without arguments I can't even attempt to see it your way.
Post reply on HN