Comment by vannevar | Hacker News Reader

Comment by vannevar | Hacker News Reader

FTA: Scrum forces iterations, forces feedback, forces smaller iterations. These are all good things, which I loved about Scrum.

And yet the author spends most of the article denying that these aspects of scrum are useful at all. Planning sessions are "highly inefficient," a "quick meeting between the architect and the developer" is better. What if someone else has an important piece of information that the dev and the architect don't? Maybe another dev on the team has done something similar in the past, and could have warned that the estimate was low? He won't be in that meeting, to avoid being "bored to tears" with a story he isn't working on.

So how do you know if Scrum isn’t right for you? If it’s hard. If it’s easy, then it will work for you.

Obviously, if something is hard, there can't be any possible benefit to it. It's so much easier to get rid of all that process stuff and just churn out code as fast as you can. What could possibly go wrong?

The author has a point. Scrum is costly. Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.

At least it is in the beginning. People leave, experts become expert teams, silos widen and it soon become the good old planning nightmare we have all learned to "love" in enterprise development.

The author has a point. Scrum is costly.

I would prefer Scrum can be costly... it will also remain costly if people don't actually do the inspect and adapt bits of scrum and aim to improve the process.

I say this as somebody who is actually not a huge fan of Scrum :-)

Obviously it is more productive to silo specific knowledge to specific people, generally the expert (or more motivated) in that field.

Actually - I often find that isn't true. If you silo knowledge then those people become bottlenecks in the process. Since their the only people everything has to flow through them that relates to that topic.

For example I find that teams improve if the "UX Expert" switches from being the person who does all of the UX work, to being the person who facilitates UX work among the whole team.

That way the easy stuff gets done by the whole team, and the UX person is freed up to focus on the tricky stuff and stops being a bottleneck for general progress on the UX front.

> What if someone else has an important piece of information that the dev and the architect don't?

That isn't good enough justification. You are too much erring on the side of caution.

But it's not costing me much. My devs still need to be in on planning their own work, and if they're all on the same scrum there should be a lot of overlap. Listening in on the planning for work entirely unrelated to their own should be pretty rare.

Reply on news.ycombinator.com