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

61–70 of 93 posts

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

#61

Post by stephenhuey »

hinkley wrote: post #54
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 got…

Scrum does not discourage adding additional tools as needed. It tries to provide a minimal framework and nothing more.

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

#64

Post by EngineerBetter »

I wrote an article on the negative psychological impact of commitments in sprints (https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-j...). It's great to see renewed focus on shifting away from a term that has been used to make developers' working lives unpleasant, leads to lower-quality code, and gives false certainty to stakeholders.

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

#65

Post by stephenhuey »

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.

Hear hear! Scrum predates Agile. It welcomes mixing in other tools as needed, e.g. XP, Agile, etc. After 15 years of professional software development, I just picked up a scrum master certificate a couple days ago after my employer paid for the class. I'd rather see teams using scrum than just winging it unless they are provably experienced or extraordinarily competent. Individuals can be good at their work but it's often difficult to get everything in sync on a team, or even if the team is super amazing the complexity of getting things done in a corporate environment with lots of moving parts and dependencies is usually aided by using tools such as scrum. Even when a complex corporate environment commits to trying to follow it, it's still a struggle to get the basic elements of scrum adhered to (enough time with product owner, enough time figuring out dependencies, any time at all spent identifying ways the team could do better in the future and reduce friction, impediments, or needless work). Take a look at the Scrum Guide - I'd be satisfied if just the few events in the minimal scrum framework could be fit in, but often not even that happens.

* edit: provably

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

#66

Post by wnevets »

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.

Trying to explain this to people who are "certified" is exhausting.

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

#67

Post by daanlo »

I am a big fan of scrum precisely because of the word commitment (I hand't realized it was removed). Forecast means we need to use a larger estimate next time. Commitment means: "how can we still get this live". In a good culture the answer to this should rarely be work extra hours or reduce code quality - it should be reduce scope of functionality. Without the commitment you often get micro feature creep, where a bunch of non-essential micro features are added. A bit like this (https://lawsofux.com/parkinsons-law.html). It is also the obvious moment in time to tell a product owner "we need to remove functionality x or not ship". Without the commitment that important conversation is never had. In my experience micro & macro feature creep is one of the biggest issues in sw development. Obviously you can still do the above with the word forecast, but forecast empowers you less to actually change anything (apart from better aka higher estimates next Sprint). On a general note: I feel scrum is often misused to "manage" engineering teams, when it is really a productivity tool that the team should use for itself.

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

#68

Post by mistermann »

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…

> 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 if I am the only one that feels this way.

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

#69

Post by 0x445442 »

mistermann wrote: post #68
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…

> 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 requirements for my home build, I leave that to them. I just expect my requirements to be met at or near budget.

A lot of these software process issues boil down to managements never ending quest to commoditize developers.

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

#70

Post by dlezama »

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.

Well, nobody makes money by pointing at the manifesto. But a whole business can be built around "certification" and all that.
Post reply on HN