The most difficult thing I’ve had to do since our team moved to 100% remote working is remote Agile ceremonies. 

Pre-lockdown, I always insisted on people joining in person whenever possible and I always designed the ceremony to have the greatest impact on those in the room. People who dialled in were never an afterthought, but I was convinced that they would not benefit from the session as much as the people in the room. 

People dialling into retrospectives was the biggest challenge. I always felt you could only really participate if you were there – how else could you be fully involved and grasp the feeling in the room? 

Even with video, how would it even be possible to understand the vibe of the group if you weren’t there?

It was a problem that could not be solved so why even bother trying to solve it? My thinking was that they would just have to understand the impact, and it didn’t matter too much anyway because we always had most of the people there in the room so it was fine.

Well, pretty quickly it became apparent I didn’t have a choice anymore. 

Not only was this something that needed to be addressed quickly, it may well be the way forward for a long (if not permanent) time. 

So what were the rules that needed to be in place for this to work? 

Well if we were going to make sure that we could communicate effectively we needed to be able to see each other. That meant video. 

There is something about looking someone in the eyes that makes communication easier. It also forces focus – if we are all on video we are obliged to pay attention. It’s somehow easier to pay attention when you know all eyes could be on you! 

Another thing that we can do with video that is more effective than audio alone is interact. Just because we are not all sitting in the same room it doesn’t mean we can’t do physical things. Little activities like getting people to stand up and jump about a bit and being able to see each other are fun. And you can all laugh about it together like you were in the same room. So it’s not the same, but it’s not an excuse to have a dry boring retrospective. 

There are a few video conferencing tools out there. We were already using Google Meet and decided to stick with it. It’s free and it comes with most of the core features that paid video conferencing tools come with. 

Collaboration is probably the most important part of Agile. Video is a good start, but we also needed to be able to share things in real time. 

When we were sitting in a physical room, one of my favourite bits of kit was a whiteboard. The ability to write things down and share things instantly with the team was very effective. 

Losing this ability in a Retrospective was initially very disruptive to the flow of the meeting. I searched high and low and finally settled on a whiteboard that our team found great for sharing online, Whiteboard Fox . Multiple people can all share and contribute to this in real time which is great for when we want to work together on a problem. Taking this one step further and using this on a touch screen makes it much easier to use than with a mouse.

Another great tool that helped our team with collaboration was Slack  – we were using it already and it really helped us transition to 100% remote working. 

Having this very useful tool meant we could easily share links and other text with each other. We also began to use it for writing down and sharing as we would normally do with Post-It notes in an in-person Retrospective. Slack also integrates with a lot of other tools you might be using to run your development like JIRA, GSuite, Trello and many more. 

Doing Agile ceremonies in person is always going to be easier – but getting creative and finding new ways to do these when our team transitioned really stretched us and if anything made us a better team. There shouldn’t be an excuse for making Agile ceremonies any less engaging and interactive remotely. There are many tools and techniques out there that can be used and built on to make the experience a positive one, It’s about testing and trying these out, and seeing what works best for you and your team. 

My colleague Manjit wrote a piece about knowledge sharing for SaaS development teams – take a look.