Why I'm not a big fan of Scrum • Hacker News Board

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

#131

Post by dalai » Mon, Aug 08, 2016, 1:21 PM UTC

bbcbasic wrote: post #8

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…

Sounds like you are doing "scrum but" aka your own methodology. However their article is criticizing pure unadulterated scrum.

The article is also criticizing their particular version of scrum. For example "collecting points" or obsessing about them is not unadulterated scrum; the word points or planning poker are not even mentioned in the scrum guide. Any good developer, scrum master or book on scrum will tell you that story points are not a performance metric and they are only to be used by the PO and just for planning ahead.

There is little to criticise about pure unadulterated Scrum because there is surprisingly little prescribed and what little there is they openly tell you that you can change it in the retrospective. The real problem is that management, agile coaches (and unfortunately sometimes also some developers) often want to religiously apply every little thing they ever read in a book and seemed like a good idea. I think that solutions to all the problems the author mentioned are possible without deviating significantly or at all from scrum -- should that be important for whatever reason. The only prerequisite is that everyone involved is open to change.

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

#132

Post by uklenny » Mon, Aug 08, 2016, 1:22 PM UTC

draz wrote: post #106

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…

I am Product in a large corporation, and it's a certainly a fine balance. In a previous life, I was a developer, and I dealt with similar issues. I have a lot of respect and empathy for the the Tech team. Therefore, I asked my Tech team to inform me when things are getting out of hand -- that's the responsible Product thing to do . I instituted that technical debt is part of our KPIs. If it's not captured, it's not a…

The problem with raising issues with a framework like Scrum is that despite many share references, most people are in environments which apply Scrum in a slightly different way.

We talk about organisations applying Scrum but what we're really referring to are groups of people, and depending on those people, their mindset, their history and their current role requirements - they will use the Scrum model in their own idiosyncractic way.

Take the point about technical debt and running so fast with an Agile development workflow that you never get to refactor code or properly document etc.

Even if you just took that in reference to one specific company, the value of, cost of, and importance of these things could be different at different times.

When a startup is running to get MVP out to get customer feedback, it's usually much more efficient to set the basic expectation that the first version of your product will get thrown away once you've learned all the important aspects of what you need to deliver. With that in mind - startup development is a completely different beast than when your product is established and you have paying customers with expectations of up-to-date documentation etc.

Some managers are do not have good people skills and manage by just holding developers to account based on the expectations set in their Scrum planning day. Discussions about whether refactoring should be done yet or not may not even be something they want to know/talk about and they rely on engineers to factor that into their sprint estimates.

Depending on whether the company is being driven by sales/demo opportunities, or feature roll-out timescales etc. then the call about whether to do something 'quick' or 'right' may drop either way.

For developers it's important to understand the dynamics that are driving the business and what their role is (sometimes you have to 'JFDI'). If you have a good engineering team with a strong leader then these things shouldn't be that visible to anyone else. It's also important to be able to meet the expectations you set. If you keep delivering late then you'll also struggle to get people to let you do more than the minimum required at the time.

For the business as a whole it's all about the big picture and understanding the decisions you make and what their impact (short and medium term) is.

If you want quick releases and don't have the resources for that to allow for good documentation and/or scalable code, then you need to understand that technical debt is building up and at some point it will need to be paid.

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

#133

Post by daemin » Mon, Aug 08, 2016, 1:22 PM UTC

crdoconnor wrote: post #63

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…

One amendment I always wanted to make was to have a "technical debt dial". You could stick it on the wall next to the scrum board. The debt dial should be from 0% (spend all the time refactoring) to 100% (spend zero time refactoring, get it out at all costs). Management should have complete control over the dial. Developers should have control over what kind of refactoring they do (ideally the retro should have a que…

One question I have is how does one actually objectively measure technical debt? I mean by anything more than a guess or intuition. Does every singleton/global variable count? Does every comment with a HACK count? What other factors contribute to technical debt, and by how much?

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

#134

Post by shadowmint » Mon, Aug 08, 2016, 1:23 PM UTC

camtarn wrote: post #33

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

I'm skeptical about retrospectives.

We've certainly done them, identified problem points and then solved them (and it does feel good to do that..) but it doesn't actually seem to make things better.

Lets compare it to say, personal estimations:

When you estimate, execute and reflect, you can tangibly improve your estimation process.

You can quantitatively observe an improvement in estimations on tasks when people go through this process.

Previously; estimated 20 hours for (task). Took 10 hours. Repeat... soon, your estimates are for 10 hours, and you're quantitatively, objectively able to make consistently better estimates.

Retrospectives in my experience don't do that.

You can sit through 50 retrospectives and each one identify a problem area and then fix it and yes that does feel good, but objectively when I reflect over the defect rate as a result of the process, I feel like retrospectives make zero impact on the rate at which technical debt accumulates.

There's something missing in the way they work; all you (well, all we, I suppose, this being my personal experience...) ever do is find things that are wrong and fix them. Objectively when you look at it, there's no closing of the loop where the defect rate drops.

There's no process improvement that generates less problems in the future... all it ever is is band-aiding to prevent technical debt spiraling totally out of control and devastating the project.

There must be a better way, where you somehow measure how technical debt was created and work to incrementally prevent it happening... but I've never seen that actually happen in practice.

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

#135

Post by cechner » Mon, Aug 08, 2016, 1:24 PM UTC

specialist wrote: post #126

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 intended to be the straightest line towards measuring your real progress on a project, and not much else." More like wandering in the desert, hoping you find the promised land. Been thru scrum master training 3 times, been on many "agile" teams. I've never heard this rationalization. Rather, a common justification for "agile" was you always have a working product. Which might be nice if things worked out th…

If you're objecting to people who treat scrum (or any project management tool) as a one-stop-shop that will cure all ills I agree with you, but nobody here is saying that.

If you are objecting to defining the scope as small tasks and measuring your progress through that over time, then continually re-evaluating this scope as requirements change, then I think you are not working in an environment that would benefit from this kind of tool.

Its just a pragmatic set of guidelines, and objecting to it with such ridiculous vitriol makes you sound as foolish as the people I think you're objecting to.

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

#136

Post by pvdebbe » Mon, Aug 08, 2016, 1:26 PM UTC

UK-AL wrote: post #40

blub wrote: post #37

Earlier quoted context omitted.

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.

Probably because of Parkinsons' Law.

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

#137

Post by cechner » Mon, Aug 08, 2016, 1:29 PM UTC

dasmoth wrote: post #98

cechner wrote: post #60

Earlier quoted context omitted.

I agree, it is often not the best approach. But many situations demand a well defined approach to estimation and although the OP tried to preempt this, he didnt provide an alternative

I reckon most experienced coders can cope with estimation when it's justified (i.e. "can we realistically get this done before ? And if not, is there a useful subset we can manage?"). The bigger problems come when estimation isn't about keeping promises, but rather a part of some form of scientific management aimed at "getting velocity up". There's also something of an uncertainty principle here -- more precision of…

if its being used to 'get velocity up' instead of measuring velocity then its not being done right.

I personally think estimating projects is one of the most difficult things about this industry. Especially if we're talking about delivering many calendar-months worth of effort for a team , unless its just a variant on some other project[s] the team is well experienced at

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

#138

Post by jackcosgrove » Mon, Aug 08, 2016, 1:31 PM UTC

In my experience, people matter more than methodologies. If you have good people on your team, product and dev, then you can make any methodology work. If you have bad people, no methodology will work. Advocating for one methodology or the other is far less important than hiring the right people.

That said I prefer Agile to Waterfall by a lot, and Agile developed in reaction to Waterfall so I think it was a success.

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

#139

Post by cechner » Mon, Aug 08, 2016, 1:31 PM UTC

crdoconnor wrote: post #109

cechner wrote: post #64

Earlier quoted context omitted.

if pressure is ramping up and quality down the sprints arent serving their purpose. One of the few defining characteristics of scrum is that the developers define how much they can achieve, and this estimation is improved over time. If this is not happening there is something else wrong with the culture and Scrum is being used as a scapegoat.

A few defining characteristics of scrum that lead to overly optimistic predictions: * The prediction is made in a meeting while your head is "out of the code". * The prediction is made in a group setting, rendering the decisions more easily subject to peer pressure and groupthink. * The prediction is made up to 2/4 weeks in advance of actually doing the work. * The prediction is made without risk of overshoot attache…

It sounds as though you objecting to being required to give any estimate at all.

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

#140

Post by bmj » Mon, Aug 08, 2016, 1:32 PM UTC

s_kilk wrote: post #82

maxxxxx wrote: post #22

Earlier quoted context omitted.

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 how we ended up with the "Shadow Sprint" at a previous workplace. A whole bunch of utterly essential engineering work was left out of the sprint process, so many of us would just go ahead and do what needed to be done anyway while working on whatever tickets we'd picked up frome the "real" sprint. Utterly dysfunctional of course, but if it's do-or-die, I'd prefer to 'do'.

How did you handle regression testing of the refactored functionality? That's our biggest hurdle. QC is swamped with "regular" sprint work, so there's no way they manage any additional load during the sprint.