
Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011) - bradmwalker
https://www.scrum.org/resources/commitment-vs-forecast-subtle-important-change-scrum
======
jryan49
I still think it ironic that when looking at the actual Agile manifesto at
[http://agilemanifesto.org/](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.

~~~
jt2190
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 very clear, basic instructions as a
starting point, and hence Scrum steps in to fill the gap. What's unfortunate
is that scrum isn't a program for developing software managers from rigid, by-
the-book managers into experienced, _agile_ managers: Instead it encourages
newbie practices for everyone, forever.

~~~
mistermann
> 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.

~~~
0x445442
> 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.

~~~
beat
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.

~~~
Nomentatus
Yes, I have seen businesses die, both ways. The problem is that YAGNI cashes
out to "make the right decisions" \- it's logically a tautology, but an
emotional encouragement to drop features. Dropping is usually the correct
decision - but too often catastrophic when it's not. If you invoke YAGNI you
have to be careful you aren't "picking up nickles in front of steamrollers" \-
a great idea until suddenly it's not. Fortunately, frequent iteration gives
people a more realistic view of the cost of raisins.

~~~
beat
I haven't seen businesses die because they _can 't wait two weeks_ for a new
feature, and had to have it _right now_. I have seen businesses die because a
development team was so paralyzed by constant interruptions that they were
dysfunctional and couldn't get any real work done.

~~~
Nomentatus
If it's a better data structure, then two weeks might set the course, alas.
It's happened to me. Fact is, one can't get away from judgement calls, slogans
might nudge in one direction or another, but it all remains a judgement call
what's just a raisin and what isn't. The fatal problem is bosses up the chain
who want to demonstrate they matter and are worth their expense by throwing in
superfluous raisins; having a crude slogan (misleading or not) to deter them
is fine by me.

~~~
beat
A "better data structure" is almost never an emergency. And being unable to
adapt or extend a data structure in the future is not agile, and it's not the
simplest thing that can possibly work.

Back when I first started building a startup, I thought "Thank Dog I no longer
have to deal with stupid compromised software, and can start writing
everything right!" By the time I was getting anywhere, I was well into toss-
over-wall methodology. I did things that I knew full well were compromised and
would hurt me later, because the work needed done, and needed to "be done". It
was a real education.

I actually have a lightning talk in mind on this subject, called "Why software
sucks", that argues that suckage is the nature of software development, and
that "barely works" is the best we can realistically ask for - or even should
ask for.

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

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

~~~
smackay
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.

~~~
hinkley
But Scrum is working! Why would we ever change?

------
gedy
We had Ken Schwaber come in to our shop early on in Scrum when we were
struggling to get a new product going, and at its basics Scrum made tons of
sense. Get a small group of people together to figure out how to make the
highest priority items to ship to the customer (each written in a few
sentences), then _leave that group alone_ until the sprint was done. The
"commitment" was on delivering the value in the few sentences, not matching
mockups, specs or some never-ending chain of tasks.

It was a really simple and effective approach, but where it broke down was:
there's a lot of people/roles/depts who have no idea how to work
incrementally. UX "needs to work ahead", product "needs the whole backlog",
Ops "have their own backlog", etc.

Scrum didn't work with everyone hawking over a few engineers - then it just
becomes task tracking bullshit.

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

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

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

~~~
dudul
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.

~~~
neltnerb
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.

~~~
theptip
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](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.

~~~
rapala
Exactly. The point of time boxing is that you have to stop and reflect on the
time spent. It gives you the chance to switch tasks if priorities have changed
or to split the current task.

Or to go on to the next sprint with the same task. But here lies the problem
in many cases. The sprint is taken not as a time box but as a deadline. A
sprint should meen: "You can work 2 weeks, 5 days a week, 8 hours a day on
this. Then you stop to think."

------
taeric
Funny to see this. I thought getting commitment was one of the soft mechanisms
of scrum. An annoying one, because power dynamics are always at play. Still a
mechanism, though.

I think I'm supportive of the idea on removing it. Seems the goal is
ultimately to find ways in rhetoric and action to align the teams in working
to the end goal. Which, often, might require tradeoffs to reach a timely
delivery. And timing is a requirement.

~~~
crdoconnor
It probably made more sense to put it in in the beginning when the process was
still being sold to senior managers. Now that scrum is much more embedded,
taking out for the reasons given makes more sense.

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

~~~
philbarr
[https://imgur.com/a/OnJKA](https://imgur.com/a/OnJKA)

~~~
joejerryronnie
Fantastic, I'm using this in my next presentation to management.

------
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](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.

~~~
brightball
Depending on the size or the organization, that word commitment can create
numerous issues.

It can keep teams from collaborating because of a need to finish their
commitments first, effectively blocking the other teams and delaying actual
delivery of the product. You can see the same issues in customer support
requests. The second that somebody decides to measure completed sprint
commitments, you are in deeeeeep trouble because it forces people to low ball
to hit that number. It removes your ability to pivot.

The entire concept of sprint commitments in a moderately sized team is
borderline destructive.

This change is the best news about software development I’ve read in YEARS.

------
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...](https://www.linkedin.com/pulse/scrum-makes-you-dumb-daniel-
jones)). 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.

------
je42
This PDF is pretty nice. Regarding the differences of Kanban vs Scrum.
[https://www.crisp.se/file-uploads/Kanban-vs-
Scrum.pdf](https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf)

------
perseusprime11
Is Agile & Scrum still relevant? I am seeing more and more consultants who
used to selling this stuff have moved upmarket into Lean and Digital
Transformation of companies.

------
romanovcode
Can we deprecate scrum in 2018?

~~~
dang
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.

------
brightball
This is perfect.

------
saas_co_de
[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

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

~~~
dudul
Yes.

~~~
make3
at which company did you see it, and was it everyone

------
woliveirajr
Tag [2011] is missing...

~~~
sctb
Thanks! Updated.

