Elisabeth Hendrickson: Agile - An Inclusive Community
This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
It is difficult to believe that the Agile manifesto is only ten years old. So much has changed since 2001.
In many organizations, open team rooms replaced closed-door isolation. Collaboration aided by ephemeral artifacts - index cards and sticky notes - superseded hand-offs via documents. Test-driven development and continuous integration, both considered new, radical, and fringe practices in 2001, are now commonplace.
Tools have changed radically. Eclipse, now one one of the most popular editors, was created in November 2001 . Between then and now it has become a defacto industry standard. Like other modern Integrated Development Environments (IDEs) it supports automated refactorings such as rename and extract.
And where once the only options for automating tests involved rolling your own tool or buying expensive proprietary technology (or both), open source tools have blossomed. Frameworks such as Fitnesse, Cucumber, Robot Framework, and drivers such as Watir and Selenium, have achieved widespread adoption.
It may seem that the creation of the Agile Manifesto was a watershed event that led to all this change. It is a key artifact created on a specific date by a renowned set of signatories. Its creation represents a definable moment in time, an anniversary we can celebrate. It's the stuff of legend: a declaration of defiance against a rigid status quo; a pithy, articulate, almost poetic public statement borne of tremendous frustration.
Such things have power.
But it is the events in the months before and since that were the real watershed: the conversations about how things could be better that ultimately led to that fateful meeting at Snowbird; the gatherings where practitioners shared ideas and knowledge; the discussions that led to the clear articulation of practices and the creation of tools to support those practices.
That said, the Agile Manifesto served as a catalyst that reached out to far-flung corners of the industry to forge a community and a movement. It clearly, boldly, and unapologetically laid out a set of back-to-basics values and principles. Its simple message and strong words resonated deeply for many of us laboring under the burden of cumbersome ceremony-driven processes that supported the illusion of progress over actual, working results.
Naturally, some felt left out of the newly formed community. "Where are the testers?" some asked. And also: "Where are the business analysts?" "What about the designers?" "Hey, what about sysops?" "Don't forget DBAs!"
Even now some people feel that their specialty has been left out.
But there is no reason to feel excluded. The only ones being excluded are those who have not shown up for the party. I find it difficult to imagine a more welcoming community anywhere.
I should know.
In 2003, I attended XP/Agile Universe in New Orleans. At that point, I'd been keynoting at tester conferences for years. I had a popular testing blog. I was accustomed to people knowing who I was at industry events.
Not this time.
In most of the sessions I attended, I was the only tester. I was also often the only woman in the room. I was a noob with no geek cred. I was nervous. I felt like a gate crasher. I joked about infiltrating the enemy camp.
Fortunately, I soon realized that the self-deprecating humor was unnecessary, even silly. Everyone made me feel welcome. People went out of their way to include me in conversations.
By the end of the conference I no longer felt like an outsider.
Over the next few years, I became a full-fledged member of the community. I was a session reviewer then track chair on Agile conferences and was elected to the Agile Alliance board of directors. I now serve as a co-chair of the Agile Alliance Functional Testing Tools group.
The Agile community has swelled as the popularity of Agile has grown. Sometimes communities implode given such rapid expansion. Much to my delight, this community has retained that same welcoming vibe it had back when all the Agilists all knew each other.
To be sure, we are not a wholly united community. There will always be those who take an "I'm more Agile than you" stance. There are some who vocally express their concerns about the commercialization and even commoditization of Agile while others seek to profit from its popularity. Debates rage about controversial topics including certification, tools, and the "right way" to do practices.
But through it all, there is a solid core of respect. Ultimately the Agile community values diversity of thought. As Liz Keogh said in her Gordon Pask Award acceptance speech, she belongs to a "community of thinkers." 
Not only is there room for everyone in this community, but we need everyone. If we wish to get the results that Agile promises, we need everyone's perspective and expertise. We may not always agree, but most are open to listening to contradicting viewpoints.
This message is of particular importance to those who work in organizations that are transitioning to Agile. It is in such organizations where I most often hear of people feeling "left out."
Organizations new to Agile are all too prone to establishing education programs that divide learning opportunities neatly along traditional silo walls. They send product managers or business analysts to product owner classes. They send project managers to CSM classes. They send programmers to TDD classes. They often don't know what to do with designers, quality assurance professionals, system administrators, DBAs, and other specialties, so they leave these people to fend for themselves.
By the time I meet these folks they feel alienated. Disenfranchised. "Everyone else got training on what this transition means," they say. "We didn't. We don't know what to do."
Some are bitter. "This new process seems very programmer-centric," they say. QA groups accustomed to owning anything with the word "test" in it even feel threatened. "The programmers are talking about selecting testing tools," one test automation manager told me. "That's MY job."
I wish these people knew that Agile is for everyone. That it's not about us and them. There is no them. There is only us. And we need everyone at the table.
So I will tell you what I tell them. Perhaps you can pass on the message if you meet someone who needs to hear it:
If you are feeling left out, don't wait for an invitation. Show up. Join the conversation. Let your voice be heard. Listen to others.
You will be welcomed.
About the Author
Elisabeth Hendrickson is the founder and president of Quality Tree Software, Inc., a consulting and training company dedicated to helping software teams deliver working solutions consistently and sustainably. She also created Entaggle, a community-based site for giving and getting professional recognition. And she founded Agilistry Studio, a practice space for Agile software development in Pleasanton, CA. A software professional for over 20 years, Elisabeth has been a member of the Agile community since 2003. She served on the board of directors of the Agile Alliance from 2006 - 2007 and is one of the co-organizers of the Agile Alliance Functional Testing Tools program. Elisabeth splits her time between teaching, speaking, writing, programming, and working on Agile teams with test-infected programmers who value her obsession with testing. You can find her on Twitter as @testobsessed.
Trainings on Agile Specialities optional, but trainings for Teams required
Good to read your article. I believe apart from individual trainings Agile even more requires training for teams and how to work, collaborate and deliver as a team. Agile processes such as Scrum are kept simple based upon empirical evidence - Lean is the keyword. Most of our special engineering knowledge is still valid. But what hardly is understood by all our experts is team work.
A couple of Agile certificates has been created, targeting at experts nowadays. We have Agile PMI for the "new agile PM", we have CAT for the "new agile tester" and all receive a piece of paper with these great training formats. But what is left out is delivering these kind of trainings for whole teams. I hope this development is just a temporary phenomenon, before we will get further to developing Agile teams and organizations and before we will have the educations program for the "Agile architect" and "Agile IREB" ;-)
Recently blogged about this: