Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

mdalmijn.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#51

Post by proc0 »

dsalfdslfdsa wrote: post #50
proc0 wrote: post #13

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 s…

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.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#52

Post by proc0 »

pydry wrote: post #28
proc0 wrote: post #13

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 s…

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

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#53

Post by cbsmith »

torginus wrote: post #21

Imo the fundamental failure of Scrum as a planning methodology stems from the fact that it gives user requirements ('user stories') to developers and expects them to translate them to a technical implementation almost as an afterthought that's barely acknowledged in the framework. Most of us work on huge codebases with tons of baggage and hundreds or thousands of engineer-years invested into it. Implementing a featur…

> Figuring out how to do the feature is usually part of the 'planning' and 'grooming' activities which are 'invisible work' with timeboxed team meeting slots allocated to it, even though a well-thought out implementation can save tons of time.

Those time-boxed meetings aren't where you come up with the well-thought out implementation plan. They're where the work is prioritized, the well-thought out implementation plan is communicated with the team, and the work size is estimated.

> Just plunging in and doing it means that a large uncertainty exists as to how much effort said feature wil take. This can either lead to time overruns or padded estimates (or both)

At the start of a project where you're going something different from what you have done before (and with software, if you're not doing something different... why aren't you just using the software you've already written to do the job? ;-), and needs/circumstances change faster than you can complete projects anyway, so unless you can predict those changes (in which case, you have the wrong job ;-), even if the task was without any novelty, there is intrinsically a lot of uncertainty.

Recognizing that the uncertainty is intrinsic, the agile approach to manage it is to break down the work into lots of smaller chunks with well defined checkpoints. This allows for many opportunities for course corrections in response to changing needs/circumstances and/or learnings about the size of the work. It's basically just a standard pid controller dealing with a noisy system.

You're right though: another approach is to spend a great deal more time up front making a detailed estimate of the work... although that doesn't control for uncertainty about changing needs/circumstances, which will often change during the time you make your detailed estimate. ;-) There's also the matter then of estimating how much time it will take to estimate the work... since until that part is complete you would have increasing uncertainty. Now you can estimate how much effort the estimate will take to complete. That's a smaller task that will take less time to complete, so there's less uncertainty about changing needs/circumstances while you're coming up with an estimate of effort for the estimate. Also, if you estimate how much effort it will take for you to estimate the effort to make the estimate. Once you observe how far off the mark you are estimating how much effort it will take for you to estimate the effort to make the estimate, you'll have more information to calibrate your estimates with, so you can use that to have a more accurate estimate of the effort to make the estimate...

Yup, it kind of ends up as the same thing.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#54

Post by mytailorisrich »

torginus wrote: post #21

Imo the fundamental failure of Scrum as a planning methodology stems from the fact that it gives user requirements ('user stories') to developers and expects them to translate them to a technical implementation almost as an afterthought that's barely acknowledged in the framework. Most of us work on huge codebases with tons of baggage and hundreds or thousands of engineer-years invested into it. Implementing a featur…

> Scrum has no proper way of handling these activities.

That's not true.

A high-level user story will indeed require investigation, architecting, perhaps experimentation. So create tasks for each step and add them to the backlog!

The 'planning' part in Scrum is mostly planning the sprint, i.e. what the team is going to work on during the next incremental period based on the tasks in the backlog. This is very different from thinking about how designing a feature, which is an activity that should be treated as a task.

Working in short "sprints" also helps in the investigation and architecting phases, because the format is aimed at forcing small, incremental progress when a potential common pitfall of investigation and architecting is spending a lot of time dreaming up something and writing extensive documentation, which will end up being useless or performing poorly in the real world [1]. But you can use "sprints" along perhaps modeling tools to split this into shorter architecting-experimentation-refining cyles.

Again, the common issue here is the superficial, literal reading of Scrum without thinking of the deeper point, which is what matters.

[1] Remember the Agile Manifesto's point about "working software over comprehensive documentation" because of that.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#55

Post by dsalfdslfdsa »

proc0 wrote: post #51
dsalfdslfdsa wrote: post #50

Earlier quoted context omitted.

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 ar…

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

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#56

Post by mythhabit »

mytailorisrich wrote: post #19

This feels like a rant that does not make any substantive points and ends up looking like an example of what it sets out to criticise. > Sprints seem to put people on the wrong foot as if we should rush to complete everything in the Sprint... This is arguing about semantics. If you don't like the term, use another one or explain it better to your team. The important thing is to understand the point, which is to have…

I agree. And it's worth remembering that Scrum is a starting point. The entire point is to adapt the process such that it fits the team/product/organisation, through retrospectives.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#57

Post by proc0 »

dsalfdslfdsa wrote: post #55
proc0 wrote: post #51

Earlier quoted context omitted.

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 ar…

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.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#58

Post by torginus »

Scarblac wrote: post #42

At its best, Scrum can be a tool to limit manager micromanagement (only at the level of a whole sprint), while also empowering the team to work the way it considers most effective because everything Scrum suggests as defaults (like what meetings to have and what their goal is) can be changed by the dev team. In practice management doesn't give a iota about what Scrum says their role is and everything becomes discussi…

In my experience Scrum is the worst enabler for micromanagers

- PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it

- PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted

- You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'

This leads to demoralized devs working on crap codebases they're not allowed to fix.

Re: Scrum's Built-In 'Get Out of Jail Free Card' Against Criticism

#59

Post by mytailorisrich »

torginus wrote: post #58
Scarblac wrote: post #42

At its best, Scrum can be a tool to limit manager micromanagement (only at the level of a whole sprint), while also empowering the team to work the way it considers most effective because everything Scrum suggests as defaults (like what meetings to have and what their goal is) can be changed by the dev team. In practice management doesn't give a iota about what Scrum says their role is and everything becomes discussi…

In my experience Scrum is the worst enabler for micromanagers - PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it - PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted - You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bot…

> - PO suddenly wants to do something yesterday - they just give their task top priority so you're forced to do it

That's fine. It's their role to prioritise features. BUT within the framework this should apply to the planning for the next sprint as the point is not to interrupt the current sprint unless there is an overwhelming reason.

> PO want the button to have that exact shade of teal - they won't accept the story until it looks exactly like what they wanted

Nothing wrong with that. It comes down to explicit and clear feature specification.

> You want to clean up the messy code you're touching - just make a story for it and watch the PO rank it to the bottom (essentially meaning it'll never get fixed) - since it has no 'business value'

This situation applies whatever the framework you're using. You need to sell what you want to do by explaining the value, or you do it step by step under the radar. There should also be someone with clear authority over the codebase who can make these decisions and sell them/negotiate with project management. Again this is not Scrum, but software development in general...

Post reply on HN