Blog Culture How async and all-remote make Agile simpler
March 2, 2021
7 min read

How async and all-remote make Agile simpler

Engineers at GitLab and IssueTrak share their tips on adopting Agile while working remotely.

runlanes.jpg

Whether you have the Agile manifesto memorized or thought agility was a sport for dogs, there are a few core principles that engineers and non-engineering folks can adopt to improve communication, collaboration, and efficiency in their work – whether or not they’re working from the same office.

Interestingly, the first piece of advice GitLab team members shared for engineers (or content developers) using Agile or working remotely is the same: Over-communicate!

"Provide maximum context in discussions and document the outcomes in the most appropriate location," says Lindsay Kerr, frontend engineering manager for Threat Management at GitLab. "This allows other members of the team to benefit from synchronous conversations while giving stakeholders insight into the progress of the team."

How Agile keeps development lean

Agile software development is all about developing solutions through collaboration and iteration, with some of the techniques being stand-ups, sprints, and more. Another key principle of Agile: Making processes more lean.

During our annual user conference GitLab Commit, the software company IssueTrak explained how migrating to GitLab helped the company embrace Agile software development. Before, IssueTrak was using five tools to manage their ticketing and repositories and power their CI/CD pipelines, at a substantial monthly cost. After IssueTrak migrated to GitLab, they reduced their monthly costs by 80% and simplified their toolchain by adopting GitLab for all their software development needs. You can read more about their experience below.

Why all-remote and Agile pair well together

GitLab has embraced the principles of Agile software development in two key ways. The first way we've built agility and efficiency into our culture is by embracing all-remote, asynchronous work. By working remotely, team members can work when they want and in places and spaces that best suit them. Remote work has become more widely adopted since the COVID-19 pandemic has disrupted the traditional office, explains Lauren Barker, fullstack developer working on the Website.

Remote work is a simple concept to grasp, but asynchronous (async) work is a bit more complicated. At GitLab, working async looks like optional meetings with detailed agendas and Slack channels are busy but without the pressure of an immediate reply. Zoom meetings are recorded and posted on the GitLab Unfiltered channel, which supports our commitment to transparency and breaks down silos by improving communication across teams.

"Working asynchronously enables an individual to contribute when they’re 'on'," says Lauren. "Sometimes you’re feeling super productive and motivated on a certain project at 2 AM, not during normal business hours such as 9-5."

The core of effective async, all-remote, and Agile workflows is documentation. By clearly defining project scope and needs in writing, processes are easy to follow and replicable for all users. At GitLab, perhaps the most important rule of all is our handbook-first principle, which states that our handbook is the single source of truth in the organization and challenges team members to document everything. Tyler Williams, website fullstack developer at GitLab, discussed the value he’s derived from the handbook-first mentality at a recent Inbound Marketing team meeting and said that handbook-first coupled with async work is what powers Agile for him.

Insights on remote team building with Agile

Tyler and Lindsay both acknowledge it can be challenging to build team camraderie remotely when applying Agile principles like stand-ups when you're not in-person.

"It is easier to implement the human-connectivity pieces of an Agile mindset when you are in person," says Tyler. "It is easier to implement the process-focused pieces of Agile techniques when you are all-remote and asynchronous."

"Distance can remove people from consequences," adds Brandon. "A bad manager could drop a project on you, turn off remote messaging, and go on vacation. I've experienced this at previous workplaces."

But working alongside humans in the same space isn’t always an upside. In-person work can make personality clashes more commonplace, says Lindsay.

Remembering when Agile was analog

Before project management tools like Jira and GitLab, scrum teams had to plan sprints manually using things like post-its, index cards, and white boards. While this analog approach to sprint planning can be good for team-building, it was less efficient in the long-run.

"When I started working on scrum teams in 2008 we actually stood up together in a room during stand-up. We looked at post-it notes (tasks) associated with index cards (stories) when discussing the answers to our three questions (what did I do yesterday, what am I doing today, and what is blocking me)," says Lindsay.

"We used an egg-timer to make sure our stand-up didn't go longer than 10 minutes each day. I drew our burndown on paper each day, across every two-week sprint, for the course of a three-month project. We looked each other in the eyes when we gave our answers, watched our teammates move the post-it note from 'to-do' to 'in progress', and celebrated together when a post-it moved to the 'done' column."

It is hard to document progress using the analog approach to sprint planning. When one team member is out sick or on vacation, they lose the historical context of a project as post-its move columns, and meetings happen without thorough notes or recordings.

"In an office setting, it may be easier to adopt the human-focused mindset, but it is much more challenging to adopt appropriate processes to keep Agile techniques running, and it is a much less enjoyable endeavor to coach people around process," says Tyler.

GitLab is designed for Agile

The other way we've embraced Agile principles at GitLab: we've baked many Agile artifacts into different features of our DevOps Platform such as issues, labels, milestones, and weights, etc. "These words seem somewhat abstract but they are all different ways to help you categorize and organize information to help you work agilely," explains Brandon Lyon, frontend engineer for Marketing at GitLab.

These Agile features coupled with robust CI/CD help us keep GitLab lean and allow our customers to continuously deliver software to their customers.

"If the main point of Agile is to continuously deliver working software as value to customers, GitLab enables teams to be Agile because it has the best CI/CD tools I've ever used, and they're integrated directly in my day-to-day task management workflow," says Tyler.

How two teams use sprints with GitLab

In their GitLab Commit presentation, IssueTrak team members Lisa Cockrell, director of development, and Jordan Upperman, fullstack developer, said that they created two custom issue boards using GitLab, one of which is the "Ready for Sprint" column and board. Sprint planning meetings are much shorter now because the team can just look at the "Ready for Sprint" board to identify which issues are ready to enter the development process.

"Our use of these two Kanban boards allows us to pivot with ease when necessary. As bugs are found during testing it's easy for us to quickly weigh the new ticket, remove an item with equal weight, and send it back to the top of the 'Ready for Sprint' column," says Lisa. She explains that this process prevents scope creep and helps stakeholders remember that when work is added to the sprint, something else must come out. Watch the entire presentation to learn more about how IssueTrak uses GitLab tools for Agile development:

Brandon, Tyler, and Lauren all work on the Digital Experience team at GitLab, which is responsible for our marketing website. In the spirit of iteration and efficiency (two of our values at GitLab), the team is in the process of updating the way they conduct sprints. Tyler opened an MR to facilitate the discussion – share your tips for sprints by commenting on the MR or suggesting a change.

We are constantly looking for new strategies to communicate and engineer with clarity and efficiency. If you have any suggestions for how to better embrace Agile, async, and all-remote work, let us know in the comments or tweet at us @GitLab. If you are still new to this topic, our advice is to try and go with the flow, and leave your expectations at the door.

"If you keep in mind that Agile is a flexible, human-focused approach to knowledge work and delivering value to customers, the rest will fall in place," says Tyler. "Take strong opinions with a grain of salt, and give yourself room to make mistakes and remember that it's impossible to know everything."

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert