Many of us are trying to find ways to adjust to what is now becoming our biggest work-from-home experiment. Whether your organisation has adopted a sweeping remote work policy, or you collaborate with global team members or clients who have done so, many now find themselves in a new, potentially confusing environment.
The circumstances surrounding the coronavirus, and its effects on teamwork, motivated us to dig a bit deeper into what works, and what doesn't, when 'work-from-home' becomes the new norm.
Agile transformations are, by nature, difficult without face-to-face contact. But difficult is not impossible. When it comes to coaching, transformations actually run into many of the same obstacles we’ve explored in the first four parts of this series: missing microinteractions and body language, relying on informal communication, having to alter behavioural patterns. This post will address those challenges, and others that are more specific to Agile projects.
First and foremost, if you’re working on the client-side of an Agile transformation, it’s important to set expectations early in regards to time, progress and discipline—all of which require a bit extra from teams working remotely.
Let’s talk strategy
After remote interactions are in place, the transformation must be planned using much short interactions, and in smaller groups. A few general tips:
- Keep a clear and available online roadmap using Trello or JIRA
- Run weekly catch-ups with your sponsor to show evidence of progress.
- Design small experiments to be run in small groups, in short periods (think weeks, not months).
- Keep everyone involved in a single experiment connected using a group text chat or voice/video chat tools.
- Have a plan to broadcast progress to the whole department/company, with an emphasis on visual information.
- Be mindful of social factors, and ask for feedback about how the transformation is affecting daily work. Video logs can be a more personal and powerful tool to use here.
Remote Coaching from point A to point B
As a general rule, pilots should be reduced in number when working remotely. Remember, each experiment takes time and energy, so be mindful of how many you plan to run in parallel.
After pilots, make sure you have the tools and communication methods in place to understand results, and bring people together for online discussions when necessary.
When it’s time to roll out practices you learned during pilot experiments, take a gradual approach. Each new team must adhere to the steps followed by the pilot team until Agile is more firmly ingrained in the remote work culture.
Remember, scaling in normal conditions is already a complex matter, so when you’re attempting to scale remotely, moderate your expectations in terms of time and difficulty.
If you’re using Scrum, some structure will be in place that can be replicated remotely. From our experience at PALO IT, some simple planning and preparation by the Agile Coach or Scrum Master can often make coaching sessions much smoother.
Long meetings tend to be ineffective in remote environments. It’s too easy to lose focus and lack interaction. Keep this in mind during coaching and sprint planning especially, and be sure to make user stories clear and visible using a task management tool.
For more complex concepts, use screen sharing with audio. You won’t have a physical whiteboard to draw on, so using virtual whiteboard tools can also be helpful.
If you see your team starting to lose focus, you probably need to up the speed of the session, and encourage more interaction. Make sure everyone has an opportunity to speak. Those who are shy need to be catered to as well!
When you reach a sprint retrospective, put everyone on the same video call, and collect feedback to prioritise the overall discussion. You’ll be facing a lack of visual components here, so again, using a virtual whiteboard or a specific online retrospective tool (eg: Scatterspoke, IdeaBoardz) can be extremely helpful.
Retrospectives have a tendency to drag a bit in remote environments, and may take some time to progress, so make sure you’re providing your team with concrete information from the previous sprint. This sets the scene and drives the discussion. In that same vein, when it’s time to gather data, limit the number of items per participant. Nobody likes a monologue in this scenario.
If you don't have access to a virtual whiteboard or online retrospective tool, you’re going to be responsible for collecting all information and organising it visually. One way to save time here is to ask your team to prepare their points, and send to you via private chat ahead of time.
Sprint reviews can be a timekiller, as it's necessary to switch presenters once in a while. Be aware of this when scheduling. Remote voice/video calls with the Product Owner and the stakeholders are key here. Remember to keep reviews concise, laying out the points that will be discussed at the very beginning of the session. Stakeholders should also have access to your deployed application, making it easier for them to show examples, or explain their requests or doubts.
For the daily scrum, voice/video calls are a must. Text updates are a big no-no. Monitor time spent by every team member, and share the task manager screen while people are speaking. This ensures everyone is aware of what task/story is on the docket.
Prolonged silences can be common after each individual update, but there’s no need to lag, set a rule in place that each person indicates the next team member to speak after their turn.
Of all the sessions of a Scrum delivery team, backlog grooming is usually the hardest. People tend to diverge a lot when facilitation isn’t on par, or the item you’re grooming is still too raw. Large items can be extra-difficult as they might carry a lot of doubt, concern, and questions.
To aid in this setting, establish agreements about when something is ready for grooming. What kind of information does your team want? Do they need the user story to be completely written? Work these questions out well beforehand.
Also, set a timer for every item and make sure the team is well aware of the running clock. When time is up, let the team decide if they’d like to continue the discussion or not. Always stick to your timebox.
