All Hands

Many leaders are having difficultly with “All Hands” type meetings in a remote setting. The ones I have spoken to find that the meetings lack the usual level of participation that they are used to and there can be a disconcerting lack of feedback on the information that is being conveyed

Introverted people will tend to stay quiet, extroverted people will seem to expand to fill the silence and this will be amplified in an online setting. Even the usual advice of “turn your video cameras on” is of limited use when you’re speaking to a large group of people as eventually you run out of screen real estate. As a facilitator it can be pretty challenging to get people to participate at the right levels.

I’ve written about meeting etiquette before here. Effective meetings tend to limit the number of people involved to the absolutely necessary. Therefore you need to consider what the meeting is for. In the case of an “All Hands” this is often to radiate pertinent information across a department or company. You might normally expect people to raise their hands and ask questions to clarify points that you have made or so that you can expand on the things that you’ve said. Obviously that’s somewhat more challenging in an online setting.

Some online tools have a “raise hand” functionality to flag when someone has a question which you can encourage people to use. Most video conferencing has chat functionality as well which can be used by all participants to type their questions. If you are going to use these tools, you may need to delegate to a helper to monitor these live channels for feedback and to let you know when it comes in.

Looking at a contemporary example outside of the workplace, Twitch is a platform for live streaming video games. Often each stream will have hundreds or thousands of viewers at once. Twitch presenters will often take time out of their games to read live chat and respond to questions. This usually occurs when they are in a loading transition or waiting for something to happen in game. Applying this principle to the workplace, build in this time to your meetings or use transitional periods for questions if you have multiple presenters in your meetings.

If you are giving the same “All Hands” multiple times (say, in different time zones), then keep a note of the questions that get asked. It is likely that you will get some questions that come up multiple times and some different questions too. Use these questions to put out an FAQ after the meeting for anyone that misses it. Add to this FAQ if more questions come in at a later date via other channels.

If you don’t need to convey the information in a live format, think about other channels in your company that you can use to radiate this information. Good communicators will use multiple channels to make sure the information they are conveying reaches as many people as possible.

This isn’t unusual anymore – some help with hiring remote workers

The UK government has just announced that they are shutting their schools and we’ve all been working remotely now for a week or two. There are now lots of people offering advice on how to do things better, now that we’re all in a distributed environment.

One of the challenges I see coming down the line in the coming months will be hiring. Everyone will be able to say that they’ve worked remotely, it’s no longer an unusual thing. Even when we do overcome the challenges that a pandemic brings, many companies may decide to stay working remotely or at least have policies which allow their employees to do so more often.

So how do you tell if the person you’re interviewing is any good at remote working? Is this their most effective way of working or do they need support? Here are some questions you can ask to get a feel for how that person is in a remote setting.

• Tell me about a time where you worked remotely for a week or longer? How did it make you feel?
• What’s the hardest thing about working remotely? What can you do about it?
• What do you think your last team would say about the time you spent working remotely?
• What kind of support did your manager give you while you were working remotely? Did it help?
• Tell me about some difficulties you had while remote working that you didn’t overcome? How did you cope?
• What is your home office like? Do you always work from there?
• If you were to go back in time, what would you do differently if you were going to start working remotely for the first time again?

Obviously you’ll still need to assess whether they can technically do the job or not, but that’s a subject for another time.

Some things you weren’t expecting about remote working and what to do about them.

As the UK government moves into phase 2 of their plan for dealing with COVID-19, many private businesses will begin initiating their own strategies for business continuity while attempting to delay the spread of the virus. Many of the IT-based businesses I know are either closing offices entirely or are strongly encouraging their staff to work from home.

There is plenty of advice on how to work from home efficiently. I’ll not go into much detail here, I’ve covered it in the past both on this blog and at conferences. Most of it is common sense and should apply regardless of whether you’re co-located or not.

For example, if you’re having a meeting:

• Make sure you have an agenda. What are you trying to achieve with the meeting?
• Make sure you establish ground rules, how do people contribute to the meeting?
• Should people be fully present, or be doing other things at the same time, like coding or sending emails? (Hint, it’s the first one)
• Are you taking minutes, and if so where are they?
• Where are you recording any follow-on actions?

In a remote setting there are a few extra things to do to help you work and communicate well. Remember to turn your video cameras on if you’re taking a call. Make sure your mic is working and is of decent quality. Make sure you have a comfortable working space with a decent chair (assuming you have space in your home).

But that’s not what I wanted to talk about in this post. There are also some other things that might happen that you should be aware of when you start working from home for more extended periods of time.

You’ll get longer periods of unbroken time and you’ll probably get more stuff done. On the flip side of this, you may end up working longer hours. In order to avoid this, set yourself some boundaries. Choose times and stick to them. You might choose to start work at 9 have lunch at 12:30 and stop working at 5. Remember to take breaks. Consider using the Pomodoro Technique or similar to divide up your work and time.

Working from home requires you to be more disciplined and communicate more. Some people will find it easier than being in an office, some will find it harder. If you’re a manager you will need to dedicate a little more time to staying in touch with your team(s) as you’ll find the levels of support you need to give people will be different to if you were in a more traditional setting.

You’ll probably have to use multiple channels to communicate. If you’re using instant messaging, some people will find it easier to communicate directly into a channel and this helps spread knowledge which is good but it’s not for everyone. Some people will feel more comfortable talking on private channels or on calls. Unfortunately I’ve not found one silver bullet that makes this all easier, but experiment frequently and find something that works for you. The main thing is to find a way to reduce the isolation that can lead to loneliness and mental health issues.

Be sure to encourage social, non-work related interaction. If you’re going to be working from home for weeks on end, consider building in opportunities for social interaction. Having an instant messaging channel for this is a good start but make it fun! Ask random questions or grab some (work safe) Cards Against Humanity black cards.

Er… COVID-19?

Think about getting your team to post pictures of their lunch or you could get together for a “remote beverage bash”. Grab a drink of your choice and talk about non work related things for 15-30 minutes.

If you’re in a country that hasn’t had all social gatherings and venues shut down and you’re not showing signs of the virus (fever and/or cough), make a special effort to catch up with other people in your life after work. Do it now, while you can. Nobody knows how this situation will evolve.

Most of all, look after yourself. Physically and mentally.

“You need Terry on your project? Ok, here’s what you need to know…”

Sometimes people move teams. The reasons why can be varied. It could be that that person’s skills are needed on a different set of work. maybe to drive their personal development you need to provide other opportunities for them. Or perhaps they are unhappy for some reason. Regardless of the reason, it’s going to affect your organisation. By adding or removing a person from a team you are changing the team dynamics of two teams. In order to help keep both the teams and that individual happy, you really need to understand what makes them tick.

If you’re the manager that is losing a person, you hopefully already have a working relationship with that individual but you may not have had the head space to figure out how this is going to affect your team. If you’re the manager that is receiving a new team member, you might already have a fair idea of what your team needs but you may not know the person that is joining you.

Depending on your organisation, the hand over of line management may happen casually between two managers, with little to no structure. When I looked online, I couldn’t really see anything to help this transition. At the very least you should have a conversation with the line manager who is giving up or receiving the line report. Before you have the meeting, try to summarize (in writing) what the reasons for the move are. It’s good for everyone involved to be on the same page.

For the process of handing over itself, I came up with a few questions you can ask or answer to ease the movement of people around your organisation.

Happiness

What motivates / demotivates this person?
Are they happy at work?
Who are their friends at work?
Do they have any triggers for things that upset them or that they have particularly strong opinions about?
Are there areas where they’ve been particularly happy or excited to work on in the past?

Communication

What are they like on a 1:1 basis?
What are they like in a group setting?
Have they raised any concerns or needs over the move?

Work/Life

How well do they manage their work / life balance?
What do they do in their free time? Any hobbies?
How is their general well-being (both home and work)
What are their regular working hours/days?
Do they have any “invisible” commitments outside work that we need to ensure they’re supported with.

Personal Development

What personal goals are they working towards?
Do they want or need training on anything?
What was their biggest success recently?
Have they struggled with anything recently?
What are they hoping to get from the change?
Do they have an existing buddy/mentor/coach – will that relationship change if they move?

Support / Management

How do they prefer to be supported/managed
Are there any current issues or problems that need managing
What did they like / dislike about their old team?
What are their strengths and weaknesses?
Do they have any preferences/strengths/issues working with particular technologies or environments.
When are they going to move and sit with the new team?

You might not have, or be able to get all the answers to the questions but finding out as much as you can will give you a head start in being able to build rapport with your new line report.

Because we’re all terrible at breaking down our work.

Most of the teams I’ve worked on have been not so great at breaking down the work that lands on the development backlog. There are plenty of resources out there on what stories are, and multiple different ways of writing them. There’s also articles written about different story splitting techniques. I couldn’t find anything out there about deliberately applying the theory however so I thought I’d write something.

Before I dive in, lets start with some definitions

Epic – Also known as a “very big” story, that is unlikely to be completed in a single sprint or planning cycle. Would normally be broken down into several stories before being pulled onto a backlog. Epics can also be used for defining the main focus of a development team for a series of sprints.

Story – A smaller piece of work that can fit into a sprint or planning cycle specifically aimed at providing value to the end user and/or the customer. It can be good to apply the INVEST criteria to any story that you’re writing or at the very least include some acceptance criteria to define when a story is complete. Typically a story would be written in non-technical language to make it accessible for all interested parties to discuss. There are lots of different ways to write stories, Here’s a link to some sample formats.

Task – Pieces of a story that describe how the story is going to be achieved. These are usually written by the people doing the work. They should generally be short lived and completed within the sprint or planning cycle.

Splitting patterns

When examining a story (or an epic), you’re going to need to break it down. This has already been written about in much more detail over here. To keep things simple, I’ve summarized some of the commons ones:

• Most difficult bit first (What’s the hardest piece of the story to solve?)
• Simple case first (What’s the simple solution to the story?)
• Functional first (Make it work, worry about performance later.)
• User flow (What’s the first thing the user does. What’s after that?)
• Per use case (What does user A want to achieve? User B?)
• Per operation (buy a subscription, change a subscription, cancel a subscription)
• Spike (What questions do you need to answer in order to know more about the solution?)

This is great! We now have some lines of thought we can use to think about our stories. We need to practice using these deliberately so as to get used to using them naturally and to ensure we don’t fall into the trap of using one or two of them over and over again.

Kata

Much in the same way as you’d practice different coding techniques in a coding kata, you can practice breaking down stories into tasks in a similar way. There is a little preparation to do in advance of your task break down kata.

Before you start, you’ll need to define some problems to split up. The problems should be large enough that they can be solved with multiple steps. Some examples might be:

• Make a banana split
• Go on holiday abroad
• Buy something from an online store
• Set up a new computer for a relative
• Organize a party.

Try to work out if your problem is an epic or a story. If you’ve picked an epic, can you split it and write each story against the INVEST mnemonic? You want to end up with a few stories that can the broken down during the task break down kata.

Running the session

Split up in to groups of 2-3. Participants should be anyone that needs practice breaking down stories into tasks. If you can, try to make sure there is a mix of disciplines breaking down the selected story.

Choose a splitting pattern from above or from elsewhere, then take 10-15 minutes to apply the pattern to break down one of the stories. After you’ve applied the pattern, try to think around the edges and work out what was missed. What else needs to be included to make the story “complete”?

If you have lots of participants, compare and contrast results with other groups in the kata. Once you’re done you can try splitting the same problem again using a different pattern or use the same pattern on a different problem. Some problems will lend themselves better to one type of splitting pattern that others. Just keep practicing and you’ll get better at knowing which pattern to use for what kinds of problem.

Experiment: Working as a fully distributed team

In the first week of December I ran an experiment where our entire team was made to work remotely from the main offices. The aim of the experiment was to experience what our remote employees feel every day and to improve team communication, both within the team and external to it.

Our team is probably one of the most distributed engineering teams in Metail. While most of our engineers are in the Cambridge office we have a few that work remotely. We’re lucky enough that those guys are in the same time zone but nonetheless we still suffer a lot of pain that distributed teams feel, especially when the rest of the company is more used to working between Cambridge and London.

Our hypothesis was that we would probably miss out on a lot of incidental “water cooler” conversations. We also guessed that communication with the rest of the organisation would be somewhat difficult.

Before Kick off

I had to lay some groundwork before the experiment began. Firstly I checked with our crew director and the other engineering managers that this wouldn’t impact anything crucial. We communicated widely across multiple channels that our team would be entirely remote in the week before start date. I spoke to the team as well to hear their concerns. It certainly helped to draw up a few guidelines and at a high level we came up with:

• We’ll used Slack by default and Skype as a backup
  • We will say when we are at our keyboards and when we’re not
  • Everyone will use headset and have their webcams turned on.
• In general we will try to ensure that we are over communicating
• If there is a problem or someone can’t be reached, people are to come to me (the engineering manager) or our crew director.

There were a few practical things to take care of as well. We made sure our contact details were added to all the meeting room Skype accounts and we checked we could all access internal resources via the VPN. We also had a couple of trial calls to make sure Slack and Skype would work for us (they did).

So how did it go?

We were able to anticipate the problems we hit; there wasn’t too much that was unexpected. It was much harder to run work past people on a casual, in person basis. Attempting to do so required both parties to mic up and jump on a Slack call.

Meetings with the wider company is where we struggled the most. We noticed that people in Metail occasionally talk over one another and because of this it was hard to participate in guilds and other group meetings. Usually it meant one person in the office would drown out another who was further away from the room mic. We also noticed that if there were multiple people in the office participating in a meeting, remote workers often ended up ignored. In some cases it was difficult to observe body language that would normally be cues for a person to start talking. From time to time it was hard to hear people in the office. Sometimes this was because of problems with the audio equipment, other times it was because of background office noise.

We encountered a few minor technical issues as well. Some of these things were easy to fix like tweaking rules on a firewall. Others were harder to diagnose like why a developer was seeing Jenkins time out during load, preventing him from being able to see when builds were finishing. A couple of times we had issues with Slack where one person in the group couldn’t see another but these were easily fixed by leaving the call and re-entering it.

Generally speaking the engineers found it easier to focus on the work they were attempting to do. On the other hand it was pretty difficult for myself and our crew director being the main communications interface between the team and the rest of the company.

I also discovered that my house gets really cold during the day if I don’t put my heating on! I made a special effort to be a little more social, going out to dinner and to the pub for much needed social interaction.

Conclusions

On the Monday following the experiment we ran a retrospective where we recorded our experiences. On the whole, the world didn’t end and the company kept working. We recognise that it was a pretty short experiment, lasting only a week. We certainly affected how the rest of the company interacted with us by communicating that it was coming up. I have a better understand of the pain our remote people go through every day and I’m going to be reminding people in the office about it in the future.

If you engage with remote employees or are planning to in the future, here is what I’d recommend:

• When you’re having a meeting with remote people and it’s possible for everyone attending to have mics then do so.
• Let remote employees know if you are starting a meeting late.
• Respect meeting etiquette and allow all attendees to fully express themselves. Don’t interrupt until they’re done speaking.

Breaking sabotage techniques.

Recently I came across this article which talks about how some of the sabotage techniques in a declassified CIA field manual mirror some of the more frustrating parts of some company cultures. I’ve included an except below:

Interesting reading! Especially when you compare it to decision making processes in business. It’s pretty much exactly what you don’t want to do. If you can’t make decisions effectively, you’ll struggle to be productive. However if you take the eight points listed above and reverse them, you get something like this:

1. Make decisions quickly, taking shortcuts to expedite decision making where you can.
2. Make your point concisely
3. Avoid committees as much as possible. Try to keep the number of people making the decision below five
4. Don’t bring up irrelevant issues, stick to the topic.
5. Focus on the intention of communication instead of specific wordings.
6. Don’t reopen discussions when a decision has been made. (At least until you have tried it for a bit or have new information)
7. Be brave, make decisions with courage.
8. Don’t worry about whether a decision conflicts with another.

Which feels a whole lot more useful and productive! You could try using these as meeting norms in your next meeting.

Different ways to write agile stories

Stories are a way for development teams to express the work that they’re doing. Too often I see teams that either use just one way to do this or don’t use any format at all. I thought I’d collect some links to some different story formats for capturing development work. I’m not saying one way is better than others, I’m just presenting some options from around the web. If you have others, please feel free to leave them in the comments.

The Classic

As a <type of user>, I want <some goal> so that <some reason>

Job Story

When _____ , I want to _____ , so I can _____ .

Feature Driven Development (FDD)

<action> the <result> <by|for|of|to> <object>

I.E. – Estimate the closing price of stock

Hypothesis Driven Development (HDD)

We believe that <this capability> Will result in <this outcome> We will know we have succeeded <We see this measurable signal>

Welcome.

This is a place where I collect my thoughts. It’s likely to change over time. That’s probably a good thing. All thoughts and opinions are my own unless indicated otherwise.