Can distributed teams be agile? Does Jira kill agility?
I was scrolling LinkedIn when I saw a picture of Jira executing a wrestling splash on Agility. It triggered a train of thought about the place for tools like Jira in the context of distributed teams that span different time zones and on which the team members often have to split their attention into multiple projects.
In my experience as a software engineer, I have seen that the words Agile, Scrum, and Kanban are often used interchangeably. One reason for this is that the key ideas of each one fits really well with the others. These ways of work share some assumptions:
- Team co-location: everybody is in the same geographical location, building, or room
- Undivided attention: each person contributes to a single team/project/product
How can distributed teams remain agile when these two assumptions are broken? Before we go into the challenges that distributed teams face, let's take a quick look at key differences between Agile, Scrum and Kanban.
- Agile: originated in software development with a focus on delivery of value through close collaboration with customers and being flexible in responding to change
- SCRUM: originated in software development with a focus on time-boxed delivery cycles (iterations) with a fixed scope
- Kanban: originated in manufacturing with a focus on visualizing work, managing flow, and reducing waste
The fact that the terms are used interchangeably it's a reminder of how similar the philosophies are. These ways of working are complementary and teams mix and match practices from all of them without batting an eyelash.
1. Documentation as communication
The distinction between communication and documentation can be blurry for distributed teams. Recorded communication can be seen as extended documentation, at the same time, documentation is a form of communication.
Distributed teams can use recorded communication like chat, email, comments, etc. to bridge the gap created by geography. As long as communication is given priority over the tools or processes, the use of documentation as communication seems to maintain the spirit of the agile manifesto.
2. Communication through a central channel
Some complex tasks require sharing context with multiple people. Consolidating context in a central location such as Jira/Wiki, makes it easier to onboard newcomers.
3. Documentation and context switching
Distributed teams are often composed of individuals that participate in multiple projects simultaneously. Individuals who have to split their attention into multiple projects reduce the impact created by context switching by documenting useful details, such as the current status, and planned next steps.
4. Tools don't kill agility, people do
For distributed teams, systems like Jira serve as a central place for coordinating work. I find it intriguing that people with technical IT skills often forget the value of systems like JIRA and at the same time they can deliver complex systems. Jira is bloated and could offer better user experience but it does not impose any workflow or methodology.
5. Every project management tool wants to become like JIRA
In principle, e-mail is sufficient. However, once you get used to the amenities of modern collaboration tools, it's hard to go back and use only e-mail. Popular collaboration tools seem to be converging in terms of features like creating a task from a chat conversation, tracking status, assigning, visualizing tasks and their relationships, linking to code or documentation, etc. Tools that started with one of these features continue adding more features until they cover all the basics of project management.
Companies arrive to systems like JIRA by taking a holistic/integrated approach. It's not perfect, but the available options are only a round of funding away from becoming like Jira.
Project management and collaboration is a complex domain, which explains why most tools offer a terrible user experience. I always remind myself that it could be worse, imagine doing project management only with email and PowerPoint.
