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

Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

scrum.org

Post reply on HN
Print view View original

71–80 of 93 posts

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#71

Post by 0x445442 »

justspamjustin wrote: post #24

My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team togethe…

> But sprint planning is a waste of time IMO.

Agreed. Don't forget to throw daily standups in their. My current project spends 2.5 person hours per day on the daily standup.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#73

Post by chris11 »

jryan49 wrote: post #25

I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.

On another note, what metrics could be commonly used to judge individual dev productivity, and should they be used?

I'm wondering because I have had places bring up metrics like average story points completed per sprint in performance reviews. Which kind of confused me when numbers for our team seemed to be doing fine, and it seemed like my work was going well based off of previous conversations with management.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#74

Post by beat »

0x445442 wrote: post #69
mistermann wrote: post #68

Earlier quoted context omitted.

> Instead it encourages newbie practices for everyone, forever. I feel like YAGNI is similarly abused, I don't know how many times I've said "You know what, while we're at it we should...." only to be overridden with "YAGNI!", only to be proven right 3 months later, only now the cost of refactoring > value of the feature, and saying I told you so isn't being a "team player", so no one ever learns. I very often wonder…

> I very often wonder if I am the only one that feels this way. You're not. One of the bigger issues I've seen with Scrum is not being able to shoe horn in work that needs to be done because business didn't identify it as a "story". I believe development is there to serve business and any processes used to facilitate this serving should be defined by development. I don't dictate how a general contractor satisfies my…

There's an analogy I like to use... you're baking bread. Bread is just flour, water, yeast, and salt, plus maybe decoration ingredients. You mix things in the correct proportions, let it rise, bake at the right temp/time, and you get bread. Easy, right? Then someone wants you to put in raisins. "It should be easy! It's just a handful of raisins, I don't see why you're telling me it can't be done!", they shout, five minutes before the oven timer goes off.

Scrum is, at heart, designed precisely to stop the behavior you're demanding - that is, the endless stream of "small" interruptions and constantly shifting priorities. The raisins.

Why are you trying to "shoe horn in work" for this iteration that you weren't aware was even an issue when the iteration planning happened? Is production down? Is it a hair-on-fire emergency that threatens the business? Or is it just "important". FUCK important. If it's so important, put it in the story backlog and have it done in the next iteration.

If it's important enough to disrupt the iteration, it's important enough to cancel the iteration, toss all that iteration's unfinished work onto the backlog, and start over. That's how Scrum is supposed to work, but never does, because someone wants raisins at the last minute and thinks it's not a big deal.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#75

Post by lowbloodsugar »

tootie wrote: post #59
jt2190 wrote: post #45

Earlier quoted context omitted.

The Agile Manifesto suffers from "the curse of knowledge": The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it's important to not specify a method for every situation. But there are many, many people entering the software industry who don't have their years of experience, and who need ver…

Exactly. I look at it as following the Dreyfus Model. If you don't know what agile delivery looks like or how to approach it, you start with Scrum and follow it religiously. Once you get the feel and the team is accustomed, you can modify it to suit your needs or just wing it and keep the goals in mind.

Unfortunately, what teams do religiously is the process, contrary to the manifesto. So they put a Scrum Master pin on someone, they do Sprints and burndowns. They cargo cult.

I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why".

Jeff Sutherland said there are three things that must be true for a team to be a Scrum team:

1. It must be self-governing.

2. The team members must be on the team 100%

3. The team members must stay for the duration.

With the exception of start-ups, I've seen maybe one team which met these criteria. But they all had sprints. And of course, they were all held to their commitment. Scrum is now a tool for management to death march people.

Think of all these metrics that management measures scrum teams on. Can you imagine any of these teams turning around and saying, "We're going to measure how many of your bullshit wishlist items meet the definition of an actionable story when presented in sprint planning, and how many hours are wasted?" Of course not. Management can't abide a team that meets rule 1. "I'm a manager! I must manage! What is my job if my teams are self managing?!"

Scrum, as Ken Schwaber describes it, is a fantastic way to develop product. Unfortunately, if you are in an organization that would truly let you do Scrum, then you probably don't need it. You are already qualified, experienced and empowered. If its a hundred twenty-year-olds being told to "do scrum", it probably ain't Scrum.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#76

Post by watwut »

lowbloodsugar wrote: post #75
tootie wrote: post #59

Earlier quoted context omitted.

Exactly. I look at it as following the Dreyfus Model. If you don't know what agile delivery looks like or how to approach it, you start with Scrum and follow it religiously. Once you get the feel and the team is accustomed, you can modify it to suit your needs or just wing it and keep the goals in mind.

Unfortunately, what teams do religiously is the process , contrary to the manifesto. So they put a Scrum Master pin on someone, they do Sprints and burndowns. They cargo cult. I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why". Jeff Sutherland said there are three things that must be true for a team to be a Scrum team…

I worked on self governing teams without manager, twice. Never again. Relationships were hell with constant power struggle between wanna be micromanagers over who is going to be non existent leader and get to have his vision.

Clear responsibilities, accountability and personal autonomy are so much, so much, better arrangement then self governing team.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#77

Post by oomkiller »

matwood wrote: post #60
justspamjustin wrote: post #24

My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team togethe…

> We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. I'm curious about a few things, if you don't mind answering. When do tickets get broken down into manageable chunks? Who does the breakdown? When is a rough cut of effort put on a ticket? S/M…

A breakdown step in your development process breaks down work into equally sized chunks, that all count against WIP limits. If you're interested in using Kanban for software development I suggest checking out Eric Brechner's book and youtube videos.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#78

Post by dang »

romanovcode wrote: post #13

Can we deprecate scrum in 2018?

Please don't post unsubstantive comments here. I'm sure few people here have any fondness for software processes, especially in the corporate decadence stage, but that's no reason to make HN worse.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#79

Post by joejerryronnie »

gaius wrote: post #48
leethargo wrote: post #35

Earlier quoted context omitted.

Running a marathon is not the healthiest thing to do either. Even "marching" has a bad connotation in this context.

People get necks and backs broken in real scrums too. A real scrum is a violent fight for control between opposing teams. A lot of these analogies were not well thought through. I will wager the methodology merchants behind scrum were neither runners nor rugby players ever.

Ah yes, the shenanigans that occur in a real scrum are no joke. Some of our forwards would wrap tape around their entire head (including ears) to prevent their ears from being torn off.

Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)

#80

Post by joejerryronnie »

philbarr wrote: post #34
bamboo_7 wrote: post #31

Yes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.

https://imgur.com/a/OnJKA

Fantastic, I'm using this in my next presentation to management.
Post reply on HN