the “empty chair test”

I’ve been using the term “empty chair test” for many years. I recently learned that it’s not a commonly used term. In fact, I googled it and this blog post is the only reference I can find. Oh well. I’m going to continue using the term. It’s clear to me and mostly self describing.

The idea is that when you hire an employee, consultant or contractor, he/she needs to quickly be providing more value to you than an empty chair.

Day 1

It’s rare for someone new to pass the empty chair test on day one. That’s because day one is centered around getting the new person a computer, setup, teaching him/her what you do, etc. It has happened though. We had a contractor search Google on his phone and find out how to do something that needed research. (while waiting for his computer to be setup.) While I was particularly impressed by this, I don’t have any expectations of someone passing the empty chair test on day one.

In fact, I’m surprised if I get 50% of my work done on day one because my focus is training. I do try tao pair as much as possible on day one. For example, I showed last summer’s intern how to write a Groovy script and then he did some. I could have gotten it done way faster myself. But he learned something. And then later in the summer when I needed that done, I didn’t need to be involved at all. So a good investment.

This is the key. You want to invest heavily in training new people. It pays off later! And if subtract that time from what the new person is accomplishing, it is unlikely you break even right away. No worries there!

A month in

By a month in, the new person should be getting things done. Either independently or pairing depending on your culture.  The new person probably isn’t as fast as people who have been there longer as it takes time to learn everything about a new system. That’s normal and ok. However, it is a red flag if you are still spending more time training the person than he/she is accomplishing. It’s also a red flag if there is lots of re-work required. Or the new person is still arguing with you about team practices. Bringing up a practice in a retrospective for improvement is fine. Refusing to do something is not.

By a month in, if your team (including the new person) would be accomplishing more with one less person, it’s time to revisit what to do. Aka if your team would literally be better off with an empty chair, if is time for a conversion with the person, a new strategy for acclimated them or to think about saying goodbye.

Notice how I didn’t account for the fact that you are paying the person yet. Whether so and so is worth X dollars a year is a test that is higher than the empty chair test. However, if the person can’t pass the empty chair test on a timely basis, there is n’t much hope of them passing the “earning their salary” test.

Longer

At this point, it is time to get rid of someone who isn’t passing the empty chair test. It’s time to start earning the money he/she gets paid rather than be compared to an empty chair!

Using Agile Games to improve meetings – the virtual/remote edition

This evening, I went to the NY Scrum User Group where the topic was “Using Agile Games to improve meetings”.

As the presenters went through the games, I thought about how they could be adapted for a virtual/remote team. I spoke about Virtual Scrum last year at a Birds of a Feather session. I’m doing a presentation/breakout session at Spring One on the same topic this year and looking forward to adding an agile game or two that applies to remote teams!

In thinking of remote equivalents, I wanted to preserve the sense of fun along with the message/goal of the game. Here’s how that went.

Story Cube

The Story Cube game involves rolling dice and talking about feelings based on the dice. For more, see this Story Cubes description. The only part of this that is physical is the dice.

As a remote alternative, I thought about having pictures with each of the images and using a randomizer to display some on screen. Then the talking would proceed the same as if the images are on the table.

Dana Pylayeva (one of the presenters) noted there is a phone app if you want to spend $2. (That’s a lot cheaper than the physical dice by the way.) We searched for it during the meeting and found Rory’s Story Cube app. Looks cute. With the app, you’d need one per site.

Feelings Game

The Feelings Game involves physical EMO cards with feelings listed on them. Each feeling has a number next to it. In response to a prompt, each person writes the number of a feeling on a post it. The post its are randomized then the group discusses. For more, see this Feelings Game description.

This time there are two parts to make remote. The feeling cards part is easy. You make a web page/powerpoint slide having a table with numbers and feelings listed. Or you have each site print a copy. Or you buy a set of cards for each site.

Then you need a way to anonymously share the number everyone chose. There are a number of online shared whiteboarding services. I like web whiteboard because you don’t even need to login to use it. What’s more anonymous than a site you can use anonymously! (you likely don’t want to use google docs or one note because either the author is tracked or the perception is that it is)

Fist of Five

Fist of five is a survey technique where everyone holds one to five fingers up at the same time. For more, see this Fist of Five description.

This is really easy to make remote. My team does “finger voting” frequently. Especially at sprint planning. We do thumbs up/side/down voting. We do story point estimate voting. (When we were a collocated team, we used planning poker estimating cards. When we became a distributed team, we used pointing poker for a while. Then we had a retrospective suggestion to use our fingers instead and it took.) We do voting from a multiple choice list to see what people think of design tradeoffs.

Anyway, finger voting is easy over video conference/Google hangout/etc as you see each other. if you can’t see each other, pointing poker is good for voting. You can set it up to use any options you want. So you can choose the numbers 1 through 5 instead of estimates and you have fist of five.

Ehab El-Badry shared with me this anonymous fist of five tool. Nice!

My Right and Mrs Right

In this game, the facilitator reads a story and the team passes legos left and right when they hear “right” or “left” in the story. Those words come up a lot. I couldn’t find the exact story used at the meetup, but a similar story is here. Then she asked questions about the story. And we hardly listened because so fixated on the legos. (It was also more complicated because she had everyone holding two legos and changing hands in addition to passing them. I think this was to make the task harder.)

Clearly we aren’t passing legos around remotely. But I think any sufficiently complicated task would work and have the same effect. It loses a tiny bit of the team bonding but that wasn’t the main point of this learning game; it’s about the shared knowledge/reference for why multi tasking doesn’t work. Ideas of remote friendly tasks to replace the passing of legos in a circle:

  • Put a paper clip in the left or right pile when you hear those words
  • Count the number of times left or right comes up (this might be too easy)
  • Count how many words are mentioned that contain three letters

Beautiful meadow

There’s lots of physical objects in this drawing game. There is a large paper, multiple colors of markers and a page of requirements. For the details/text of the game, see this beautiful meadow description.

We clearly need a shared document tool for this. We could use web whiteboard. For this game, there is no need to be anonymous so Google docs, OneNote or your favorite collaborative editing tool works. After splitting up the different groups into different shared document URLs, the moderator would drop the instructions into each board and keep time. Participants would have to be instructed to only communicate through the shared doc – no IM! But other than that, it’s equivalent.

Clapping/Raising hands

This was an unofficial game. “If you hear me, clap once” or raising hands to get everyone quiet. These work through phone or video chat respectively.

WIP Game

I can’t find an online reference for this game, but it is easy to explain. Half the group tries to write “I must limit work in progress” five times as sentences. The other half does the same but by writing “I” five times then “must” five times then, well you get the idea. About halfway through the time it would take to do this, the group is interrupted becuase the project ran out of budget and figures out who can deliver full sentences.

The only thing to change for remotes is to determine who uses which approach. Physical colored cards don’t work. But counting off or a random number or anything else to split up the two halves works.

Constellations

An object forms the center of the room. Then questions are asked and people move closer or further away. For more, see this Constellations description.

I’d make this remote by using a collaborative editing tool like web whiteboard, Google docs or OneNote. I’d either put an image on the center of the whiteboard or draw a giant dartboard. Then I’d give people a color to use to represent them or type their initials in the spot where they would “stand”

Candyland

I can’t find an online reference for this game, so I’ll describe it. We stood in pairs in front of colored pairs. We spent a minute talking about what we learned and then moved X spaces.

I think this is the most challenging to make remote friendly, but it is still possible.  At the beginning, have everyone pick a number. Randomly or by choice. Then have #1 and #2 chat, #3 and #4 chat, etc. After a minute, have the numbers shift.

Conclusion

Being on a remote/virtual team often requires a little imagination. But it’s fun. And easier than you might expect to adapt to.

“why did you decide not to be a developer”

Last week, I got asked “why did you decide not to be a developer” by a junior developer while we were pair programming. My first reaction was “I am a developer”. My second was confusion as we were writing Selenium/JUnit code at the time of the question. She was typing and I was the navigator. (In this particular pairing session, she was the driver for 95% of the time as I’ve worked with Selenium extensively and she had never used it before. The only times I drove were for a few “Java idioms” where I wanted to show how it was done.)

After I got past my first two reactions, I gave a far better response. Another teammate IM’d me to say it was a good explanation and I replied that it would make an excellent blog post. So here’s that blog post.

There’s different types of developers

I’m currently on a Dev Ops type team. We do tools and consulting to teams creating business applications. (usually web apps but not always.) I consider myself a developer. I write code. I deliver software. Sometimes that software is a standalone tool we wrote. Sometimes it is automation for an open source tool. Sometimes is it is customization. Sometimes it is automation of a task. Sometimes it is a requirement that the open source software doesn’t meet. But I write code regularly at work. I also read code regularly to troubleshoot open source code.

Frequency of coding on my previous team

On my previous team, I was a business/web application developer. Towards the end, I had advanced to the point where I was the tech lead and SQE (software quality engineer). And this was a decent sized team so it took up time. I spent a lot of team mentoring others, doing analysis, in meetings, etc. I didn’t code every day on that team, so typing code can’t be the measure of a developer role. Interestingly, the code I write on my current team is often harder/more technical than the code I wrote on my previous team!

First time idea of being on the dev ops team full time

A teammate floated the idea of me being on the tooling team full time a good number of years ago. At that point, I wasn’t even able to think about it. I needed the experience of being a tech lead/architect/whatever of a larger team before I was willing to “specialize”. So I understand the question. But it’s not a matter of not being a developer. It’s a matter of being a different type of developer.

My title/department

My title is still developer and I’m still in a development department. That hasn’t changed. So my company thinks of me as a developer too. It’s just that our customers are now developers too while they used to be the business.

Programmer vs developer

This wasn’t in my answer, but I want to include it here. There’s a difference between being a programmer and a developer. We aren’t just boxes that take in detailed requirements and spit out code. That’s true on any team.

Finally

Finally, the good news is that she asked the originally question because she was impressed with my coding skills.