Scrum is founded in the belief that self-organizing teams can figure out what they need. When true, this is sometimes not sufficient. And sometimes, particularly in software development, it seems not to be true.

I took my CSM course from Ken Schwaber himself. (Yes, I have a CSM. I also got my CST on the same day.) Ken clearly believed that Inspect and Adapt works, and that the team can indeed figure things out for themselves.

Ken demonstrated this repeatedly in the class. Most every interesting question, he had the class divide into teams, discuss the issue, and come up with the answer. Invariably, they did so.

The team, self-organizing, can observe what’s going on, and generally sort out what needs to be done to resolve issues.

By and large, Ken’s vision of self-organization is well-founded.

There are two issues:

First, a lot of the concerns that the team identifies are outside the team, in the product definition space or the project management space. While the CSM’s job is to resolve those issues, their ability and power, is often not up to it.

Scrum doesn’t tell us how to resolve that, or anything, really. If it’s set up right, and if the SM is good enough, it’ll get resolved.

Principles, rules, flow, none of these will fix that if it happens.

The second issue, I believe, is even more troubling. While the team probably can at least see the solutions to “process” issues, Dev Teams are almost never equipped to work out development issues. They just don’t know how to deliver the Increment.

The techniques needed, ATDD, TDD, Refactoring, and so on, are not taught in schools, and are not used in most shops, Agile or not.

Scrum, by design, is free of specific practices. It relies on the team to know, or find out, the practices they need.

Unfortunately, in the case of software development, most teams aren’t even really aware of the necessary practices, and certainly do not have the understanding and skill to select and install them.

An unanticipated consequence of these two issues is that many – I believe most – Scrum installations do not thrive. Some, we know, become Dark Scrum™. No one wanted this, and few expected it. But it’s the case.

The solutions for these concerns all revolve around “more learning”. I believe that nothing one does in the initial few days is likely enough. And the fact is, in the case of developers, few of them are even exposed to the two days of training that a typical CSM gets.

Scrum teaching and coaching tries to address the first group, teams needing more depth of information. But the Scrum community hasn’t been particularly successful even with the few dev-focused offerings they have, and I don’t see other effective ways of helping the developers.

Bottom line, an unintended consequence of the way things have shaken out in the market is that Agile and Scrum are not close to as effective and joy-making as they could be.

I continue to work on this, and I continue to be uncertain what else to do.

Advise me. And help me.