I recently went to the Agile2016 conference in Atlanta, GA. It was a great conference; I met a lot of people and learned a lot about managing teams and people and how agile is evolving as a practice.

But, I saw something else there and throughout my experience working in agile that disturbed me: agile purists. Now, let me clarify here before anyone is scared off. I’m talking about people that say to be “agile” you have to do things a specific way (often their way). Any deviation to them is “not agile.” This disturbs me because it is usually consultants saying that their “proven 5 step methodology” will transform your organization into the agile ideal. Now, as a consultant, this may sell more deals, I don’t know, but what I do know is that agile is based on empiricism, not blindly following a “proven” methodology. Like in science, we should question everything.

So I’ve taken to calling myself an  agile “realist.” I take this to mean that there is no one “right” way to do agile. There are many good ways and equally many bad ways to do or become agile. As long as you and your team are honoring the four principles of  the agile manifesto, you are “agile.” I work with many teams in their transition to agile, typically they choose Scrum, but some choose Kanban, Scrumban or a unique blend that matches to their regulated industry. All of these are still “agile.” As a consultant, I want to be able to see all the ways of working in agile, collect good and best practices and offer those to my clients. Not as a new or unique methodology or way to do agile, but as a toolbox that together, we can assess their situation in their journey to be agile and pick the best tools. There is no one size fits all.

What I’ve come to realize though is that these thoughts aren’t new, and in fact are probably closer to the agile manifesto and principles than the so-called “agile purists.” This is because agile is built on empiricism. The manifesto starts with “We are uncovering better ways of developing software by doing it and helping others do it.” Not “We found the best way to do development so follow these steps, go to this training and get this certification.” Instead, we are finding better way by doing different things and helping others experiment. This is laid out in the last principle as well: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” This principle applies to both the product a team is building (experimenting so that we can fail fast if needed) but also the process the team is using (what is working, what isn’t working, what new things can we try?). Experimenting, trying things out, and continuous improvement are part and parcel to being agile, not following directives, frameworks or made up best practices. That’s part of what got software development into such trouble with traditional or waterfall development; assuming that what worked for other engineering practices would automatically apply and be best for software engineering!

So back to why this disturbs me so much. Having 100+ consulting firms, each with their own proven best-practices and 5 step journey to agility confuses many people new to the agile world. They wonder who is right, are they all right and how do they become agile. When in reality, each and every one of these consulting firms probably is agile but not the only way to be agile. As a community, we should be promoting good practices, regardless of source, and not pretend there is one path to agility. Anyone who says they have all the answers to becoming agile for every situation is either lying or delusional!