hen was the last time your boss dropped in to ask you for an update about your current project? For most people, it might happen once a week, but for increasing numbers of people, the answer is never, as they work offsite or away from the other members of their development team. This is all well and good … unless you’re the one that needs to know what your team is doing!

There’s a better way to exchange information of this type; a way that would put status data into a simple gauge-like format that can be consumed at a glance. And devices to deliver this kind of usability already exist. I believe that the introduction of aptly-named glanceable objects will come to play an important role in managing software teams, and to a large extent supplant and replace the real or virtual informal status updates we now exchange with our colleagues. Glanceable devices provide information drawn from the network visually without requiring user intervention. The speedometer on your car is a predecessor to this kind of device: you don’t boot it up and ask it how fast you’re going; instead you look at it; if the needle’s buried in the red, you know you’re apt to get a ticket.

Products like Ambient Device’s Ambient Orb (Figure 1) perform the same function, but can take their data from the network. Devices like these can display the value of a measurement using color, animation, or needle placement at a glance throughout the day; observers can use what they learn from the device to decide whether more investigation is necessary in much the same way a small-team manager can read the looks on her team members’ faces and decide to call a team meeting to find out what’s up. Where I work at Rocket Mobile, I’m using just such a strategy: The Ambient Orb on my desk can present either recent CVS activity (helping me gauge the need for increasing peer reviews and the level of risk from rapid change), the shift in our found/fix bug ratio, and whether our nightly builds are successful.

Figure 1. Glow Bug, Glow: An Ambient Orb on a manager’s desk can give them instantaneous, nearly subliminal understanding of project status data at a glance.

Technology is largely responsible for the growing number of remote workers, so it’s only logical that managers are increasingly turning to technology to solve these new remote-worker problems. In traditional office settings, meetings and informal water-cooler talk help provide both explicit and implied communication about a project’s status. But when teams are distributed geographically, managing communication becomes much more difficult. When Internet Messaging, email and conference calls replace casual contact and meetings, both the tone and content of communication change, often for the worst.

One such use is to collect metrics to form an administrative dashboard. This concept is not new; customer relations management (CRM) and sales management software have used the idea for years. In his book Software Project Management: A Unified Framework, (Addison-Wesley) Walker Royce suggested the use of a similar concept in software development for software managers. Today, you can see the concept evolving in interfaces such as SourceForge, where a glance at a project’s home page can provide an overview of the development status of a project, number of contributors, number of pending tasks, bugs, and so forth (see Figure 2).

Ironically, the metrics provided by SourceForge are often better than that collected by corporate software teams! Many small organizations neglect the importance of metrics, whether or not the team is collocated. Neglecting metrics can create its own set of problems, but is often kept in check simply because the organization’s manager is comfortable with the style and nature of the team and can intuit a project’s health by being around team members. Unfortunately, as the team grows (or goes distributed), this strategy doesn’t scale.

Larger successful organizations (distributed or not) turn to various metrics to help measure software progress. Personal metrics, such as those set out in the Personal Software Process (PSP) can help individuals track their progress towards project goals. For team-wide measurements, everything from the much-maligned line count to methodology-specific metrics such as project velocity as well as quality coverage metrics such as found vs. fix ratios and defect density help track overall project status. Of course, which metrics you choose are a function of management style and your organization’s choice of software methodology. Regardless, the purpose is simple: Metrics give management a measurement of progress.

Enter the dashboard: a high-level snapshot of project status for management. But how should you present that dashboard? Scripts can generate a great deal of this information, so email output from the generating scripts is an obvious place to start. Unfortunately, with the large volume of email present today, people file automated reports in the trash almost as fast as they file spam, making it a poor choice for many. A project Web page is an excellent place to start, especially if your organization already has one or uses a wiki for collaboration. This can be especially powerful if you combine the project summary with other relevant information for management through syndicated news, creating a page that people are likely to make their home page in the workplace.

Figure 2. Forge Ahead: Project metrics from a sample project team is shown in use on SourceForge.

A better alternative, or at least a solution that augments other displays, is to represent a concise summary of project status through a glanceable device. The interface to a glanceable is much the same as the subliminal messages you get from locally available team members: an indication of project tone, which prompts investigation if needs warrant. Interaction is both convenient and instantaneous; it doesn’t require additional effort, and its ubiquity allows others in the same setting to obtain the same information.

It’s easy to interface a glanceable with the remainder of the administrative dashboard, too. At my job, I use an Ambient Orb in my office (I picked it because integration was easy, not because of any special properties of the Orb itself) driven by a set of scripts that monitor the health of our daily build as well as the rate of project changes in our source code repository; a separate script can direct metrics from our bug database to the Orb. A glance at the Orb tells me if our sources build and how fast things are changing; when the orb begins blinking or turns a deep red, I know something’s up that requires hands-on attention, and can turn to the project wiki and bug database for the details. It’s easy to channel other information, too; because the interface to the device is via the Web using XML, just about anything you can measure through an automated process becomes a candidate for summary via these devices.

I predict that glanceables will play an increasing role in both large-team and distributed-team efforts, but that their value will pay off most in the latter category. Once an organization decides to observe and collect metrics, the low cost of integration and intuitive interface makes introducing a glanceable device trivial, and the gains immediate. At the same time, they continue to extend and capitalize on the benefits of the metrics they draw upon, providing empirical evidence hard to obtain with more informal interpersonal communication. Moreover, because the very nature of a glanceable is both immediate and unobtrusive, it fills the natural human desire for subliminal information collection, a need largely unfulfilled in other aspects of communication employed by distributed teams.