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

51–60 of 93 posts

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

#51

Post by theptip »

neltnerb wrote: post #36
dudul wrote: post #26

Earlier quoted context omitted.

Let's say you do 2 week sprints as part of your process. You do a sprint, finish it, and then do another sprint immediately after. How is that viable? Effectively it means that you never stop sprinting. I don't think it's sustainable.

Is that actually what scrum suggests sprints are? Thanks, I missed that, that's silly if so. I assumed by the name that this was like a one week a month kind of thing.

I think there's quite a lot of getting hung up on the word itself here... According to the Scrum guide, a sprint is just:

> a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

(http://www.scrumguides.org/scrum-guide.html#events-sprint)

There's nothing that says you need to "sprint" through your sprints, quite the contrary it's supposed to be a way of measuring your team's steady-state output by making the feedback loop short.

If people are really hearing the word "sprint" and thinking "ah, Scum is telling me to work at 110% all the time without stopping", then I put forth that no methodology or change of terminology is going to save them from themselves. However, I suspect there's something about the timebox structure that makes short-term thinking the default unless discipline is applied, and discipline is hard.

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

#52

Post by sorokod »

weego wrote: post #49
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.

I worked at a large consultancy in the UK where the platform team were 'agile' in that they had 2 week sprints, but those 2 week sprint goals were fixed for months ahead. If you needed a small API addition or specific bug fix in one of your apps (elearning courses) to launch a product on the platform and you hadn't foreseen this 2 months+ in advance then you were out of luck (unless you had leverage on one of the pla…

In my experience this kind of Agile inevitably emerges when the desire to be agile is limited to a (small) subset of the organisation.

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

#53

Post by cybergoat »

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…

Scrum is a sad joke. But corporate loves feeling "safe", with estimates in hand, even if they readily blow out. Usually it ends up with "watergile", a total mess.

You can just time kanban tickets vs estimated size (all the forecasting, tracking, etc, should be done by a manager, without wasting the team's time) combined with pulling from the right hand side and vigorous action towards blockers. Optimise for throughput.

During the best version of this, as I experienced, we spent about 5 minutes in the morning as a team, and occasionally visited the board throughout the day (not as a team, sometimes as a pair, to discuss something and add/move tickets). My manager at the time spent some time at the end of each week by himself collecting cards and doing the tracking to make the higher-ups happy.

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

#54

Post by hinkley »

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…

Scrum doesn’t prescribe enough techniques to be successful. Somewhere, maybe in an interview, I heard someone say that they never saw a successful Scrum team save that they were doing half of XP too.

So far I have not found an exception to this. Thing is that means everyone is doing Scrumbut (we do Scrum, but...) Which means you have to relearn or reargue with every single team about the exact same concerns. It’s gotten old.

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

#55

Post by hinkley »

smackay wrote: post #30
jryan49 wrote: post #27

Earlier quoted context omitted.

If you read the actual Agile manifesto, what you are doing now is more agile than scrum :)

A lot of the artefacts of a process are intended to help teams transition from the old way of doing things and to help teams who have stalled or failed to deliver. Sprints, as far as I understand them, were intended to get the wheels turning and to demonstrate results at regular intervals so the customers for any software development effort could see progress and gain confidence that the team was going to deliver. On…

But Scrum is working! Why would we ever change?

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

#57

Post by hinkley »

ionforce wrote: post #42
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…

Do you not have due dates or stakeholders that want predictability?

In a waterfall organization many of those due dates are months out.

Finish and deliver don’t have to be the same thing. Especially when features depend on each other.

A group of unaffiliated contractors slipped kanban into Boeing in part because we never said what we were doing. But every time there was a hiccup we proposed another kanban process. WIP limits took a while but saved a lot of headaches. If we are over the limit and you finish a story you had to help someone else or get a special dispensation for the leads (sometimes we had stories that depended on other teams and the next story was straightforward).

It is by far the biggest silent conspiracy to do good that I ever participated in.

Unfortunately after we got reported into a sustaining team there was some peer to our manager who would not shut up about Scrum. If you’ve done Kanban, Scrum is like when your parents make you hang out with your kid brother’s friends.

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

#58

Post by crdoconnor »

philbarr wrote: post #32
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.

Absolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.

I think that's largely the fault of the manifesto. It is entirely unclear about what putting "individuals before process" actually means.

One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests.

The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.

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

#59

Post by tootie »

jt2190 wrote: post #45
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.

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.

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

#60

Post by matwood »

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/L often matters when making priority decisions.

Post reply on HN