
Scrum Thinks People Are Stupid - rizumu
http://nih.blogspot.com.es/2012/03/scrum-thinks-people-are-stupid.html
======
marcusf
There's a lot to take offense to in this article and I wonder if the author
has any practical experience with working within agile constraints or if he
just picked up a book and didn't like it. For example, "In theory, developers
are supposed to be interchangeable in agile/scrum". I've never seen that
articulated in any agile literature. To the contrary, the agile manifesto puts
"individuals and interactions" on, literally, its first line. It's ALL about
people and finding ways for people to contribute to delivering working
software.

Processes at their best are self-imposed sets of constraints that are
empirically found to lead to better software (for whatever axes of 'better'
makes sense for your team - faster, feature richer, higher quality, etc.)
Scrum gives you a baseline set of rules to abide by. Any team who've worked
with Scrum for more than a few months will start to tweak, add to or remove
from these rules. If they're any good, they'll measure their tweaking and see
what works and what doesn't. This is the whole point of having a
retrospective.

As another example, if you want to include quantifiable performance bounds in
your stories, do so. We work Scrum-ish, and we have a set of QA steps for
every story implicit in its delivery (works across supported browsers, feels
fast, immune to common security errors, etc). We test for this, and we demo
it, but it's not articulated in every story. It's implicit in our work.

~~~
rbarooah
If they weren't able to adjust their rules to become effective before they
adopted scrum, why should they be able to do so afterwards?

~~~
marcusf
Who are 'they'? It might be that teams come from a more rigorous environment
with project plans and imposed rules and were never given the chance to
experiment with how they create software, or they might come from an
environment without any rules whatsoever. Both work for a lot of companies,
but usually you try something like Scrum because they don't.

A lot of times it requires a change of mindset where managers and executives
have to relinquish control and trust developers to do what's right. That might
not be the easiest thing in the world.

------
sqrt17
I'm not a hardcore scrum proponent, but "Scrum compensates for lack of X, and
hence works less well for people who have X" is not necessarily true. Being
able to swap the product backlog can help correct planning errors, but it
doesn't make planning skills obsolete. What it does, though, is to assign an
exact responsability for planning errors (sunken costs through unneeded
functionality are the product owner's fault, changes in plans that are not
realized yet are not realized).

Many important things in a Scrum process can be achieved through the
definition of what is "done". If you know for sure what parts need to be
optimized, then optimizing them may be part of getting them "done". If you
don't, then there is no point in pointlessly optimizing the whole system where
only a fraction of these optimizations will be useful and the rest of them
just make the code less readable.

------
Argorak
I am beginning to think that even small teams should be split in two groups:
feature and maintenance (even if this means a 3person/1person split). I often
see the need for internal tooling and polishing that is never met, because
there is no one assigned to it, everyone has to build features. Scrum is a
great tool for feature-driven development. Kanban is a great tool for
continuous tasks. Why not have one team doing Scrum for features and one
Kanban for maintenance? I often see that split in companies that have
developers and a separate admin group, why not do that for developers
internally?

This would eliminate the "optimizing considered harmful" point, because there
is group that can work on continuous improvement.

~~~
Deestan
I'm imagining that will cause unpleasant friction between the two.

The Feature group get all the credit and are heroes for solving things
quickly, while the Maintenance group have to clean up their bloody mess
without getting any recognition.

~~~
Argorak
I think thats a problem in general. I've seen companies where the admin team
was highly regarded, although all they did was (good) maintenance work. But
they were also good in talking about this in a way of "this and that got
better _in general_ because, over the last weeks, we worked on improving _this
and that_ ". The idea of actually naming the people that have to do
maintenance also gives them the possibility of talking about it in context of
their work.

------
jrabone
Totally agree. The whole Agile farce is about treating programmers as idiots
who'll end up putting a flight simulator in your spreadsheet unless you nail
them to a task card, and program managers as drooling morons who spin a wheel
of fortune to pick the direction.

Now, there are some companies who DO develop like that - I'd venture to
suggest they aren't the successful ones.

Hire better developers, hire better managers, incentivise the lot of them to
care about the thing they're building. Ditch the Agile crap, it's about
minimising the damage incompetent people can do to your project, while
compromising the best people until they too are just mediocre.

~~~
marcusf
Not to be confrontational, but I'd wager that you've never developed in an
agile context for any longer period of time?

~~~
jrabone
The last 7-odd years in my 20 year career, 50 (very smart) people, multiple
teams. Long enough to watch it spread through a company, with the attendant
disruption, only to be revised away as the realisation set in that, like so
many silver bullets, it was only nickel-plated at best.

Now I'm watching as another 'Agile' team pushes 6x4 cards around (at least
they've managed to adopt a half-assed electronic version of that). Sadly
there's no methodology that'll save them, but that's a different problem.

~~~
marcusf
Then I don't get the hostility displayed in your original comment. Of course
it's not a silver bullet, it's a set of tools for managing development
together with a philosophy of work.

YMMV but we've used several agile ideas (for example iterations,
retrospectives, stop-the-line) to great effect to reign in scope creep,
increase quality, reduce overtime and make people happier, overall.

------
peteretep
The thrust of this article seems to be that Scrum is designed to work in the
real world, rather than in a made up utopia the author admits doesn't exist.
Great.

~~~
rbarooah
I think the authors argument is not that Scrum isn't better than many other
approaches, just that it may have the downside of limiting further process
development when teams are healthy.

------
adrianhoward
The article doesn't really resonate with my experiences of working with good
Scrum teams.

It does, however, sound very much like some organisations I've been involved
with who have adopted one or two of the Scrum practices, but haven't really
understood the core of the process.

Scrum teams should be relentlessly focussed on improvement.

It's a deliberately minimal process which can help in of itself since
everything outside of that process is open to question and change.

Even ignoring that of the five regularly scheduled events in Scrum two,
arguably three, are specifically focussed on self-assessment and improvement
(Sprint Review and Sprint Retrospective are the definite ones. I'd also argue
for the Daily Standup/Scrum because of the focus on obstacles in the way of
progress).

Now there are certainly criticisms that I have of Scrum - but thinking folk
are stupid and not fixing problems are very definitely not on the list. If a
team does not focus on improving their process every sprint then _they are not
doing Scrum by definition_.

------
saool
Then Scrum is smart.

