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

Why I'm not a big fan of Scrum

okigiveup.net

Post reply on HN
Print view View original

31–40 of 387 posts

Re: Why I'm not a big fan of Scrum

#31

Post by blub »

awesomerobot wrote: post #20
greyman wrote: post #5

For our dev team Scrum works fine, the key is to use it just as a framework, and not following every rule to the letter. For example: - Obsession with points We don't have that obsession, sometimes we even don't assign story points, just hour estimates - Meeting extravaganza - Again, for example remote people don't need to attend all meetings, sometimes we just clarify the work items outside the meetings. - The sprin…

I'm a designer and my experience with small scrum teams has more or less been the same - a lot of the issues are handled by developers who are given some agency to self-manage and who are half-decent at doing so. I've only worked in one environment that was true scrum, and I don't know if it was the process or the organization — but it felt so overly boxed-in. The last point has been the biggest one for me. Across mu…

One can do this 80%/20% split. Not sure if it's mentioned in some official guide or it developed through trial and error.

Usually the 20% is reserved for bug fixing tasks which can't be estimated and therefore can't be included in the Scrum framework.

One of my projects has a "technical backlog" which is actually just a Jira task with multiple subtasks which gets dragged from sprint to sprint. As you can imagine this doesn't work so great from a process/tool perspective, but it gets the job done (i.e. Major refactorings can be and have been performed).

The thing with Scrum is that a lot depends on the PO and SM. If they're open minded and experienced you can get something decent. If they're dogmatic and pray at the altar of Jira, prepare for suffering.

Re: Why I'm not a big fan of Scrum

#32

Post by UK-AL »

stevesun21 wrote: post #12

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.

Honestly, if you can get away with it Kanban + NoEstimates + Continual Releases.

Scrum becomes useful when you are required to plan(or attempt to) schedules for certain features far in advance.

Re: Why I'm not a big fan of Scrum

#33

Post by camtarn »

Quoting a nice idea from the article: "One way to achieve this might be putting work items through what I would call an algebra of complexity, i.e. an analysis of the sources of complexity in a work item and how they combine to create delays. The team could then study the backlog to locate the compositions that cause the most work and stress, and solve these knots to improve the codebase. The backlog would then resemble a network of equations, instead of a list of items, where solving one equation would simplify the others by replacing unknowns with more precise values."

I've never been on a team that does pure Scrum - even ones which intended to do so always ended up with what we termed "Scrum-ish": taking the ideas from the base methodology, but adding a whole level of 'house rules' aiming to patch up obvious gaps. For instance, always making time for one refactoring or technical debt task per sprint, tracking accuracy of estimated time versus actual time elapsed (deeply uncomfortable but very useful!), the hundreds of different rules around trying to make standups shorter and more useful.

I am a big fan of well-run retrospectives, though: they can be a really nice way to feel empowered as a developer, especially when you have one retrospective identifying that Thing A keeps causing everyone pain, and the next retrospective having everyone say 'Hey, Thing A is so much better now!' Never realized they weren't 'meant' to be about technical matters, though: in our Scrum-ish teams, they were always open for all topics, and I think that's a very good idea.

Of course, the fun thing about Scrum-ish teams is now you have a whole new level of debate that can happen: "We're failing because we're not doing Scrum rigorously enough!" vs "We're failing because we're doing Scrum too rigorously, and what we need is more house rules!" ;)

Re: Why I'm not a big fan of Scrum

#34

Post by camtarn »

dudifordMann wrote: post #30

I agree that there are individuals and companies who have defined such ridged structure and expectation into their Scrum method that they can no longer be considered an agile approach missing two of the key purposes of agile approaches: * Individuals and interactions over processes and tools * Responding to change over following a plan Now, I cannot say that Scum abstractly is a bad approach to attempting to be more…

"the team size is too big" - this is a very good point. Towards the upper limit of the recommended Scrum team size (3-9) they can get really unwieldy. I've been to a standup with an even larger team, which included a couple of design and marketing folks, and it was unbearable. The recommendation's there for a good reason.

Re: Why I'm not a big fan of Scrum

#35

Post by humanrebar »

maxxxxx wrote: post #22
cageface wrote: post #7

I've been doing Scrum-driven development for a few years now after working much more independently for most of my career. I understand why managers like it because it at least lends some structure and predictability to what is an inherently unpredictable enterprise. But the author's criticisms of the incentives of Scrum are on point I think. Because the stories are always articulated in terms of user facing features…

In my view the only way to handle this is to make constant refactoring part of the work without telling management. If you ask for permission for refactoring you will almost always get a "No".

This is mentioned in the article as possible only for small changes. When the refactoring involves more systemic problems, it becomes impossible to make the change in the course of making other client-facing changes.

I'll add that some subsystems are a mess but stable. It's difficult to make refactorings with other changes when there aren't other changes to make. I see this in particular with old but stable subsystems that will need to be ported to new environments someday, but it's never a good day to lay the groundwork for that inevitable change.

Re: Why I'm not a big fan of Scrum

#36

Post by chatwinra »

This talk about agile by one of the founders was posted on Hacker News a while back, it is good, and I think complements this post:

https://news.ycombinator.com/item?id=11548334

To summarise, the issue Dave Thomas has with agile is that it has become a prescriptive framework, 'Agile' (with a capital 'A'), rather than what it originally started out to be, which is a means of being agile (small 'a').

I really liked this talk, and agree with both him and the OP of this thread that some parts of the 'Scrum' as a prescriptive framework may not work for you.

I find it a bit strange that the OP singled out the retrospective as being a negative- for me this is the best part about 'Scrum', as long as you're not too prescriptive about it.

Really the retrospective is a chance to improve yourselves as team each sprint, and it's a chance for people to get stuff off their chests. It shouldn't be just about scrum, it can be anything - adopting new approaches to development eg: TDD, discussing the state of the code, anything. That's what makes them (for me anyway and I think(!) my teams) enjoyable & useful meetings.

Re: Why I'm not a big fan of Scrum

#37

Post by blub »

thefastlane wrote: post #10

do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice. if a software engineer is more than a couple years out of college, i don't think she/he should put up with it either.

These are just games designed to avoid some estimation biases. The problem with biases is that one still can be caught by them even if they're aware that they exist, so such games might have some value.

An alternative would be to explain what the biases are and address them in each estimation round. But who does that really?

We've settled on playing games, which can seem childish at times.

Re: Why I'm not a big fan of Scrum

#39

Post by altcognito »

humanrebar wrote: post #15
cechner wrote: post #2

Scrum proponents (a label I would tentatively apply to myself) would tell you that 'you're doing it wrong' but unfortunately a point-by-point reply to this article would detract from the general problem here: Scrum is intended to be the straightest line towards measuring your real progress on a project, and not much else If youre working on a project where it is important that you have as-accurate-as-is-realistic an…

> Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Scrum is actually part of the problem, IMO. I've seen many teams turn scrum into a hammer and treat all future problems as nails. Example problem: The foobar story has failed failed for the third sprint in a row. Likely discussed in retrospective (plausibly good i…

All of the items you listed under unconsidered should be brought up by the dev team. If the dev team is uncomfortable bringing them up, then that's probably a sign of friction between the dev team and management, which is really common.

Re: Why I'm not a big fan of Scrum

#40

Post by UK-AL »

blub wrote: post #37
thefastlane wrote: post #10

do we see bank analysts playing 'planning poker' when it comes to putting together pitch decks or research analyses? no. and they'd transfer out of any group where a manager tried to implement such a practice. if a software engineer is more than a couple years out of college, i don't think she/he should put up with it either.

These are just games designed to avoid some estimation biases. The problem with biases is that one still can be caught by them even if they're aware that they exist, so such games might have some value. An alternative would be to explain what the biases are and address them in each estimation round. But who does that really? We've settled on playing games, which can seem childish at times.

However most of these biases are slightly recursive.

it always takes 20% longer than expected, even when taking into account it takes 20% longer.

Post reply on HN