It started as a parody on the many cringe worthy, cliché ridden, corporate presentations we have all been subjected to. But for IJYI it came to represent one of our core values.

It grew with an ever-increasing frustration with our project staff for using chat tools to communicate when they sit within arm’s reach of each other. But it became a key behaviour in our teams delivering high quality software within a competitive timescale.

The simple message to our staff was that in all cases we had to

“Prioritise face to face and verbal communication over all other mediums.”

This included when working within the team and equally importantly when working with our customers.

No more faceless emails from developers, no more misunderstanding the tone of a written conversation and certainly no more disappearing into a comms black hole because you didn’t want to admit you didn’t know the answer. It was time to front up, talk to each other and collaborate as directly as physical boundaries allowed.

This was far from a new idea and this certainly isn’t the first time that I have tried to do this but this time it has really stuck and that seems to be because I gave it a name:

“Tic Tac Toe.”

The name itself has little or no discernible relationship to what it has come to mean. If I remember rightly it surfaced as I tried to wedge some buzzwords into some kind of recognisable acronym for a Quarterly staff meeting. A friend of mine said “the T must stand for Transparency and/or Trust” to which I responded “if you like,” but truthfully that is at best, a happy coincidence.

So why does it work and why does it make such a big difference?

I can only speculate on the answer to these questions and any conclusions are based purely on anecdotal evidence but I think that the core problem in IT is that your customers don’t trust you and developers (and bloggers) can be quite insecure and competitive with each other.

Let’s take the first of those two controversial sweeping generalisations and relate it to “Tic Tac Toe.” IT is complicated, expensive and notoriously poor at delivering to an agreeable timeline. The Scrum process is designed to address these issues by putting the customer at the centre of the software development process and insists that they work directly with the team delivering the value.

The problem is that the process is not usually a happy collaboration but more of an ongoing negotiation and the term negotiation brings up the very real possibility of conflict. Most people will go out of their way to avoid conflict no matter how essential or innocuous it maybe. In IJYI, the way round this was to reduce the chances of direct conflict by hiding behind impersonal communication mediums or not talking at all. The thing is, you can’t avoid it. It is not only required it is inevitable. All the approach did was delay the inevitable and make the problem a whole lot worse.

By embracing the values of “Tic Tac Toe” the team started talking on a daily basis directly to the product owner. To be clear this was not via a BA or PM, in a stand-up meeting or some other mandated forum. This is every individual member of the team talking to the PO directly to ask questions and validate assumptions as and when the need arose. The effect was to:

• Shorten the feedback loop to minutes
• Almost entirely eliminate misunderstandings of requirements prior to the story being built
• Vastly reduce issues found by the customer
• Increase the throughput of completed work

The second of the sweeping generalisations is regarding the nature of developers. Every team has a broad range of personalities and skills but almost across the board no one likes to admit they are wrong. This directly impacts our ability to operate a continuous improvement approach to delivery and leads to unnecessary delays through issues not being surfaced.

One to one chat channels, emails or waiting until a designated meeting all reduce collaboration and increase the feedback loop, especially when it comes to highlighting tricky technical problems.

In this case the words “I need your help” become your biggest friend. “Tic Tac Toe” encouraged developers to talk face to face on an adhoc basis and to try and use this phrase when starting any conversation. In 99% of cases if you directly ask someone for help they will do exactly that. Try it next time you are in a restaurant or any kind of service environment. It actually makes a difference.

For us the effect was to enable our continuous improvement on a daily basis and not just in the sprint review meetings. It also facilitated knowledge sharing and stopped any misconceptions at source. It flips the “not wanting to be wrong” paradigm on its head because it started to become “I want to be right.” Everybody wanted to be the person who spotted the problem and solved the issue because it was obvious that by doing so they moved the delivery forward and gained some standing in the team.

In the end, I knew this was starting to work when someone parroted it back to me. I sent a chat message and was immediately confronted by a developer with a big grin on his face who announced at the top of his voice for all to hear “Tic Tac Toe!!” It was also obvious that the noise in the office increased and our customers started referring to our staff by name. It was even identified by a key customer as the reason why they thought a project was going well. They told me “We have seen more of you in the first two months of this project than we have seen all our other suppliers in the last year.” It is now an integral part of our USP.

Ultimately the improvement in communication, in conjunction with a DevOps mind set, has delivered an improvement in morale, increased our rate of successful delivery and built trust with our customers. While “Tic Tac Toe” might not be the right brand for everyone, it is having a brand that seems to be the important factor in making this simple and obvious behaviour stick.