Hacker News Reader

Comment by frossie | Hacker News Reader

Okay, interesting post that left me with a "Well, yes and no" response.

The accusation is, that the "scrum master/coach" role in agile has gone from being an in-team activity to being a project management activity. I do think that is true. I also agree that Agile has become a buzzword that companies are adopting without truly understanding it (in the vein of http://www.halfarsedagilemanifesto.org/ )

But the reason Agile won't be killed is the same reason Waterfall hasn't been killed: it's the optimal choice in some scenarios.

(And before you sneer at Waterfall, go build me a nuclear power station with Agile).

View on HN

I think the biggest problem is the naming. When I heard the title Scrum Master, I envisaged someone that was a master, someone with training - and yes, someone who runs the project. I recently read Succeeding with Agile by Mike Cohn and now understand it's just a role title - it's the person tasked with making sure scrum practices are used - regardless of how much scrum experience that person has - and is distinct from the project manager role. It really needs to be renamed - it's like a bad variable name.

"(And before you sneer at Waterfall, go build me a nuclear power station with Agile)"

Or a sudoku solver.

Meh? I build a suduko solver one night on my own in 2-3 hours. I've seen agile do much more than that. What are you trying to say?

I think it's referring to the sudoku TDD blog series that happened a few years back. Essentially, someone tried to implement a sudoku solver using TDD - and after several posts, never managed to finish. Peter Norvig then came along and wrote a short elegant implementation.

Some use this to say TDD - which has ties to agile - doesn't work. But most people conclude that TDD isn't a silver bullet and you have to know about your problem domain before diving in.

Here's someone elses' blog post which includes links to both sets of posts: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s...

Ok, that at least makes sense. But ... sudoku is a puzzle - you don't (or at least I didn't) get there by iteration and testing, you get there by a flash of insight - "if I try searching like this, I might be able to end up with a solution to any sudoku board" and few hours later I knew I was right. In that way, it is unlike almost all large-scale software development.

Agile can't generate insight from nothing, it's not a silver bullet. But at least if you have some unit tests around your cool new code, you know that you won't accidentally break it later.

> (And before you sneer at Waterfall, go build me a nuclear power station with Agile).

Wasn't the point of Royce's paper that waterfall wasn't even suited to avionics?

That's a good test for people who talk about software development and project management: ask for a summary of Royce's conclusion.

I also like to ask about the specific (and testable!) assertion Brooks made in his most famous essay.

Anyone who can answer those questions well demonstrates a working understanding of project management.

And before you sneer at Waterfall, go build me a nuclear power station with Agile

That would be interesting. Scrum says that your team should get themselves an appropriate set of tools and processes for the task at hand, and iterate, then inspect and adapt.

For a mission-critical lives-on-the-line software system, I'd imagine that there would be a lot of simulation and testing before the production release. Do you see a problem with that?

Reply on news.ycombinator.com