Do you notice teams working in silos across your organization? It’s a common occurrence, and one of the biggest mistakes an organization can make, especially when the separation created by silos involves teams that have the same goals. Often, the development of silos is caused by a lack of awareness, and confusion on where to turn for best practice guidance and usage. Or, let’s be honest here, sometimes it’s just an under resourced admin.
Ah, but there is a way to break through the silo effect: streamlining. When you streamline your applications, like, well, your Atlassian applications, it will help you steer clear of the mistakes created by silos – and perhaps keep silos from forming in the first place. Streamlining your applications will also help teams resolve and ship as many issues as possible, in less time, and have a clear line of communication while do so.
But. (There’s always a but.) We all know that consolidating your applications is easier said than done. And it sure ain’t a one-person job. So, how to break through the silo effect?
One way to do it is by enlisting the services of a TAM, or Technical Account Manager. A TAM’s primary focus is to help provide strategic, best practice, and technical advice for implementing, using, and scaling your Atlassian applications. This can mean many things – and different things for different customers – but one example is by helping enterprise organizations “marry” their Atlassian applications in a way that supports their teams’ workflows. Just this synchrony has a strong influence on avoiding the silo effect.
Visualizing development: why seeing is believing when it comes to avoiding silos
A TAM in our San Francisco office recently worked with a Fortune 100 financial services organization that had several instances of JIRA Software and several instances of Bitbucket. The TAM worked with his customer in understanding the need for development visualization within their organization, information architecture, and development patterns. The concept is really quite simple. Teams have access to what others are working on because there’s quick access to JIRA Software data inside of Bitbucket, and Bitbucket data inside of JIRA Software. JIRA Software can track which builds, branches, and pull requests in Bitbucket relate to a particular issue, and so on.
This gives teams across the organization (not just development teams) insight into how the code developers are working on directly relates to the issues in their own projects. And developers don’t need to leave JIRA Software when they need to create a branch. Together, this makes the development workflow smoother and subsequent tracking of the code, branches, pull requests and builds that much easier process.
Understanding Information Architecture boosts speed
Have you ever been in a building and can’t find the exit? Or visited the zoo and can’t find the monkeys? Information Architecture (IA) is about helping people understand their surroundings and what they’re looking for. The way JIRA Software and Bitbucket are organized, structured, and now the data is labeled supports IA in helping end users understand where they are within the application, what data they’ve found, and what to expect in terms of next steps.
A Bitbucket instance is divided into a series of projects, each one housing a collection of related Git repositories. A common pattern is to have one Bitbucket project corresponding to each JIRA Software project – but there’s no hard and fast rule if you have different requirements. Each repository contains all of your source code artifacts – your code, your Git branches, tags, and pull requests.
If you’re using JIRA Software, a common development pattern is to reference the issue or issues that you’re fixing in your commit messages. When you push those commits to Bitbucket, a lightweight indexing process plucks those issue keys out of your commit message and stores them for later use. One of these uses is displaying them inline on the repositories commits page.
Using development patterns that support your workflow
There are two fundamental components to any JIRA Software project, a set of issues that represent business problems, features, or bug fixes that need to be implemented in your software. And then there’s the code that actually implements those changes.
If your developers use a traditional linear workflow in their repository (like committing directly to the trunk if you’re using SVN or master if you’re using Git), it can be hard to tell what state your issues are in. Without marrying JIRA Software and Bitbucket you’d be unable to tell that a developer has started work on a particular issue, whether the feature is complete, or if they have more changes to commit.
The TAM unified and integrated the enterprise’s JIRA Software and Bitbucket instances, and ensured the teams smoothly transitioned to the new setup. He also worked closely with engineering to ensure the developers and other stakeholders were completely satisfied and productive with their new Git workflow.
If you’re interested in working with a TAM to, please don’t hesitate to reach out!