The Manifesto for Agile Software Development states explicitly that “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
As we have seen, the idea is that face-to-face communication is the preferred way because it eliminates misunderstandigs, confusion and overhead.
But now remote or hybrid working is becoming the norm and is for sure here to stay.
Is the agile process compatible with people working remotely or distributed teams?
Working and collaborating remotely is coming with specific challenges but is not incompatible with Agile. The agile process can also thrive in a remote format, provided that the challenges are taken care of.
To perform best under these circumstances, it is very important to acknowledge these challenges.
We need to accept and embrace them and find strategies to reduce their undesired effects or we need to find ways to live with them.
Overall, being agile has never been more important than now: we need to continually learn, inspect and adapt to the situation that emerges.
Here are some best practices for smart working.
Establish team working norms
The first things for remote teams is to establish norms how to interact, how to run virtual meetings and also identify which digital communication platforms are most appropriate for each task.
For example, email may be most suitable for formal but non-urgent requests, while instant messaging may be more appropriate for an informal but quick check-in and phone calls can be used for urgent requests.
Because virtual communication can occur at any hour of the day or night, it’s important to establish guidelines on when to communicate to preserve the boundaries between work and non-work responsibilities.
Employees could create rituals that allow transitions (in the absence of commuting) in order to manage those boundaries. Personally I like to have a dedicated work corner and small setups when I start and end (it’s enough to take out the laptop and connects it to the monitor).
Discussing and agreeing on team norms helps to align on how we want to work together.
It anchors expectations on how we want to behave towards each other when remote.
By this it builds a foundation for trust.
The discussion about these norms is as important as the written rules.
You will probably need to iterate through the rules, processes and tools until you have the right approach.
Team leaders should explicitly articulate and encourage the norms they want the team to adopt, but remember that actions speak louder than their words, especially when it comes to creating a climate of psychological safety.
Critical events, especially early in a team’s life, have an oversized influence on team norms.
For example, a single instance of a team leader criticising, talking over or otherwise dismissing a concern raised by a team member can set a precedent for the whole team, increasing the perceived risks of raising such concerns. It is easy for critical incidents to turn into repeated patterns. Once a norm of “not rocking the boat” becomes entrenched, it takes serious effort to reverse it.
Team leaders should not be the only one responsible for creating a healthy climate, however. All team members can actively shape a team’s norm. After all, teams are social systems in which each member plays a role in sustaining or changing the team’s trajectory. For example, in a team where people have tended not to speak up with anything but the safest suggestion, any team member can start to shift this problematic climate.
Fine tuning the meetings
To maintain the short and efficient meeting processes that agile approaches require, virtual meetings just require some fine tuning to the meeting rules that you should already have (a clear agenda, purpose, topic, etc.):
- Check set-up and attendance: start your meeting with 2, 3 minutes technical start-up.
Invite people to look at their settings and check if everything works: “Now please check that we can see and hear each other.” Do it until you can do a week without an incident.
- Start with how are we going to work together remote: create a working agreement with behaviour norms.
- Be explicit on the meeting format: brainstorming, discussion, presentation, …
- Balance involvement: invite people not to be observers but participants.
Make sure, people have understood your view.
- Expect misunderstands and ask for confirmation if you are not sure, like “do I understand you correctly that this is …”. Make sure, people have understood your view.
- Breakout sessions when the team is large.
Large meetings do not work well usually, even less when virtual. If your planned participant count is more than 7-8 people, consider using break out rooms to engage people in working together
You start together on the same video call, but during the event, you can create and use separate rooms (many meeting platform allow that) for sub-teams to generate insights or decide what to do.
Or hold meetings with a small, cross-functional group to accelerate decision-making. Once the smaller group has reached some preliminaries, more people can be brought in.
- Use integrated chat for voting and take decisions.
- Leverage remote meetings tools such as sharing screen and the virtual whiteboard.
- Repeat and summarise: write the summary in the calls chat and open it again the next time.
- Use chat at the end of the meeting to collect feedback.
Finally, let’s talk what could be some examples for typical Agile events hold in a virtual way.
A virtual daily stand-up meeting?
The fulcrum of agile teams is the daily stand-up meeting. Remote work requires new customs for these daily stand-up meetings and a little more orchestration is needed.
For in-person teams, it is customary to have someone present their work and people chime in directly. The effectiveness of this approach depends in part on people’s ability to read social cues and see that somebody else is about to speak. Clearly, that no longer works in virtual meetings.
Web cams help only a little. Tend to over communicate in this case.
If someone disagrees or would like to express something, remind that they should do it explicitly by voicing a statement.
Then there is the problem of people unintentionally talking over one another or waiting to read a virtual room that is not readable. One option is to give each person a dedicated time to speak without interruption and explicitly handing the virtual baton to the next person when is finished.
Finally, daily meeting are stand-up because you want them to be quick; well, that could be stretched for virtual meetings as people usually attend seated from their remote place.
In this case it’s even more important for the Scrum Master to control the timing and avoid people talking too long or the meeting dragging on. Split the meeting into separate break rooms if a discussion around a specific point arises.
How to virtually brainstorm?
Because virtual meeting platforms fail to provide the natural conditions for real-time brainstorming, asking team members to write down thoughts on a shared platform prior to group brainstorming is a useful practice to make. Team members can make comments in a shared document whenever a thought comes to them on their own time.
When the team gathers, members can immediately start evaluating certain ideas or dive into challenges that they need to resolve rather than spend valuable time hashing out ideas in the first place.
Using collaboration tools, this allows the team to constantly iterate without the boundaries of a conventional in-person workshop. Team members don’t need to wait to bring up the subject with colleagues in the office during scheduled meetings or when a colleague doesn’t appear to be busy.
Shared documents can be a particularly useful way to socialize an idea and get a team to make a quick decision on it, letting people engage with the content on their own time. After everyone has had a chance to comment and offer input, the team can be assembled for a virtual meeting to discuss any remaining concerns or comments. Because everyone has had a chance to communicate their thoughts in writing that the rest of the team has seen and that can be saved for future reference, coming to a decision is often much easier.
Personally I like to have wiki-style pages used for internal brainstorming and jotting down ideas. Much more flexible than presentation slides.
A format for a remote Iteration Planning / Retrospective
This is a generic framework, similar to the one used for the Retrospective:
- Check in – introduce everyone and gather expectations
- Set the stage – get everyone on the same page about the purpose of the event
- Generate insights – inspect different elements: increment, backlog, DoD, etc.
- Decide what to do – adapt what have been inspected
- Check-out – Conclude what has been achieved and what are we going to do next
- Inspect and adapt the event – invite people to think what can do better next time for the specific event
- Start event with a check in, e.g. ask people to express how did the last iteration planning go.
Ask how much energy they have now as emoji; or their current mood as cat (show images of grumpy cats, happy cats, etc)
- Set the stage. Invite people to share a word or two on the intention you hold for today’s meeting to be a success.
- Generate insights. Show / collect data on people availability as well as DoD, team velocity and last Retrospective agreed actions.
Invite PO to tell /write in the chat what will be the focus/purpose of the Iteration.
- Decide what to do. Craft the Iteration Goal together. Invite people to individual brainstorm and write one sentence describing the Goal. If bigger team do this in break-out rooms and ask each break-out to select one by voting. Present goal option and decide on one in the main call/chat.
Now add the Iteration Goal-related items to the Sprint Backlog in your planning / tracking tool. Do it in break-outs or even individually. Present results in main call using the planning tool.
Create sub-tasks. There should be enough sub-tasks for the first couple of days of the sprint. Create those individually and in break-outs. Present in a main call.
- Check out. Check planned workload and invite people to vote how realistic it is to do this using a scale of 1-5.
- Inspect and adapt. Ask people to vote in the chat 1-5 if it was achieved the purpose of the event. Invite people that want to comment to do so. Ask to answer how do we run it next time so that can be improved.
Invite people to check-out with emoji or one two words in the chat – how do you feel now.
- Check in. Ask the team to draw the emoji that captures their feeling about the most recent iteration on the white board or to type the emoji in chat.
- set the stage. Congratulate team on a job well done with finishing the iteration and invite everyone to go over the stats together.
- Generate insights. Open the Iteration metrics to show the team their progress over the course of two weeks. What do the trends look like? Is it a consistent pattern from other iterations before or did something happen in the most recent one? Invite the team to voice their thoughts and write them into the chat as well. It might be a good idea to have smaller breakouts for 5-10 minutes at this point and come back to the main call after.
- Decide what to do. Ask the team what they believe they could have changed from the most recent iteration. It is important that the coach or Scrum Master raises at least one thing to focus on for change in the upcoming sprint. There could be more behaviors or innovation ideas put forward from this call. It might be a good idea to have smaller breakouts for 5-10 minutes at this point and come back to the main call after.
- Check out. Ask people to vote in the chat 1-5 (put number) return on time invested.
Invite people to check-out with three words – What’s my #1 takeaway from today?
- Inspect and adapt. Ask to answer how do we run it next time so that can be improved.