Nodding Is Not Enough

Using nodding heads as criteria to determine team understanding, alignment, and commitment is kind of risky.

Wikipedia defines it. A nod of the head is a gesture in which the head is tilted in alternating up and down arcs. In many cultures, it is most commonly, but Not universally, used to indicate agreement, acceptance, or acknowledgment. [http://en.wikipedia.org/wiki/Nod_(gesture)]

I will define nodding as binary output from an individual with a "true" value in a giving context. Yes, I am nodding or not.

But, the million-dollar question is. What are you nodding to? What component in the diagram? What part of the plan? Remember it could also mean: Yeah Right! And I'm Chuck Norris!

Having said that, would you rely on nodding heads as way to determine people buy-in and understating in your project?

Well, this post is to foster software engineers to make their peers to "produce content" in their team interaction. Because nodding heads is not enough.

The reason why is important to make people generate content. Is that this is the only way ambiguities will surface. Many times it had happened to me that I thought I knew something, until I tried to do it. The same thing happens in a team. There are many misconceptions that need to be revealed, preferably as soon as possible depending in the criticality of the topic. It is your job to help catch them.

Now I am going to cover some of the activities that helped our team members identify misalignment and improve communication.

Daily Status Meeting (15 min)

We started every day with our daily standup meetings, which last no more than 15 minutes. In which people "produced content" answering three questions, what did you do yesterday, what are you doing today and do you have any issues? We also addressed any important reminder.

Common time & Cubicle Discussions:

Having all the team available at the same time in the same place. Is the best you can get. Having team members to talk in the cubicle open the opportunity for people to produce content by asking question, writing in the board or even thinking out loud.

All this availability of information lead to uncover many issues and solved them right away issues.

Status meetings (45minutes):

These helped the team to keep aligned with our plan, tracking data and quality.

In this meeting different team members had the opportunity to produce content (Planning, Tracking, Quality). An important lesson from these meetings was that presenting content in the similar format systematically kept people focused on the data.

Topic of the week and Sanity Checks:

This is an activity we did to proactively make people "produce content" on important topics such as architecture, processes and planning.This helped considerably to surface team misalignments.

As can be seen during our studio project we invested a lot in team communication.

However, that was not all. There were some software engineering practices that provided other communication channels. These were Fagan inspection and Pair programming. These practices complemented communication areas that were not covered with the previous techniques. Specifically, they improved knowledge transfer of coding practices and technology specific concepts. Also, Fagan and Pair Programming required continuous participation of different member to identify issues that could impact quality.

All this investment paid off with team alignment, good environment and a good client survey result. So, my recommendation is to have different ways to assess team alignment instead of assuming too much.