Let's get back to normal!

Five themes for your first day back in the office


Working in the same place - colocation - won't feel normal until it is normal - until it has happened many times. Resuming collocated work for the first time is an opportunity to start rebuilding normality. Normal, for us, means excellent conversations, spontaneous interaction, fast feedback, sketching, body language. The simply mind blowing impact of silly stuff like colourful stationery and a beer fridge!

The challenge is that working remotely has just begun to feel normal, and is practical for many. Travelling into the office for anything less than special and well organised feels like a bit of an effort, yet well-organised spontaneity is the least special kind.

What if there were experiences on offer that make the most of in-person working, are playful and special, yet encourage the spontaneity we have all missed out on? These might be a great excuse to get back together, that make a real and immediate impact and help people through the return to normal.

We're going to give you five great experiences to start with. Five different themes that live up to the occasion of your first day back in the office.

1. Re-establishing a team charter

Depending on how quickly your team changed, and how long you were separated, your team may be feeling a little shapeless. On Zoom, deep conversations are limited by the rapid onset of fatigue. Your first get together is a great time to chew over the fundamental mission of the team and the deeper values that drive it.

Core Values by Geoff Watts 

One way to come up with a set of values you share is to start with a large set of options and for each team member to individually whittle it down to a short-list of a certain size. Coaching expert Geoff Watts is on hand with a set of 50 values and a detailed process to produce a set of values as a team artefact. Choosing from someone else's set means that this task can be done without the help of a English professor or a thesaurus!

One of the stand-out successes of the lockdown era was Team Topologies, a book that encouraged us to think clearly about the impact of our team organisation on the flow of value.

Authors Matthew Skelton and Manuel Pais ask the reader to map out the relationships between teams and the problems or value streams (business domains) that they are working on to be clear on what is keeping their minds busy (cognitive load).

A useful exercise in the office is plotting the relationships your team has with other teams using the Team Topologies Modeling Shapes. Think of all the occasional interactions and automated dependencies that you might tend to forget. How does your team interact with others that consume your work? Do people use an email, or a Slack channel for instance? 

Once you have a clear sense of your values, workload and relationships, a final exercise is to put this together into a single charter or "API". The goal of a team API, like a software API, is to describe what you can do and how you want people to interact with you. 

2. Clarifying roles and responsibilities

Unclear responsibilities can easily arise and can have serious consequences. Examples include neglected responsibilities, over burdened team members, under utilised and idle team members, and missed opportunities to collaborate, as well as conflict.

Fortunately, several efforts have been made to plot out the responsibilities that sit with various roles within project management frameworks such as GDS, DSDM even scrum. You can use these bits of research as a check list, or a kind of mirror, to inspire useful ideas and conversations about how these models of roles and responsibilities differ from your own.

To achieve this in person, and to spot over-burdened and under-utilised individuals, Agile coach Laurence Wood has synthesised a common set of roles and responsibilities and put them into a deck of cards - Richer Roles.

The team can read through responsibilities on cards and hand the card to the person they feel owns that responsibility. 

3. Reflecting on your processes and behaviours

A retrospective is a perfect in-person event to help improve procedures at work. Body language becomes visible again and teams regain the ability to collaborate in a real environment. Handwritten sticky notes provide the opportunity to use colour and position to share subtle information such as priority and affinity - without participants getting bogged down in editing text on screens.

Retrospectives come two flavours - open and prompted. The content of an open retro is proposed by members of the group. A prompted retrospective employs expert opinion to prompt the group to consider specific factors. Groups tend to reflect on recent experiences so a prompted retrospective often takes a broader perspective. Prompted retrospectives are often packaged as card decks. Cards can be used communicate by waving, ordering, building a matrix, displaying and radiating, pointing, dot voting etc.

Laurence Wood's Richer Retrospectives, prompts team members to consider how frequently they would like to practice a certain behaviour or process.

The output of this exercise is a matrix that you can display in a shared space, and a single action focus for the team to work on next

Perhaps you are used to performing three column retrospectives (e.g. start, stop, keep) and simply want to encourage a greater richness of conversation? Paul Goddard's Retrospective Lexicon encourages a descriptive, emotional or action oriented perspective, as determined by team's coach or leader. Alternatively, you can mix things by simply selecting column headers at random from the deck.

4. Honing your software delivery practices

Sometimes it is not clear to managers what their teams are struggling with and what they are excelling at, especially with the extra distance imposed in 2020. Maturity models are helpful, providing a standard against which a team can be evaluated. A health check, a process of self-assessment, is a popular way to use a maturity model to target support where it is needed without any judgemental comparisons.

The in-person medium provides the best opportunity to explore the content of healthcheck standards. Such a conversation should allow team members to discuss what the criteria is supposed to mean, and what it means at their organisation, and to consider recent experiences. This helps remove noise from assessment scores and allows teams to focus attention on procedures and practices they value most, and even agree action items autonomously.

Matthew Skelton's Software Delivery Assessment is our recommended healthcheck model. It has 66 factors listed across six suits. The six suit version is assessed over 2 hours without exploratory conversations. Fatigue is certainly an issue if you want to go into all the available detail, but by taking on the models in person you have the option to go as deep as needed. If you are organising more than one day of in person events, try splitting the suits across three one hour sessions and dive in!

5. Threat Modeling

If your team has a strong set of values, clear responsibilities, great processes and delivers using modern practices then I have good and bad news. You are probably a happy and high-performing team. Well done. The bad news is you have fewer excuses to head back to the office.

A great in-person exercise to consider is threat modeling using the gamified versions of Elevation of Privilege or OWASP Cornucopia. This process takes your team to the next level by helping your developers master something that confounds many: making software secure in a fun and accessible way!

The simplest definition of threat modeling is drawing pictures to help you spot problems (and decide what to do about it). We know that getting together around a white board is a great way to get a picture done quickly. Spotting cybersecurity problems though, takes a little effort. How do people used to building features hope to calculate how to break them?

Fortunately, a huge amount of research has been done into common security errors. Several organisations have studied how security breaches arise from design flaws and omissions. You can review this research and treat it as a check list, or pick up a gamified version of OWASP or Microsoft research and turn this into a competitive game.