Let me take you back to 2007 for a moment…
The scene was Lincolnshire, Illinois, in the ballroom of the Marriott hotel where XP/Agile Universe 2002 took place. It was the second North American conference on Extreme Programming (XP), and after nearly two years of researching, learning about, and experimenting with Extreme Programming in my work, I had reached a fork in the road. I took the opportunity to complain to a few of my new friends about it at the conference’s banquet dinner. As I remember it, Ann Anderson called Chet Hendrickson over and told him, “Joe here says we sold him a bill of goods, ‘cause no-one will let him do XP.” That was how I felt—as though someone had shown me the One True Way but made it so radical that it was practically impossible to go that way. No one would let me do XP anywhere—I had tried! You can understand why that might upset me.
My, how things have changed. I’m both doing and teaching XP these days, and I’m by no means the only one. I read stories of agile teams having more success and being happier by delivering good software early, often, and well. The message is no longer quite so radical, and I foresee the day when people will begin to wonder why we ever called it “extreme.” In these five years, however, I have noticed an alarming trend: Agile transitions need change agents, and so many of these change agents seem to have forgotten something. I’m guilty of it, too, which is why I’ve taken the time to remind us all about it.
I’ve spent most of the past five years teaching the practices and techniques of Extreme Programming. I’ve taught in the classroom, on teams, at conferences, through articles, and even by writing a book. I’ve worked with teams and with individual programmers. I’ve taught test-driven development, refactoring, evolutionary design, object-oriented programming, iteration planning, release planning, pair programming—I’ve even taught these techniques to high school students. It has been mostly an enjoyable ride. I feel good about what I’ve taught these people, and many of them feel good about what they’ve learned. I’ve forged a number of friendships both within the agile community and by bringing new people into the community. I’m reasonably well-known, people like me well enough—so why be dissatisfied? It’s simple: Too many of us have unwittingly acted like hypocrites.
Yes, I mean it that strongly, and here’s why.
If you’re an agile consultant, teacher, mentor—any agent of transition to agile—you’ve undoubtedly done what I’ve done: You’ve taught test-driven development and refactoring to programmers, story writing to customers, exploratory and customer testing to testers, and adaptive planning to managers. You’ve gone beyond the basics and shown some of your favorite tricks of the trade. But I have to ask you an uncomfortable question: Do you remember the Agile Manifesto? It’s pretty clear that we value people over process. It’s right there in the first line. But have you taught your students, your teams, and your clients about teamwork?
At the same time, if you’ve had an agile transition inflicted on you, or you’ve attended a class or listened to an agile consultant speak, how much of that time was spent talking about teamwork? Did you get more from the experience than just learning how poorly you’ve done your job for most of your career? Consultants are tough, and even though they probably didn’t mean to be so blunt, even if they tried to sugarcoat it, that’s likely how it felt to you. I’m here to apologize for them, because I do it, too. Let me explain why we think we’re doing the right thing.
It was love at first sight for me and Extreme Programming. Test-first programming? Obviously excellent. Iterations? Of course. Pair programming? Who would bother to program on his own if he could work with others? It was a flood of great ideas, and I wanted to try them all, every last one of them, now. Worse, I wanted everyone around me to try them because this obviously would make all our lives better. We’d deliver sooner, we’d go home on time, we’d sleep better. Why wouldn’t we start now? What I didn’t know at the time, and what I didn’t appreciate until relatively recently, is that organizational dysfunction is in the way, and it’s not because people are stupid or evil. That’s just what happens when we bring any large group of people together to work. We need to do that thoughtfully and not haphazardly.
Since I came to this realization, I have learned two things that I now use to guide my work:
Extreme Programming works best when we work as a team and Being a team takes ongoing effort and courage. This has affected me deeply. No longer can I simply teach test-driven development, help a team automate its build, institute regular planning, and call it a day. Even if I could install all the Extreme Programming practices into an organization from top to bottom, that wouldn’t be enough. I need to help these people become a team. Without that, do I deserve credit for success? Looking back, my greatest successes have come when my protégés were already a strong team, and my worst failures have come when they weren’t. Something was missing, and I think I have it now.
I would like to set a challenge for you, from agile consultants to unwitting participants in an agile transition: Emphasize teamwork. If you’re a change agent, talk about teamwork and introduce it into the change program. If you’re in a room with a change agent talking about becoming agile, ask him how he plans to address your organization’s teamwork issues. Ask him whether he intends to talk about teamwork at all. Show your commitment to teamwork by being vulnerable and asking for help.
After all, it’s people!
(Almost) Ten Years Later
I wrote the first version of these words at Pearson Airport in Toronto in 2007, reflecting on my work as a fledgling “Agile coach”. Around that time I started to hear the rumblings that led, over time, to a large segment of our market growing to hate that term. What a waste.
It’s now late in 2015 and I’m traveling Europe once again challenging people to undertake XP (and Agile in general) “more seriously” or, if you prefer, “as if we meant it”. Many of the concerns I had in 2007 remain today: a significant portion of the Agile community has created a racket, and among those who come by their Agile-related income more honestly, a significant portion of them end up promoting a superficial, and ultimately doomed, version of XP or Scrum or Kanban or whatever is popular at the moment. As a result, I see strange articles from people I respect, such as Dave Thomas’ “Agile Is Dead (Long Live Agility)”. I respect and (mostly) agree with these points of view, but these authors use the word “Agile” is a dangerous, irresponsible way. (Sorry.) They either decry the racket or pointless, superficial practice or both, and by calling that “Agile”, they teach people that “Agile doesn’t work”.
Except, of course, that it does work and you don’t have to be born with it. And remembering that people lie at the center of Agile helps us take one giant step in the direction of effective practice. We can do more, but it would make me happy enough if we just did that.
I have found grounds for optimism. I spent two wonderful days at XP Days Germany 2015 in Karlsruhe, at the epicenter of perhaps the world’s greatest concentration of love for XP. There I found not fangirls and fanboys, but rather thoughtful, mindful, determined practitioners. I found “XP As If We Meant It”. And Scrum. And Agile. Even some Kanban! This gives me hope. Now I have to act like a “hope camel”, storing this optimism for the dark days of late winter when, at home, I will probably feel like everything is horrible and nothing matters. I will need to remember that, on the contrary, across the world I can find people whose lives have improved by practising Agile software development well.1
If we remember to show respect, just listen, and become genuinely curious about what others do and think, then we will enable the rules and guidelines and ideas in Agile software development to do what we think they can do, through us.
And yes, I know how much that sounds like religion. It is not. It is philosophy. It is what living one’s values sounds like. Even if Agile hasn’t transformed the world of work, I’m happier. Are you? No? Would you like to be?
Pawel Brodzinski, “Carnival of Agile Bullshit”. I love this stuff. A random walk through both the racket and the superficial practice of Agile.
Ron Jeffries, “We Tried Baseball and It Doesn’t Work”. A humorous look at what happens when one changes the rules before one understands how they work.
Bob Hartman, “Agile Anti-Pattern: Doing Agile”. A perfect example of the kind of article that bugs me, because I agree generally with the sentiment, but when you say “Doing Agile is an Anti-Pattern”, it muddies the water. Clickbait. Marketing. It’s fine.
I hesitate to say “properly”, because I don’t want to fall prey to the No True Scotsman fallacy, but honestly, a significant population does stuff that they think “is Agile” that just isn’t Agile. Sorry. I can help.↩