Dear Agile, Your Gurus Suck
Like any engineer, I've had some unproductive conversations on the internet, but I caught a grand prize winner the other day, when Agile Manifesto co-signer Ron Jeffries discovered Why Scrum Should Basically Just Die In A Fire, a blog post I wrote months ago.
possibly most wrong article about scrum ever written. no comments allowed. :( http://t.co/em5vorGlnT&mdassh; Ron Jeffries (@RonJeffries) February 18, 2015
I tried to have a civil conversation with him, but failed. It was such an uphill climb, you could consider it a 90° angle.
I answered Mr. Jeffries's points, but he ignored these remarks, and instead reiterated his flawed criticisms, at length, on his own blog.
If you're the type who skips drama, I'm sorry, but you want a different post. I wrote that post, and published it on my company's blog. I got some better criticism of my anti-Scrum blog posts, and I responded to it there. I also heard from Agile luminaries like Mr. Jeffries, but unfortunately, none of the insightful criticism came from them.
Because of Mr. Jeffries's high profile, I have to respond to his "rebuttal." But he failed at reading my post, and again at reading my tweets, so my rebuttal is mostly going to be a Cliff's Notes summary of previous remarks.
But let's get it over with.
It's Not Just Me
RSpec core team member Pat Maddox said this after seeing the Twitter argument:
@gilesgoatboy same dude who said "I want to learn RSpec" at agile conf, Ward recommended pairing w/ me, dude said "I'll find someone else"— Pat Maddox (@patmaddox) February 19, 2015
@gilesgoatboy of course, he couldn't have known that I was on RSpec core at the time. But I think a Ward recommendation ought to be solid...— Pat Maddox (@patmaddox) February 19, 2015
"Ward" is Ward Cunningham – another Agile Manifesto co-signer, the inventor of the wiki, and one of the creators of Extreme Programming. I'm not a huge fan of methodologies, but in my opinion, Extreme Programming beats Scrum. Even if you disagree, for people in Agile, yes, a Ward Cunningham recommendation ought to be solid, every time.
Here's an anonymous email I got from somebody else who witnessed the flame war:
We had a local “Scrum Masters” meet up here in [my home town] maybe 5 years ago. At the time my wife was trying to figure out a career transition for herself and a friend recommended becoming a Scrum Master. I’d been doing Scrum for a couple of years and I was friends with the organizers so I sent her over to that meet up. She came back and told me it was an epic fail and Ron Jeffries was the most unprofessional, rude speaker that she’d ever seen. In hindsight, it was probably a good thing that it turned her off Scrum completely.To his credit, Mr. Jeffries starts out his blog post by acknowledging that he could have been more polite with me:
Ron Jeffries was rude to most of the people asking questions about how to implement Scrum. One person in particular mentioned having an offshore team and some of the challenges involved in making Scrum work with a geographically distributed development team.
Ron Jeffries’ response was “Fire all the folks not in your office. If you’re trying to work with people offshore, you’ve already failed. Next question."
Even if this was 2010 and the prevailing thought in our industry was that offshoring and remote work didn’t work, his response was just tactless. He had similar short, rude responses to nearly every question that night and it resonated negatively with everyone there. I don’t think they ever asked him back there again.
My first reaction was not the best. I should have compassionately embraced Giles’s pain... But hey, I’m a computer programmer, not a shrink.This "apology" implies my expectation of basic common courtesy is equivalent to mental illness.
Mr. Jeffries then stumbles through several failures at basic reading comprehension.
Basic Context Fail
We'll start simple. In my post, I wrote:
I've twice seen the "15-minute standup" devolve into half-hour or hour-long meetings where everybody stands, except for management.I then gave examples.
At one company...Mr. Jeffries used the singular every single time he described my teams, my projects, or the companies I worked for:
At another company...
Things were not going well in planning poker and Giles’s team did not fix it...So he didn't even get that when I said I was talking about two companies, I was talking about two companies.
Giles’s team’s Product Owner...
Why didn’t the time boxes do that for Giles’s team?
...I’m sad that Giles suffered through this, and doubtless everyone else on the project suffered as well...
And I’m glad Giles remarks that Scrum does not intend what happened on his team. It does make me wonder why this article wasn’t entitled “Company XYZ and Every One of its Managers Should Just Die in a Fire.”
Advanced Context Fail
In fairness, you only had to miss the point of four or five paragraphs in a row to miss that detail, and my post contained many paragraphs. However, the point of those paragraphs was that you see Scrum practices decay at multiple companies because Scrum practices are vulnerable to decay. They have a half-life, and it is brief.
Mr. Jeffries missed this point. He also failed to recognize hyperbole which I'd thought was glaringly obvious. I said in my post:
In fairness to everybody who's tried [planning poker] and seen it fail, how could it not devolve? A nontechnical participant has, at any point, the option to pull out an egg timer and tell technical participants "thirty seconds or shut the fuck up." This is not a process designed to facilitate technical conversation; it's so clearly designed to limit such conversation that it almost seems to assume that any technical conversation is inherently dysfunctional.These egg timers really exist. I added "shut the fuck up" to highlight the ridiculousness of waving an egg timer at somebody in order to make a serious business decision. Somehow, however, what Mr. Jeffries took away from those words was that I actually, in real life, attended a planning poker session where somebody told somebody else to shut the fuck up.
It's ironic to see conversation-limiting devices built into Agile development methodologies, when one of the core principles of the Agile Manifesto is the idea that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation," but I'll get to that a little later on.
For now, I want to point out that Planning Poker isn't the only aspect of Scrum which, in my experience, seems to consistently devolve into something less useful.
Quoting from his post:
What’s going on here, and why is planning poker being blamed for the fact that Giles seems to be surrounded by assholes?I don't even get how Mr. Jeffries took that literally in the first place.
...People do cut their fingers off with the band saw, and I guess people do get told to shut the fuck up in a planning poker session.
Should not happen. Should never happen...
No one in Scrum wants abusive behavior...
Things were not going well in planning poker and Giles’s team did not fix it. That makes me sad, very sad, but it doesn’t make me want to blame Scrum. Frankly even if Scrum did say “Sometimes in planning meetings tell people to shut the fuck up”, that would be so obviously wrong that you’d be a fool to do it...
someone with a pair could take an individual aside and tell them not to be a jerk.
But I'll rephrase my point: building conversation-limiting rules into planning poker contravenes the basic Agile principle that face-to-face conversation is important. Additionally, these conversation-limiting rules provide an easy avenue through which the Scrum process can devolve into something less Agile – and also less productive – and I believe Scrum has several more design flaws like that.
Since Mr. Jeffries equated asking for basic courtesy with asking for free therapy, it's probably no shock that his condescending tone persists even when he acknowledges my points. I pointed out naming errors in Scrum, and he responded:
I’m not sure I’d call those “conceptual” flaws, as Giles does, but they’re not the best possible names. Mary Poppendieck, for example, has long objected to “backlog”. Again, I get that. And I don’t care...This is an adult, intending his words for public consumption. Even when he sees I'm right, he dismisses my critique in favor of his own critique, even though he also acknowledges that his own critique probably doesn't exist.
Giles objects to velocity. I could do a better job of objecting to it, and who knows, somewhere in here maybe I have, but the point is a good one.
Still, this is the apex of maturity in Mr. Jeffries's post, so I'll try to be grateful. We do at least agree "sprint," "backlog," and "velocity" are flawed terms. If a civil conversation ever emerges from this mess, it might stand on that shred of common ground.
But I'm not optimistic, because Mr. Jeffries also says:
For my part in [promoting the term "velocity," and its use as a metric], I apologize. Meanwhile you’ll need to deal with the topic as best you can, because it’s not going away.Apology accepted, and I'll give him credit for owning up to a mistake. But his attitude's terrible. If velocity's not good, you should get rid of it. And I don't need to deal with it, because it absolutely is going away.
Scrum's a fad in software management, and all such fads go away sooner or later. The most embarassing part of this fracas was that, while my older followers took it seriously, my younger followers thought the whole topic was a joke. Velocity is, in my own working life, less "going away" than "already gone for years." My last full-time job with Scrum ended in 2008. Since then, I've had to deal with velocity for a grand total of four or five months, and they weren't all contiguous.
Mr. Jeffries continues:
Giles has gone to an organization that pretty much understands Agile...I'd agree Panda Strike "pretty much understands Agile," but that's why we regard Scrum with skepticism. We also understand several flaws in Agile that I'd guess Mr. Jeffries does not. And it should be obvious I already had "a fun way to be productive" before Scrum got in my way. Why else would I dis Scrum in the first place?
I’m not sure just what they do at his new company, Panda Strike, but I hope he’ll find some good Agile-based ideas there, and I think probably he will. More than that, I hope Giles finds a fun way to be productive...
For the record, at Panda Strike, we do use some Agile ideas, but that's a different blog post.
I'm publishing this on my personal blog, not the Panda Strike blog, because this is my own social media snafu. On the Panda Strike blog, I've gone into more detail about Agile and Scrum, our skepticism, the compromises we'll sometimes make, the flaws we've found in the Agile Manifesto, and the things we still like about it (and, to a lesser extent, Scrum). That blog post is more balanced than my personal attitude on my personal blog.
My post on the Panda blog is a response to the coherent criticism I've received. Please do read it. I hope you enjoy it. But here I'm responding to incoherent criticism from a high-profile source. Sorry - the man has sixteen thousand Twitter followers, and every one of them seems to want to bother me.
Also, a point of order: I am not "Giles" to you, Mr. Jeffries. I am "Mr. Bowkett" or "Mr. Bowkett, sir." Those are your only choices. You don't know me, sir. Mind your manners, please, because I'd like to use my own without feeling put upon. And your repeated claim of being "sad" on my behalf would be creepy if it seemed plausible, but it does not. It reads as insincere, so maybe you could just stop.
My blog post argued that Scrum practices decay rapidly into non-Agile practices. Weirdly, most of my critics have repeatedly stated that my argument was not valid because I provided examples of Scrum practices which had decayed into less Agile versions.
Mr. Jeffries was one such critic. During my Twitter argument with him, I reminded him of this point repeatedly. Here's one of several such reminders:
Even after this exchange, he continued to hammer the idea that my argument – that Scrum's Agile practices decay rapidly – is invalid because the decayed versions of these practices are not Agile.
Mr. Jeffries's Terrible Reading Comprehension May Not Be A Fluke
One of Mr. Jeffries's Twitter followers, a Scrum consultant named Neil Killick, wrote a blog post criticizing my post also:
A controversial blog post... suggests that Scrum is broken for many reasons, but one of those reasons cited is that the 15 minute time box for Daily Scrum (aka Standup) is too short to allow for meaningful conversations, and promotes a STFU culture.This is false.
The phrase "shut the fuck up" occurred in a discussion of planning poker, not daily standups. This concept of "a STFU culture" is Mr. Killick's invention. The time-boxing in standups might undermine the Agile principle that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation" – it's certainly odd to find this "inhibiting conversation" theme in an "Agile" methodology – but a major theme in my post was that standups frequently go too long.
Having failed to grasp this, and possibly without ever reading my blog in the first place, Mr. Killick then explains how to solve a problem I never had:
IMO, in the situation the author describes, Scrum has exposed that perhaps the author and his colleagues feel their time together in the morning is so precious that they resent ending it artificially.So, recap.
As the Scrum Master in this situation I would be trying to find out why they are not able to continue talking after the Daily Scrum? Perhaps they struggle to find the time or will to collaborate during the working day, so being forced together by the Daily Scrum gives them an opportunity that they do not want to cut short?
I write a blog post about how Scrum's a waste of time. I get two blog posts defending Scrum. Neither of the individuals who wrote these posts showed enough respect for my time to read the post they were responding to. Both of them say inaccurate things about my post. Both of them then offer me advice about how to solve problems I never had. And this is their counterargument to my claim that Scrum is a waste of time.
A Quick Defense Of Some Innocent Bystanders
Many Scrum defenders have said things to me like "if your company had a problem with Scrum, it was a messed-up company," or even "if your team had a problem with Scrum, they were incompetent."
On behalf of my former co-workers and former managers, fuck you.
One of the companies I mentioned was indeed very badly mismanaged, yet I worked with terrific people there. There were some flaws at the other, too, but it was much better. There were plenty of good people, nothing really awful going on, and Scrum still decayed.
(In fact, standups decayed to a similar failure state in each case, even though the circumstances, and the paths of deterioration, were very different.)
I saw these problems at two companies with a serious investment in Scrum, and I saw echoes of these problems elsewhere too. It's possible that I just fell into shit company after shit company, and the common theme was pure coincidence. But I doubt it. And if your best argument relies on coincidence, and boils down to "maybe you just suck," then you're not coming from a strong position.
Is that even an argument? Or is it just a silencing tactic?
The first time or two that I saw Scrum techniques fail, my teams were using them informally. I thought, "maybe we should be using the formal, complete version, if we want it to work." The next time I saw Scrum techniques fail, we got official Scrum training, but the company was already being mismanaged, so I thought, "maybe it doesn't matter how full or correct our implementation is, if the people at the top are messing it up." The next time after that, management was better, and the implementation was legit, but we were using a cumbersome piece of software to manage the process. So I thought, "maybe Scrum would work if we weren't using this software."
Eventually, somebody said to me, "hey, maybe Scrum just doesn't work," and it made more sense than any of these prior theories.
And Scrum's answer to this is "maybe you just suck"?
Valid Critiques Addressed Elsewhere
As I said, I got better opposing arguments than these, and I addressed them on the Panda Strike blog. Check it out if you're curious.