This question tends to get asked a lot. Sometimes a team is new to agile and just wants to know if they are on the right track. Or perhaps they experienced great results early on but now things have fallen off a bit – pace, bug counts, team happiness, or what have you. In some cases a consultant, coach, or colleague may be saying, “you’re doing it wrong.” A blog article describing “fake Agile” may be resonating a bit too much for comfort. These are all good reasons to take stock of what you are doing and look for improvements. First however, I suggest examining the question itself, “Am I doing Agile right?” The thing is, that is exactly the wrong question to be asking.

It turns out that “agile” isn’t really a process. It’s a mindset, an approach, a philosophy, a way of being (hence the lowercase “a”). It’s far less about following a particular set of practices than it is about being flexible and responsive to change. What kind of change? Just about anything. Changing requirements, schedules, market conditions, teammates, leadership, customers, organizational structures, you name it. Agile came about in the world of software development precisely because people started to realize that the pace of change had become so fast that it was smarter to embrace that change and find ways to work within it than try to resist. The result is a way of working that isn’t locked in stone, but instead is itself flexible, changing and morphing with the environment, context, and conditions within which it operates. 

Focus on Agile principles, not practices

Let’s go back to 2001 and take a look at the Manifesto for Agile Software Development. This is what kicked off the whole Agile movement. It describes four values for software development. If your industry is different then the words would change somewhat (“delivering quality healthcare” instead of “working software” anyone?) but the underlying values should be consistent. Value people and interactions, deliver something that works, collaborate with customers, and respond to change. Importantly, there are no specific practices listed here. Take a look at the Twelve Principles link further down the page. These were added later, after years of hard-won experience. The principles are more detailed (and more industry specific), but still steer largely clear of defining processes or practices. 

The point is that there are myriad ways to “do” Agile. Some will work wonderfully for your environment, your team, your product, your customers. Similarly, there are lots of agile practices that work well for someone else, but might be terrible for you. Most likely there will be quite a few practices that you will invent for yourselves. Those will probably be the most effective of all – until you find you need to modify or replace them, which you should not hesitate to do! The most successful agile practitioners tend to continuously modify their practices to suit their current context (which of course is also constantly changing). Let the underlying values and principles of agility guide you, and you will likely be on a good path. Your path, not someone else’s.

Does that mean you should just make it up as you go along? Probably not. You’ll want to become well versed in many agile practices that people have had success with, then pick and choose, modifying to fit your circumstances. 

Agile Anti-Patterns (wrong ways to be agile)

While there is no single “right” way to be agile, there are many ways to go wrong. Here are 4 red flags to watch out for:

1. My way or the highway. An overly proscriptive approach is usually too inflexible to support agility. Quality agile coaches or trainers can be a real help on your journey, but watch out for those who preach that there is only One True Way.
2. Fixed scope and fixed date. Since an agile team focuses on learning as it goes, including learning about the right feature set, there needs to be some flexibility in feature scope, delivery date, or both. Targets are fine, but when you decide to build that new killer feature just uncovered in conversations with real customers, the plan you previously had in place needs to flex.
3. Lack of buy-in. Sometimes one group will dictate “we are going to do Agile from now on.” This might come from Management, Product, Engineering, or elsewhere. It’s usually a recipe for disaster. An agile transition is a major undertaking that will require the buy-in and support of all the stakeholders and participants in order to succeed. If this is too heavy a lift at your company, look for a way to start with a pilot project, then demonstrate small scale success to generate acceptance and even enthusiasm for larger adoption. 
4. No change in engineering practices. (This one applies specifically to software engineering teams.) Software teams can expect to do some things differently. Traditional engineering practices tend to result in software that is resistant to change rather than open to it. You will want to adopt practices that support evolutionary design – continuously improving the design to account for previously unexpected features. This might include practices like continuous refactoring, lots of automated testing (preferably using TDD), frequent collaboration, continuous integration, automated builds, and more. Implementing Scrum without adding high-discipline engineering practices like these is a common anti-pattern.

Evaluating your version of Agile

What are some positive signs that you are headed in the right direction? Keep your eyes out for feedback loops, an emphasis on learning, improved responsiveness to change, and experimental mindsets. Steering tends to come from “inspect and adapt” rather than “command and control”. In time you can expect to see an increased focus on high quality collaboration and teamwork along with a host of benefits from that, such as lots of listening, equalized speaking times, and people treating each other with respect.  People will be enjoying the work and working together. All of this contributes to a thriving agile environment. It usually doesn’t all happen right away or all at once. Rather, this is what the end state looks like. For teams with agility as a common goal, getting there is a journey worth taking.  

Do you need to pay attention to your practices and process? Absolutely. Every day if possible. Even so, try to pay even more attention to agile values and principles. Behaving with agility cannot guarantee success, but in today’s world, failing to do so is a powerful recipe for failure. Ask not “Am I doing Agile?” Ask, “Am I being agile?”

About the author

Troy Frever is the VP of Engineering at LiquidPlanner, and has been a technical team leader and software developer for over 30 years. Troy champions a human-centric, quality driven philosophy founded on an iterative experimental mindset. He is a skilled communicator and leader, and has deployed Agile theory on many different teams, especially in growth-focused startup settings.