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

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

#221

Post by lmm » Mon, Aug 08, 2016, 3:31 PM UTC

Udik wrote: post #163

crdoconnor wrote: post #63

Earlier quoted context omitted.

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…

I often have the impression that the term "technical debt" is just an euphemism to avoid admitting that someone in the team has produced poorly thought and poorly written code. I'm not sure I ever found myself in the position of writing bad code just for the sake of speed - I surely wrote tons of bad code because I didn't know how to do it better, or because I didn't have the requirements clear from the start, or bec…

What value comes of characterising it as "inadequacy"? I mean you may enjoy the self-flagellation but does it actually help plan or work effectively?

To my mind the "debt" metaphor captures important intuitions: it accumulates interest, slowly at first but rapidly if you have too much of it, it can look like it isn't a problem until it is, taking on more is often an easy way out of your current situation in the short term.

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

#222

Post by eli » Mon, Aug 08, 2016, 3:35 PM UTC

frandroid wrote: post #209

We now use Kanban on our team, after using Scrum for a couple years. Pointing is a process to discover unexpected hurdles or uncover hidden knowledge from coworkers, and as a guideline. By not having sprints, you just focus on your current ticket, and not artificial deadlines or points. Tickets will be done when they are done, and managers don't have expectations of completeness that as disconnected from reality. We'…

I'm considering a similar approach with my team. Any specific resources or books or tips you found especially helpful?

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

#223

Post by lmm » Mon, Aug 08, 2016, 3:37 PM UTC

frandroid wrote: post #209

We now use Kanban on our team, after using Scrum for a couple years. Pointing is a process to discover unexpected hurdles or uncover hidden knowledge from coworkers, and as a guideline. By not having sprints, you just focus on your current ticket, and not artificial deadlines or points. Tickets will be done when they are done, and managers don't have expectations of completeness that as disconnected from reality. We'…

There's certainly a lot to like about that approach. But my experience is that it makes it very easy to end up with tickets that end up taking months (because there's no longer a natural point at which to stop and take stock), and/or accepting tickets that don't really have clearly defined acceptance criteria, which risks working on something that won't actually turn out to be useful. I don't like the artificial 2-week cadence of Scrum but I think I might still prefer it to not having one at all.

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

#224

Post by lmm » Mon, Aug 08, 2016, 3:38 PM UTC

daemin wrote: post #133

crdoconnor wrote: post #63

Earlier quoted context omitted.

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?

There is no objective measure. Yesterday's good code is today's technical debt.

But at the same time there is definitely some underlying real quantity. Different developers may not agree on every single aspect, but they'll agree about the difference between a good codebase and a bad one, and it really does take longer to make changes to the bad ones.

So what can you do?

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

#225

Post by tootie » Mon, Aug 08, 2016, 3:41 PM UTC

JoeAltmaier wrote: post #184

neilni wrote: post #182

One of the most essential part about Scrum is that it aligns the understanding across all the stakeholders, including business owner, customer, designer, developer etc. Hence the meeting, prioritization, backlog, daily standup/daily write up as development process artifact etc to focus on the priorities that create the most business value under flexible scope, fixed time and fixed money. scope, time and money are the…

Except most of the 'stakeholders' don't give a fig for what the Engineers value. Like technical debt, robustness of the solutions, relieving bottlenecks both in code and in development. So Engineers get herded into little incremental projects that management can swallow as having 'business value'. And the herd marches toward the cliff as the code base wanders around the solution space but never gets fundamentally sou…

No process will solve the lack of understanding. Also, this goes both ways since engineers frequently don't give a fig about business priorities. Sometimes your refactor isn't really that valuable and is costing the company money.

If you have a culture of trust between departments, you should be able to have honest conversations.

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

#226

Post by Chris2048 » Mon, Aug 08, 2016, 3:43 PM UTC

cechner wrote: post #214

wott wrote: post #203

Earlier quoted context omitted.

I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.

can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring v…

Assume each person giving different estimates for their own work, but not up front - ongoing as code is written.

How is that the same as not being "required to give any estimate at all"?

> he doesn't want to have to commit to it

why not? an estimate is an estimate, not a commitment. Committing to an estimate makes it a commitment, not an estimate.

I might expect a dice roll to be 3.5, I'm not committing to the next roll being 3.5 - analysis should inform policy, in this case expectations informing stated commitments, but the two are not the same.

Furthermore, this bullet point actually takes the quote out of context - He specifically doesn't want to commit to the estimate produced under the previous conditions, not that he won't commit to any estimate. The difference is choosing to commit to an estimate you have high confidence in, versus any estimate given automatically being a commitment (where estimates may be required on demand).

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

#227

Post by crdoconnor » Mon, Aug 08, 2016, 3:44 PM UTC

cechner wrote: post #214

wott wrote: post #203

Earlier quoted context omitted.

I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.

can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring v…

>* while he is actually writing the code

Yes. I can take time out to answer email. I can take time out to make estimates as soon as I get an estimate request. Doesn't have to be done in a meeting.

>(so not up front)

What the fuck is the point of an estimate that's not made in advance???

>not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates

The latter. Is that a problem?

>(third point same as first, dont want to estimate up front)

"Not up front" is not the same thing as "not 4 weeks in advance". I'd do it as soon as the PM needed it to do prioritization.

>must incorporate what is often called 'contingency'

If you think risk and contingency are the same thing you're an idiot. Risk is story A (e.g. upgrading dependencies) might take 0 hours or might take 4 weeks while story B (updating translations) is going to take 1.5 hours and it's really only going to take 1.5 hours.

Contingency is (for example) "let's make sure we have 4 weeks spare before doing story A".

>(which is actually what the whole point of measuring velocity is for!)

No, velocity is about measuring how fast you're doing stories.

>and the final point - he doesn't want to have to commit to it

Yeah, because as soon as you start assigning blame for missing feature deadlines the technical debt dial gets ramped up to 11 and predictions become an exercise not in being accurate but in CYA.

An estimate about how long something is going to take can be wrong for many reasons that aren't the developers fault - bugs in libraries, technical debt in dependencies, technical debt they weren't aware of and didn't create, team members disappearing, etc.

If you want developers to commit to things make sure it's things that they have full control over.

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

#228

Post by redler » Mon, Aug 08, 2016, 3:46 PM UTC

ozmbie wrote: post #148

thackerhacker wrote: post #52

Earlier quoted context omitted.

It's a long time since I've had to deal with "strict" Scrummers. But I do remember being utterly baffled as to the insistence on user features being ready by the end of a sprint, even for quite complex, technical components. Why can't we make some sub-component this sprint then the UI bit the next? I tried various ways of reframing it such that the developer of the UI be the "user" but it didn't wash.

Because that two weeks you spent writing excellent code is mostly useless unless you have a way to get feedback on it. As a customer, you've given me no value. What if you finally hook up UI to the sub-component and the customer/stakeholder decides they don't like any of it? You could have known about it earlier.

The problem with this is that it imposes a membrane on the process that is only permeable to work that contains a shippable piece of user-facing software. It presupposes that all work can be divided into such pieces. And since that's not true, it leads to contorted stories to squeeze necessary work through that membrane.

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

#229

Post by mrharrison » Mon, Aug 08, 2016, 3:47 PM UTC

I guess there are many way to use points, but what was described in this article isn't the way we use them. Points are great for a group of people to groom a story (estimate a features difficulty). Points are an estimate of difficulty. The way we do it is we have a story that describes what feature will be built, then as a group we talk about it and then all at the same time (so we aren't persuaded by others) rate the story with points (level of difficulty) and if we all (developers) rate it at the same points then we add the points, if we have different opinions on the points (level of difficulty) then we discuss why we think it's easier or harder. And this helps others who wrote the story foresee issues or know of other simpler solutions. Works great if you ask me, and that's how we were taught to do it.

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

#230

Post by cechner » Mon, Aug 08, 2016, 3:51 PM UTC

cechner wrote: post #214

wott wrote: post #203

Earlier quoted context omitted.

I don't know how you manage to read this. He seems to say he would like to be in a situation where he has the means to give good estimate but scrum forbids it and forces to give random and biased estimations.

can we infer that he would like to give his estimates: * while he is actually writing the code (so not up front) * not in a group setting but as an individual, so either one person estimating the whole thing or each person giving different estimates * (third point same as first, dont want to estimate up front) * must incorporate what is often called 'contingency' (which is actually what the whole point of measuring v…

(replying here because I guess we've reached the maximum depth)

I am here assuming that you want to be able to try to measure your progress through the project (as I mentioned, this is the only thing scrum does for you). Both of you seem to be suggesting (dont insult me if Im wrong) that this isnt the highest priority.

And no, velocity is to make the whole system self-adjusting. If I put 3 points against a story we use velocity to discover over time how long those 3 points take. This self-adjusts to incorporate for contingency.

If you disagree with this then we simply disagree on what velocity is about. It doesnt make us enemies, we dont need to get super pissed off at each other.