Over a million developers have joined DZone.

Lost in Agile Translation

DZone's Guide to

Lost in Agile Translation

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

As ambassadors for organizational change, we routinely face obstacles ranging from the usage of scrum rhetoric by trainers to stubbornly persistent misconceptions.

As a result, we continually strive to improve upon how we connect to those who may have already been biased by agile misinformation.

While some experts recommend a shock therapy approach, I try to find a way to relate on a personal level and then move onto more subtle ways of introducing change.

Speaking agile to the military

The military can be resistant to change, even more so than an enterprise organization in the private sector. They are, however, beginning to adopt agile methods for their defense software. To a large extent, I believe it makes a great deal of sense. I have witnessed first hand how counter terrorism software needs to quickly shift direction due to the rapidly evolving terrorism landscape. (that’s another post entirely) Yet when speaking to those who’ve done it their way for 20 or 30 years, you can quickly be shut down by using terminology that they cannot relate to.

Enter the OODA loop.

The OODA loop (for observe, orient, decide, and act) is a concept originally applied to the combat operations process, often at the strategic level in both the military operations. It is now also often applied to understand commercial operations and learning processes. The concept was developed by military strategist and USAF Colonel John Boyd.

This loop, which can be compared to the PDCA loop, has similarities to agile software development. Instead of beginning the conversation with agile terminology, I start out speaking to the OODA loop and then relate it to software development. I’ve found that people have been much more receptive to my ideas with this approach.

If you are skeptical, it seems I’m not the only one trying this technique since Eric Ries referenced OODA in his Gov 2.0 talk.

Speaking agile to musicians

Over the summer I had the opportunity to participate in a sort of speed dating agile adoption therapy game. It wasn’t as painful as it sounds, and I spoke to a particular individual that had a problem with a major stakeholder refusing to participate in an agile adoption. The music software team needed expertise from the music theory stakeholder in the organization, yet this stakeholder was resistant to change and wary of the newly adopted agile software development process.

Enter jazz music theory.

The form of a jazz tune generally consists of a melody (known as the head) played over a chord progression (known as the changes). When performing a tune, the musicians typically play the head first, then take turns improvising over the changes, then play the head again. As they improvise, they often take liberties with the changes, by adding, removing, or substituting chords on the fly, and choosing notes from different scales to play over a given chord.

Dave Nicolete
then suggested that he speak to the stakeholder in a way in which he can understand the challenge at hand. This meant putting the agile terminology on the back burner, and instead using a jazz music theory metaphor. This involved speaking in terms he can relate to, and then converse about the overlap such as small teams, improvisation and such. It was an angle he had not yet tried, and I watched his eyes light up as he prepared to go back and try it out.

If you are curious, others have also written about the link between agile and jazz music.

Speaking agile to project managers

A few years ago I created a grassroots agile adoption cheat sheet in which I attempted to map agile terminology to project management terminology . While my intentions were good, I invoked the wrath of rabid commenters who basically tore the article to shreds. It was quite the learning experience for me, and in it I found a nugget of wisdom from Michele Sliger that I use to this day when conversing with traditional project managers.

Let’s take the daily scrum, for example. I will teach that it’s a 15-minute meeting that the team has every day to coordinate their work efforts, and that we stand up during the meeting so that we aren’t tempted to pontificate. Then I’ll begin referring to it as a 15-minute daily stand-up meeting, and later I’ll shorten it to the daily stand-up. This way I can be clear about what it is and its intent, and we just shorten the phrase as understanding develops. If you refer to it as a status meeting, the intent changes because of the listener’s current understanding of that word — and then people show up ready to report to their manager rather than to coordinate with each other…

Be creative and make an effort

These techniques are only a few that have helped me navigate the pitfalls of agile conversation. I do not limit their use to dialogue with executives or potential clients, as I even work them into the interview process for additions to existing agile teams. For example, I’ve co-opted a technique from Najati at Cyrus Innovation in which I ask interviewees to paint a picture of agile software development.

Their responses have been everything from flowers to a slinky, but they always lead to enlightening conversations about the approach without getting bogged down in the terminology.

What are some techniques you have used to help bridge the gap and avoid getting lost in translation?

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}