

The "Holy" Scrum War - bdehaaff
http://blog.aha.io/index.php/the-holy-scrum-war/

======
greening
Scrum definitely focuses on "What", but it is much more than the author
claims. The difference between Scrum and "old school engineering" (aka
waterfall) is primarily that Scrum actually measures the full production
cycle; you can't do that with the long development cycles of waterfall. If you
use Scrum to measure the full development cycle (which means you actually ship
the Sprint product), you can then use velocity to forecast feature delivery in
the future with some statistical justification.

If your engineers say that "agile doesn't forecast", they are giving you a
snow-job. They are using agile as a weapon against naive Product Managers who
don't understand Scrum and why it was created. Scrum was designed to replace
the inaccuracies of waterfall "pseudo forecasting", which had resulted in many
projects failing dramatically. Basically, waterfall "planning" is hypothesis
without any verification. In contrast, Scrum verifies with shipped product
every Sprint.

Astute product managers can use Scrum's verified velocity to forecast far into
the future, with the usual tools of statistics (such as standard deviation,
etc.). It isn't prescient, but it's the best we have. Waterfall is far worse.

Scrum done well is an experimental framework for measuring and improving
feature production. It works when done well, but it is hard to do.

You can think of Scrum as a religion, but only in the way that
atheism/agnosticism is a "religion". There's faith-based development and that
includes waterfall; there's reality-based development and that includes Scrum
(but could include any other technique where you measure and forecast using
shipped product and velocity).

On the matter of Product Management, Scrum's short iterations buy you
something cool: You can do Lean Product Management a la Eric Ries. This is the
Product converse of Development's Scrum. Lean Product Management says "We
don't know that much about the market, so let's run experiments to find out
more, then let's adapt as we learn."

Scrum lets you experiment with production; Lean Product lets you experiment
with markets. If you are certain that your production methods are sufficient
(and you don't need truthful forecasting), then you don't need the
experimentation of Scrum. If you are certain your market hypotheses are right,
then you don't need the experimentation of Lean Product.

------
thirdstation
I am trying to reconcile these two statements made by the author:

1) "[Scrum] provides a framework that prioritizes delivering real, working,
business-quality software sprint after sprint."

2) "Scrum is engineering centric. Great companies are customer and product
centric."

So, with the second quote the author sets up this dichotomy between Scrum and
being customer-focused. But to me, the first quote (which is accurate)
positions Scrum as supremely customer-focused. Meaning, to deliver value as
soon as possible, as much as possible.

I think the author fails to make any persuasive arguments about Scrum. His
arguments about what Scrum is not are inaccurate. I was hoping for some useful
counter-perspective.

~~~
k1w1
I don't think that those two statements are inconsistent. The OP is not
disparaging scrum, but rather pointing out that when organizations embrace
scrum as a religion they lose sight of the fact that scrum is a tool for
engineering - it is not the complete answer to making good products.

Scrum provides a tool that allows you to run your engineering org like a
factory production line - it is efficient and (sometimes) predictable. But
just having a good production line doesn't mean that you are going to build a
product that customers want to buy - only that you will build something
faster.

------
BenLinders
I agree that most of scrum is focused on engineering. The product owner is
where it focus lies on product. I've seen companies where product managers
became better in having product delivered on time when they adopted the
Product Owner role with scrum teams.

@BenLinders

