
Mind the Burndown, Comrade – Scrum Propaganda Posters - alwaysunday
http://visage.co/scrum-youll-love/
======
nickbauman
Agile works as a bottom-up methodology only. Once the PMs get a hold of it,
they figure out a way to wire their TPS-report-"did you get the memo on that?
It needs a cover sheet."-thinking into it so that it's effectively destroyed.
Scrum is the goto agile methodology for these people to wreck, and wreck it
they have.

Consider: My local chapter of the Project Management Institute has ~7000
members. Are the even 7000 competent people in the area that can act as leaf
node workers for these folks? I doubt it.

------
fsloth
Philosophically I find it hilarious these posters supporting a particular
agile flavor are using the style of the ultimate waterfall command and control
system which certainly was not based on reciprocal communication and immediate
feedback loops :D

Love the hands in the "all blockers" poster.

------
Spearchucker
I'm pretty ambivalent about it, because after 25 years of seeing methodologies
come and go and come again with the same ideas wrapped in different names I
believe projects that succeed, succeed in spite of the chosen methodology,
rather than because of it.

[https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e8...](https://www.wittenburg.co.uk/Entry.aspx?id=99bb5987-e08d-4e81-974d-daa5e07c0d5f)

~~~
marktangotango
From my experience I've found that scrumm holds back good, fast developers
because they focus on only doing their share in a sprint, when they could
rocket ahead and be pounding on the backlog.

How can you keep your best developers motivated and busy in an agile/scrumm
environment?

~~~
tirrellp
Scrum focuses on "systemwide" optimization where the "system" is the
development of an increment of a software product from concept to completion.

Letting a good developer "rocket ahead" optimizes for that developer
(localized optimization) but not for the complete system (global
optimization).

A more "global" optimization of that developer's time and energy, since they
can do twice the work in half the time, is to mentor, support, teach, and
otherwise spend their energy helping EVERYONE get to their level. Since they
can and will get their "portion" of the work done quickly, they have bandwidth
to add values in other ways as a force multiplier.

From my experience people like this end up in "lead" or "architect" roles.

[http://www.payton-consulting.com](http://www.payton-consulting.com)

~~~
mempko
Scrum requires that all team members are already competent and fast. Don't let
this consulting company fool you.

~~~
trhway
>"Scrum requires that ..."

Interesting trait of scrum - whenever there is scrum related discussion the no
true Scotsman fallacies immediately pop up. By the way, scrum is actually a
methodology to get something out of non-delivering teams. For everybody else
it is just like throwing sand into their engine's cylinders.

~~~
tirrellp
I would agree with that. When a company brings me in, the first question I ask
is "What is the problem you are trying to solve?"

Most of the problems that management _think_ are because of the team are
mostly (80%+) caused by people/processes/habits/cultural issues UPSTREAM of
the team.

In other words, shit rolls down hill.

------
matthewmacleod
I appear to be in the minority as an engineer who rather enjoys Scrum – we've
been delivering working features to customers at a steady pace; they've been
involved in the feedback process; we've managed to improve the process through
the retrospectives; the burndown charts etc. have been useful in understanding
where bottlenecks are.

I guess the key, like anything else, is not overcommitting, not having
interfering management. I suspect that applies to any PM methodology, though.

------
eterm
I can't tell if these are mocking or not? (Even down to capitalisation of
SCRUM).

Personally I think agile is best thought of as a broad church of methodologies
rather than anything concrete to adhere to, and especially I think the sprint
approach isn't always suited to business needs.

But a generally agile approach I think is good, and I think daily stand-up
meetings are good for communication even without sprints or a maintained
backlog.

~~~
kylequest
It's a pretty big fail when people wait until the daily stand-up to
communicate. It's better than not communicating at all, of course :-)

Either way, daily stand-ups are the worst thing about scrum especially when
they are hijacked by PMs. I'm yet to meet a develop who'd look forward to
stand-ups. I know they exist somewhere :-)

If you are curious about what other people (you don't talk to a lot) are
working on then Hubot is a good solution. Hubot has a great plugin to let you
share what you are working on without having to deal with stand-ups.

~~~
blazespin
There are different types of communication. Some things need to be
communicated to the whole team, something you don't want to be doing more than
once a day.

The one thing about stand ups that I find to be a profound waste of time is
reporting what you've done. Isn't that what SVN / GIT / JIRA / etc is for?

~~~
kylequest
Sadly most of the time stand-ups turn into glorified status reports for
managers/PMs :-( Stand-ups are meant for developers (carried out for
developers by developers). If devs don't get enough value out of them (to
offset the "distraction factor" they introduce) they shouldn't exist.

SVN/GIT commit messages and Trello/JIRA notifications sent to
Slack/Hipchat/YourInternalIrcServer are a great way to aggregate all that
information. You can write a Hubot/YourOtherChatBot plugin to gather and
summarize that information to make it even easier to track.

By the way, with Hubot you can just say "What everybody is working on?" and it
will show you the status for everybody.

------
trhway
after a year and half of thorough, to the letter, BigCo company-wide (only
super important/critical projects were excepted :) push of Scrum/Agile/Lean
down our throats and as result, in particular, work on our complex multi-team
project slowing down to a crawl and failing to release while everybody was
super busy with their mouths foaming and not being able to catch a breath,
about a year ago everybody in our BigCo almost instantly forgot these words
and about associated reports/tools/meetings/bla-bla-bla - Christmas magic i
guess. The only thing reminding that it wasn't just a nightmare dream, that it
was real is that our team's weekly status meeting is called "scrum meeting" :)

Beside other failures, one of a major failures of scrum in real environment
(not toy building fun exercise during a scrum course) is failure to address
the multi-team environment of real multi-layered projects. A team would
usually have dependencies and dependents. In scrum/sprint process a team would
try to avoid committing to anything with unsatisfied dependencies which
results in that any vertically dependent feature would take a series of
sprints, much longer than in non-scrum environment. Add to that complete
impossibility of iterations/adjustments on the feature - team A delivers to
team B and team B has no chance (until a sprint much much later in the
release, i.e. never) to have team A to do an additional iteration upon the
delivered changes desired as a result of the actual usage by the team B. It is
expectably much worse when it comes to 3 layers/teams (like
persistence/framework, business logic, UI).

I specifically asked consultants (during 2 different courses by 2 different
consulting companies and at work) about dependencies management in scrum, and
blank-facing was their answer. Think about it - software development
methodology without addressing inter-component/layer/team dependencies.

------
faragon
Agile methodology reminds me Asimov's "Reason" (short story), in this case,
poor management methods masking the whip behind a ridiculous religion/faith
plus some "gamification".

~~~
mempko
Scrum comes before "Agile" was invented. Scrum has more connections with lean.
But scrum is agile too.

~~~
faragon
s/Agile/Scrum/g

~~~
mempko
Agile manifesto was published in 2001? Notices I am using a capital A here.

