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

21–30 of 93 posts

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

#21

Post by crdoconnor »

make3 wrote: post #11
saas_co_de wrote: post #2

http://programming-motherfucker.com/

do people really pair program in real life? I've never actually seen it

I find it useful for knowledge transfer. It's a good way of bringing new hires up to speed for the first week / two weeks. If you leave them to their own devices they have a tendency to get overwhelmed and fearful of continually bothering you to ask questions.

It's sometimes a more efficient way of building stuff where, for a particular task, you need a whole bunch of knowledge or information that's currently living in somebody else's head.

Also, if I'm having one of those days when I feel sluggish having another person there kickstarts me a bit...

Defaulting to pair programming for every task - especially when the conditions above are not met is a super inefficient and overbearing way of developing though.

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

#23

Post by neltnerb »

dudul wrote: post #16
qznc wrote: post #12

Now I would suggest to deprecate "sprint". It is not healthy to sprint continuously. Sane software development is much more like a marathon.

I don't know if this is meant to be facetious, but I actually fully agree. "Sprint" is a terrible analogy because in reality it is impossible to be sprinting all the time. I usually just say "iteration".

I'm confused, doesn't your statement mean the analogy is good? You can neither "sprint" at work continuously nor constantly sprint in reality.

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

#24

Post by justspamjustin »

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 together and discuss it. When we see that there needs to be architectual discussions and high level planning, we do it immediately when we recognize the need for it. The idea that you can try and commit to or even forecast how much can be completed for a period of time is pretty absurd. Just identify the minimum requirements of what needs to be done and do it. Retrospective is still productive. But sprint planning is a waste of time IMO.

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

#25

Post by jryan49 »

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.

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

#26

Post by dudul »

neltnerb wrote: post #23
dudul wrote: post #16

Earlier quoted context omitted.

I don't know if this is meant to be facetious, but I actually fully agree. "Sprint" is a terrible analogy because in reality it is impossible to be sprinting all the time. I usually just say "iteration".

I'm confused, doesn't your statement mean the analogy is good? You can neither "sprint" at work continuously nor constantly sprint in reality.

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.

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

#27

Post by jryan49 »

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…

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

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

#28

Post by rebeccaskinner »

make3 wrote: post #11
saas_co_de wrote: post #2

http://programming-motherfucker.com/

do people really pair program in real life? I've never actually seen it

Just to counter the other responses here. Yes, and it's even more dreadful than you might imagine if you've never done it. I recommend running fast and far away if you ever find yourself interviewing on a team where pairing is the default assumption.

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

#29

Post by henrik_w »

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…

I agree, I have the same experience.

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

#30

Post by smackay »

jryan49 wrote: post #27
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…

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. Once everything is up and running smoothly then it's entirely reasonable to drop all that and just focus on delivering - you don't need a lot of packaging an rituals to do that.
Post reply on HN