Telerik blogs

A few months ago I wrote to you about why teams succeed. I talked about the “high bandwidth” team that stressed communication and collaboration. While I believe that communication and collaboration are the keys to success of any team, I always felt that there was another important component to the equation.

I visited a large retail global customer here in Hong Kong today. They are working on a large application for their product development group using Silverlight 4.0 and have teams in the United States, India, and Hong Kong. We were talking first about their use of Telerik tools and then the conversation moved on to teams and process. They are having success and are using the agile methodology Kanban. When I left, they were proud to show me their Kanban board with all of their user stories, tasks, features, and burn down.

clip_image001

That is when it hit me; the other component of highly successful teams is transparency. I started looking back throughout my career and looked at the high performing teams that had successful projects and the very successful ones were the ones that had the magic combination of high bandwidth and transparency.

I remember ten years ago building the original Zagat.com at the height of the .COM boom. We held “open staff meetings” where our weekly staff meetings were attended by other managers from around the company. Our own version of a Kanban board was posted outside the door of our main room. We were still using Microsoft Project and Gantt charts, each chart for each project was hanging outside of the room as well and updated daily. That level of transparency built trust with the organization and enabled us to work with the business closer.

I use to get pushback from the team about our transparency; the team did not like transparency when they were behind schedule. My argument was that we had to show the good, the bad, and the ugly. Besides, it is a well-known fact that we are motivated to work hard not by money, but by our creativity and the chance to produce something truly awesome. I figured that if we make that process more public and transparent, the employees would be even more motivated. By making our product development cycle public, the team took more pride in what they did since everyone was watching.

In addition, this process solved minor disputes between team members. Once when the VP of Marketing was at our open staff meeting, two developers were arguing over something petty. They forgot that the VP of marketing was there and later told me that they “looked bad” in front of the marketing VP. The next time I made sure that the founder of the company was at our staff meeting. Everyone on the team got the message and the transparency worked.

I was also very transparent with the business information coming into IT. I use to disseminate our monthly sales numbers (which were a closely guarded secret) to the whole department. The CEO asked me to stop since IT were the only people in the company besides the senior management to know this information. I responded with even more transparency and shared with the team our profit and loss information as well. (The CEO was not happy, but to her credit, she did not stop me.)

The Agile movement really helped push the importance of transparency forward. The very intention of the Scrum or Kanban board is to be public; same with the daily scrum meeting. If the business is engaged and attending your meetings, there is going to be more productivity and much less friction. Luminary Kent Beck wrote a white paper on agile tooling and teams where he stressed transparency. Beck says:

“When I started programming the weekly status report was sufficient. Here’s what I did this week, here’s what I’m planning to do next week. Press fast forward twice, though, and the weekly status report becomes as quaint as a debate about the relative merits of assembly language and higher level languages. … transparency is a choice you make to offer trustworthiness to you teammates. A transparent team can more cheaply and effectively coordinate their efforts towards shared goals. Acting transparently sends a signal to others that they can trust you. Trust, when realized, reduces the friction of development as people focus more on what they are accomplishing together and less on avoiding blame.”

Ten years after my experiences at Zagat, it is even easier to be transparent. There are many tools that help with transparency. Kent Beck also states in the white paper:

“One way out of the Reporting Dilemma is to stop explicitly telling people what you are doing. Instead, rely on your tools to infer your intentions from your activities and report that for you.”

Agile teams usually publish burn down charts and team velocity charts to report progress between iterations. In an effort to be both more transparent and more automated, the industry has moved to Agile Dashboards, dashboards that read from your repository and automatically publish your burn down and velocity charts as well as other vital information related to the iteration and build process (including my personal favorite, who broke the build.)

Several vendors offer an agile dashboard, such as i.e. Rally’s Team Status Dashboard, VersionOne, and of course Telerik. Our Agile Dashboard, a free tool, posts all the important details of a project on a dashboard for the whole world to see. This tool is meant to be on a large TV, hanging over the receptionist’s desk when you walk into a company complete the status of the current iteration, burn down charts, and even a photo of who last broke the build.

clip_image002

This decade will be remembered as the era when technology teams fully embraced transparency. As teams start to automate their transparency and look for ways to be more open, the quality of the software they produce will only improve. I look forward to this brave new (open) world.


About the Author

Steve Forte

 sits on the board of several start-ups including Triton Works. Stephen is also the Microsoft Regional Director for the NY Metro region and speaks regularly at industry conferences around the world. He has written several books on application and database development including Programming SQL Server 2008 (MS Press).

Comments

Comments are disabled in preview mode.