The Agile Ecology

Today let’s talk about why I think the Scrum trainers, coaches, companies, and associations need to be doing something about Dark Scrum™. I think everyone in the “Agile” community needs to be working on the problem, and I wish they’d work together. The analogy is the environment and the things that happen when we make adjustments to it. From the article blurb:

If your factory pollutes the river, you’re supposed to clean it up. If you plant kudzu to combat erosion, you are responsible for its destruction of everything in its path. If you swallow a spider to catch the fly, and die when you swallow the horse, of course – it’s on you.

Now let’s be clear. I am not suggesting that anyone in the Scrum / Agile is intentionally doing harm. I’m not saying people are culpable. I’m not blaming people. I am saying that we are all responsible for the effects of what we do and that we should bear responsibility for cleaning up the messes, even though we didn’t intend them.

Now some of the messes are pretty remote from us, and we’d like to believe that they all are. I said right here in these pages that you need to test your code to refactor and you need to refactor to work incrementally. If you don’t do those things, I’d like to wash my hands of you. You didn’t do as I recommended … why do I owe you anything?

Well, if you read what I said and didn’t follow my advice, maybe my advice wasn’t clear. Maybe it wasn’t persuasive. So I should at least up my game before more people fall into the trap you fell into. But should I feel the need to do anything for you, the dumbbell who didn’t take my advice, wrote crappy code, now finding yourself stuck in a maze of twisty little passages all different?

I freely grant that on a given day, I’m inclined to let you flounder. Except that I hate to see people suffering even if they did it to themselves. So I might at least mention Michael Feathers’ book, Working Effectively with Legacy Code.

And, hell, I’ll sit down with just about anyone who’s pleasant and take a look at their code with them. No, I won’t visit your organization and teach you at no cost the class you should have taken two years ago. I might come in and help you at the same fee I would have charged then.

Or I might not. Now if I had given you advice and you followed it to the letter and got in trouble, maybe I should feel more inclined to help out. I don’t know: hardly anyone ever follows my advice.

But there is a connection between the 17 old men who had a meeting in Snowbird, and the poor devils working in the code mines of insurance companies in Ohio, suffering under the heel of the boot of the draconian sons of expletives who imposed a bastardized version of something called Scrum on them. We started this thing and we should at least feel sad that it has sometimes gone so far off the rails. And we should do what we can to keep it from going more off the rails, and to help some people get back on the rails.

Well, the Scrum Industrial Complex is closer to the root cause of the Ohio Insurance Mines than I am, and I think they, too, should be doing what they can to bring things back into line.

And of course, they are. I hear it every time I mention any of the Dark Scrum concerns within hearing of a Scrum Trainer, Coach, or Scrum Alliance person.

“I tell every class that they should refactor their code.”
“I tell every class not to put undue pressure on the team.”
“I tell every class they should send their developers to training.”
“We offer a conference with great material.”
“We have free pages on our web site with great information.”

And they are. At least the people I talk to are doing some things. And still programmers are asphyxiating in the dust-filled air of the Ohio Insurance Mines. Are the 90 percent of trainers and coaches who don’t even participate in the available forums doing such things? Literally no one knows. There is no Quality Control on Scrum training or coaching. None, not any, zero.

And is what’s being done enough? Not in my book. As long as one programmer somewhere is suffering under Dark Scrum, not enough has been done. And them as has profited from this wave of Agile Enthusiasm is the ones what owes help to the poor bilge-rats down in the mines.¹

Now before this series is done, there will be complaints that I’m just ranting and not offering anything positive. You know the game, you can’t call out a problem unless you have a solution. The number one way of deflecting concerns. Well, intercourse that, as well as the penguin you rode in on.² Here’s an incomplete list of things that should be looked at and considered:

• Take stronger action to make continued learning a necessity. Might require literal forced expiration of CSM. That, of course, would be bad for business.

• Provide much deeper support for “managing management” for CSMs, in particular protecting the team from oppression and other Dark Scrum™ actions.

• Put much stronger emphasis on producing the Increment and how to use it to manage the process, the PO, and the stakeholders.

• Acknowledge that Scrum is occasionally used to build software and that there are things people really must know how to do to do software in Scrum style. Invest real dollars in getting that training out there, recognizing that the odds are strongly against a multi-day paid training regimen³ for all developers.

• Explore the very real possibility that Scrum’s dictates from decades ago are no longer quite in tune with the world, and adjust the teachings.

• Analyze the causal loops – not just the good ones – that come from things like Sprints and Backlogs, and devise training, education, practices, techniques for countering the negative ones and enhancing the positive ones.

• Consider taking positions like those of SAFe, that everyone needs Scrum training, not just some former BA you’ve chosen to carry the mixed job of PO and SM.

• Observe that CSM training is not the best first training for everyone and do something about it.

• Do real research into the success and failure of the whole world of would-be Scrum, not just surveys of our own satisfied customers. Figure out causes of difficulty and work on them proactively.

• Accept that if you’re in the business of changing the world, not everything you do is going to be directly paid for by the person you help, and find more ways to help people who can’t or won’t pay, including managers and team members, even ones who have never spent a dime with the Scrum Alliance.

• Increase focus and training on the impact of quality on the flow of value

• Accept and integrate important ideas from outside, a bit faster than “stories” and “task boards” got adopted. possibly acknowledge sources. we’re all in the same system.

• Repudiate and work against notions like “twice the work in half the time”, which cause people to think “go faster” instead of steering and working incrementally toward value.

While I think those specific ideas may lead to some important improvements, what I’m really hoping for is for a sufficiently large and sufficiently dedicated group of people and companies to begin to feel responsible for helping those who may never have attended their class, never been coached by them, and especially never put a penny in their pockets, but who are still suffering as the indirect result of the well-intended good advice we’ve been handing out.

We want to take credit for the good things that have happened, and we have every right to do so. We should also accept responsibility for the bad things that have happened, via chains of causality that we never foresaw, and we should do something about those things. We should prevent more of those things from happening, and we should mitigate the ones that are happening now.