How we’re solving them with Jira

This article is part of a blog series!

Part 1 – The challenges of scaling software development teams globally

Part 2 – The challenges of scaling software development teams globally – How we’re solving them with Jira

This is the second blog in a series of two. In the first blog, we looked at growing pains felt by scaling agile globally. In this blog, we’ll explore how Jira tackled these challenges and give you some tips and tricks to overcome the hurdles of scaling agile at a global level (And if your company isn’t global, don’t worry! There are plenty of pointers for companies of all shapes and sizes.) Let’s dive into it!

Tool fragmentation: Helping teams consolidate and connect tools together

For those who did not read part I of this blog series, here is a little background on why Jira set out to solve the challenges of scaling software teams globally. After living through rapid growth – we’re talking going from one office in Sydney to multiple offices in eight different countries – the Jira product and development teams took a moment to reflect on Atlassian’s growth. Scaling a company involves adding new people and inherently acquiring their methods of working. This usually results in workflow information scattered amongst disparate systems and an inability to make decisions and move fast. So we set out to truly maintain Jira as the single source of truth that pieces together the status across all related tools: meet the dev panel.

jira_dev_panel_600px

The development panel is Jira’s one-stop-shop for issue details, providing team members with all the necessary information of an issue, where an issue is in its workflow, and whether or not it’s been pushed to production. This continuity is possible, because Jira integrates with various repository management systems and continuous integrations tools. It’s helped the Jira team tremendously by taking away the need to jump between Jira and Bitbucket, Bamboo or Stash to find out what’s happening.

In the development panel, users can view the number of branches, commits, pull requests, and failing builds. Users can also see which stages the code has been deployed to, whether it be staging, QA, or production and when they were updated. You can even create a new branch in Bitbucket and Stash and run automated tests within Bamboo with just one click of the “create branch” link.

By giving visibility into the code activity that happens outside Jira, within Jira, a huge amount of valuable time is saved by removing the need to trace code to related issues and figure out its status or history.

ProTip: To access the Jira development panel and view the development detail, click on an issue and view the bottom right panel

Distributed teams: Giving teams a better way to collaborate

The dev panel was the answer to a lot of our growing pains (tool consolidation is awesome), but growth for Atlassian translated to new geographies, quickly. This brought new resources and more remote teams to the table all working towards the same goal.

The challenge of working with people in different locations or organizations is the constraint on a team’s ability to communicate and collaborate. Scheduling conference calls across multiple time zones, hunting down the most up-to-date status of work, and ensuring everyone is working from the same single source of truth can feel like a lot of wasted time. And heck, it is. But if meeting each other face-to-face simply isn’t possible, how do you lower your dependency on it?

triggers_admin (1)

Since we think of Jira as the single source of truth for development teams, one of the most innovative features we’ve built in response to our scaling challenges are automatic workflow triggers, which automatically update issues. In other words, if an action occurs in a tool outside of Jira, like a build or deployment in Bamboo, or a pull request in Bitbucket or Stash, the updated status of that issue will automatically be reflected in Jira. This ensures that every team member is always looking at the most up-to-date and accurate status of project work.

Here are examples of development actions that can trigger an automatic update to an issue’s status:

  • Pull request created/reopened/declined
  • Commit created
  • Branch created
  • Review started/submitted for approval/abandoned

Automatic workflow triggers are about the tools working smarter and harder, so you don’t have to. In fact, they get out of your way. We’ve had a customer tell us that they really appreciate the Bitbucket triggers, because now, his QAs who work solely in Jira, can instantly know when a new issue is ready for review once a pull request is created in Bitbucket. The QAs are also more prepared to discuss overall product health, because all issues have been quickly and cleanly updated. They no longer have to waste time following up with developers to find out what the latest status is, or wait for them to manually change the status of an issue.

Using auto workflow triggers eliminates the context switching that most members of a software team have become accustomed to. This means each member of the team can spend time where it counts and maximize his or her talents. It also eliminates the risk of someone forgetting to update an issue or updating the issue incorrectly.

For teams that use outsourced developers who are unfamiliar with company processes, automatic workflow triggers prevent the need to train or up-skill them in different tools or physically enforce company protocols. Outsourced developers don’t have to remember to transition an issue in Jira or describe what they have done, because the auto workflow triggers have done it for them. This also means that people who are more comfortable working in a particular tool can stay there. For example, product and project managers can stay in Jira for project management and developers can stay in Bitbucket or Stash for code management.

ProTip: To configure automatic workflow triggers in Jira with Stash, Fisheye/Crucible, Github or Github Enterprise, Bitbucket check this out

Moving to Agile: Giving teams better visibility to manage information flow

With all of this connectedness between tools, and teams across multiple time zones, the Jira team still felt the heat when it came time to release. When teams adopt agile practices, the goal is to work faster in small teams to iterate and deliver code as often as possible. With everyone moving at a faster pace, and with more interdependencies between teammates, it became more crucial than ever for Atlassian team members to always be on the same page on an upcoming release.

release_hub_active_600px

To help software teams see the real-time progress of a current version being built, we created the Jira Release Hub. In the summary view of all versions in the Release Hub, users can easily see the status, progress bar, start date, release date, and description. In the detailed view for a particular version, users can quickly see the breakdown of issues by To-Do, In Progress and Done and the total number of issues. Below the bar, there is more detail of each issue within the version, showing a summary, assignee, and status.

A very useful feature of Release Hub is the “Warnings” Tab, which alerts you to any potential development issues that could cause a problem in your release. It will display when the status of a Jira issue doesn’t properly reflect the related development activity. For example, a “Failing build” warning will display when an issue is done, but is linked to a failing build in Bamboo, or an “Open pull request” warning will appear when an issue is done but has an open pull request in Bitbucket or Stash.

When it’s time to ship, you can even release a version from the Release Hub which will mark the version as complete, move incomplete issues to other versions, and trigger a release build in Bamboo.

For teams that are highly inter-dependent and don’t have the time to update everyone on what’s happening, or have distributed team members who aren’t able to connect due to time zone overlaps, the Release Hub is gold.

ProTip: The “Warnings” tab will display if you have the “View Development Tools” permission for the project and you are a project administrator for the project. You can hide or show warning types by clicking the “Manage warnings” button. To get more insights into the Release Hub and to learn how we use this new tool at Atlassian, watch one of our most popular webinars: Journey to a stress-free release

Removing boundaries by connecting Jira and Hipchat

JIRA-HipChat-integration

Lastly, the answer to our communications problems came in the form of Hipchat. If you ask any Atlassian the first thing they do every morning, most will tell you that they’ll review their team’s Hipchat room to see what they’ve missed the night before. But it’s not just conversations that occur in Hipchat rooms, work progress in Jira is tracked as well.

By integrating Jira and Hipchat, teams are able to mirror the activity and status of a Jira issue in a dedicated Hipchat room and view the conversation around that issue from within Jira in the dedicated Hipchat panel. Or, if you’re already in Hipchat and need to quickly pull up the status of a Jira issue, just mention the issue key or paste the URL into the Hipchat room. This gives you less context switching, more automatic status updates, and the ability to have one infinitely searchable conversation about your project.

For our remote teams, one of the most popular Hipchat add-ons is called ‘Standup’. At the end of your day, it will ask you what you worked on today and what you plan to work on tomorrow. So when a remote dependent team gets to work on the other side of the world, they can simply check the standup room and see what their co-workers have done and plan to do next. This eliminates confusion or the need to send off an email and wait for a response.

By stripping away the boundaries between Jira and Hipchat, agile teams can truly move with speed to get work done.

ProTip: To configure Jira with Hipchat, check out these nifty instructions.

That’s a wrap, folks

To recap this series, we showed that despite the numerous pluses of teams becoming more agile and scaling globally, there are still associated challenges. Broken communication, difficulty in collaboration, and lost productivity are at the heart of the problems. But on the bright side, we also showed you how Jira and the suite of Atlasssian tools that can connect to it, is able to solve these problems. We know we still have a long way to go to make software teams peacefully hum together, but the Jira team will always be with you as you grow.

Want to learn more?

Register for the webinar

The challenges of scaling software development teams globally – Part 2