Mind the Burndown, Comrade – Scrum Propaganda Posters

  • 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.

  • 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.

  • 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...

  • 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.

  • 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.

  • 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.

  • 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".