Semaphore

In agile software development, an information radiator is a (normally large) physical display placed in a prominent location in an office, where passers-by can see it, and which presents an up-to-date summary of the status of a software product or products.[1]

The best way we’ve found to keep the team informed of the build status is to display it high on a wall near the team as a big red or green indicator. When there’s only a single project going on, we’ve found that a screen that’s simply all red or all green is effective. At Pivotal Labs, though, we have many projects going on at once. Rather than putting numerous TVs up on the wall, we’ve created an application that aggregates multiple projects onto one page.

Tddium

Edward announced this four years ago as http://ci.pivotallabs.com. A year later, we open sourced this as Pivotal Pulse and then renamed it CIMonitor. That lasted a few years, until we integration Pivotal Tracker details, which prompted a rename to Project Monitor last year.

Cruise Control

Fast forward to me joining Pivotal Labs in November. Project Monitor was on the walls of our office, but the radiator had a leak. Our internal Project Monitor instance was running on a server in our Director of IT’s office. During Sandy, every monitor in SF timed out trying to connect to our nyc-based ci servers. We had serious scalability issues that affected polling, the delayed job queue was unreliable, and our codebase needed a code debt payment plan. There had been a few dedicated sprints to triage open wounds, but a long running branch for an eventmachine based polling refactor had lingered as a pull request from several months ago.

This is pretty common in older codebases, especially so for internal projects that don’t get any attention unless they’re on fire. Even worse, the backlog had suffered from being on autopilot for too long. I’ve seen this happen in many products that have been in the market for a while — they’ve checked the box on value proposition and moved onto “wouldn’t it be cool if” type functionality. I was informed that I’d take the reigns as Product Owner and we had a mini-inception on my first day.

Team City

Beyond ramping myself up on a new codebase, I struggled to sort out who Project Monitor’s stakeholders were and what its remit truly was. Because consumption is inherently passive, I couldn’t rely on metrics or many of the other tools in my belt. It was working, but was it solving problems?

Luckily, two key events helped me crystallize a thesis for what PM should be. First, during a trip to our SF office, I realized how broken support was for our newest CI, Travis. The CloudFoundry team, which had just moved in-house, was growing frustrated with confusion over which of their (40+?) builds was actually broken vs. broken on a branch vs. just not broken. With no beach in sight, I carved out some time to push a fix and heard a collective sigh of relief from the CF team.

Shortly after, a hiring surge paired with a project ramp down created a large team of Pivots ready, willing, and able to tackle our backlog. My colleague, Johnny Mukai, sent on a reflection on how things were going and his concerns for the product’s direction:

It’s felt great to dig into Project Monitor and take care of some traditionally thorny pieces of the app, merge in some long running branches, and revel in the camaraderie of being on a large team again.

As we plow through open issues and Project Monitor transitions from ‘please fix this’ to a ‘what new features shall we implement’ kind of project, I have some reservations. In my experience, Pivots use Project Monitor for one thing and one thing only and they only want it to do one thing and it had better do that one thing well. (One. Thing.)

The build goes red, instantly I understand that something has run afoul. On a board of builds where only two things happen, it’s obvious that I need to immediately address this. On a busy board with a million things going on — some of them open to subjective interpretation — it’s easy for me to just glaze over. If it were important, there would obviously be a giant red notice for me, somewhere.

Closer (by Travis) [2]

Click. At that moment it was clear to me that Project Monitor is a dashboard for engineers and product owners building a product. Not a devops board, not a metrics showcase, just an indicator that someone needs to act. Not everyone agrees, but being opinionated is the only way to ensure that a product stays relevant.

We just spent time reimagining the Tracker portion of our status screen, and I’m proud of all the collaboration and feedback the company gave as we broke down the problem, released and refined.[3] I saw Project Monitor running in a colleague’s office this weekend, and even fielded a support question from a Windows user in Finland! Stepping into a new product as PM is hard; if you find yourself in that position I encourage you to work on a clear thesis that guides your efforts.

Project Monitor today. See our repo for more information on getting started.