Back in the late 1950s when iterative and incremental development methods — two of the underpinnings of Agile development — were first being utilized at IBM’s Service Bureau Corp. in Los Angeles, it would have been inconceivable that development teams could be created one day to work together on the same project from multiple remote locations. One of the core tenets of the Agile development manifesto was that team members — including the developers and business people involved — should be face-to-face throughout an entire agile project. But, today there are three challenges that can make this difficult: 1) Getting the time commitment from business people; 2) Finding developers in the same time zone, never mind the same office space; and 3) Low unemployment requiring companies to find ways to attract the best talent in whatever geography it takes.
But the latest 2018 State of Agile Report found that times are changing. According to the report, 79 percent of those surveyed responded that they had at least some distributed agile teams, and in many ways this reflects today’s work reality that 43 percent of us are working remotely.
Over the last five years I have almost exclusively managed Agile teams composed of team members stretching across the U.S. One of my teams has been working with the Bureau of Ocean Energy Management to create and launch the Marine Minerals Information System (MMIS). MMIS is a state-of-the-art tool that was developed to assist decision-makers in managing coastal recovery and planning coastal resilience projects.
In order to build MMIS remotely, we applied the Scrum framework and used a host of tools to emulate face-to-face interactions. Here are the seven tools we used:
- Webinar software, such as GoToMeeting or Google Hangouts: This is the first tool every remote Agile team needs to have in its arsenal. It’s imperative that you standardize on webinar software that can be used as your “meeting room” to hold all your team’s Agile ceremonies, such as ideation, planning, standups, reviews, retrospectives and grooming meetings. Video cameras can really help to emulate face-to-face interaction, but the most important thing is for the tool to be reliable.
- Stories on Board: This web-based tool enables you and your team to lay out a shared understanding of the product by building a story map of the product. This tool is easy to use and allows you to drag and drop user stories into logical releases, add details such as story points, acceptance criteria, assignments and more. Once the story map is complete, you can export to several formats. For example, we typically export to Microsoft Excel.
- Azure DevOps: We import the story map into the backlog and add further details. We share the backlog screen with all the stakeholders and slide stories up and down until we have a prioritized backlog. We use the Kanban boards, a work and workflow visualization tool, to keep the team organized and on track. During standup meetings, we have a member of the development team share screens with the rest of the team via webinar software. Each team member gives their standup addressing the tasks on the board, while the meeting facilitator updates the board with new status and information.
- Test Planning Tools: The teams I work with typically build user acceptance tests (UATs) formatted in a Microsoft Excel spreadsheet specifically for UATs. This enables our testers to work in a familiar software format to execute the test and return the results. For very large or especially complicated projects, we use formal testing software. The Azure Test Plans software enables developers to write and execute test scripts that can be linked directly to user stories which helps when you need to test a large number of functional scenarios.
- AWS and Microsoft Azure Cloud: Development teams need several computing environments to develop and test in; one for development, one for testing and one for production. Depending on the project, we use either Azure or Amazon Web Services. The Agile teams I work with build the product in the dev tier. Once we test and prove it is stable, we deploy it to the staging server for further testing and then to demonstrate it to stakeholders. As the stories are accepted, we deploy to production. Working in the cloud gives us the flexibility to pay as you go, configure for the times the team is not working (i.e. during nights and weekends), and provides access from remote locations.
- Slack for daily communications: Remote teams can use Slack as a stream of communication between team members. I recommend you assign a unique “Slack” channel for your project. Each member of the team then subscribes to that channel, and then every time someone is having a conversation via Slack, you can view that conversation. By utilizing Slack, you are creating an open environment similar to a traditional office setting where everyone’s sitting at a table.
- Planning Poker: For estimating user stories virtually, we use PlanningPoker.com. The software works to simulate the real game of Planning Poker where one user story is presented, discussed and then estimated. Each user is blind to the other user’s estimate until everyone has voted. The facilitator (usually the Scrum Master) then reveals everyone’s estimates at the same time and the discussion ensues until a consensus can be made. The software is free and tracks all the results and details. This is a fun game that engages the whole team in discussing what needs to be built to meet the acceptance criteria.