The Sherpa Project

From The Tao Of Programming…

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?’”

“It will take one year,’” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.

So true.

Stay small.

Over the past couple of days, I’ve been pulling together a simple Information Radiator for CruiseControl.net. The idea behind the project is to use the power of visualizations to provide simple, visible, and informative displays that expose the current-state of your automated continuous integration builds.

I threw this app together very quickly a week or so ago and I’ve been amazed at how addictive it’s become. In our team room, we have a dedicated monitor that is always running the application. The result is that you know exactly where the builds stand as soon as you enter the room.

I initially wanted to put this together as a temporary solution to picking out what items we will use to show our build status. We always bounce back and forth about Nabaztag, orbs, lava lamps, and other physical things to show our build status. It’s usually easier to find an extra monitor than it is to get a purchase request approved for a wireless-enabled rabbit. Big Visible Cruise is the same idea, it’s just a visualization instead of a physical device. Judging by how much we all enjoy seeing it, it will probably stick around in addition to any physical device we pick up.

You can find out more about the project at http://code.google.com/p/bigvisiblecruise/. After the holiday I’ll post some pictures and explain how we are utilizing the big display in our team room.

In the meantime, you can likely get an idea from looking at the display while it’s monitoring three different projects in the following screen shot…

This shows that I have three projects (Foo, Bar, and Some Project) being run on my CCNet server. In this example Foo and Bar are successful and Some Project is broken.

The other state that isn’t represented in the pic above is the “building” state. When a project is building, the row representing the project will turn yellow.

By default, BVC will poll every 15 seconds. I recommend using BVC with CCTray so that you have a big visual display along with auditory clues about your build process.

Big Visible Cruise is being released under the MIT license.

If you’re interested in WPF and/or information visualization, I’d love any contributions
I plan on providing some interesting visualizations over the next couple of months. Let me know what you’d like to see on the RoadMap page.

An interesting facilitation technique that I’ve learned to frequently rely on is silence. The first time I ran across the technique was in a CSM course taught by Hubert Smits and Tamara Sulaiman. One of the exercises that we explored was Silent Grouping. The exercise was great and worked very well in the context of the training session.

When I returned to work I started trying various techniques with silence and most of them went very well. The majority of our facilitated sessions were very large and it was usually a constant challenge to move off of side conversations and keep the group focused. One of the techniques that frequently returned good results was using time-boxed silence alongside various other techniques that are used often in agile meetings (brainstorming, prioritizing, sorting, grouping, etc.).

There just seems to be something about the ability to become rational, absorbed, and focused on the task when the “no talking” rule is in effect. It frequently seemed easier to drive towards consensus when the group used silence as a method for creating, grouping, and processing information.

I sat down to catch up on a little reading this weekend and have been making my way through The Wisdom Of Teams. This is a very interesting book about the observations of various types and levels of teams, the way teams perform, and the characteristics of each respective type.

I’ve always viewed teams as teams and recognized good teams by “that feeling” that you get when you participate in one or see one in action. Beyond “that feeling”, I really hadn’t thought about the categorization of teams beyond a “good” and “not-so-good” level. This book has been very interesting because of the research and observations that they have done in grouping the different categories as well as comparing and contrasting the different types.

Throughout my time in the IT industry I’ve seen all these categories of teams and participated in each respective type. One very relevant point from the book is the discussion about the differences between working groups and teams. This really hit home with me because of the methodology changes that I’ve been involved with as both a consultant and an FTE.

The image below shows the different categories discussed in the book and the evolution of performance when moving along the curve.

One thing that I’ve noticed from starting up various initiatives to move towards agile methodologies over the past couple of years is the thrashing that occurs when you move from a command-and-control structure (usually accompanying traditional methodologies) to a self-organizing structure (more prevalent with agile methodologies).

It’s rare that a new agile team hits the ground and starts performing as a “high-performing” team in the first couple of months. I’ve never seen it happen when the team members are coming from traditional methodology backgrounds. I really think this can be expected because there is so much happening so quickly. This scenario is usually very disruptive and usually overwhelming from the standpoint of the individuals on a new team.

While the leap from “working group” to “potential team” can be a rough experience for many individuals, the progression from “working group” to “real team” (and possibly to “high-performing team”) is a pleasure to watch and a pleasure to be involved with.

So, what is the difference between a “working group” and a “team?” The book recognizes the basic distinction as performance.

“A working group relies primarily on the individual contributions of its members for performance, whereas a team strives for a magnified impact that is incremental to what its members could achieve in their individual roles.”

I think that the giant leap in forming a team for most individuals from a command-and-control structure is the blurring of roles and shared accountability that occurs on a team. Most individuals in command-and-control organizations or models think from the standpoint of individual contributions while a true team focuses on mutual accountability and the contributions of the team. This is a hard leap to make, but the benefits (both organizationally and personally) are usually tremendous.

There is a really interesting article here that looks at how various colonies and groups self-manage. This article has some interesting ramifications to thinking about how we communicate as humans and how we communicate in different team environments. There are also some interesting thoughts floating around in mind about how some of the tools that I typically use could be modified to be more useful.

Why Penguins Have No Commanding Officer [InsideKnowledge]