Here’s an article that just drives me nuts: Using Agile Scrum to Manage Developer Teams. The problem I have with this article is that it is just crazy bad in its use of language and ignorance about the fundamentals. Here are some examples:
Agile Scrum
This is not a thing. Agile is a philosophy of doing software development. Scrum is a particular instance of Agile. Saying “Agile Scrum” is kind of like always saying “furniture table” instead of just “table”. It shows a pretty fundamental gap in the writer’s knowledge.
As with any software development lifecycle (SDLC) framework…
Scrum is definitely not an SDLC. Scrum is a framework (and the author uses the term correctly a little earlier in the article) but is deliberately missing most of the details that would make it an SDLC. It is designed to be incomplete instead of complete. SDLC’s are meant to be complete solutions for delivering software. Scrum shows you the gaps and exposes the problems you have delivering products but doesn’t tell you how to fill in the gaps and solve the problems.
Next, the article mis-quotes Scrum.org by incorrectly capitalizing Product Owner and Scrum Master. And in some sort of ironic error, puts “Scrum master” in quotes. Yikes!
The conclusion of the article about when you might choose not to use Scrum is also a bit mis-guided. There are lots of organizations successfully using Scrum in highly regulated environments: medical, banking, government, etc. Some of them are even my clients! I would be happy to provide direct references if needed.
Finally:
Does your team work remotely? Despite advances in video technology and online collaboration tools, the requirements for structured daily contact makes Agile Scrum tough to implement successfully for virtual teams.
Yes, remote work is bad with Scrum. But it’s also just plain bad. Don’t do it if you can avoid it. All that Scrum does with a remote team is show you just how bad it really is.
Affiliated Promotions:
Please share!
Forgive me, please, but I love this post. It is not often I get to see Mishkin let his emotions loose…and even in this state he is thoughtful, interesting, and painfully correct.
Hi Mishkin!!
So much discipline: you really held back and pointed out a few big flaws. Sadly, most readers of that article will never make it to this blog, they have buried the comments so well on that page!
I was struck by the important philosophical inconsistency: the big blunder of “use … Scrum to manage teams.”
Scrum is, as you mention, incomplete. This is because each team must fill-in-the-gaps for their context BY SELF-ORGANIZING to become more effective. Scrum is not a tool to “manage” a team but to teach a team to manage their own work so managers can get back to removing obstacles and enhancing communication.
Anyone who continues to apply traditional management methods (or worse, micromangement) to a Scrum team will create distructive dissonance within and around the team. For example: a team may have to choose between succeeding together (which makes business sense & breeds organic process improvement) or succeeding personally in a “bell curve” competitive ranking scheme (which ensures a bigger bonus cheque). When asked to do both (an oxymoron) weird and unpredictable behaviours emerge (it’s a complex human system, it adapts!) These might include “necessary” compromises that suck the life out of Scrum, and/or conflict with “the boss”. In all cases, job satisfaction suffers and retention and/or performance suffer.
Niels Pflaeging has made the case elegantly and succinctly for “the death of ‘management’ ” in his book Organize for Complexity, due out in English any day now. Until then, some of the book’s material is covered in his whitepaper, found here: (in multiple languages)
http://www.betacodex.org/node/1300
It packs a punch with a few words and helpful mages. Enjoy!
Deborah Hartmann Preuss