Kent Beck once said that he created Extreme Programming to make the world safe for programmers. More and more, we’re seeing a need to make Scrum and “Agile” safe for software developers. What should we do?

Update: Public discussion is presently active on the Yahoo! extreme programming group. Please join us there.

Update again: Concluding paragraphs.


A number of things are coming together for me. We’ve seen the “Die in a Fire” articles here and here, and Flaws in Scrum and Scrum Fails, I’m Told, Endlessly. I also wrote of Jeff Sutherland’s tweet about Testing inside the Sprint.

I raised the testing topic, in the context of developer training and the Certified Scrum Developer program, on the Scrum Alliance training and coaching list. I took as my theme, Jeff’s statement about not testing inside the Sprint being one of the biggest problems. I got some serious push-back about that, from people saying that no, the biggest problem is culture or portfolio management.

I also got a fair amount of support from trainers, including Mike Beedle, a Manifesto author who has always been a supporter of XP technical practices in Scrum.

Three Manifesto authors and the Manifesto’s first signatory, Chet Hendrickson, are Certified Scrum Trainers, and we all say that XP-style practices are critical to real success with Scrum for software development. More needs to be done. I’m starting to explore that here.

He’s dead, Jim?

Maybe Agile and Scrum have already died, if not in a fire. Dave Thomas, another Manifesto author, thinks so. Martin Fowler, yet another Manifesto author, wrote long ago about Flaccid Scrum.


There is no doubt: the quality of Scrum and Agile on the ground is too damn low. Results are at best weak. The ideas are misused. The values of the Manifesto are not followed. And most important to me, developers are not thriving.

To some extent, this may be inevitable. Jerry Weinberg’s Law of Raspberry Jam says The wider you spread it, the thinner it gets.

The number of memes used incorrectly is too damn high!

There’s no doubt that Scrum installations are often too thin, or are otherwise poor reflections of what the Manifesto had in mind. The articles linked above only scratch the surface of the material you can find about how screwed up some projects are.

And as for “Agile”? Even if you don’t want to get pedantic about using an adjective as a noun, there’s no doubt that “Agile” has become a buzzword meaning whatever its user wants it to mean.

But maybe there’s hope. Jerry also offers the Law of Strawberry Jam, As long as it has lumps, you can never spread it too thin.

Agile Software Development methods include lumps, some good and perhaps some bad. The good ones include the notion of a Product Champion, Product Owner, Customer, whatever we call it. The iterative and incremental style of development provides focus and transparency. Iterations limit work in progress, as does a pure Kanban style. The idea of running tested software, or product increment, drives quality development — at least if we’d do it. ScrumMaster / Coach, inspect and adapt, impediment removal … there are many good idea lumps that shouldn’t go away, and likely will not.

Another lump worth mentioning is that there’s a strong focus on the craft and techniques of software development, both close to the Agile movement and near it. Bob Martin, James Shore, J B Rainsberger, and others offer strong on-line learning opportunities in the techniques of software development. There are all kinds of learning opportunities on the web, like Code School, and training programs like Black Girls Code or Dev Bootcamp.

I am coming to believe, more and more, that to be a successful developer in the “Agile” style, we need a lot more than just testing, refactoring, and continuous integration. We need a lot more than technical and programming skill.

We need to learn how to be an effective member of a Development Team. Whether we do it all together in a room, or we do it long-distance via Skype and Github, we need to learn to work together, to trust each other, to use each other’s skills to build, not just software, but a powerful team. So as much as I respect and applaud the learning opportunities above, I believe we need more, focused on how to be a team. Not in some touch-feely way: many of us didn’t get into this work to be all cozy. But we do need to understand the dynamics of working together to create the product that our stakeholders need.

There’s a big difference between mostly dead and all dead.
– Miracle Max

There’s enough good in “Agile” and Scrum that the ideas are not likely to go away. They will be with us for a long time, and there’s a core of quality notions that support making the processes successful and keeping the developers productive and happy. And we can do more. We need to do more.

Still too thin

These concerns are not new. See, for example, this rant from 2009. Watering down. So much of the Scrum and “Agile” out there is watered down.

Whatever the cause, many, perhaps most, Scrum software development teams are not working as effectively as they might. This results in increased pressure on the teams, reducing effectiveness further, reducing Scrum’s success, and making teams very unhappy. It’s that last part that I really care about.

Successful software development needs to align with the values of the Agile Manifesto, and its principles. Things change, and there are new principles and maybe even new values, but I think the Manifesto stands up well. Successful software development, therefore, stands on the individual software developers who do it, and their interactions, creating working software, with customer collaboration, responding to change.

That’s not happening often enough nor strongly enough. I want to see something done.

What’s your plan, big man?

As a Certified Scrum Trainer and Certified Agile Blowhard, I have some sway inside the Scrum Alliance and, on some days, even outside. I am also one of the creators of the Scrum Alliance “Certified Scrum Developer” program. All that means that I can probably influence what the Scrum Alliance does with support for Dev Team members. Here’s what I’m up to just now:

  • I’ve started a couple of discussions inside the Scrum Training and Coaching list, raising consciousness about Dev Team issues.
  • I’ve found a number of supporters for the topic inside that group, and even a few who are willing to put in some time pushing it forward.
  • That group has expressed interest in a number of ideas:
    • Breaking out the general “CSD” into a number of separate Qualifications
    • Addressing Dev Team issues, not just individual technical abilities
    • Exploring in the market how to make Dev Team training more desirable
  • I’m working to get Dev Training to be part of the Scrum Alliance plans for additional Qualifications, where small teams would build learning objectives, tests, and training material.
  • I’m exploring whether and how to get Scrum Alliance recognition for existing offerings like the TDD and refactoring training mentioned above.
  • Updates below:
  • There’s a fairly active discussion on the Yahoo Extreme Programming Group, where you are encouraged to contribute thoughts and help. Right now, it’s kind of the active log of the discussions.
  • I had a chat with Carol McEwan, managing director of Scrum Alliance. She is interested in the topic, open to a well-considered recasting of “Certified Scrum Developer”, and certainly open to creation of new “qualifications” and materials to help.
  • Declan Whelan, an Agile Alliance board member, has said that he would like to help and thinks the Alliance could help. They have a couple of things going on that relate to the developer level already. He and I will be chatting the week of March 30th.

Flaccid Agile is a problem for all of us who understand Agile Software Development, and for everyone who’s trying to do it. The present weak implementations of these ideas are not advancing companies as well as they might, and they are making software developers suffer. If the Agile and Scrum Alliances can help, that’s great. With or without the Alliances, people in Scrum and Agile teams need help.

In the previous version of this article, I said “I want Extreme Programming back”. I meant “to come back”. Even then, better to have said “I want the world to have what XP can give”.

I want Scrum Dev Team people to have what XP practitioners had, and what many XPers still have today, what Mike Sutton refers to as Value, Flow, Quality, Joy, and Continuous Improvement.

I remember how empowered and effective XP teams felt in earlier days, and the strong community spirit that went with that. XP teams today still feel that way, and in some parts of the world, that spirit is still alive, thanks to people like Rachel Davies in the UK, and to many others whom I don’t even know.

I want developers on Scrum / “Agile” teams everywhere to have that feeling. Somehow, I would like to see the community come together better, and help the thousands of people who are experiencing Oppressive Agile (just made that term up).

I’m not trying to lead that effort, create a new method, or take over the world. Not my thing. I’m just trying to use what voice I have to improve people’s lives, and in many places the life of the “Agile” developer is in peril.

Development team members all over need help. If you’d like to help, and I hope you would, join the XP list, which should at least support a conversation. Maybe we’ll find a new home, and if we do, you’ll hear about it there.