Lessons Learned Adapting To Remote Work

[#1]

Introduction

This article explores some of the lessons we learned adapting to remote work.  Over the last two years, the Covid pandemic has forced organizations to scramble to support a fully remote work environment.  Supporting a fully remote work force requires comprehensive changes touching every aspect of IT including cybersecurity, networks, workflows, tools, Agile practices, operating platforms, governance and oversight.  While it is true that some of the benefits of in-person agile collaboration are lost in a hybrid remote work environment, there have also been some gains.   Here are some lessons we learned working in a 100% remote environment, successfully delivering an extremely challenging IT solution against all odds.

Attempting to use Agile methods for a fully remote team poses a number of challenges such as defining and managing requirements, maintaining quality, and sustaining motivation and engagement. The main challenge underlying all of these is maintaining a high degree of collaboration.  In our particular situation, some of the team members worked in different time zones, further exacerbating this problem.

As long-time users of the Atlassian suite of products (Jira Cloud, Confluence Cloud, Trello, and BitBucket Cloud) we were better prepared than most for this challenge.  In general, Agile Lifecycle Management (ALM) tools have improved significantly over the last five years, and that is more than evident in the Atlassian suite.  Atlassian’s tools have gotten more capable, new offerings have been added, and the third-party plugin marketplace has burgeoned spectacularly.   The pandemic has spurred a wave of incredible innovation that has changed the game.  For a long time, software tools struggled to match the flexibility of a plain-Jane physical whiteboard with sticky notes—but were useful for reporting and auditing.  Now, we we are quickly closing in on a time where electronic tools will meet and even exceed physical workflow systems in nearly every respect.

Adapting to Remote Work

Below is a list of practices that we used to facilitate our Agile work of our remote team.  We established some of the practices up front, others evolved over time, and some were happy accidents or the results of trial-and-error experimentation.

• Establishing core hours
• Longer standup meetings to limit the number of interruptions during the day
• Always keeping camera on during virtual meetings
• Heavy use of a team Slack channel
• Cloud git repository with cloud-based CI/CD, integrated with Slack
• Expanded usage of our Confluence team space
• Story Mapping Plugin
• Jira conventions: daily comments, recording collaborators

Core Hours

The concept of establishing a set of core hours where everyone must be online is not a new one, and many teams had established these prior to the pandemic.  However, while working remote we found this practice to be essential.  We established a 5-hour period where all team members agreed to be online, including both west coast and east coast-based personnel.   Although we never tried it, we suspect that having less than a 4-hour overlap could have a significant negative impact on most Agile teams.  We would love to hear from teams that have managed to be successful without establishing core hours.

“Longer” Standups

Our team used the Scrum Agile method, with many Kanban practices sprinkled in (this is sometimes known as Scrumban).  One of the key Agile practices recommended by both Kanban and Scrum methods, is that of the short daily standup.  Like all Agile teams, we strived to complete our daily standups quickly, say in 15 minutes or less.  However, we found that technical discussions emerged out of our standup on a regular basis, and soon it was a daily occurrence.  Agile coaches will recognize this as a common pitfall for Agile teams, and we at first assumed the same thing and attempted to steer the team to closure.  However, when we analyzed what was happening more deeply during a retrospective, we discovered that the team preferred to combine the standup with their technical discussions in order to have fewer interruptions during the day.  Our team found online meetings to be more intensive and therefore disruptive than the type of casual water cooler conversations that are commonplace for co-located teams.

We discovered that, while team members would still meet with each other over MS Teams as needed, they had come to rely on the fact that everyone would be online simultaneously during the standup, so it would be easy to simply extend that standing meeting.  By using this time slot, there was no need to create a calendar invite, coordinate schedules, etc.  Team members indicated that they found the longer daily meeting to be convenient—that is, the benefits were high relative to the cost.  

In order to accommodate this strategy, we simply extended the calendar invite for the daily standup to a full hour each day, and it became two meetings in one.  On some days there was no need for the after-meeting, so we simply ended early.    It is important to note that we did not actually extend the daily standup itself—we generally completed it quickly, but then seamlessly jumped into technical discussions.  In fact, we found that the fact that the team expected a technical discussion to take place every day immediately after the standup actually helped us get through the standup even more quickly, since there was no fear that some technical point would be missed.

 Camera On!

In order to increase engagement, each team member agreed to turn their laptop camera on during every online meeting.  We recorded this in the team’s working agreement, documented in Confluence.  We agreed to a protocol that if an emergency arises (package delivery, baby crying, etc.) that turning the camera off is an indication that one has stepped away.  We all agreed in this case to turn the camera back on as soon as the situation in question is addressed.

Team Slack Channel

Many commercial software development and support teams have been using Slack for years, but it is relatively new for government.  Knowing that we were going to be working remotely, we configured a slack channel for the team from day one— and we have never regretted it.  Slack channels have many benefits.  They enable team members to communicate continually without breaking concentration.   Slack users are socialized not to expect an instantaneous response.  Yet, unlike email, it is easy to resume the thread of a discussion hours later without losing context.  We created a separate slack channel for messages from our CI/CD pipeline.  We didn’t want those to clutter up our team channel, and yet we needed everyone to be aware of the progress represented by the builds that were executing and to be able to respond immediately if the build was broken.   Each build message included a link to view automated test results.   This practice is one we will carry over to all teams regardless of co-location or remote status.

 Cloud-Based CI/CD via BitBucket Pipelines

Given the magnitude and uncertainty of the technical challenge before us, we knew we would need an automated build, continuous integration, and continuous deployment capability.  On the other hand, we dreaded the prospect of logging into the Agency VPN, setting up Jenkins pipelines and troubleshooting the inevitable problems.  Fortunately, we were able to use Bitbucket Cloud instead.  We configured a few BitBucket pipelines to automate our builds, run tests, and generate test reports.   All builds were kicked off automatically both in the main branch as well as pull request branches.  Each build generated a slack message that contained a link to view the build results and test reports.  This setup was transformative.   None of the team members could remember a more seamless, trouble-free DevSecOps experience.  I, for one, will not be going back to Jenkins anytime soon.

Increased Usage of Confluence

We set up a Confluence space for our team, as is customary for our organization.  However, we found that the remote environment encouraged us to use our team space much more than before.   Keeping the team contact sheet up to date was paramount.  Everyone added their mobile number and time zone so we could track time differences.   Here is a list of some of the capabilities we used:

Meeting notes template.  We captured action items and aggregated them.  Confluence macros automatically aggregated all of the action items on every child page and summarized them.  We captured names and titles of everyone who attended each meeting and made sure to capture all key decisions.  Team members and government stakeholders alike found these very helpful, and we referred to them often to understand which technical questions had been answered and which were still outstanding.

Agile cadences.  We created a page for each cadence where we indicated any adjustments or customizations we made.  We added a page for Backlog Refinement, Sprint Planning, Daily Standup, Sprint Review, Retrospective, and Team Working Agreements.  We used Ken Rubin’s excellent Visual AGILExicon graphics which are available for free from here: https://innolution.com/resources/val-home-page.

Risk List.  We created a risk list and maintained it in our Confluence team space.

HOWTO articles.  We captured HOWTO articles for common challenges such as fixing up git when it spits up.

Glossary. Anytime a team member encountered an unfamiliar word or acronym (both business and technical) we would place them in the glossary, whether or not we knew the definition.  Team members would occasionally browse the glossary and add in definitions, wikipedia style.  There are probably still a few not yet defined!

Questions and Answers. Many of our government SMEs were not able to meet with us very often. We have seen this affliction spell doom for several Agile teams.  Our approach was to capture all of our questions in Confluence so we could rapidly go through all of them when we did get precious face time with the SMEs.   While we still had a few situations where we had to make assumptions while waiting for answers, we were able to adapt quickly to those situations by keeping the code base clean and easy to refactor.  We maintained QnA lists by date so the government could easily refer back to exactly what they answered and when.   This was particularly helpful to the team when the government changed its mind on a few items.  Rather than assigning blame or arguing about who was right, we simply acknowledged that things had changed (our team was one of many interdependent teams running in parallel) and got down to work and did what needed to be done.  The government appreciated the team’s flexibility and that served to build trust.

Design documentation.  We captured designs and architectural discussions here.  The content from our informal Confluence pages eventually made its way into formal documentation to fulfill government lifecycle management requirements for formal design artifacts.  Having the notes, sketches, and in progress information available was invaluable to the technical writers who had to eventually produce the baselined documents, and we found that they were also very helpful when we had questions or needed interim clarifications from our government stakeholders.

Story Mapping All the Time

We found that our story mapping Jira plugin, which we have long used for backlog grooming, became our go-to visualization board for any kind of impromptu planning, sprint planning, or design discussion.  The team found the tool so convenient that we ended up using it several times a week.  The key feature of the story map is that it provides a richer, two-dimensional view of the backlog, arranging stories alongside their Epics.  By arranging the Epics to match their temporal order with respect to one of the main use cases, a story map helps find missing pieces, duplicates, and facilitates adding new enhancements in just the right place.  The tool maintains 100% synchronization with the other backlog and Agile board views, and it is rock solid.  Perhaps the most important feature of the story map plugin is the way it enables an analyst to add new user story candidates as fast as a government SME can describe them. As long as you have a reasonably good typist on the team, this tool virtually eliminates the need for taking separate notes, capturing voice memos, or using other tools that require someone to transcribe/translate them to Jira as a second step. In 20 years of software development, this is the very first tool I found that can do this, and it is a game changer.   The plugin was our constant companion, enabling us to immediately and seamlessly capture all important information during meetings as team members, analysts, and SMEs came up with ideas, experiments, new features, enhancements, and defects.

Jira Issue Conventions

Finally, we adopted a few extra conventions for working with Jira issues that we found helpful for remote work.  For example, we mandated that every team member must add at least one small comment to every issue they were working on each day.  That way, even if nothing changed, the team would never be left in the dark if a given team member was out sick or otherwise unavailable.

To further encourage collaboration and ensure the Agile board accurately reflected what each of us was doing, we added a custom “Collaborators” field and recorded everyone working on each card in that field.  We customized the Agile board to display the Collaborators field so that all applicable team members were displayed, not just the assignee.  With this in place, the choice of whether someone was actually assigned to a card versus added as a collaborator became more or less just a formality.

Conclusion

Using the techniques described above, our remote team was able to successfully deliver a complex piece of new software.  Moving to a fully remote posture required a few tweaks to our Agile practices, as well as a few customizations, conventions, configurations, and 3^rd party tools.  All in all, this demonstrates how the Atlassian suite forms an essential part of enabling hybrid and remote teams to deliver successful outcomes using Agile methods, without skipping a beat.  How about your transition to remote work?   I would love to hear how our experience compares to others.

[Christine P. Dela Rosa]

There's a good balance of team engagements here of async and sync interactions, which is nice to see as some teams have swung the pendulum all the way from "only live in person" to "only async and remote."

[Andy Gladstone]

Thanks for sharing @Craeg Strong. So many of us have jumped back in to the 'on-prem' mindset, it served as a good reminder that there were lessons to be learned during our time as a remote workforce that should be reviewed and possibly implemented even in though we are back in the office. 

[Walter Buggenhout]

Thanks @Craeg Strong for sharing such an extensive post. I liked (amongst several other things) the mention of the documented work agreements for your team. It got me wondering if that is an extensive list of agreements, what areas it covers and what you do as a team to define, implement and review them.

[Craeg Strong]

@Walter Buggenhout  Re agreements, you are right-- the team working agreements for remote teams are slightly different than for co-located teams.  For example we all agreed to add at least one comment to each work item assigned to us every day, and to type in status information in the slack channel if we couldn't make it to the daily standup.  I would be interested to hear some of the additional agreements other remote teams have made.

[Walter Buggenhout]

It is great that you mention the topic of the daily standup @Craeg Strong. We too have the - not necessarily very explicit - agreement that people who can't make it to the standup leave a note for what they should otherwise have contributed.

That does, however, lead to one way communication. The person who isn't there shares an update from his/her perspective, but is not included in whatever gets discussed by the people who are actually there. And - depending on what gets discussed during a standup, of course - that implies a risk of gently introducing a separation between people in and outside the (physical or virtual) room.

Of course, as long as missing standups is occasional and/or there is no key information for the team that is shared exclusively with those in that specific call, I don't think this necessarily a major risk. However, I do believe sharing the fundamental information as to where you have this standups as a team (seeking/finding help, unblocking issues) in writing is a very good idea to keep everyone in the loop.

We experimented with a weekly standup channel in Slack, where we would focus on last weeks achievements and targeted outcomes for the week ahead, as well as areas where we expected to get blocked or need help.

[Jerryton Surya]

Thank you for sharing this valuable information.

[Charly [DEISER]]

Thanks for sharing!