(2015-03-04) Bowkett Jeffries Scrum Argue

Sept'2014: Giles Bowkett on Scrum. Scrum, the Agile methodology allegedly favored by Google and Spotify, is a mess... Consider Story Points... If it had a name, this informal (Planning Poker) game would be called something like "the person with the highest status tells everybody else what the number is going to be.".. Planning Poker isn't the only aspect of Scrum which, in my experience, seems to consistently devolve into something less useful. Another core piece of Scrum is the Stand Up Meeting... I've twice seen the "15-minute standup" devolve into half-hour or hour-long meetings where everybody stands, except for management... At this second company, virtually everything landed in the parking lot, and it became normal for the 15-minute standup to be a 15-minute prelude to a much longer meeting... Scrum's ready devolution springs from major conceptual flaws... there's a fundamental cognitive dissonance between "sprints" and "sustainable development," because there is no such thing as a sustainable sprint... Another core idea of the Agile Manifesto, the allegedly defining document for Agile development methodologies: "working software is the primary measure of progress." Scrum disregards this idea in favor of a measure of progress called "VelocIty.".. Story points, meanwhile, are completely made-up numbers designed to capture off-the-cuff estimates of relative difficulty. Developers are explicitly encouraged to think of story points as non-binding numbers, yet velocity turns those non-binding estimates into a number they can be held accountable for... If you're tracking velocity, your best-case scenario will be that management realizes it means nothing... I don't think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: "business people and developers must work together." Why are we supposed to think developers are not business people?.. The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense. Well-written text very often trumps face-to-face communication... In addition to defying logic and available evidence, both these Agile Manifesto principles encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points. People are happy to treat these workers as adults and trust them to do their jobs. I don't know why this same trust does not prevail in the culture of managing programmers.

And a follow-up. I'm hoping to find out more, later, about what it's like when you're on a Scrum team and it actually works. To be fair, not every Scrum experience I've had has been a nightmare of dysfunction; I just think the successes owe more to the teams involved than to the process... Of all the criticisms of my blog post that I saw, literally every single one overlooked what is, in my opinion, my most important criticism of Scrum: that its worst aspects stem from flaws in the Agile Manifesto itself... The Agile Manifesto existed because developers and consultants had begun to recognize that many ideas in tech management were unnecessary, inessential historical relics... In many industries, companies just do not need to have synchrony or co-location any longer (Distributed Team). This is an incredible development which will change the world forever. Do not expect the world of work to look the same in 20 years. It will not.

Feb20: Ron Jeffries responds. My first reaction, instead, was to point out that almost none of the things Giles complained about are actually part of Scrum. They are, of course, things that people trying to use Scrum sometimes do... But still, is it unfair to expect the tool to be used wisely? Well, maybe not unfair, but perhaps unrealistic... I’ll wager Giles’s team’s Product Owner didn’t have that as their prime responsibility. I’d even put a little down that they didn’t have a real Product Owner at all. Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?... I no longer recommend velocity, which means that I also no longer recommend story estimation in points or other measures (No Estimates).

Mar04'2015: Bowkett addresses Scrum again, but not apparently responding to Jeffries. WaterFall used too much written communication, but Agile doesn't use enough. (He's a big fan of GitHub.)

Mar04'2015: Bowkett responds to Jeffries. 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.".. 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.