2013-01-04 Artemis Contact Report - Work Team Building Exercise

I wrote this Contact Report after playing Artemis at my office. I billed it as a Team Building Exercise and wrote this report to emphasize the Team Building aspects of the game in hopes that we will be able to do more of these at work.

Artemis Team Building Exercise
Ship: USS Rita South Central Flotilla.
Crew: ID Team at NetIQ.
Port of departure: School House. 17th floor. NetIQ offices. Houston, TX.
Stardate: 2013.01.04 Noon-1:00 lunch. 2:00-3:00 missions.
Eric Mallory reporting.

Setup
Except for me, we were an all-rookie crew, so we took it slow. We started with lunch and a briefing. We covered the basics of the game and watched a 15 min console overview video narrated by a guy who desperately wants to be Hikaru Sulu "The weapons officer doesn't drive the ship, she shoots things." I was so excited to be having such an adventure at work as a Team Building exercise I was beaming.

We ran Artemis 1.66 with the ItBLnF mod as provided by Dean Mallory. One crewman commented:
It did help that we were familiar with the original Star Trek series. The stations and tactics appear taken from the Kirk-era Enterprise. Knowledge of these old episodes took away some of the "What am I supposed to do here?" fears of the first couple missions.

We started with a crew of 12. We followed the Pair Programming model: One person drove the console, the other navigated. We rotated between every mission. The Navigator rotated to the Driver position. The Driver rotated to the Navigator position on the next console. We successfully completed six level-one missions in the two hours we had scheduled. We were supported by a veteran crew of three. They provided setup and break-down manpower (I should more specifically say Brother- and Nephew-Power), functioned as on-site technical support when consoles went down, inserted peanut gallery commentary as appropriate, volunteered for red shirt duty, and even knitted a line or two on my winter scarf. Between each mission we debriefed as a crew, focusing on what we wanted to keep doing, stop doing, and start doing.

I captained the 1st mission and we hit on most of the basic functions and tactics of the ship:
• Navigating the ship around the sector
• Launching an ECM and a Nuke at the enemy (a popular combination)
• Announcing our arrival at a starbase and docking
• Performing a side mission to get extra coolant
• Raising and lowering the shields (very important)
• Scanning an enemy to get status and shield frequency
• Targeting an enemy, setting the appropriate beam frequency, and firing beam weapons
• Dropping mines
• Overcharging systems to improve their efficiency

As hard as it was for me to give up the captain's chair, after our first mission, I inserted myself into the rotation and navigated at the communications console. Our next Captain took command with nary a mutinous look.

Debriefs
As a team-building exercise, I thought it was very successful. Our debriefs went well with lots of discussion on how we were performing. In addition to the obvious:
• Don't fire an ECM at a starbase
• Remember to raise shields before entering combat
we observed several key areas where we could improve as a starship crew and talked about how they directly relate to areas where we could improve as a team at work.

Communication is Key:
We observed that in this simulated, high-stress environment, it was important for each member of the crew to bring the information they had to the attention of the crew. A side mission available only on Communications does not benefit the crew if Communications does not announce the mission loud enough for at least the Captain to hear.

At NetIQ, we encourage all members of scrum teams, core teams, and the ID team to be engaged, vocal, and visible.

Bias Towards Action
At first, the crew would notice something they should do and they would ask the Captain for permission to do it. This got to be overwhelming to the Captain. So we looked for ways to empower the crew to take action and notify the Captain. This came up several times. As a rookie crew, we were reluctant to take initiative for fear of doing something wrong. Repeatedly, our Captains appreciated the crew suggesting overall tactics and taking the actions necessary to complete our mission successfully without waiting for confirmation from the Captain on each action.

At NetIQ, we encourage everyone to see what needs to be done, and do it. Not to wait for approval for, confirmation, or for an approved plan. This bias is particularly true when working with people eleven and a half time zones away, when waiting for approval could easily cost us 24 hours. Instead, we encourage everyone to do the next right thing and keep the interested parties informed of what we are doing. Course corrections do not cost us as much time as we save by taking immediate action.

Communication Really is Key
In addition sharing information, we found it was important to communicate the appropriate information. We learned to listen when Communications announced a side mission. However, the mission details were long and took too much time for the Communications Officer to go through completely. We had Communications share the most important information first (the benefit of the side mission) so the Captain could make a quick decision on whether to pursue the side mission.

At NetIQ we strive for clear and economic communication. In meetings where many people are present, we encourage everyone to say what needs to be said and move on. Stand up meetings are meant to communicate what was done, what will be done, and blockers. Other information, like design discussions, are taken to a more appropriate forum. Further, we discourage the repeating of information multiple times in the same forum.

Vision and Direction
The crew found we performed better if given clear vision and direction from the Captain. "Dock with DS2" is very clear direction that we could work together to achieve. With this direction, Science got us a heading and range, Helm used that information to get us there, Communications got the starbase ready for our arrival, and Engineering raised power to maneuverability and warp when appropriate. This worked better than the Captain keeping the fact that we're going to DS2 private and issuing turn-by-turn orders to each officer.

At NetIQ, we've seen how micro-management does not work. Once again, this was particularly significant when working with geographically diverse teams. We do better to give clear direction and vision and trust the distant team to get the job done. We have also been working lately on clarifying User Stories so we are all clear on what it is we are building. The better we do at clearly documenting and communicating what we want to do and what we expect of each other, the more efficient we become as a team.

Did I mention that Communication was Key?
The more we worked together, the better we got at communicating with each other. The last few debriefs all included an item where someone brought up a crucial piece of information that helped us significantly.
• Engineering asked, as we were going into battle, if the shields were up? They were not. Weapons sheepishly raised the shields, and Communications found the Red Alert button.
• We fell in love with the ECM/Nuke combination. All the Captain had to do was identify the next target. Science fed heading information to Helm, Weapons complained about running out of ECMs and Nukes while loading the last two, and Communications was finding out which starbase had enough on hand to resupply us.
• After we noticed the friendlies would happily plod straight into a singularity or mine field, Science and Communications were talking with each other non-stop about how to direct the friendlies on a more useful course.

At NetIQ we encourage non-shaming feedback and discussion. Multiple clear-thinking individuals can come up with a better solution to a problem than a single one. Communication really is key in a business that profits from the creative collaboration of smart, motivated individuals who get together as a team to fulfill a common goal.

Confessions of One Reluctant Captain
"Oh, crap!" and "I have no idea." are not successful morale-building slogans.

Which reminds me we did talk about deciding to doing something quickly vs. spending more time analyzing the situation. The crew thought we were better off making a decision quickly and starting to do something rather than doing nothing while spending more time evaluating the situation. In the instances where we changed our mind, stopped doing what we started, and did something else, we did not lose much time. In the instances where we finished what we started, we benefited from starting earlier. This might should go in the Bias Towards Action section.

At NetIQ, we embody this idea through the Agile development and a bias towards action.

Next Time

I think we could have done better, as facilitators of the exercise, to insert some lessons learned. For example:
• After the team noticed how important communication was and how we're communicating too much or not enough, we could have brought in some examples of how clear concise communication can help:

COMMS: Captain, I have a mission to get us coolant.
CAPTAIN: Not now COMMS, we don’t really need coolant.
OR
COMMS: Captain, I have a mission to get us 2 more nukes.
CAPTAIN: Let's do that one.

CAPTAIN: Dock us with a starbase that will get us some more nukes.
SCI: DS2 is the closest SB.
COMMS: DS2 doesn't have any nukes. DS1 has 3.
SCI: Heading to DS1: 280. Range: 21K.
HELM: Turning to 280. Give me High speed turn.
ENG: High speed turn.
HELM: Done with high speed turn. Heading is 280.

Then we could have practiced using better communication, correcting communication in real time, and evaluating if the change helped.

At NetIQ we regularly participate in sprint retrospectives and evaluating and improving the team's performance. We could have used this as an opportunity to practice.
• When we noticed that we were less effective when we waited for the Captain's approval to do something, but as a rookie crew we were reluctant to take action for fear it would hinder our progress towards success, we could have shared our experience around how much permission we give the crew and what things require explicit permission from the Captain. This is from the South Central Flotilla Officer's Handbook:
Bias towards action.
Each officer is empowered to do the next right thing if that action:
• Advances us towards our goal
• Does not interfere with an order given by the Captain.
The following actions are the only actions that require direct confirmation from the Captain:
• Loading tubes
• Firing Nukes, ECMs, or Mines
• Taunting the enemy
With this information as a starting point, we could have discussed how much autonomy we wanted to allow and been very clear on what everyone could and could not do without permission.

At NetIQ, we encourage a bias towards action and believe explicitly stating expectations increases satisfaction and efficiency.
• We started the missions with very little information on the technical specs of the ship. After each mission we could have shared more details.
• Specs on each of the weapons
• The things Communications can do
• Engineering presets
This detail would have improved our game play. I'm not sure it would have improved our team building.

In the end, a good time was had by all.