How to be Agile when your team is WFH

This is the write-up from the third in our series of virtual coffee breaks – designed to provide a caffeine-enriched forum for discussion amongst senior executives who might otherwise be going stir-crazy during this period of lockdown. 

The topic for this session was: ‘How to be ‘Agile’ and keep in touch when your team is fully distributed’ and our guest speaker was Neil Moorcroft, Digital Solutions Director at Zuhlke.

Neil started the call by explaining that he has been leading agile delivery teams for many years. Much of the best practice he has learned in this time is proving extremely useful now that delivery teams are working entirely remotely. 

He illustrated this with three recent stories and, while these are all from the world of software development, the principles and learnings will be relevant to many other types of work. 

Project Kick-off 

Neil recently ran a two-day project kick-off workshop for a significant project at a large retail bank. Project kick-offs like these are always difficult and he would normally insist on these being done physically, with everyone together in the same place.

As this was not possible, it was necessary to do this kick-off remotely. While this proved successful, it was not without its challenges. Some of the key things he learned were:

• Don’t try to cram everything into an accelerated schedule. Everything takes much longer when you’re working remotely.

• Keep each working session to a maximum of 90 minutes and give everyone plenty of breaks. It’s tough sitting at a screen for hours on end.

• Remember that not everyone lives in a big house with a home office; some people, especially more junior team members, may be in shared accommodation and trying to do this from a shared table in the kitchen. 

• Share key materials and design work with participants in advance. You don’t need to do a “big reveal” during the kick-off itself.

• Make sure you have a videoconference code-of-conduct. For example: have video on; mute when not talking; pay attention; follow protocol for asking questions; etc. 

• Make sure everyone tests their connections, mics, headsets, video etc. beforehand – it’s very important to have video on if possible (unless, say, bandwidth is a real problem).

• If you’re using tooling (e.g. screen mirroring) make sure it’s tried and tested beforehand and everyone is up-to-speed. 

Ultimately, this virtual kick-off was hugely successful and a great deal of fun. Indeed, many of the learnings from this experience could usefully be carried forward to physical kick-offs in the future. 

Pair Programming

Pair programming is where two people work together on the same task. There are many benefits to this approach: two heads are better than one; its more efficient; fewer coding mistakes; effective way to share knowledge and develop skills; etc.

In this case the task at hand was a medical interface with lots of graphs and other complexities. The easy option would have been to dispense with pair programming altogether and just allow everyone to work alone. 

But the benefits of pair programming are too important and, as it turns out, the companionship that comes from this way of working is even more vital when everyone’s working from home in relative isolation.

Some of the lessons learned on this project, about how to do pair programming when everyone’s working from home, included:

• Rotate the pairs frequently. This is good practice anyway, to maximise the spread of knowledge, but even more important when everyone’s physically separated. 

• Make sure one person drives and codes while the other watches and navigates and, most importantly, keep swapping these roles. Also, the driver needs to speak a lot, to keep the navigator engaged.

• Tooling is very important. It doesn’t need to be overly sophisticated. Zoom works well. The key thing is to be able to share screens. The annotation function within Zoom is very useful. 

• When swapping roles, save, share and reopen the work – don’t try to drive each other’s screens, as this will always be too slow. 

• Take frequent breaks, including shared (virtual) coffee breaks; remember to have fun.

Show and Tell

The final example was a large project for an international bank, involving many people across multiple time-zones and different cultures. 

With more than 30 people working remotely, communication is more efficient if it can be asynchronous, allowing for more ad-hoc conversations. In this case, the team made great use of Slack, in particular, where discussions could be “overheard” by the whole team.

The team found the key to running Retrospectives effectively, was to prepare well and get as much feedback as possible in advance. This way, the scrum master can collate in advance and use the Retrospective itself as more of a review session. 

The real challenge came when trying to run a Show and Tell involving participants from all over the world:

• More than 100 people turned up remotely – far more than would have been present locally for a physical show and tell.

• The key was to get the presentations prepared in advance and shared before the event, so everyone could be fully up-to-speed. It’s also important that everyone has a local copy of the presentation in case there are technical problems on the day.

• Similarly, it’s important to have the demos pre-recorded, as a fall-back in case there are problems sharing the live demo. It’s also a good idea to share links to demos where possible, so people can try for themselves during the presentation. 

• It proved invaluable to have a back-channel (in this case WhatsApp) so that anyone who has problems can communicate directly with the team. 

Overall, what Neil has learned from all these recent experiences, is its difficult running projects remotely. But we do have the tools to make this work. The most important thing is to be supportive of everyone and pay attention to any issues they may be having. Many of these new approaches are going to be useful when things get back to normal.

Discussion

The discussion towards the end of the call touched on a few further points:

How does working remotely in this way affect quality and productivity? 

• Its possibly too early to tell, but Neil is not seeing a big change. Once people are set up, they are able to work effectively. Engineers tend to sit and work with their headphones on anyway. In fact, the software engineering industry is probably better suited to this way of working than many others. 

Are there security concerns associated with working remotely, for example via Zoom?

• Yes, it’s important to be aware that videoconferencing, particularly over third-party services like Zoom, is never going to be as secure as a closed physical meeting. Its good practice to put passwords on meetings and to share sensitive data via normal secure channels. 

How do you overcome the difficulty of running whiteboard sessions over videoconference?

• The trick is to get as much preparation, from the right people, before the session. The downside of virtual workshops is always going to be reduced flexibility and spontaneity. But the upside is a more structured and possibly more productive session. 

The final observation was that many aspects of remote working are proving to be more efficient than office-based working and, hopefully, many of these new practices will carry over once we are able to return to our normal working environments. 

Including the tendency for virtual meetings to finish slightly ahead of schedule, rather than slightly behind. 

Future Events:

If you have found this write-up interesting and would like to register for future Virtual Coffee Breaks or learn more about our other events, lease visit www.clustre.net/category/events/