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

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

#231

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

crdoconnor wrote: post #227

cechner wrote: post #214

Earlier quoted context omitted.

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

The tone of this post is uncivil, e.g. "If you think ... you're an idiot."

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

#232

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

joe8756438 wrote: post #142

I disagree with most of the major criticisms here. I think it is a valid description of an experience using scrum half-heartedly, but not an argument against its purpose or value. Points, for example, the argument is based on the premise that teams are obsessed with points. What if the teams use points as a framework to discuss complexity? I have worked in scrum groups where if something was given a large point value…

This is my experience also. Points are complexity and high complexity tasks are most definitely to be addressed by breaking down stories. Dependencies are also easily addressed by setting a Definition of Ready. Don't accept a story if the dependencies aren't met (be that APIs, environments, designs, whatever). Simple.

Planning/grooming we do in one hour. You good story writers is all. I once had a planning last 12 hours because the product management was so awful. If your team sucks, no process will save you.

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

#233

Post by xwkd » Mon, Aug 08, 2016, 4:00 PM UTC

matthewmacleod wrote: post #107

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

We tend to bundle that work up and include it in tickets with the full acknowledgement of the rest of the team. "Oh, since we're adding new email features, we'll need to clean up some of the old email code. That will add additional complexity to this task, so we will estimate it higher." It works, allows us to still track the impact on velocity, keeps everyone informed, and makes technical debt clear and trackable.

I believe this is the correct approach. You're not hiding the complexity of the work, and you're also not compromising on quality. This leaves only the task of saying "no" when asked if you, "for now, could just..."

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

#234

Post by a-priori » Mon, Aug 08, 2016, 4:09 PM UTC

lmm wrote: post #223

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

When I worked on a team like this, the rule was that when you came free and are looking for work, before you started any new stories you looked at the work in progress to see if you can help out to expedite any of it. The idea is that it's everyone's responsibility to try to minimize the work in progress (Lean).

We also had the general expectation that one story should generally take no more than about two weeks. Before starting a story, if you think going in that it will be too big, then you try to limit the scope or defer parts of it into new stories until you're confident it can be done in two weeks.

Once a week we tracked how long stories were in the "In progress" column, and once it'd been up there for three or four weeks, people started asking how they can help wrap it up. I think the longest I remember a story being in progress was about 6-7 weeks, and that was real uncomfortable for us. Typical times were 1-3 weeks.

So we had a weekly cadence for demos, and product owners liked that they would see steady, regular progress rather than being inundated with sudden large dumps at sprint boundaries.

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

#235

Post by vpeters25 » Mon, Aug 08, 2016, 4:09 PM UTC

JoeAltmaier wrote: post #179

vpeters25 wrote: post #169

> First of all, what are story points? Are they measures of time it takes to complete a story? If yes, then why are they not in terms of time? Are they measures of complexity? Story points are a measure of "relative amounts of effort". A 2 point story is twice as hard, as far as effort to implement it than a 1 point one. > Scrum meetings (aka rituals) have been among the most miserable hours of my life... Would you r…

For some engineering tasks, the work and the planning are almost the same thing. Once you've explored the problem, the code is the small part. When asked to estimate, the answer is "I'll let you know when I'm getting into it". Then you're made to do a 'spike', which is indistinguishable from doing the task. Except do it in a day now. So the Engineer thrashes around trying to figure it all out in a day, and comes up w…

In agile, the estimates should be decided by consensus of the whole team. Requiring a single engineer to come up with an estimate is a smell.

Here is a quick 4 step planning meeting process based on planning poker:

1. Pick story from backlog, explain in a couple minutes what do you think would take to implement it.

2. Team members pick an estimate of the effort.

3. If there is consensus, note estimate on story, pick next, goto 1.

4. If there is no consensus on estimate, have highest and lowest explain why they picked their estimate, goto 2.

If you are expending more than 5 minutes on a story and there is no estimate, push it down and move on. It's not ready for development. The whole planning meeting should not take more than 1 hr.

This process, allows everybody involved in development to have an idea of the overall project and chip in with their experience to impact estimates (this might require refactoring class X, it might be hard to test, will conflict with Y and Z, etc)

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

#236

Post by engi_nerd » Mon, Aug 08, 2016, 4:15 PM UTC

clifanatic wrote: post #201

maxxxxx wrote: post #146

Earlier quoted context omitted.

True, but don't forget that non-broken organizations are very rare :-)

Do you know of one? I've been looking. For 25 years.

All organizations are broken, but some are more broken than others.

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

#237

Post by retbull » Mon, Aug 08, 2016, 4:16 PM UTC

I've been noticing more and more that I code around the stories rather than following the best practices from the beginning. When I am adding a DB connection and we don't have liquibase or fliway in place I can't add it because that is a ticket for next week and I need to get it done now. I write code that sucks so that I don't break from my sprint and possibly work on something else first.

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

#238

Post by patothon » Mon, Aug 08, 2016, 4:18 PM UTC

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 don't like scrum myself, but let me try to defend it because I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it.

Let's just remember that Scrum is just a tool that is trying to replicate some practices of the toyota production system (TPS), and an important principle of the TPS is continuous improvement, and Scrum has this through restrospectives. Another principle is quality built in.

Now, how to avoid having a rat's nest after 2 years?

First of all, you have to remove velocity as a goal for your team. It's easy to game, and it de-incentivizes finding a _predictable_ velocity, which is the goal of that tool.

The goal of velocity, is to know what's the "cost" of building an healthy system.

i.e.: Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything, because you bring them predictability, and that's mainly what they want. They might think you're slow, but hey, all of this is relative.

Suddenly, what does that mean when your team only ships 5 arbitrary points? That they had to push extra. That there was an unexpected problem. That things were on fire and you had to stop working on features entirely.

Basically, that there is something to retro on, find the root cause and anticipate for next sprints, and use to go back to the healthy level of points.

I used this at several places. It demands trust, but it always pays off.

With some teams I worked with, we set up a technical prioritization planning meeting every week, where basically decided what was going to be prioritized for that week. Each team was picking 2/3 things to do on top of the features.

You don't tell anyone. You do it.

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

#239

Post by dkersten » Mon, Aug 08, 2016, 4:23 PM UTC

blub wrote: post #17

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.

Deconstruct Scrum and perhaps something like RUP/DAD (Scrum doesn't tackle the whole lifecycle) into components and understand what the purpose of each component is. Start from Kanban and add stuff until you get a process that matches the critieria of the organisation. This requires a lot of skill though, so many teams are stuck with one-size-fits-all tools like Scrum, especially now that it's become a management buz…

Instead of inventing my own system, I would go with the (rather new) GROWS Method[1], which is designed to be adapted to suit your needs (but only after a certain level of experience is gained).

GROWS splits its components into stages, through which your team progresses as they become experienced with the various practices. The stages are:

Stage 1 is very simple and easy and about getting your team setup on good practices (eg source control). At this stage, you should be following it rigidly.

Stage 2 is about making sure the right people are working on the right things at the right time. A rigid but simple agile-development system.

Stage 3 is about applying judgement and critical thinking to stage 2, adding release planning, retrospectives and other plan-and-feedback practices

Stage 4 is the stage where your team is experienced enough to tune and alter the practices so that they work best for your unique situation

Stage 5 is when you're ready to replicate your teams practices for other teams or environments.

I like it because it acknowledges that no one-size-fits-all system can be perfect for everyone and provides a framework that allows itself to be changed, but does so around a "skills model" to prevent premature change.

"This requires a lot of skill though"

Exactly. Which, in my experience, most teams do not have. All too often have I been in a team practicing some form of agile, but they don't like X and would prefer Y and so they change the framework to suit their needs and then it fails and they blame the framework, saying it doesn't work, when in reality what happened is they changed and broke it, because they are not (yet!) experienced enough in that framework to actually tweak it to their needs. GROWS is designed with this in mind.

[1] growsmethod.com

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

#240

Post by the_fury » Mon, Aug 08, 2016, 4:23 PM UTC

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…

I've routinely brought up all of the unconsidered comments in retrospectives. Retros are all about making sprints better, and talking about technical problems is integral to that.