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

Re: Reality Driven Development: Fixing Project Management in Software

#71

Post by cabalspecter » Fri, May 25, 2018, 9:24 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 believe the efficiency got "worse" because it revealed the harsh truth earlier which the Gantt chart hides... until the very end.

Re: Reality Driven Development: Fixing Project Management in Software

#72

Post by tonyarkles » Fri, May 25, 2018, 9:42 PM UTC

brightball wrote: post #8

jrs235 wrote: post #3

Earlier quoted context omitted.

Have you read "The Principles of Product Development Flow: Second Generation Lean Product Development" by Donald G. Reinertsen?

I have not but I just ordered it. From the description, it looks like we're on the same page.

Just another thumbs-up on this one. Fantastic!

Re: Reality Driven Development: Fixing Project Management in Software

#73

Post by bluesnowmonkey » Fri, May 25, 2018, 9:42 PM UTC

Oh, there was a silver bullet after all. Turns out Kanban and 2 hours of pair programming per week is the Right Software Development Methodology.

Re: Reality Driven Development: Fixing Project Management in Software

#74

Post by WJW » Fri, May 25, 2018, 9:46 PM UTC

monkeynotes wrote: post #11

brightball wrote: post #2

Author here if anybody has any questions.

With paired programming I have always felt comfortable sharing a Googling of the problem with either the co-driver or the driver, depending which role I am in. Can you explain what you perceive to be the problem with accessing something like StackOverflow to help solve a persistent problem or even to simply jog one's memory? I find that this fear of being shamed for using the obvious resources at our fingertips to be…

I can imagine that this is really tied to the confidence you already have. If you feel that you are a capable programmer then looking up something on Stack Overflow is just looking up something you kinda know but forgot. No big deal.

For someone in the grip of impostor syndrome, it is admitting that you are indeed just faking it and don't know enough to 'deserve' your position.

Now it is probably not true, but that does not matter for how people react to it...

Re: Reality Driven Development: Fixing Project Management in Software

#75

Post by TulliusCicero » Fri, May 25, 2018, 9:50 PM UTC

> The moment that story estimating becomes time estimating...stop. That's not what it is there for and you're not trying to assign out every minute for a person.

I don't see the distinction here. The whole reason you're estimating things is to guess at how long they'll take. If the story points do not translate to time, what use are they?

Re: Reality Driven Development: Fixing Project Management in Software

#76

Post by mlthoughts2018 » Fri, May 25, 2018, 9:53 PM UTC

TulliusCicero wrote: post #75

> The moment that story estimating becomes time estimating...stop. That's not what it is there for and you're not trying to assign out every minute for a person. I don't see the distinction here. The whole reason you're estimating things is to guess at how long they'll take. If the story points do not translate to time, what use are they?

The other thing is that time estimating has to inherently consider which specific personnel work on something, but often this is taboo.

Re: Reality Driven Development: Fixing Project Management in Software

#77

Post by radley » Fri, May 25, 2018, 10:04 PM UTC

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.

Re: Reality Driven Development: Fixing Project Management in Software

#78

Post by dboreham » Fri, May 25, 2018, 10:25 PM UTC

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.

Group chat applications didn't exist before Slack of course.

Re: Reality Driven Development: Fixing Project Management in Software

#79

Post by PeterFBell » Fri, May 25, 2018, 10:28 PM UTC

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 overlap.

Slack is great, but it doesn't completely replace the ability to see and talk to people once in a while!

Re: Reality Driven Development: Fixing Project Management in Software

#80

Post by mikekchar » Fri, May 25, 2018, 10:43 PM UTC

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.

Not take focus away from that good idea (and it is a good idea), the biggest flaw in "Agile" is that people think that stand-ups are for reporting work progress/status. A stand-up is for getting clarification on what you are doing, arranging to get help, clearing up misconceptions between people, ensuring that the interfaces for different stories are meshing (and people aren't going off in wildly different directions), etc. This is why you have scrum master running the stand-up and not a manager. This is why you especially do not have a project manager running the stand-up! It is a technical meeting.

Status should be communicated through artefacts. For example, if the software has shipped, then the story is done. If you are doing a spike, when the new stories have been written as a result of the spike, then the spike is done. The only time you should need more status than that is when there has been a problem and your story got set back. In that case the scrum master should just tell it to the (project) manager -- it's a 30 second conversation and does not require the presence of your entire development team.

In the (very likely) case that your (project) management is not happy with the frequency of status reports (because it takes to long to finish something), then you need smaller stories. Getting your story size down to the size where you can complete about 1 per day will go a long way towards making your management happy. Of course the downside is that you have to be organised -- which, very ironically, most (project) managers really hate. They'd rather have stories that say "Deliver the product" with no other details and go back to their meeting (where they will undoubtedly discover new extremes of productivity, finding endless stacks of 3 word stories).