I have recently noticed how many Agile practitioners are beginning to sound like evangelists. Not the nice, quiet, save-the-world-one-step-at-a-time missionary-type evangelists, but the crazy cultish evangelists. They’re the ones preaching that their version of Agile is better than the version of Agile you’re doing. They often talk in Capital-A Agile rather than adopting some of the key principles that agile originally grew from. They talk in a strange language that other people (non-agilists) can’t decipher. This hurts all agile teams, and we should look to build a shared understanding even with people who don’t speak the language of Agile.

I recently had such an experience at a client site. A development team were well down the path of agile and were successfully pushing out new versions of their product. A misstep with a side project had meant they had to bring in another team to cover that project. Doing the right thing, they were trying to avoid creating an “alien artifact”, whereby a piece of work is developed by an external vendor company and just handed over to the client (‘thrown over the fence’). Rather than have this alien artifact thrown into their laps that they would have to maintain in the future, they were going to work closely with the vendor and collaborate on the development. This all sounds great!

But what struck me was that the client development team, having adopted the language of agile (more specifically Scrum), weren’t actually getting through to the developers from the other team. They were always referring to cards rather than requirements or features or any terms that might ring true with the other team. They were heistant to talk about the joint effort required without writing up cards and holding estimation sessions. The vendor’s development team, in turn, had lots of ideas and concepts but couldn’t articulate them in the same language and a coherent manner that the original development team could grasp. I was left with a feeling that both parties weren’t quite on the same page and that most likely, the original team would just be left with an alient artifact - because it would just end up the easiest way to deliver the required product, rather than a piece of real collaborative work. The very thing both teams had set out to avoid.

So what went wrong here?

Let’s revisit what the original Agile Manifesto says.

Individuals and interactions over processes and tools

As the Manifesto says, it’s people over tools and processes. Scrum and agile are merely tools and processes for you to use as you see fit. The aim of this statement is to ensure that people collaborate. That they interact and communicate for a common goal.

It’s not to say that tools and processes don’t have their purpose. But the tools and processes of Scrum and other methods were never intended as an impediment to the main point of making teams of people communicate. There is value in the individuals and interactions, as well as the processes and tools, but there is more value in the individuals and interactions therein.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Whilst quite a lot of people have heard of the Agile Manifesto, not as many people have gone through the Agile Principles. One of which is relevant to us here: that the most efficient and effective way of moving information around a development team is a face-to-face conversation. But it’s really important for teams to remember that the conversation isn’t just strictly within the team itself, but it also includes the other teams and people that the team interacts with.

Both teams that I observed were failing to interact correctly. Both struggled to communicate in the other’s language, rather than finding common ground to fully understand each other and build interaction.

It’s an easy trap to think that just because agile has become more common knowledge in the software development (and the wider project management world), and that you can simply rely on the language, tools and processes that you do your daily delivery in and everyone will follow along (and have that shared understanding that we’re all aiming for). If other people don’t understand what you’re talking about, don’t think that your tools and processes will help people understand your aims.

Try speaking their language and helping them understand yours. Don’t assume they know what you’re talking about. If you find out that they do, great! But most of all, focus on collaborative work - the interactions of individuals. Speak their language and teach them yours.

Great work comes from great collaboration, which comes from a shared understanding. Find a new, common language for both groups to work together.