Communicating Toward an Agile Transformation

Posted April 12, 2018 in Business Agility & Software Engineering Excellence
Paul Oldfield

Communication is difficult. You may think you’ve been doing a good job of it, but have you? Recently I was in discussion with a group of experts in agility and a familiar three-letter acronym came up. We discovered that among 10 of us we had at least five different and distinct ideas about what that acronym meant.

This is a relatively simple case, readily detected and dealt with by use of feedback, paraphrasing, well-directed questioning, and a few other simple techniques. However, it served further to underline an observation that I first considered a trite one-liner, but now I consider to be a very powerful observation of reality:

The greatest problem in communication is the illusion that it has been accomplished.
                      – George Bernard Shaw

A different but common difficulty with communication is that no matter what one says, it will invariably be interpreted within the world view of the listener. If the words don’t make sense with a person’s world view, the listener will take it that what you mean is something that he or she can understand because it does fit with that person’s world view. In such circumstances it can be seemingly impossible to communicate the ideas you want to get across, because they just do not fit in the world view of the intended recipient.

This is a problem that occurs time and again through an Agile transformation, and has been recognized as a problem for much longer. Professor Douglas McGregor's “Theory X, Theory Y” split between beliefs of how to get people to do good work for you has been with us for over 60 years now, and underpins the split between the “command and control” and “self-organizing teams” approaches that tend to conflict head-on during Agile transformation. For a different example; the belief that “It is best to get everything right up-front” of a pure waterfall approach is in direct conflict with the belief that “the best way to get things right is to try something and learn from the feedback this generates” of the Agile approaches.

To change mindsets, we would need to change the beliefs that underpin them. We can split the reasons why people believe, into three broad categories: scientific, political, and religious. Don’t get too hung up on the names; what matters is why people hold their beliefs and what can happen to change them. Scientific thinkers need to know and understand a reason why their beliefs should change. Political thinkers need to have someone they respect persuade them that other ways of thinking are better. Religious thinkers are intractable but occasionally have an epiphany that changes their belief. It is difficult and unreliable to manufacture these, and attempts can entrench existing thinking.

Maybe we don’t need to change the mindsets. It might be sufficient to persuade people (on both sides of a difference) to consider that other points of view might have value. This can become easier if we can discover shared goals; points of agreement from which only the approach to achieve them is in dispute.

It turns out that this approach of opening minds to the potential benefits of opposing ideas can be very valuable. Time and again we find that the best approach is at neither end of the scale, but instead at a “sweet spot” that balances the forces and harvests the best aspects of either end of the scale. For “Theory X, Theory Y,” a modicum of directed instruction might set people up well to self-organize. For “getting things right upfront vs. learning through feedback,” we soon find that a small amount of up-front work puts us on a track that makes the feedback we get more valuable.

We should not look for a “religious transformation” from unthinking adherence to one mindset to unthinking adherence to another; that takes a lot of effort for little benefit. Better to reach a world view that can dispassionately view and acknowledge the benefits and downsides to each side of the argument, in order to reach a balanced approach appropriate to the immediate context.

About The Author
Paul Oldfield
Paul Oldfield graduated in Botany and moved later into computing in the hope of getting paying work. Since 1985, he has worked in a wide variety of organizations, domains, system types, and roles. Highlights include air traffic control, expert systems, inland revenue, anti-virus, among many others. He specializes in what makes ways of working appropriate to the context. Currently he is living in the Scottish Highlands, assisting a local start-up… Read More