You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 3rd 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.