Where do you sit as your Agile team's designated business expert?

Where do you sit as your Agile team's designated business expert?

"You're doing it wrong!"

If I had a dollar for every time I've heard an overbearing Scrum Master, misguided "Agile expert" or overzealous individual claiming to be an Agile coach say these or similar words, I'd be a rich man indeed.

What is right or wrong is often situational in Agile. The Scrum Master who insists that you must sit with the team may or may not be correct as to where you would be most effective. The idea that there is one and only one correct answer to the question of where you should sit is too simplistic.

Read More

"Draw Left": Why Communication Matters

"ROCK!!!" Despite my warning, the ominous scraping sound moments later told me we were leaving a bit of our canoe behind us on this trip down the Shenandoah River. This little encounter is an example of what my son jokingly calls "painting the rocks" based on the red vinyl marks we sometimes leave as reminders of our passage.

Normally, when canoeing, we try to avoid collisions, and at first I was puzzled and a bit upset that my son had not reacted in time to maneuver the bow of the canoe out of the way. He's a skilled paddler and a simple stroke of his paddle would have been all it took to slip by unscathed. Why hadn't he done what I expected?

Well, in the somewhat heated discussion that ensued, I discovered that I hadn't exactly been clear as to the location of said rock. Besides, I had the advantage of polarized glasses and despite being in the stern, generally was able to see submerged obstacles well before my son. Lacking this critical information, he simply pulled the business end of his paddle out of the water and let me steer assuming I had it all under control. Had I wanted him to do something, clearly I would have said so.

On reflection, admittedly much later and after much fuming, I realized that we could have avoided the rock if I had simply shouted "Draw left, now!" Never mind trying to point out the rock. Avoiding the rock was the goal. Getting the front of the canoe to shift to the left was what was needed now.

Our collision resulted from a failure to communicate. We had mastered the right paddling techniques. But, we hadn't mastered the practice of communicating in a language that would enable us to operate as a team. In the end, it shouldn't have mattered whether or not my son could see the rock. It only mattered that he know what was needed.

At the shout, "Draw left, now!", my son would have simply put into action what years of practice have make into muscle memory. He would have reached his paddle far out over the water to his left, slipped the blade into the water, and, with a quick stroke, pulled the flat side of the blade toward the side of the canoe. The bow of the canoe would have shifted to the left and aided by a stern draw or even a simple angling of my paddle on my part, the canoe would have slipped by leaving that rock unpainted.

In a team environment where a rapid response may be necessary, whether canoeing downriver with a partner or as a team member on an Agile project, it helps to have a common language or lexicon to foster quick communication. The right words spoken at the right time tend to lead to the correct action. The use of words outside the lexicon may lead to undesirable results.

It takes time and practice for a team to create a common language. Once developed, instructions like "Draw left" result in quick and efficient responses. Giving an instruction like "Rock!", which is not part of the language, is often inefficient and ineffective. Developing proficiency or fluency in the team's language is essential to the smooth flow of the team's work.

What is your team's language? How proficient are your team members in their way of communicating?  Consider both business language and technical language. What are the words that are unique to, or have a special meaning, in your environment? For example, the word "forging" means different things to a banker than it does to a blacksmith. The phrase "breaking the build" has a meaning unique to the practice of continuous integration. Knowing what this phrase means is essential to the team to know what action is required next. Investing a bit in creating and practice in learning a common team language will pay off well in improving your team's communications proficiency.