
Why Scrum is fundamentally broken (but we still use it) - exch
http://joostdevblog.blogspot.nl/2014/03/why-scrum-is-fundamentally-broken-but.html
======
ericHosick
> Purists want you to believe that only pure Scrum works

Purists would realize that Scrum was defined to be a self reflecting, self
improving system. Scrum allows people to alter scrum to meet their needs.

> Scrum deliberately asks the team not to look too far ahead

This is not true. The product owner can put as much stuff on the backlog as
they like and the team should know about it. Scrum does ask the team to not
spend a lot of time estimating out stories that are months down the road (so
very loose estimates are ok).

> Scrum forces that the plan cannot change during the Sprint. This way they
> know where they stand during the Sprint.

This is true but not totally true. Scrum requires the product owner to "stand
back" during a sprint. But, at any time, the product owner can declare the
sprint un-productive and it restarts. How does the team know they aren't
adding value if the product owner can't stop the sprint?

> For a game to be "potentially shippable" after every Sprint (as Scrum
> requires) the certification requirements

See above where scrum allows you to alter the "rules" of scrum to meet the
needs of the users. Scrum is not written in stone.

------
programminggeek
The author has a very literal notion of "shippable". Shippable could mean to a
beta group. It could mean to the public. It could mean that the feature is
"done" but not turned on or it's hidden behind a feature flag.

Also, you are supposed to have retrospectives after each sprint to improve.
This sounds like a discussion that should have happened with the OP's team at
a retrospective.

~~~
ogreyonder
Agreed. His argument is essentially that you can't meet deadlines with Scrum,
because you must always be in a 'shippable' state at the end of each sprint.

I'd argue that if you can't meet deadlines with scrum, there's no way you'd
meet them without it. His definition of 'shippable' is very narrow--like you
said, just because it doesn't meet console certifications doesn't mean that
it's not "doing scrum".

I wouldn't put the app I've got after the first dev sprint on the app store,
either. It's not done.

------
vannevar
_Shipping dates are therefore always met according to Scrum: just stop
developing at the deadline and release the product in whatever state it was in
at the end of the last Sprint._

The author perpetuates the myth that scrum is incompatible with businesses
that have hard real-world deadlines. This is not true. Nothing in scrum
requires you to blindly plow forward working through an un-altered backlog one
week at a time until you either miss a big deadline or release a half-baked
product. All scrum requires is that when adjustments are made (like cutting
features in the face of an upcoming deadline), they are made according to an
orderly process of prioritization that occurs during sprint planning and while
grooming the backlog.

What agile buys you is early warning when inconsistent objectives emerge, so
you can make adjustments well in advance instead of in a last-minute panic
right before the deadline. Sprint-by-sprint demos ensure that you really know
where you stand versus your backlog and roadmap. No more, "I think we're about
20% done with that".

------
bertil
It sounds like he is saying that Scrum is not compatible with platform
specifications because those are too stringent… From my experience, those are
not very appropriate as goal posts, but they don’t make scrum unusable; there
is just a secondary list of goals between Playable (locally) and Shippable, in
addition to game specification.

Not sure why he calls the first one ‘Potentially shippable’ though, not when
he imagines project development with significant artwork drafts that should
not be shipped: contradiction is within his own interpretations, there, not
incremental methodology.

------
richliss
The main principle behind the potentially shippable product increment is
linked to the concept of always prioritising the highest business value
stories, and in particular vertical slicing of functionality so that its
implemented top to bottom.

In the game industry this would generally align with working towards a single
level demo, possibly with simple graphics so that its playable and gives the
end user an idea of what kind of game it is, and how enjoyable it could be
with more work.

Now for a new type of game, or something a little different, this is
absolutely the best way to go as you can find out if your belief in this game
is supported by interest from those who play the demo before you spend years
and huge amounts of money. So the standards you'd need to meet from Microsoft
or Sony need to be implemented only when you feel you would like to ship it to
the general public.

If used for the next Call of Duty game it may well damage the brand unless it
surpasses the standard of the previous game, so whilst it is potentially
shippable, it wouldn't be sensible to ship it any further than internal
testers until you know its to a high standard.

Scrum is simple to implement but harder to get right, which is why so many
groups implement what is defined as "ScrumBut", and when they don't get the
suggested benefits blame Scrum rather than their "ScrumBut".

Think of it as being similar to speaking to a Spanish person. Scrum is
speaking pure Spanish, and ScrumBut is speaking mostly Spanish and some
English as you can't quite master those more complicated parts. If they don't
fully understand you can't guarantee its the fault of the Spanish language,
but rather its more likely the few English words you've used instead of the
possibly mispronounced Spanish ones.

I'm certain there are some teams who have implemented pure Scrum and have not
found the suggested benefits, but so many of these posts slagging off Scrum
I've read are from people who have adapted Scrum, or haven't implemented it as
suggested in books/courses.

I'm certain many of these people will end up slagging off XP, Kanban and every
other framework/practice when they don't implement those fully either.

Before any quotes the Agile Manifesto at me, the individuals and interactions
part is suggesting that if doing something at a process level that isn't
adding any value then you stop doing it as you can achieve the same with less
process and more interaction, not stop doing it because you don't like doing
it even though its something you should do as it adds value.

------
catmanjan
You don't have to create something ship-able between each sprint, it just has
to be demo-able.

------
mcmillion
There's nothing more annoying than a blog that commandeers swipe navigation.

