Hacker News Reader

Comment by proc0 | Hacker News Reader

If I recall, one of the creators of scrum boiled it down to two elements: a cycle and a reflection on that cycle. All scrum types revolve around that in different ways, and it seems most orgs fail to understand this.

The biggest tool of scrum is having cycles, and then reflecting on the cycle in order to move it in the right direction, but most of the time there are still quarterly planning and bad adherence to the sprint planning (bringing in new work in the middle etc), which defeat the purpose of scrum to begin with. Additionally, scrum should be owned by the contributing team and that almost never happens, as it is controlled top-down by managers and leadership.

View on HN

If you boil scrum down to that then there is no scrum because scrum didn't invent iterative development or retros.

It invented a bureaucratic way to cargo cult them though.

My understanding is that it was always about creating a kind of protocol for engineers to collaborate better. and scrum just packaged those concepts so they could be implemented by anybody. The bureaucracy happens because it's usually not owned by the contributing team and instead orgs like to synchronize all their teams into one unified process, so it inevitably becomes "corporatized".

That's the theory. In practice it became a way to cargo cult those things with bureaucratic rituals.

This was completely the fault of scrum for being highly proscriptive about the process. It's like teaching somebody to program with rote learning or something. It just fundamentally doesn't work because the core of the process requires human ingenuity, creativity and freedom to work and by having a rote process those things are inhibited.

In my experience, the reflection at the end of each cycle is a useful way to make the team feel empowered and in control of their destiny, while all that happens in reality is that they complain to each other once a sprint and the damage is safely contained without bothering management.

Also, what is so bad about quarterly planning? Not everything ships immediately - this shows a very strong web app bias.

Yeah that happens but that same meeting can be used to address that and get the team back on productive conversations. The team needs to align with the goals though and often this is not properly communicated and everyone is pulling in their own direction.

Quarterly planning sets quarter level expectations but each cycle is meant to set bi-monthly expectations for the purpose of changing directions if needed. They are at odds with each other, if you do sprints properly, quarterly planning will almost always change, and if you try to adhere to the quarter estimates then sprints are not needed other than to micromanage that quarterly commitment.

How do you plan anything that needs a longer-term view than two weeks (which is most software development except web apps)?

If doing scrum, you don't do the long term estimating. You have goals but they're not slotted into a timeline, instead they are iterated on sprint by sprint until it's done. You can do projections but even those have to be taken lightly because the point of sprints is to change direction if needed.

Reply on news.ycombinator.com