subscribe via RSS
All I wanted was a huge TV hanging above our workspace displaying the build server status page. Too much to ask from the enormous IT market in 2015? Apparently.
We bought a 50” Panasonic LED TV (thankfully, with a generous corporate discount). The facilities folks eventually hung it on the wall and provided a quad power outlet and a network drop for whatever device we were going to tuck up there.
I thought we would just plug in a Chromecast and browse to our build status page. Haha, you have to be kidding me! You can’t just run a browser. Neither can the Amazon Fire TV Stick, Roku, or Apple TV. The Amazon Fire TV supports a browser, but only if you enable developer side-loading and want to run Mozilla Firefox unsupported.
Don’t forget, you might need to authenticate to your wifi network via captive portal. The Amazon Fire TV has that feature now and some of the other boxes will be getting support later.
You need a third-device “casting” to the dongle full-time!
- Chromecast (or similar)
- The device that’s actually doing the work :(
There are a variety of reasons not to do that…
- Don’t want to remember to login to see the dashboard
- Don’t want to leave a desktop session live and running all day (security)
- Don’t want a reboot for Windows updates to take down the dashboard
The “set-top” box category of devices are letting us down. So, we’re looking for some kind of full-blown PC in a mini-box. Maybe the Asus Chromebox? Nope, it’s running ChromeOS, which can’t be authorized to connect to the corporate network.
The guest network doesn’t have permission to access the dashboard without a firewall rule exception request.
So, now we have a $1000 black rectangle hanging on the wall. I’ll let you know what ends up working.
- The corporate network requires domain authentication and/or some kind of device registration that requires meeting some arcane security measures.
The developer in this story had been attending status meetings. These were good meetings, they were attempts at transparency and cross-functional communication. They were snappy and there was always time for questions.
For weeks, the project management team had been presenting the general status of the many releases that were in various stages of the software development lifecycle. Yes, there were released versions in support, receiving patches and hotfixes, versions in active development, and versions being planned and experimented on for future release.
The statuses were like:
- Bad, we’re going to miss a deadline or slip a feature. (
- In trouble, we’re trending downwards. (
- Good! Everything’s on track. (
And the presentation of these releases and status often looked like this, let’s say that 1.0 is the current released version, 2.0 and 2.1 are in various stages of development or testing, and 3.0 is in planning.
| 1.0 | 2.0 | 2.1 | 3.0 | |-----|-----|-----|-----| | - | ~ | ~ | + |
Of course, we’re “trying hard” to meet that deadline or to get that feature in. But, are we reorganizing the teams around the most important goals? Are we communicating hard messages to customers about that future service pack so that we can meet the 1.0 goals? It’s not really clear sometimes.
Let’s skip ahead and look at the reported progress as old releases rolled out and new ones popped in.
| 2.0 | 2.1 | 3.0 | 4.0 | |-----|-----|-----|-----| | - | ~ | ~ | + |
Wait, a minute… 2.0 isn’t improving and 2.1 is still in trouble. But, look, 4.0 is doing great! The key understanding was a quote(ish) from a project manager…
Of course, 4.0 is looking good because we haven’t started working on it yet! (chuckles)
If you understand that “working on it” means “starting the development phase”. The problems start when the damn developers get their hands on the perfect requirements. You’ll see, over time, that the statuses are fixed. They’ll always appear in that state in that order. The releases simply roll over them, like a wave.
| 1.0 | 2.0 | 2.1 | 3.0 | 4.0 | 4.1 | |-----|-----|-----|-----|-----|-----| | - | ~ | ~ | + | | | | | - | ~ | ~ | + | | | | | - | ~ | ~ | + |
I believe that the feedback loops between the teams are broken. The organization is not collaborating across the teams towards a shared goal. There is no real change, so the statuses will never change.
Though we don’t readily admit it, the team I’m on is part of a remote organization. We have offices in multiple time zones, work-from-home folks in different states, and offshore partners. We are trying to build a culture of remote/async work even when a lot of meetings happen in this office.
One part of that is encouraging collective ownership of meetings. For example, we started holding “lightning talks”. Mostly around technical topics, by developers for developers. But, everyone is invited and we’ve had QA folks and IT people come by and talk, too. Even managers got on board and started presenting softer topics!
I’ve been scheduling them, hosting the audio conference, starting the screen share, etc. But, that makes me a bottleneck. I want anyone to schedule these and for a quorum of participants to be able to start the meeting without waiting for some “official” meeting host.
Most enterprise email/calendering systems don’t make this easy because you can’t transfer ownership of a meeting or assign multiple owners. I’m looking at you, Outlook. So, I quit using recurring meetings. A recurrence makes it “mine” instead of “ours”. I developed a nice template that anyone can copy, edit, and deploy for their instance of a lightning talk.
Your audio conference line won’t start without the host. All the participants can be on the line, unable to chat, listening to muzak. Ugh. Not to mention, we have to “order” a conference line from our Corporate IT catalog! Virtual meeting rooms and screen sharing tools (like WebEx) have the same strong idea of single ownership. The host starts and controls the meeting. Without the host, you have no meeting, no sharing, no chat, no video, no recording.
So, here’s what we do to enable and encourage collective meeting ownership (some of these are specific to our tools, but you’ll get it):
Schedule the virtual meeting “room” for every day of the week for the longest possible period. WebEx doesn’t allow a 24-hour room, so we schedule two 12-hour meetings. This allows anyone anywhere at any time to start or join a virtual meeting. WebEx now has the concept of “personal” rooms that are always available. This is another option! But, a “permanent” room allows some kind of branding or titling to make the purpose more obvious.
Configure the virtual meeting room so that the first participant to sign in is the “presenter”. We don’t want to wait for a “host” to assign presenter permissions. This also lets the presenter get started and setup their rig early.
Provide the host key/code in the meeting agenda so that any participant can claim the host role and start a recording or configure this instance of the meeting. Again, the goal is not waiting on a single designated host!
Similarly, provide the host audio conference key/code to all participants so that the first participant actually starts the audio conference and they’re not stuck listening to hold music. It also helps to disable entry tones (the “bing” or required “say your name” part). We need to stop saying “Who’s on the line?” every time!
Allow the participants to use as many features as possible: chat, video, notes, file transfer, etc.
Be sure to record the meeting and provide a streaming and download link, a transcript (or minutes, etc.), and any relevant notes on a wiki and as a reply to the meeting invite, so that all the participants have access.
If you must require a code to dial in to the audio line, most phones should support commas (soft-pause, around 2 secs) and semi-colons (hard-pause, requires you to tap a button) between the conference number and the code. For example:
You should provide the link to the downloadable recording, because who wants to stream the recording when WebEx’s plugin asks for these permissions?
If you’re awesome, you’ll convert the recordings to a normal format using their recording editor.