

The Insufficiency of Scrum - BillSchofield
http://billschofield.typepad.com/my_weblog/2009/08/the-insufficiency-of-scrum.html

======
raganwald
When Ken trained me on Scrum, he was very clear about the fact that Scrum in
and of itself was not sufficient for project success. Scrum punts a large
number of important decisions to the "Project Owner," and therefore it is a
very poor fit with projects that don't have an active,hands on project owner
or proxy for the project owner.

if you have a incoherent project owner whose priorities drift from sprint to
sprint, you will end up with a beautifully executed, disciplined execution of
an incoherent product.

~~~
Retric
Scrum forces the client to decide which features are most important. It bribes
them with the idea they can have some things next week to avoid a death march
6 months from now. This helps to create useful products without wasting time
building useless things.

As long as the most important 80% works chances are the project will be
considered useful even if it does not do everything. Which is important but it
requires a skilled team to execute well over time.

~~~
raganwald
> Scrum forces the client to decide which features are most important

Aaaaah, I think it's fair to say that Scrum forces the client to declare which
features are most urgent and that in the ideal project the client aligns
urgency and importance. However, just like real life, it is difficult to align
these two orthogonal concepts.

Sometimes things become urgent because they are tantalizingly easy to do.

Sometimes things become urgent because someone important thinks they are
important.

Sometimes things become urgent because the client is personally invested in
them.

I agree that "as long as the most important 80% works chances are the project
will be considered useful even if it does not do everything," but I am
cautious about assuming that just because you ask the client to name the most
important features ona sprint-by-sprint basis that you will agree in hindsight
that the most important 80% of a product got done.

------
presidentender
I have to ask: how often do these formal buzzword project management
techniques find their way into the real world? I've not been doing this long,
but it seems to me that the folks who set deliverables either don't use these
methodologies, or use an unnamed amalgamation. Am I wrong?

~~~
mikeryan
Agile methodologies have made their way into many startups and established
companies. When I was working at Comcast large portions of the software
engineering groups was starting to sync on a product cycle.

That being said - I've not seen much consistency across implementations. It
generally breaks down to some sort of product backlog which is worked on in
small chunks on some cycle (months, weeks, two-weeks whatever...). This is a
pretty basic change to the normal waterfall cycle and easy to implement, and
works well for many teams.

The rest of the Agile/Scrum/pick your particular method is left to the
project/product/SE manager and you really have to find what works for your
team, and I'm not sure makes that big of a difference in the end.

------
patrickwelsh
What feels least sufficient to me are systems for learning Scrum, or XP, or
any blend of practices/patterns/principles well enough to do more good than
damage. We therefore generalize from poor data. We draw conclusions from poor
execution during the learning curve.

Another big issue for me, in SW Dev, is the opacity of "code asset"
deterioration as we start to iterate features through it quickly. Scrum can
exacerbate that. Once we start cranking the Sprint crank, poorly disciplined
programmers can hack the code to bits even faster than before, without
stakeholders noticing.

Hence agile wags once called Scrum "XP without the P".

------
thunk
Yeah, it needs a little more OT in the middle.

~~~
thunk
Note for posterity: I meant _in the middle_.

