Atlassian is a unique software company: we use our own products just as much as our 40,000+ customers do. And like so many of our customers, we experience the same growing pains that many software companies face, especially when it comes to scaling. Why? Because Atlassian went from one small team in Sydney, to over 1,300 people across eight countries in just over a decade. That’s a lot of bodies to manage and a lot of time zones to juggle so it’s no surprise that scaling globally has proven to be one of our most difficult yet exciting challenges.
In this post we’ll explore the trends of agile software development teams becoming more distributed and inter-dependent, as well as give you insight into the specific problems Atlassian faced and continues to face with rapid growth. Plus, if you’re hungry for more, you can read the follow up blog in this series, which will highlight how the Jira team tackled scaling challenges with product improvements (basically, we created features that made our lives easier).
The mission (which we chose to accept)
After living through our own scaling trials and errors, the Jira product and development teams took a long, hard look at the nature of planning, tracking, and collaborating, and asked the questions: What will project management be like five years from now? And how do we stay ahead of the trends of remote work and the ever-expanding team?
The answer came in the form of “Project Hummingbird” in 2013. We gave it this cute name to imagine what it would be like for teams to hum together in a no-nonsense way to create better software. By 2013, Jira teams were distributed between multiple locations and we knew that if the next five years of software development were going to be anything like the last, remote work, outsourcing, and distributed collaboration were only going to continue to grow at a crazy-fast pace. So the Jira and Dev Tools teams reflected on what issues they were facing with scaling globally and took an even closer look at market trends to try and figure out how to create better software, specifically for agile development.
Moving to agile: smaller teams and faster development, yet more interdependency
Before the mid 2000’s– and even earlier – software development belonged to an era of waterfall project management. But by 2008, working in silos and in long development cycles was starting to hamper progress. Market trends were shifting and delivering value quickly and often to the market was a necessity to survive as a company. As a result, software teams were becoming smaller and worked collaboratively across disciplines in very compressed development cycles. Agile software development was the new black.
When Atlassian started out in 2002 as a small startup, we functioned in a very scrappy way with people playing multiple roles and teams empowered to make decisions rather than follow a rigid hierarchy. Although we stole some elements from methodologies like “Extreme Programming” we were very far from a formal process. In fact, it felt a little chaotic at times, as we’re sure most startups can relate to. But we knew that if we wanted to grow quickly and go global, we needed to have a better system. So around 2007, we more seriously adopted agile and most teams did scrum. Agile became even more apart of our DNA after we acquired Greenhopper, or what is now known as Jira Agile. Teams became more structured and inter-disciplinary and daily stand-ups, sprints, board planning, and tracking and retros became routine. The transition to really implementing agile and scrum was a little awkward and took time to adjust but ultimately it brought about very positive cultural and behavioral shifts (and eventually great opportunities).
Distributed teams and tool fragmentation
In an ideal world, the Jira team would all be sitting on the same floor of the same building and able to talk around the water cooler every morning, but although co-location is great for agile software teams, business realities rarely permit this. Growing companies naturally expand geographically and across time zones, software engineers like flexibility whether that be working from home or a coffee shop. The Jira team is no stranger to any of these experiences, with core teams in four offices around the globe; specifically Asia Pacific, America, and Europe.
Having offices around the world covering nearly all timezones is awesome! It means someone will always be awake to solve problems and talk to customers. But we all know that it isn’t that simple. For teams that work together but are separated by a vast amount of time and space, communicating and collaborating becomes extremely challenging. For example, our key engineering offices in Sydney and Gdansk are exactly 12 hours apart, meaning there are no overlapping working times at all. When we initially started working across different offices, we experienced many organizational problems. Sometimes people in different locations would work on a solution to the same problem, causing confusion and hurting team cohesion. Other times, one office would ship new code but forget to communicate and coordinate that with the other office, causing the service to break.
Another consequence of smaller and more distributed teams is tool fragmentation. Naturally, individual teams have their own preference for communication and collaboration tools like email or spreadsheets, but if your team isn’t co-located and work is tracked across different systems, it’s a complete nightmare.
As Atlassian has grown, we’ve hired external contractors, we’ve opened offices in countries all around the world (many with different cultures and languages), and we’ve acquired companies – some who have used our tools before and some who haven’t. So much change in a short amount of time can be daunting and often strain an organization. For new Atlassians to get up to speed with our way of working, they have to become familiar with our tool set including Confluence, Hipchat, and Jira and a range of developer tools. When talking to other companies experiencing a similar growth trajectory, their experience is similar.
Although extremely complex, Project Hummingbird was designed to address these challenges of working across different timezones to efficiently communicate and working with a fragmented tool set to effectively collaborate.
Don’t underestimate the impact of lost productivity
One customer told us that prior to using Atlassian products he spent four hours a week manually tracing code back to stories, identifying and updating the appropriate status, and then communicating this status across the company.
Those four hours a week snowballs into 200 hours or 5 weeks in a year in lost productivity! And that’s just for one person! Consider the massive amount of time lost if you have 10 or 100 people – the productivity losses compounds.
For a rapidly growing company like Atlassian, with four business units, eight offices, 25+ development teams, and over a thousand employees, the cost of wasted time chasing down the status of code can be extreme. Not the best spend of anyone’s time, money, or energy. And not a trend we wanted for ourselves or any of our customers.
Up next: How Atlassian tackles these challenges
In this post we laid out the trends and challenges that Atlassian was facing as we shifted to agile and scaled globally. We knew we weren’t alone in this struggle because our customers told us they experienced them, too. In the second post in this series, we’ll discuss how the Jira team has gone about solving these problems. Stay tuned!