Contents
2.5 Cloud-Based CI/CD via BitBucket Pipelines
2.6 Increased Usage of Confluence
2.7 Story Mapping All the Time
1.0 Introduction
Over the last two years, the Covid pandemic has forced state and local governments throughout the US 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.
The scope of these dramatic changes has been especially challenging for state and local governments, given the fact that many were still early in their adoption of cloud technologies, and most required their IT teams to work co-located and on-site at all times. It is a cruel irony that many state and local governments that had begun their adoption of Agile methods may have needed to work even harder to adapt to the new remote reality. How can smaller teams continue to work closely together, collaborating heavily with lightweight tools like whiteboards and sticky notes? Even now that the pandemic is in its later stages, hybrid remote work seems here to stay. Fortunately, Agile teams have found ways to adapt to the challenges of remote work, leveraging the strengths of capable tools such as the Atlassian suite and modifying Agile practices to suit the new realities. 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. This paper will describe how one project adapted to working in a 100% remote environment, successfully delivering an extremely challenging IT solution against all odds.
2.0 Adapting to Remote Work
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. We will discuss each in turn:
- 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
- Easy Agile Story Mapping Plugin
- Jira conventions: daily comments, recording collaborators
2.1 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.
2.2 “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.
2.3 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.
2.4 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.
2.5 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.
2.6 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.
2.7 Story Mapping All the Time
We found that the Easy Agile 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 Easy Agile 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 Easy Agile tool 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.
The Easy Agile storymap plugin provides a more understandable view of the backlog and a fast and convenient way of creating new work items
2.8 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.
3.0 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 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.
4.0 About Ariel
Ariel is an IT Services, Training, and Management Consulting firm with special expertise in Atlassian products, Enterprise Architecture, Big Data, DevSecOps, cloud-based microservices, web and mobile app development, AI/ML, Agile, and Human Centered Design. We are an NWBOC-Certified Woman Owned Small Business (WOSB) founded in 2010. We provide IT services to Federal Agencies and Commercial clients to help them transform their systems and, more importantly, their method of delivery. Our staff includes experts with Professional Certifications for Atlassian products, AWS/Azure Cloud, Agile, Scrum, Kanban, SAFe, LeSS, ITIL, Cyber Security, and Project Management. We currently hold a Top-Secret Facility Clearance. Ariel Partners is appraised at maturity level three by CMMI for both Development and Services and is certified ISO 9001:2015, ISO 20000:2018, and ISO 27000:2013 compliant. Ariel is an Atlassian Silver Partner, Certified Training Partner & Certified Government Partner, and is a certified Scaled Agile, ICAgile, Flight Levels, and Kanban University training facility.
Ariel provides critical support to a diverse set of large Agencies and institutions. Ariel is 100% committed to helping our customers achieve their mission objectives
Ariel has deep experience executing large systems development and implementation projects for Federal agencies and other organizations including the FBI and NYC Department of Social Services. Ariel has provided project management, business analysis, systems engineering, testing, and support services for system implementations up to $500M in size, spanning all 50 municipal Agencies in NYC, and for FBI programs used in all 50 states and in Interpol countries spanning the globe. We led the 2nd program at FBI to move from waterfall to Agile. We established a large-scale Agile governance and oversight framework for the Social Security Administration, assessing more than $500M of mission critical programs. We have worked with the DOJ/FBI since 2003 on mission-oriented programs including NCIC and CODIS and have helped them institute major new programs and initiatives including Missing Persons, Rapid DNA, and NCIC Third Generation (N3G). We have provided public training classes in Kanban, SAFe, Jira, and HCD since 2016.
Ariel has a wide range of offerings to help our customers get started with Agile or turbo-charge their Agile implementation. Our Jira offerings include a “Jira Jumpstart,” which bundles a set of Atlassian product licenses with configuration, training, and coaching to get an organization up and running immediately or elevate their existing Atlassian investment up to the next level.
Ariel provides comprehensive Atlassian coaching, configuration, training, and consulting support
