# data[].attributes.body
From Floyd May

# data[].attributes.attachment_link.readable_text
An interesting article criticizing TDD claims two cardinal wrongs in it:

1. TDD encourages micro-design over macro-design.

2. TDD is hard to apply in practice.

Towards the first point, TDD is receiving the blame for something that is unfortunately a pandemic in the software industry: few examples exist of macro-design and the process by which you learn how to do it. Learning macro-design is orthogonal to TDD, and nothing about TDD discourages macro-design. TDD simply encourages that those macro- and micro-designs are explicit (rather than implicit) and well-covered by tests.

The example in the article (and apparently in the guy's book, too?) claims that a TDD practitioner would build a skyscraper floor-by-floor. This is utter hogwash. It reflects an assumption that you would hire an inexperienced fool to design and build a skyscraper without proof that he is capable of such a task. A seasoned TDDer would naturally construct (tests first, of course) the large pieces: structural members, plumbing, wiring, staircases, elevators. The example that the first floor would be finished in its entirety, down to minute aesthetic detail, before the general structure is complete is a complete straw-man attack. A seasoned software craftsman wouldn't do that, and it's not TDD's fault that a fool would build the skyscraper in a foolish way, or that a fool would blame TDD for his folly.

Point number two, that TDD is hard to apply in practice, is again, weak. It's not that complicated: write a breaking test. Make the test pass by doing the minimum required. Then, refactor. This isn't a magic formula for "better code". Quality code still requires skill in software design - skill that TDD doesn't grant you by following the recipe. What the red-green-refactor rhythm does provide is the security that you haven't lied to yourself about the quality or coverage of your tests. Writing tests last is a very easy way to have spotty coverage of your code.

TDD doesn't promise to transform a drooling-on-the-keyboard noob into a fantastic software craftsman. What it does offer is a rigorous process for creating sufficient test coverage. Applying proper design skill while using TDD is still, intentionally, BYOB - bring your own brain.

# data[].attributes.attachment_link.title
An interesting article criticizing TDD claims two cardinal wrongs in it: 1. ...

# data[].attributes.attachment_link.description
An interesting article criticizing TDD claims two cardinal wrongs in it: 1. TDD encourages micro-design over macro-design. 2. TDD is hard to apply in practice. Towards the first point, TDD is receiving the blame for something that is unfortunately a pandemic in the software industry: few examples exist of macro-design and the process by which you learn how to do it.

# data[].attributes.attachment_link.readable_text
Floyd May's post showed up in my feed this week. His response to this article made me happy. You really should read it, then read this post by Ron Jeffries.

According to my memory of the two dozen or so attack pieces on Scrum and "Agile" I've read, each suffers from a faulty premise that undermines the credibility of their conclusion(s). That premise is:

"Agile" (or Scrum) can fail.

Given that "Agile" or Scrum can fail, then you may well work up a plausible argument as to why it has failed in a particular organization or team. However, I submit the following:

"Agile" cannot fail; it is not an agent capable of accomplishing or failing to accomplish anything.

And the corollary:

Scrum cannot fail; it is also not an agent itself but a framework used by agents to address complex, adaptive problems.

The agile manifesto is a set of values qualified by purpose statement, caveat, and described by 12 principled statements which list behaviors observed to not just correlate to success but cause it when practiced by... people.

I submit my own premises for your consideration:

Processes don't fail or succeed; people and organizations do.

And the corollary:

Frameworks cannot succeed or fail; people and organizations do.

Far from adding to the discussion, pieces like the one to which Floyd responded tend to make a sharp left turn at the outset by relying on the faulty premise mentioned above. They quickly go off road, bowling through a field of straw men and ad homimen attacks, all of which present real obstacles to making any meaningful progress in discussion. Incidentally, this is a wonderful primer on logical fallacies if you need a refresher.

To maintain credibility, each piece concluding that "Agile" and/or Scrum should be burned at the stake for the transgression of witchcraft and child sacrifice should consider explaining why there are so many well established case studies for the success of agile development cultures or organizations rocking their Scrum processes.

I like the way Jeffries puts the button on it in his post, so I'll steal it:

The challenge to [all of us], is to move beyond complaining about how screwed up ["Agile" and Scrum are] and start telling us things to do and things not to do, reasons to do or not do them, ways to know how we're doing.

Take us forward.

# data[].attributes.attachment_link.description
Floyd May's post showed up in my feed this week. His response to this article made me happy. You really should read it, then read this post by Ron Jeffries. According to my memory of the two dozen or so attack pieces on Scrum and "Agile" I've read, each suffers from a faulty premise that undermines the credibility of their conclusion(s).

# data[].attributes.body
Use the Google Doc to add your ideas and structure feedback to everyone else's!

# data[].attributes.attachment_link.title
Defusing the Myths of Failed Scrum Adoptions

# data[].attributes.attachment_link.description
Defusing the Myths of Failed Scrum Adoptions outline and brain dump. Feel free to write whatever; get your thoughts out and into this doc :)  Seems like the logic of failed scrum adoption tends to go this way: Ostensibly adopt scrum Fail to apply its principles, yet still “appear” to scrum (yes, ...

# data[].attributes.body
A dissenting opinion from Mike Sutton

# data[].attributes.attachment_link.readable_text
Street Cred

I've been in the software development industry for 21 years, using agile software development practices and principles for 14 years to actually deliver software. I've been working with Scrum for nigh on 11 years now and over the last 7 years I've coached over 120 teams and worked with over 1200 people.

With all this experience one thing has become clear - Scrum is broken.

How I assess the quality of any agile process

In theory, it seems all neat and tidy, but in practice it is abused, misused and generally ineffective. And I wonder why? I have seen many more poor implementations of the Scrum framework than successful ones. Actually - let me be explicit about how I assess the quality of implemented Scrum.

For me the success of *any* organisation's way of working - formal or otherwise - can be checked by simple questions that explore 5 fundamental concepts:

1. Value: Do we know the value we seek to deliver and are we consistently delivering the maximum value?

2. Flow: Do we understand how we reach that value and are we consistently reducing the time and/or increasing the ease by which we reach it?

3. Quality: Do we understand how good our product and workmanship needs to be and are we consistently and demonstrably achieving it?

4. Joy: Do we know what we collectively and individually need to be joyful and are we consistently meeting those needs?

5. Continuous Improvement: Do we know what we need to improve across VFQJ and are we demonstrably pursuing those improvements?

This simple list of questions invites great questions and other avenues of inquiry. It can function as both binary (yes/no) and range (how well are we doing). Works for me - mostly.

The non-recipe recipe

The fundamental reason why Scrum - as it currently exists - is broken is that it is a set of instructions, roles, rituals and artifacts that purports to *not* be a recipe. But almost every one takes it as a recipe and they follow it. But there is not enough there to be a an all encompassing recipe - there can never be.

The trouble is that, as a product , Scrum needs these illusions of completeness in order that it is taken seriously . By and large this has worked. In a world that is seeking silver bullets, Scrum has succeeded beyond it's practicality commands. It is by far the leading agile process framework in use today. It is in this illusion of completeness that lies the myriad of problems.

I remember in 2008 or 2009, there was a statement about there never being 'Scrum 2.0' - that Scrum was complete as it is. A perfectly chiseled gem that needed nothing removed nor added. This was clearly bollocks and persisted until politics and greed spilled over in the Scrum Alliance causing a bitter split between one of the co-creators of Scrum and the rest of the Alliance. All of a sudden a Scrum 2.0 in emerged in all but name.

When people have applied Scrum as a recipe the commentary from the unsympathetic dogmatics has been of the nature of:

"ScrumBut"

"Scrum shines a light on where you need to fix in your organisation"

"Scrum works, you just did it badly"

"You didn't have buy in"

Overwhelmingly any reasonable objection to some of the design flaws - and design flaws can emerge after the fact , exposed because of a change of operating environment etc - is often met with "those people are resistant, they are against change".

When Things Work, Its the Process - When They Don't, It's The People

I was first attracted to Scrum because I believed it would revolutionise the 'world of work'.

10 years on and I'm deeply disappointed. It did not revolutionise the world of work. Instead it got gobbled up by the Death Star of Work. If it had any early promise - for me it was that it would promote unprecedented collaboration between the people focused on delivering value and the people consuming it.

It may have had some success in some organisations - but this is far from 'changing the world of work'. A tiny street maybe, but never a world!

Of course a process doesn't do anything - people do. But how a process is designed has a huge impact on how readily the people take to it and how easily they can use it for the intended purpose.

More often than not I see a growing perception of infallibility of a process and an overwhelming blaming of the teams and individuals who play the Scrum roles. I feel deeply sad and angry at this.

Multiple single points of failure

Scrum Master, Product Owner and Team all collaborating beautifully - each with its clear role and responsibility - what's not to love?

Except that in *most* companies roles are so entrenched and siloed that this is the worst thing you could do - add more roles that become siloed. I hear you scream - "yes but the problem is the organisation and not Scrum" - and you are both right and wrong.

You are right because it is the organisation that is siloed and you are wrong because adding more roles when you *know* that most organisations are siloed is a dumb idea. That is like asking the morbidly obese to incorporate 3 more meals - however small - into their already dangerous diet.

Defined roles and a culture of collaboration are difficult bedfellows in any context. Especially in the context of trying to explore value through . Defined roles present an extra hurdle to overcome as we truly try and work together.

I have seen product development be disastrous for many reasons and the most common one is the single point of failure problem. Examples abound:

Overworked, overextended and ineffective Product Owners;

Scrum Masters left to single-handedly be responsible for improvement and impediments and latterly 'coaching' the team.

Teams that aren't to effectively own their tools, their craft or their collaboration.

Rituals become checklists vs achieved outcomes.

If I have to walk into another planning meeting that is schedul for 4 hours because Scrum said so - with the hope that somehow the information we don't have about the work we are expected to commit to will magically appear - I may have to shoot some unicorns.

Sprint after sprint, people do the meetings, the stand ups, the reviews etc. Scrum Masters - bless 'em - scour the communities for how to make their standups more interesting. Velocity is going up, teams are 7±2 people - things in the product backlog read like 'As a ..., I want...". The process seems to be working perfectly.

Yet software is still sitting on the shelf. Customers are not getting anything to feedback on. Developers still don't talk to customers.

Velocity becomes a stick to beat teams up

So velocity is not a defined part of Scrum - but it is a defacto part of Scrum implementations and it is both a arbitrary and crude measure of something.

Velocity doesn't mean what you think it means. It is about capacity,not speed It is *always* historic and never comparable to any other team and barely comparable to the same team over time. Sure it is a number and numbers can be compared - and that in itself is a problem because the human factors that help that number pop out are deeply flawed in most organisations.

Thankfully, the #NoEstimates movement is bringing some well deserved improvement in thinking in this whole area.

Of course you need a measure to know how you're doing. But velocity is a poor one. The emergent product and how well it is meeting the needs it was intended to meet is the ultimate measure - sadly many organisations are unable to get this - so they overdose on the measure that came with the process.

So narrow as to be quickly redundant

I was in the market for car seat a few years ago and was faced with buying something that was super specific for my son at his then age - he was 3 years old - or buying something that would support him till he was 8 years old.

Guess which I bought.

Scrum purports to be for 'new product' development - and I wholeheartedly agree. Except I don't know *any* teams that only do 'new product development'.

Even if a team that started out with only new product development - after their product reached its first users - their work mix would need to change. The fixes, bugs and so on that are different classes of work and different service responses change the mix. You could use Scrum to do these classes of work - but that would be akin to picking your teeth with a vacuum cleaner.

And this is just product related work - but what about the work everyone needs to do to continue to improve? The Human Development work? How about using Scrum for that?

If Scrum was the only thing you did - and many organisations adopt it as such - then it would get misused pretty quickly because getting shit done always trumps following a process. The question is how much of a hatchet job do we have to do to the process to get the shit done.

Scrum Shows You What Needs Fixing, It Doesn't Fix Them For You

If I had a penny for every time I've heard this, I would be rather rich.

Of course Scrum should fix something - everyone I have ever met in a company *know* what is wrong. They don't need a fancy methodology to tell them what is broken. They need something to help to try and address the problems and Scrum does not not address any of those.

If the problem that Scrum fixes is exposure of problems then it needs to be pitched as 'a framework for exposing what is preventing you from doing joyful, fulfilling new product development work'.

It ain't all bad.

I don't hate Scrum - I've just use it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep - no one would ever find it.

If you are using Scrum - I beg you to question it all. Ask yourself, your team, organisation and customers whether this is really helping you and what you are really trying to achieve. Don't even mention Scrum during that conversation - simply talk about 'how are we delivering what we seek to deliver" .

As with most things, all this can boil down to simple choices.

Do you choose to blindly follow a process or do you choose to adapt your own way of working that is focused on value and joy?

Good luck whichever you choose.
Photo by mikecogh

# data[].attributes.attachment_link.description
Street Cred I've been in the software development industry for 21 years, using agile software development practices and principles for 14 years to actually deliver software. I've been working with Scrum for nigh on 11 years now and over the last 7 years I've coached over 120 teams and worked with over 1200 people.

# data[].attributes.body
Ron Jeffries on the Subject

# data[].attributes.attachment_link.readable_text
Again today, I wake up to yet another report on Scrum's failings, this time from Mike Sutton, whom I much admire. Read his article here.

Now certainly Mike's list of Value, Flow, Quality, Joy, and Continuous Improvement represents a good way to assess whether an organization is "successful". Note that Mike includes "consistently delivering value" as part of this assessment.

Mike rightly points out that Scrum's tiny collection of roles, rituals and artifacts is not a recipe. He rightly points out that there can never be an all-encompassing recipe. I'm totally on board there. Mike also says, "almost everyone takes it as a recipe and they follow it". I have issues with that last.

First of all, I see little evidence that almost everyone takes it as a recipe, and absolutely no evidence that everyone follows the recipe. I visit many teams who call what they're doing "Scrum" and very few of them are in fact even following the recipe, if recipe it is.

Mike tosses in a paragraph about how the Scrum Alliance amounts to Scrum 2.0, together with some very mistaken history as to why there was a split. The split was certainly unfortunate, but it was not due to a split in dogma. And since the Scrum Alliance and Scrum.org both subscribe to the Scrum Guide, there is still no split.

And, of course, no Scrum 2.0 is a problem as Mike sees it, because he seems to think that some change to Scrum is needed. He says:

I don't hate Scrum - I've just used it long and deep enough to understand which bits I would throw away and which I would keep, what contexts I would use it in and which I would bury it so deep - no one would ever find it.

Unfortunately, Mike hasn't as yet written the part about what he'd keep and what he'd throw away. I hope he will: I'm much more interested in what works than what does not.

Take a look again at the article. Look at the abuses he describes, such as over-worked ineffective product owners, ScrumMasters left hung out to dry without support, teams who can't own their tools, craft, and collaboration. Those are all abuses. I repudiate each and every one of them with all my heart.

And Scrum surely does not recommend any of those. It's quite easy to find absolute repudiation of those ideas in the Scrum writings.

Perhaps you can see why someone who has thought about Scrum for, oh, fifteen minutes, would say "That's not Scrum!"

But suppose we accept, as I do, that [some/many/most/all] Scrum teams fall far short of what Scrum seems to offer. Take it that they "fail". Now I'll wager a day's pay that in a day I can find where they're not doing what Scrum says to do. (I really will make that bet. My daily rate, or nothing, if your project is "failing" and I can't find a major deviation from what has been recommended.) As a hint to save you the money, here are some of the things I'll look for:

Fully empowered Product Owner, accountable for maximizing return on investment in the product, able to say what to do and what not to do;

Fully cross-functional Dev Team, shipping tested releasable software every Sprint;

Sprint Review with stakeholders, showing them what we've got and hearing where they want to go;

Sprint Retrospective focusing on what is really wrong and doing something about it;

Something wrong with Scrum?

Mike and Giles and I all agree that Scrum teams are not experiencing the success that we'd like to see, and that we might naively expect based on what we hear about Scrum.

We do not agree, quite, on the reason. Mike and Giles and many others think there is something wrong with Scrum. To me, that's a bit like believing in magic. In the business of magic, you have to say the words exactly right, make exactly the right gestures, and hold your wand just so, or the magic doesn't work. These guys believe, it seems, that if Scrum just said the right things, and said them right, it would work and all the failing would end. I don't think so.

To be fair - and I am trying to be fair - I think Mike really doesn't believe in a written-down process at all. He tweeted to me about setting a direction and helping the team identify signals, in their context, as to how they're moving toward that direction. He said "You can't tell people everything. So tell them nothing."

Of course, that doesn't mean shut up and walk away: I know Mike well enough to be sure of that. I take it to mean that we help people to find the direction they need to go, to make it clear to everyone, and to check and see whether they're heading in the right way.

I don't know whether Mike would tell them how - here are some ways - to find direction, make it clear, see how you're doing, or not. I suspect he would: otherwise it would be a short meeting.

What's interesting is that whenever I get into one of these Twitter conversations, at least if I dot the names enough to pick up a few people in the conversation, I inevitably find someone who seems to be saying that it would be better to just tell people what to do. Force them to TDD or something. I refuse to be told what to do. That's why I work for myself, and I don't pay much attention to what I tell me to do either. So I will not tell other people what to do, not in the sense of "you must do this". I might sometimes fall into the trap of saying "you should test that", but I wish I wouldn't even do that. What I try to do is to say "Here's what I do, here's why I do it, here's what happens," and leave it to the listener to decide what to do with what he has heard.

I try never to stop until I'm sure I've been understood, or until I catch on that people aren't listening. But I never tell them "you must do such and so." Even in the book and the related talks I do with Chet, I might say that I believe there is no alternative to testing and refactoring if you want to successfully work in iterations, but I still try never to say "you must". I do think you'll fail if you don't, and I make that clear, but it's still up to you whether to pay attention, still up to you to decide what to do.

So I'm kind of on Mike's side when it comes to dictating practice. Nonetheless, I believe in having practices and doing them, and I believe that empowered product owners, frequent increments of tested working software, regular stakeholder contact, and regular improvement are pretty darn good practices to have.

One question

You've gotta ask yourself one question: "Do I feel lucky?" Well, do ya? - Dirty Harry

When you start your next project, using some method we'll call without loss of generality "Scrum", ask yourself this: "If this project is successful, are we going to say 'we succeeded' or are we going to say 'Scrum succeeded'?" Write that decision down. Then, succeed. If, however, you do not succeed, look at that card. If you were going to say "We succeeded" - and I hope you were - then you owe it to yourselves to say "We failed".

If you want to own your successes, you've got to own your failures as well.

Yeah, fine, sure, but couldn't Scrum do better?

Well, let's see. It could die in a fire. According to Giles, that might help. Or it could be replaced by nothing, which Mike's tweet seems to recommend. It could be replaced by something more stringent, like requiring, I don't know, TDD, or the use of SharePoint. It could be replaced by something simpler, like Crystal Clear, or something more disciplined like DAD (Yes, Dad, sure) or something containing all other ideas in the known universe, like SAFe.

Or maybe it should just be expressed better. Yeah, because the existing books about Scrum have all been so carefully read and followed. Schwaber^n, Sutherland, Rawsthorne, Rubin, Sims&Johnson, Cohn, Goldstein, Lacey, take your pick. Try to pick from the top tier of authors, of course. But in those books you'll find plenty of good advice, and not one of them is going to tell you to have 90 minute standup meetings, overworked product owners, or incomplete teams who can't control their work. Not one.

You could even read , which won't tell you any specific thing you should do, while describing seven things to keep your eye on, namely guiding, organizing, planning, building, slicing, quality, and value. And there are pretty pictures and some supporting articles as well.

Every time I write about something, I write about it a bit differently, in hopes that this time, these words will grab someone who wasn't grabbed before. So I'm all for expressing ideas like Scrum differently, and hopefully better. I do not believe that one single expression will work for everyone. Some people really want, and perhaps need, lots of direction. Others want to see the big picture and find their way on their own. Others are in the middle. You can't fit that into one book, much less into a few pages of Scrum Guide.

Or at least I can't. Maybe you can. Thus:

The Challenge

Quit yer belly-aching!
- Ron Jeffries, Sr

The challenge to you, Giles, you, Mike, and you, [Your Name Here], is to move beyond complaining about how screwed up Scrum is and start telling us things to do and things not to do, reasons to do or not do them, ways to know how we're doing.

Take us forward.

# data[].attributes.attachment_link.description
Again today, I wake up to yet another report on Scrum's failings, this time from Mike Sutton, whom I much admire. Read his article here. Now certainly Mike's list of Value, Flow, Quality, Joy, and Continuous Improvement represents a good way to assess whether an organization is "successful".

# data[].attributes.body
From the Schwaber

# data[].attributes.attachment_link.provider_name
Ken Schwaber's Blog: Telling It Like It Is

# data[].attributes.attachment_link.description
Last night an old friend from the Scrum Alliance told me that I'm being quoted as saying that only 30% of all teams and organizations that use Scrum will be successful. I pondered this. I didn't remember having said this.

# data[].attributes.body
https://plus.google.com/+FloydMay/posts/ezKN7q8n6FB

# data[].attributes.attachment_link.readable_text
VersionOne does an annual "State of Agile Development" survey and publishes the results for the cost of your email address. Thanks VersionOne! I recently read through the 9th annual survey results for 2015, and there's lots of good, useful data there. For now I want to highlight the top five reasons agile adoption fails, and what you can do about it:

Here are the top 5 leading causes of failed agile projects:

1. "Lack of experience with agile."
2. "Company philosophy or culture at odds with agile core values."
3. "Lack of management support."
4. "External pressure to follow traditional waterfall processes."
5. "Lack of support for cultural transition."

My strategy for overcoming these challenges in most large global organizations is employing the Studio Model, something Ken Schwaber wrote about in Software in 30 Days. The basic idea is to carve out a part of your organization as a new "Agile Studio." Within the Studio, we start projects that are allowed to use various agile concepts techniques. And because most of the people are unfamiliar or inexperienced with agile techniques (#1), we only allow trained professionals to be on projects in the Studio. And the training we use is not a weak professor led teach-at-you course or silly learn-by-playing-metaphorical-games workshop, it's serious experiential courses that include actually building software.

Making the decision to set up the Studio inherently involves management. It actually requires managers to take action to form such a structure inside their organization. By doing this we ensure buy-in, which intrinsically tackles the problems of #3 and #4. Sound too easy? Yes, we aren't done yet... The scale of the Agile Studio is the primary management discussion point once we've achieved buy-in. Do we start with just one project because we're just not that confident in this agile thing? Ok, let's do that! Or do we start with a major scaled initiative because it's critical to our business' success? OK, let's go! Once management has made a decision about how to start, they are the ones actually organizing and supporting the Studio. The lines of communication between management and the team are now open; they have skin in the game and are incentivized to see the Studio succeed. In fact, because change like this tends to make us humans nervous, we find management quite engaged in the Studio start-up. Additionally, everyone - managers included - require training and coaching in order to operate in the Studio - don't forget that #1 applies to everybody!

#2 and #5 are a bit trickier. I wish there was a simple technique to install a new culture at your big company. Instead, I've come to believe that culture is a symptom. Culture change follows after other change - structural, organizational, process, communication style, etc. The best I can tell, and this is by no means a scientific study, an organization's culture is mostly a result of the processes they use, and the communication styles of their leaders. So in the context of an Agile Studio, we actually change the processes we're using from day one. Do you want a culture that is transparent and freely inspects and adapts the work product? Well, let's use a process that builds those elements in. Soon you'll start seeing these things bleed into everyday work. As for leadership and communication styles, one of the things I often do in the Agile Studio is work one-on-one with each manager on this very topic. As an agile coach, I am skilled in this area, but I often use a Professional Coach for this type of work simply because it's such a different skill-set than "agile process coaching."

Anything - absolutely anything can fail if it is not executed properly. What is clear from research is that using Agile techniques for software development is far more cost, time and demand effective than Waterfall or other, older methods. If your company has experienced any of the above obstacles to success in Agile adoption, let's revisit your approach. Contact a Professional Scrum Trainer to ensure you remain competitive in the ever-increasing battle for better software with faster delivery.

View the original post here: http://www.erikweberconsulting.com/blog/2015/7/21/failedprojects

# data[].attributes.attachment_link.title
Top Five Causes of Failed Agile Projects

# data[].attributes.attachment_link.description
VersionOne does an annual "State of Agile Development" survey and publishes the results for the cost of your email address. Thanks VersionOne! I recently read through the 9th annual survey results for 2015, and there's lots of good, useful data there.

# data[].attributes.attachment_link.readable_text
Erik Meijer in his talk (warning, maybe nsfw because of language) from the Reaktor Dev Day makes a case for why Agile/Scrum should be done away with and goes so far as to compare Agile and Scrum to a cancer.

The more I watch it, the more I love it! Please understand that I am not being snarky or sarcastic (although I end up being ironic) - what he says genuinely inspires me and gets me charged up to go out there and write great software, genuinely treat people well, and take more pride in the software I write. Software is eating the world after all.

Watching the video can be difficult because it is very inflammatory, but if you push through you can make the following observation:
Erik Meijer loves agility and hates when people keep developers from being agile.
I started this post by going through his video section by section and demonstrating how Erik's prescriptions walk hand-in-hand with what the Agile Manifesto says, but that made for a very long post. Instead, I'll simply challenge anyone who believes what Erik is saying to be correct to first read the Agile Manifesto, don't forget to read the principles that are behind it, and then listen to his talk.

I don't think it is a stretch to say that every prescription Meijer's makes is directly supported by either the Agile Manifesto or the Scrum guide. Even his ad hominem attacks on people who haven't written code in a while (though misguided) speak to the first assertion made by the Agile Manifesto:
We are uncovering better ways of developing software by doing it and helping others do it.
That's literally the first sentence! Turns out, Erik agrees (quite emphatically) with the sentiment framing the whole Agile Manifesto - that we uncover better ways of developing by actively developing.

As you watch more of his video, you might ask me, "If he is as misguided as you claim, why should I care to listen to what he has to say?" A major problem for agilistas is that they/we (not sure if I am one) too often exist in an echo chamber. Without exposure to or cooperation with those of different even fanatically different opinions, a person will become blind to existing or future problems in their way of doing things. This is one reason why a team of people need to regularly inspect themselves and even shake things up in order to make sure their practices are still healthy, to identify problems, and to determine how to improve.

We need a second opinion

Erik rightly demonstrates several symptoms plaguing our industry. When he rails against managers using Scrum and Agile to practice subtle control, he rightly calls out the abuse of a self-organizing team. When he decries companies that allow themselves to function like black boxes just taking input and producing output, he is calling for a Sprint Review. I could go on.

Where Erik gets it wrong is not in his diagnosis but in his prescription. Agility and Scrum are frequently co-opted, even commandeered by companies and individuals who do not understand software and who see it as a tool to accomplish their own goals. This is a cancerous development, since it is an otherwise healthy "tissue" becoming denatured then behaving against the best interest of the host and even of the cancerous cells themselves; however, the way to treat such dysfunction is not simply to cut out vital tissue wholesale i.e. eliminate Agile/Scrum completely but should rather be precise, gradual reclamation and rejuvenation of the affected tissue.

I love this video because Erik Meijer's is calling for true agility.

I heard a story told once of a monk who was able to subject himself to river rapids such that he could successfully travel over a falls unharmed. When asked by another monk how he was able to do so, the sage monk said something to the effect that he traveled without fighting the current yet by slow, subtle movements steered his course through the perilous rocks. The observation being that if he had thrashed about trying to fight the overwhelming current, he would only have endangered himself and his goal of traveling the falls. The lesson is to prefer evolution over revolution.

We need to take back what is ours. Agility is vital. Though it be co-opted or commandeered, we cannot give it up for lost for if we do so, we give those who have perverted the term deed to it and risk a similar fate for any future word, phrase or hash tag we use as our banner in the future.

Our industry needs chemo therapy, not shotgun surgery.

# data[].attributes.attachment_link.description
Erik Meijer in his talk (warning, maybe nsfw because of language) from the Reaktor Dev Day makes a case for why Agile/Scrum should be done away with and goes so far as to compare Agile and Scrum to a cancer. The more I watch it, the more I love it!

# data[].attributes.attachment_link.readable_text
A good friend of mine commented on an article by Giles Bowkett entitled, "Why Scrum Should Basically Just Die In A Fire." Naturally, I was intrigued.

The guy he quoted has had some majorly bad experiences in his software organization which he wrongfully attributes to Scrum.

His conclusion: Scrum should be killed with fire.

His frustrations seem to have come from individuals and relational dysfunctions during Scrum events and misuse of Scrum artifacts; yet he should really take a hint from what my friend said in his Facebook comment:

"Smart people create the processes necessary to do the work, end of story." - my smart yet anonymous friend

I agree wholeheartedly and if the OP agreed, he would flambe not Scrum but the people in his examples and their highly dysfunctional behavior. The irony is, if the OP was given the power to annihilate Scrum from past, present and future history, the source of his problem would remain. This is because...

Scrum never fails, but people do.

Saying Scrum has failed is like saying my tool belt failed to hammer in a screw. Scrum is a methodology and cannot itself produce working software. It is used by developers to construct agile processes that best enable them to address complex adaptive problems. Producing working and valuable software is just such a problem.

People can also fail when they force their developers to adopt Scrum at all costs. This violates value #1 on the Agile Manifesto.

I would go so far as to say that Scrum is something a team should transition through instead of to if only by a little bit. If teams and organization hang out in Scrum land too long without questioning it or seeking to improve on it, they risk becoming religious zealots instead of creative problem solvers. Also...
​ Scrum is not for everyone.

If Scrum is not right for a team or organization, it should be discarded in part or as a whole. Holding on to a methodology at odds with a culture or set of good practices is likewise a sign if immaturity, not of Scrum but of the people choosing to implement it.

# data[].attributes.attachment_link.description
A good friend of mine commented on an article by Giles Bowkett entitled, "Why Scrum Should Basically Just Die In A Fire." Naturally, I was intrigued. The guy he quoted has had some majorly bad experiences in his software organization which he wrongfully attributes to Scrum. His conclusion: Scrum should be killed with fire.