This post was co-authored by Weiman Kow, a product designer in VMware Pivotal Labs' Singapore office.
Agility means being able to quickly react and respond. One thing that organizations have had to urgently respond to, especially in recent times, is the operational shift to increasingly remote software teams. This post accompanies a webinar we recently presented detailing how at VMware Pivotal Labs we have responded to this shift by leaning on our years of shared experience delivering great business outcomes with distributed and fully remote teams.
Our approach to agile teams
When it comes to building better software products, two of the pain points we often encounter are
-
Delays in delivery or turnaround time
-
Unmet needs and expectations of both users and project sponsors
Ultimately, these pain points are usually the result of long feedback loops. That includes feedback loops within teams collaborating on the software, between delivery teams and their stakeholders—especially those involved in the release process—and between the delivery teams and their end users. Our solution to shortening feedback loops within teams is the concept of the balanced team.
VMware Pivotal Labs’ balanced team
Building software products involves uncertainty and, therefore, decision-making. Every decision is impacted by different considerations, so the delivery team needs to give voice to those considerations. For example, is this product desirable? Will our users find value from these features? Designers on the team represent the voice of the customer and help to research and test these questions. Product managers may ask, is the product viable? Will it help us meet our business objectives? How will we know? Those questions are addressed by utilizing lean planning, making priority calls, and driving team productivity towards those business objectives. Engineering questions to ask would include, is the product feasible? Can we build it? Can we push it to production? What are the risks? Engineers on the team conduct technical discovery to ensure the solution we’re devising for customers is achievable and not overly complex.
That’s why our teams are composed of designers, engineers, and product managers, and sometimes include additional roles like data scientists or marketers. Having balanced teams not only brings a variety of skill sets to the table, but each person can contribute a different perspective to the conversations and decisions that take place, resulting in the fastest possible feedback loops within the delivery team itself.
For us, a balanced team follows the core practices of extreme programming, user-centered design, and lean planning. These are complementary practices that are focused on fast and iterative value delivery. Each practice requires that collaboration be dialed up to 11 within the team itself and beyond, specifically:
-
Teammates must be accessible to each other
-
Teammates must have empathy for each other
That’s so they can negotiate trade-offs and make better decisions, and why most agile frameworks emphasize the need for colocated, physically present teams. This level of collaboration is generally much easier in person because we can read body language, and radiate information around our workspace on walls and screens and whiteboards. Indeed, one of the 12 agile principles is about face-to-face communication.
So, staying productive as an agile software delivery team when working remotely means that we need to be able to replicate that level of collaboration online—while also finding ways to maintain our working relationships.
Pairing
Typically, we work in pairs during blocks of time throughout the day, meeting as a team at least every day during a daily stand-up, but also when we have any issues to discuss or decisions to make. This isn’t just pair programming; it’s pair designing, and pair product managing. We’re constantly reviewing and validating each other’s ideas and decisions. This can be very tiring and we want to avoid burnout, so while we would usually have fixed working hours on a rigid schedule to help us maintain a sustainable pace, remote pairing necessitates more flexibility.
From colocated to remote
We can’t expect that technology will always make the shift to remote work a seamless transition. Every team will need to experiment and find a way that works best for them.
The first step in transitioning is recognizing that the team is moving to an entirely different space and environment. We take a lot for granted when sharing a physical space, such as being able to infer cues from each other’s body language and tone. We need to ensure that the digital space is set up to support productivity, which in turn will force us to consider what may impact our productivity in the remote working environment.
Seeing and hearing each other clearly
We’ve all been on that video conference where we couldn’t hear someone speak, or their background noise was loud and annoying. If you found it annoying, so did everyone else. And the more people on a call, the more time gets lost. It also adds to the level of fatigue. That’s why everyone should invest in good headsets with directional microphones! There are also free noise-canceling apps, like Krisp, for those who still face issues with background noise.
Staying connected
Home internet connections can be unreliable, especially for those living in developing countries or remote areas. Sometimes it’s just the Wi-Fi signal, so we’ll plug an ethernet cable directly into the computer. Screen sharing and video may also place strain on the available bandwidth, so we use tools like Tuple that can optimize what we send down the wire.
Using the right tools, and using the tools right
Many of the apps we use run inside browser tabs. As those tabs pile up, so does the machine’s memory consumption, leading to lag not just for the user but also for their pair if they are also viewing the screen. So we try to keep tabs and open applications to a minimum.
Zoom, Skype WebEx, Microsoft Teams, and BlueJeans, etc. are all great video conferencing tools. We’ve found that it’s worth spending time exploring all of their individual features and how they might help us. We typically set up separate, persistent “rooms” for each pair to work in, and we message each other—using a messaging tool like Slack or Whatsapp—before entering another room, just like we would knock on a door. Tools like RemoteHQ, which enables virtual workspaces and customized workflows, or Sococo, which replicates physical office space online, make it even easier to reinforce the sense that everyone’s present in the same working environment.
Similarly, for collaborating together, we’ve found digital whiteboard tools like Miro especially useful. In our office, we usually cover our workspace in contextual information about our work —our goals, risks, roadmaps, actions, etc.—so having one place online and using that as our home base for team conversations has been especially useful. We’ve even created a library of shared templates to ensure we can smoothly facilitate all of our agile practices, and that’s on top of the templates that Miro already provides! Indeed, the Miro CEO recently highlighted that of all the organizations that use Miro, VMware Pivotal Labs has created the most sticky notes!
Having a dedicated channel in a shared workspace on Slack means all asynchronous team communication can happen in one place. We like to “pin” key links, such as our meetings or whiteboards, to the team channel so there is one place to go if anyone on the team needs to find anything.
It’s also important to have a shared team calendar. Working remotely can be exhausting, so more breaks need to be scheduled. It’s also harder to see when your teammates are away or busy with something else. Increasing visibility with a shared calendar helps give a sense of presence.
Adapting people & processes
Ultimately, we do need to make some minor adjustments to how we convey ourselves, and all those small adjustments can add up to a large amount of mental energy. We have to change our volume controls instead of leaning in or moving further away, for example. We also have to think out loud, look at a camera all day, and be more conscientious about etiquette and politeness—in particular, to not interrupt each other. Here are a few areas to consider when it comes to reducing cognitive load.
Physical and mental health
Even if you’ve invested in a good chair and other equipment to reduce strain on your body, remaining stationary and staring at a screen all day isn’t healthy, whether you’re working at home or in an office. And those little opportunities to exercise tend to be fewer and farther between when working from home. There are no meeting rooms to walk to, for one thing, and the trip to the bathroom or kitchen is probably shorter. So, we make sure to exercise our neck muscles and rest our eyes by focusing on something at a distance.
As a team, we might agree to schedule a 10-minute break after 80 minutes of continuous work. Making this a formal team agreement means anyone will feel comfortable requesting a break if conversations overrun. Burnout kills productivity. Everyone on our team is encouraged to regularly stretch, flex, and relax as much as possible.
Focus
When on a remote video call, especially with only one person talking at any one time, or when videos are turned off, keeping people engaged and focused can be a real challenge. It’s easy for people to switch off or do something else without anyone else noticing. We’ve found it useful to set clear goals for every team discussion, and to try and keep each discussion as short as possible. A strict timebox helps push the discussion towards its intended goal, and makes it easy for people to leave the meeting when the time is up. Always-on video and round-robin discussions encourage inclusion and visibility. Additionally, an open channel for asynchronous discussion, such as Slack, Microsoft Teams, or Skype, further creates the sense of presence.
Flexibility
We must accept that people working from home might have other commitments, such as elder or child care. Their typical work day might not look the same as it would when they’re onsite. Flexibility is especially important when working across time zones. Team working agreements and shared calendars, together with asynchronous messaging tools, help the team to plan when and how they will be able to collaborate effectively.
Empathy
The team can only be as productive as the individuals on it. When everyone is remote, it’s even more important to regularly check in with each other and ensure everyone is coping emotionally. Some of the techniques we practice are weekly retrospectives, which are a form of empirical process control that also give us the opportunity to find ways to better support each other as a team in order to avoid fatigue and frustration. We also practice team health checks, and make a point to discuss health, happiness, and work-life balance in those sessions.
Empathy means endeavoring to understand other people’s working conditions and communication preferences. One way we foster empathy is by having each team member create and share their own user manual. These essentially act as guides to help everyone better understand how to engage with one another. Topics they might cover include communication preferences, ideal working hours, and how we like to receive feedback. All of which can really help dial up the empathy within a team. And by comparing and contrasting the user manuals of all team members we can also use the information they contain to set those aforementioned working agreements. In doing so, the team can figure out how they might better help each other to collaborate and stay productive.
We have to always keep in mind that the people we’re working with might not be able to see our hand gestures, and might not be focusing on the same part of the screen as we are. We must therefore remember to vocalize our thought processes, and draw, write, or demonstrate our thoughts on screen. We also have to be strict about having one conversation at a time, to give others the chance to speak, and to avoid interrupting.
Finally, if anybody is remote, then everybody is remote. Everyone on a team needs to be given the same opportunity to contribute in the same space at the same time.
Rapport
Without the opportunity to chat casually with teammates that we would have in an office—in the form of coffee breaks, team lunches, or after-work drinks—team rapport can be a challenge. We've tried scheduling social activities where the team gathers to chat or play games. Sometimes we’ll direct our cameras around the room, the house, or out the window to share our working environments. We also have icebreaker exercises, and even randomized one-on-one chat sessions, to get to know each other better. During the COVID-19 lockdown, we’ve been carrying out our office social gatherings and birthday celebrations online, including having cakes sent to our colleagues beforehand.
What productive, remote agile teams look like: A day in the life
At an agreed time, we gather for our daily stand-up. We make the link to our team’s Zoom room the topic of our Slack channel, which we use to see each other by putting our video on and viewing the screen in gallery mode. After we each share our plans for the day ahead, we break out into product management, design, and engineering Zoom rooms, one room for each pair.
In the engineering room, we host our own tech stand-up in which we decide on the day’s pair rotations and share any relevant technical context for the upcoming user stories and chores in the backlog.
In the design room, we might dive into Figma and start iterating on the current prototype after having synthesized user feedback with the product managers the day before.
If there is new data from users, product managers may start by updating the user story map on the team’s Miro board along with some of the product backlog items. We would then update the team calendar to schedule an after-lunch team meeting, and ping the rest of the team on Slack to let them know.
After lunch, the team re-groups in the team Zoom room to discuss the updated prototype and user stories. After agreeing on the stories that are ready to be estimated in the following day’s planning meeting, it’s time for a short break, and then it’s back into the breakout Zoom rooms to continue pairing.
Finally, at the end of the day, the team re-groups for a 15-minute stand-down to review the day’s progress; at the same time, we update the team Miro board to log decisions and take down actions.
Remote teams at VMware Pivotal Labs
In other words, apart from the use of Zoom rooms and Miro boards, we operate just as a colocated product team might, with the addition of some minor adjustments specific to each discipline on the balanced team.
Design
User-centered design involves the use of in-person interviews to conduct exploratory and evaluative research. We establish user needs and ensure that we are meeting those needs by talking to, and observing, real users. But while this may sound difficult to do remotely, we’ve actually had a great deal of success interacting with users remotely over the years, even across vast distances.
A good setup for remote user interviews ultimately involves trying your best to match their environment with yours and vice-versa. We make sure the user has access to a computer, a webcam, a good microphone, a stable internet connection, and some time in a quiet space.
Tools like Figma, Adobe XD, and Invision offer ways to share URL links to any design prototypes. If a user has no one available to help them get set up, then you need to make accessing your prototype as easy for them as clicking a link.
Engineering
Pair programming promotes a focus on code quality and shortens feedback loops, and helps teams work more quickly by all but eliminating delays in the code review process. There are several pair programming patterns we make use of, like driver-navigator, where one person writes the code while the other guides and reviews it. Pair programming lends itself quite well to remote work where the driver just shares their screen. There are many tools out there that support pair programming, such as VS Code, Tuple, and Screen, and including features such as shared cursors, chat panels for pasting links—even ways to draw and highlight sections of the screen.
Screen sharing does place extra strain on the CPU, so remote pair programming might require machines with better specs than what you have currently. Large-screen devices might also place strain on bandwidth consumption when sharing the full screen, though some tools, like Tuple, optimize for that.
Working agreements for pairs of engineers are helpful here, too. We utilize them to agree on the tools to be used and how, as well as how often the pair will swap the driver’s seat, how they will review, and how they will ask questions of and make suggestions to one another.
Product management
For product managers, much of their time is spent gathering data and feedback from users and stakeholders, which they use to augment the team’s ideas and the decisions it makes. Product managers also facilitate a lot of conversations and decision-making, and communicate with an eye to visibility and alignment.
A remote toolset can make such work easier in many ways. A shared digital whiteboard for the team to reference and collaborate on every day helps remind everyone what we’ve done so far and keeps everyone updated as to where we’re going. Documenting everything digitally also avoids the problem of deciphering some people’s messy handwriting! Our shared whiteboard templates save us a lot of time when we have solutions to prioritize or a product backlog to plan.
For managing our product backlogs, we prefer to use Pivotal Tracker, which is our industry-leading issue-tracking product. You would think backlog management using an online tool would be the same whether a team is colocated or remote, but context is easily missed in the remote environment, so some additional effort is sometimes needed to add labels or comments to product backlog items. Pivotal Tracker also provides us with an analytics tab where we can monitor team metrics like cycle time, volatility, and burndown. Being able to monitor these metrics has helped highlight any potential productivity issues the team might be facing, be they a result of shifting to remote work or not. We can then discuss those issues and plan any mitigation in a team retro at the end of the week.
We also have weekly iteration planning meetings in which we discuss and estimate the effort needed for upcoming stories before adding and prioritizing them on the product backlog. We typically make an estimation by asking people to vote using a show of fingers. However, a combination of video latency restrictions around how many participants can be viewed at one time has led us to use one of the many planning poker apps available online when doing it remotely.
Conclusion
Shifting to remote work is like having your whole team teleport to a new office, where both the rules and the tools are different. It just takes a little time and effort to respond to the change and get comfortable. Remember, distributed and remote teams are not new; people and organizations have been practicing remote work for years! Indeed, within VMware Pivotal Labs we have the shared experience of many remote practitioners to help us be successful. For us, responding to change is par for the course. Clients of ours that were initially reluctant to initiate remote engagements have been impressed by how much work gets done.
In our remote environments, we continue to work in pairs. We also continue to practice extreme programming, user-centered design, and lean planning. We still hold daily stand-ups, plan weekly iterations, and continuously improve through weekly retrospectives. Equipped with new tools, techniques, working agreements, a commitment to empathy and a heightened sense of etiquette, we work with our clients to consistently deliver against our objectives, and maintain the same high level of productivity working from our desks at home as we do when working in the same office.
