A few weeks ago a company contacted us. They needed help. They were busy with a super important project and wanted to do it the agile way, and were a bit stuck. The business and management people were in City A and the dev team were in City B. They had a bit of previous agile experience in the development team but no-one else really did.
We suggested a remote call with everyone in both cities to understand where they were at. We had no idea what would happen, we were simply there to understand and perhaps guide. This 2 hour session turned out to be our best remote session yet!
As preparation for the call, we sent an email a few days before asking everyone to install Zoom (our remote conference call tool of choice) and asking that everyone dials in by themselves using a headset even if they are in the same location. We also gave them a trello board to connect to.
We started the call with everyone introducing themselves and what they do, so that we had a better idea of who we were talking to. The developers all dialed in. The business in City A dialed in together from a conference room, and a manager dialed in separately.
Immediately we could notice the difference in call quality. The group in City A was hard to hear, you were not always sure who was speaking. We also learned that Zoom adjusts volume, so every time someone far from the speaker spoke Zoom adjusted which meant we could barely hear the next person.
Tip 1 – insist that everyone dials in themselves, rather than using a conference phone in a meeting room. (Though having them experience this was also a valuable lesson.)
We then checked that everyone could access the Trello board and shared the link again. We gave everyone 5 minutes of silence to brainstorm talking points or questions onto the trello board. We needed to mute the group in City A as they had one PC and were chatting to type up and disrupting everyone else. (We needed to do this for every “silent brainstorm” we had, and mostly we forgot to unmute them until it was pointed out – so if you have this problem, don’t forget to unmute!).
After the brainstorm we asked everyone to vote for their top 3 topics. There is a nifty power-up for Trello that allows this called “voting”. Once again the group in City A were disadvantaged as they could only vote once for a topic as they had one PC, we solved this by asking them to type in the chat window what they want to vote on and we just included that in the count.
We then spent the next 90 minutes or so talking about their number 1 topic…. though I think almost every topic was touched on!
This is the fun part – we wanted to make this interactive and visual to keep everyones attention – so we were trying something new. We had attempted this a few days before and the technology had failed spectacularly – so we were prepared with plan B, but never needed it 🙂
Tip 2 – plan your tech carefully and ALWAYS have plan B (and even C).
We were screensharing an ipad pro, using Sketches to draw a mindmap with an apple pencil. We use this regularly so are familiar with the app. Here is Sam drawing the mindmap.
Tip 3 – know your app/tool backwards, you learning how to change colour should not take up 10 minutes of everyone’s time.
The conversation turned into an impromtu Backlog grooming (refinement) session. We discussed an important requirement then picked one little bit. We started a new mindmap. We then chatted about that one little bit, and it grew and grew. We again picked just one little bit. And again we started a new mindmap. We chatted about this in detail. We spoke about test cases, about success flow and error handling, what the expectation from the user was, what the simplest thing to do was. We broke this into a few really small stories with great understanding and test data examples.
The entire team contributed. They all participated in the conversation. Even though we controlled the mindmap creation – the conversation and understanding was amazing. The visual mindmap served as an anchor for the conversation and as it was ever changing, people paid attention. We thought it might distract people and cause some of them to not pay attention but it did not.
Tip 4 – test ALL your assumptions.
We wrapped up the session asking everyone for their feedback on how it went. Here is their response:
- Level of breakdown much deeper – they never realised just how deep and detailed they should be talking about their work.
- Use Case help – the Business Analysts was suprised at how much help this conversation and mindmap has given him for the use cases he needs to write.
- Visual mindmap helps understanding – everyone was shocked at how well the mindmap works to break down ideas and features.
- Collaboration – they were suprised at how much they worked together and learned about the system in just one session of talking about a small part.
- Shock – the idea of breaking things down into such small pieces to be able to give it to an end user for feedback was a shock. They can now see how much more effective this can be.
- Documentation – the whole team just wanted the mindmap as documentation as they had learned so much (it was more the conversation, and the mindmap is just a reminder)
- Change of mindset – One of the devs was very attached to creating an entire framework first. This helped him see how it might be possible to do this in parts, something he didn’t think was possible 90 minutes earlier.
WOW! All of the above in just under 2 hours. Definitely a success, and hopefully a team that has learned some new tricks in remote communication.
Tip 5 – get feedback from participants to learn what worked and what to try next. This was our 6th remote session in 2 weeks, we iterated many times!
Tip 6 – whilst technology helped, please don’t underestimate great facilitation. Without a facilitator to guide the conversation we might, weeks later, still be talking about the high level important project!
If you would like to experience this, with us guiding you, drop us an email: firstname.lastname@example.org. We want the world to see that remote work can be fun and have amazing results!