Scrum is a Cancer, a Zombie, Dead, Whatever
Installing scrum is simply a matter of finding the right wrench to pound the correct screw.
Santiago Valdarrama's ten bullet point burst is the latest invective aimed at disparaging Scrum. Some of his bullet points are on target. Others aren't much more than flashes of frustration directed at the vagaries of human nature and just how galling they can be to those accustomed to machine precision and the sublime perfection of ones and zeros. There's nothing new in this list. I've heard them all before, heard them for years, and they're likely to be voiced by an ever growing tribe of maverick/lone wolf/prima-donna technologists for years to come. I've learned long ago it's futile to rebut nano-gripes like this. The sloppy world of human endeavor will always be at war with perfect optimization.
Nonetheless, when something like this gets legs on the InterWebs, it's a good opportunity to consider the feedback and take stock what's being said.
My scrum mastering days are, thankfully, behind me. I leave that for the up-and-coming wave of Agilists. It's a required tour of duty where scrum masters and future Agile coaches can be expected to gain the essential experiences needed to master the fundamentals and, eventually, extending that knowledge into finding which methods, techniques, and tools are best suited for any particular team, project, or organization.
Or not.
The coaching field is beyond saturated. Everyone is on the "I'm a coach" trolley. Maybe the coach trolley passengers put coin in the box so they can claim rights to a seat. Maybe they're freeloading on the coach-tails of everyone else and plan to ride for as long as it keeps moving along the track. The ubiquity of "coach" is replacing "consultant," as is its non-specificity and blandness.
I could write the same thing about scrum masters. While it's getting easier to find "qualified" or certified scrum masters and coaches, It's getting harder to find good scrum masters and coaches. It's ever more common that scrum masters and Agile coaches have next to zero experience with coding or working out solutions in complex technical environments. This exacerbates the problem. Lacking this experience makes it much more difficult - but not impossible - to bridge the gap between what process leadership is asking the technical knowledge workers to do and how technical types view the world. So when an inexperienced coach or scrum master with a recipe book is assigned to work with the Santiago's of the world, the results will be mediocre at best. A lot gets lost in translation. I put this failure at the feet of scrum masters and coaches.
Of all the things in Mr. Valdarrama's post, this particular comment shines through like sunlight splitting storm clouds:
The result was always the same: It didn't work. (Emphasis added)
There's a gold mine in that statement. Hundreds of potential questions left unanswered. Questions that will reveal a mountain of shortcomings - with management, with scrum masters, with trainers and coaches, and, yes, even with Mr. Valdarrama - and missed opportunities to improve. Here are just a few that come to mind:
Were the expected results defined and communicated at the beginning?
Can you describe the "sameness" that characterize the results you did get?
Were the results always the same? Were there any changes, however seemingly insignificant, that worked to make your workday a little easier?
How do you know "it didn't work?" What specific behaviors, patterns, processes, methods, and tools came up short and why?
What metrics are or have been used? Are they being used correctly and effectively?
Were you clear on what was expected to change, with your behavior and with the team?
What was the level of trust you and the team had with the scrum master? The trainers and coaches? With management?
Were those involved at the process leadership level responsive, or were they reactive?
Can you describe the quality of the communication between you, your team, and process leadership? Describe as many feedback loops as possible. Were you listened to? Were you speaking up?
Based on Mr. Valdarrama's list, I can venture a good guess as to the answers to some of these questions. It's the answers to these questions that always seem to leave those most in need of changing decidedly uncomfortable with and resistant to the changes. This, too, is on the scrum masters and coaches to figure out and resolve.
Underlying the entire effort for implement any Agile methodology is a goal to make the process as invisible and automatic as possible. In other words, the primary objective of the scrum master or Agile coach is to make their job unnecessary. This goal is never fully achieved, but in environments where Agile "is working," it can seem like it has. Agile is simple, but mastering it is hard. The hard part is the responsibility of the scrum masters and Agile coaches. And the knowledge worker's feedback is the primary source of information for how it's going.
If you have any questions, need anything clarified, or have something else on your mind, please use the comments section or email me directly.
Photo by Einar Storsul on Unsplash