The Square Root Poster

For our final reflection poster (pdf) the team decided to try something a little...different.



It's a supergraphic:

Supergraphics are interpreted by the viewer on their own terms. Allow an audience to absorb the information at their own rate. Sure, you may wish to call attention to certain details, that’s why you’re in front of them, let the audience come to their own conclusions and this can generate fruitful discussion during or following your talk.

The best example of a supergraphic is Napoleon's War of 1812 march to Moscow by Charles Joseph Minard. It's great for a number of reasons: it's high resolution, multi-variate, indicates causality between variables, and uses great graphic design. With this map as our guide, and advice from Tufte gleaned during one of his excellent seminars (students are only $200!), the Square Root team attempted to create our own, as shown above.

Reading the Poster

The X-axis shows time logarithmically spread to show the relative effort spent in each semester.

The Y-axis shows team morale. Morale is really trust as measured using our regular team dysfunctional surveys. These surveys were taken from Patrick Lencioni's The Five Dysfunctions of a Team in which trust forms the basis of a well-functioning team.

The thickness of the line shows team maturity. Maturity was measured through our team reflection process in which we asked three simple questions. "Is the process documented?" "Is the team following the documented process?" "Is the process working for the team?" Quantitative answers to these questions let us get a notional idea of maturity and qualitative responses helped us to improve as a team.

The branching tributaries or excursions, leaving the main trunk of the graph show processes that the team was able to execute independently of other processes. This is another way of thinking about maturity. For example, by the end of the summer the team had matured such that we could tweak individual processes without affecting other processes.

The annotations on the graph show what the team decided were the most critical moments of our project. Critical moments are events which had a significant and immediate impact on the team in some way. You can read about many of the stories behind the critical moments on this blog.

Analyzing our data as a supergraphic allowed the team to see things that we would not have seen otherwise, to think about and reflect on the project in a way that no one else has thought about it. Some interesting things that can be seen in the graphic:

• The forming, storming, norming, and performing team stages are clearly visible
• The effects of better visibility on morale (we were blissfully ignorant in the fall)
• even negative things can be a positive as was the case in our planning breakdown
• Commitment to process can lead to big pay-offs
• Small changes can have a huge impact on a team and the changes should be made.

In addition, it just plain looks awesome.

Our Message

There were two big messages that we wanted people who read our poster to take away.

First, there is no single right answer except "it depends." We designed our poster so you can take away messages that are meaningful to you. As you can see on this blog, every member of the team has taken away different ideas from the studio experience. The poster was meant to reflect this by making it easier to share advice on a wide range of topics, all of which will be interesting to someone but not all to the same person. Tufte puts it best: create an image which allows readers to explore the data using their own cognitive style.

Second, since there is no single right answer and no best way of doing things, experimentation is the key to success. The studio environment is an ideal time for experimentation. Success or failure is not nearly as important as understanding why you succeeded or failed.

Enjoy exploring the data. If you have questions, please feel free to read through our blog or any other data in our project archive. If you have questions, don't hesitate to get in touch.

[Edit: We've got video of the presentation too!]

Power of Presentations

No, I am not talking about Powerpoint today.

I am talking about the presentations that are less obvious—the ones we do every day. We are constantly doing presentations, although we are unaware of most of them.

You are writing an MSD paper---that’s presentation. No matter how well thought-out your content is, if you cannot spell correctly, you’re dead. Your readers will think, “s/he can’t even spell—s/he obviously cannot say anything intelligent!”

You are serving food on the table---that’s presentation. If the noodles look like worms—no matter how tasty they are, no one may touch them.

You are sending out a wiki page to your teammates---that’s presentation. You may be wanting feedback on the content and the format, but if the pictures are awry, you may get some different kind of feedback.

My grandma told me a story when I was a kid.

A great king once saw a dream. He saw himself waking up one morning to find out that all his teeth have fallen, except for one. Terrified, the king woke up from the dream (and made sure that all his teeth were still remaining).

The next morning, he called the royal wizard and asked him for the meaning of this dream. The great wizard thought for a while, and his face darkened. He said with a sad face, “Your Majesty, this dream means that all your relatives would die in front of you. You’d be the last one remaining, all alone.”

The king was so angry at this bad news that he took out his sword and killed the wizard instantly.

The following day, the kind summoned the wisest man in the land, and asked him the meaning of the dream. The wise old man thought for a bit, and his face brightened up. “Your Majesty, this is great news,” he exclaimed, “You will be the longest living among all your relatives!”

Call it euphemism or call it polishing, the wise man survived because of the way he presented.

So lastly, when you are communicating with others---that’s presentation also. Be very aware of what you say, as you may be presenting something you don’t mean to present.

Architecture and Communication

My post today is going to talk about how software architecture can be a vehicle of communication.

What is Architecture?

Wikipedia defines architecture as the structure or structures of system, which comprise software components, the relationships among those components, and the relationships between them.

When software engineers think architecture, they primarily think of architecture and documentation and diagrams of the above-mentioned structure. And the popular “architecture” sites support such notions.

For example, Wikipedia lists the Common language infrastructure architecture as this:

The documentation suggests that all the code of the different languages get compiled to Common Intermediate Language. However, it does not say some significant things: Does the compilation support the full-fledged language or does it apply restrictions on the languages for compilation? Can the languages communicate with one another? And most importantly, what quality attributes does this architecture support, and why?

Any such diagram can raise these questions, and it is important that the development team is knowledgeable about the answers. Without architectural knowledge, the team may not have a good big picture view of the system.

This "lack of big-picture view" happens in both small and big companies. Roni Burd, a program manager at Microsoft, discovered this issue with his Bing development team. He had to take action to raise the architectural awareness of the team. I have noticed this also at my new job, where the software is too large to comprehend without proper architectural perspectives. Without good architecture documents, the team members each get familiar with parts of the system, but no one can really talk about the system as a whole.

It is the architect's job to ensure that the development team is adequately knowledgeable about the answers to these questions. S/he can share this knowledge through documentation or architecture workshops or through any other means.

We used the following activities in Spring and Summer to raise architectural awareness:

ACDM architecture reviews:

We conducted architecture reviews throughout Spring. In these reviews, the architect would present a partitioning of the system, and explain the rationale for that partitioning. Then the team would raise and record issues with that partitioning.

What we could have done better:

We should have been more upfront about giving feedback on architecture. We all had different ideas and impressions on the architecture, and we could have done a better job at harmonizing those differences. We could not relate how the pictures and diagrams of the architecture related to the actual product. If we implemented parts of the application, that would have given us a concrete mental model of how the architecture and the actual software were connected. With that mental model, we could have been better at communicating our differences of opinion about the architecture.

Architectural documentation:

Architecture documentation was our key way to communicate in Spring and Summer. These were up-to-date diagrams of the system, with design rationale relating them to the quality attributes.

What we could have done better:

Since we were implementing the product in summer, we could have improved architectural communication by printing out the architectural diagrams and posting them in the cubicle. This would have allowed the team to question and verify the architecture as they were implementing the system.

Topic of the week:

We did have some verification of the architecture at our 'topic of the week' sessions. 'Topic of the week' was our way of addressing misconceptions. Each week, at the status meetings, we budgeted some time to talk about a topic that we needed to communicate across the team.

At the architecture sessions, we addressed the following questions: how the architecture decomposition related to the implementation, and how were the quality attributes supported.

What we could have done better:
We could have addressed more architectural topics. There were questions on how did our package structure relate to our static architecture, and why were packages decomposed the way they were. These could have been better addressed early in the project to clarify the responsibilities of each package. That would have reduced some architectural refactoring work.

Avoid Project Assumptions

Assumptions are the root of all evil on a project.

Why wasn’t the branch release made today?
The quality assurance manager assumed someone else was going to do it.

Why is this code so sloppy? It’s barely readable!
The lead developer assumed that wasn’t important.

Why didn’t anyone mention this problem earlier?
The team lead assumed folks would raise concerns before they became problems.

Why are we using this communication mechanism between the client and the server?
The architect assumed the modifiability quality attribute was not important.

Why was I the last to hear about the new quality assurance process?
The process manager assumed someone else would let you know.


The fastest way to project failure is to make the wrong assumptions. At the beginning of any project, especially when there’s a brand new team involved, there are going to be assumptions. People come with biases – judgment is one of the things humans are really good at. The more assumptions you can avoid as a team, the better off you’ll be. Write down your thoughts, talk about your history and experience with everyone on the team, write down the decisions you’ve made throughout the project, and record the justifications you used to make those decisions. But whatever you do, don’t assume.

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.