Comment by vegetablepotpie | Hacker News Reader

Comment by vegetablepotpie | Hacker News Reader

Parent Full thread

vegetablepotpie

I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value.

The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.

Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.

But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.

One thing that scrum does give is it provides management metrics they can use to measure performance.

"every software project will inevitably have some risky element or difficult to estimate task"

You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.

“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable!

Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.

The criticism of the GP is that teams at his company would estimate story points differently depending on how much stress they wanted to take on and not based on the complexity of the work. This had the impact of the low stress teams not taking on ambitious work. Whereas teams that would take on ambitious work and attaching points to that work were working at unsustainable levels to meet targets.

In your Super Bowl example, you'd either get a team that would focus on doing the scrum activities but never deliver anything useful regardless of how many points it would take, or you'd get a burnt out team that's on the verge of flaming out. In either case "Story points" provide you with no predictive capacity even though predicting would provide value.

The predicting value is only per-team. If your team does 10 points per sprint, it won't deliver 20. If it does 100, it will.

But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.

[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.

If your team is doing mostly similar work and the team has the same composition for a long period, points can have some meaning.

When a team shifts projects, and changes members, there are too many variables and not enough data points, so points become useless.

Since most teams change both of those thing fairly frequently, in the close to 20 years I’ve been doing this, points are generally not helpful.

They don't help you do that, even though poor non-technical managers might think they do. That's why good software projects don't use them. I don't see any story ticket velocity points used in Linux kernel development.

You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.

I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.

> You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.

so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high

Or you don't and end up making a non-functional website for the public sector for $100M. Software projects fail often, and not for the lack of trying, there is not yet any evidence that you can micromanage them into succeeding.

Reply on news.ycombinator.com