[TEAM – Atlassian] Collaboration and Competition
Atlassian’s birth and rise coincided with the adoption of the Agile software development framework in the early 2000s and the DevOps movement that grew out of Agile a decade later1. In a non-DevOps environment, software development and IT operations function as two segregated departments responding to local incentives: simplistically, developers attempt to release features into the wild as soon as possible while IT (and Infosec and QA) manually tests those features to ensure they comply with security protocols and don’t disrupt the integrity of existing infrastructure and applications. Implicit in this tension is the notion that speed and innovation come at the expense of safety and reliability.
But in fact, a silo’ed, traditional waterfall approach to development not only impedes innovation but perpetuates fragility: because software is created in large batches before being tested, code reviews take longer and errors are harder to detect; because testing and quality assurance occur only at the very end of a project, just before deployment, tracing an anomaly back to its cause is effectively impossible and leads to short-term workarounds that everyone pinky-swears to replace with a more permanent fix…which, of course, they never do. Errors build on top of errors and mounting technical debt produces a shaky, unwieldy system that becomes ever harder to rectify, a Jenga tower of code that everyone is too afraid to touch. Feature deployments decelerate, outages mount, customer experiences deteriorate, engagement drops, and employee morale plummets.
An alternative setup, one embodied in the philosophy of Agile/DevOps, has small groups of developers working in 2 or 3 week “sprints”, continuously A/B testing and integrating small batches of code to the trunk, with every change logged into version control. Rather than having a developer wait in line for QA to test his program, a battery of automated tests – ensuring that the new function works as the programmer intended, that the application containing the function works as it’s supposed to, and that the application works in interaction with other applications – is triggered with every commit, and if a problem is detected, an “Andon cord” (so to speak) is pulled, production is halted, and the error is swarmed with resources until the root cause is identified, isolated, and resolved. In a fast feedback process like this, where code is maintained in constantly deployable state, any issue that emerges is proximate in time to the change that caused it, and is not left to migrate further down the value stream where it festers with countless other changes that went unaudited earlier, any one or combination of which could have caused the issue.
The shift from slow, error-prone big bang releases to fast, iterative improvement is both mirrored and enabled by the effortful re-configuration of organizational structures from hierarchical, territorial groups to small (“2 pizza pie”) cross-functional teams in constant communication. Rather than serving primarily as an internal help desk manually tackling ad hoc work tickets, Operations creates self-service platforms and automated testing tools, often jointly with developers. Rather than being relegated to a special team sitting at the end of a deployment pipeline, error-checking is everyone’s responsibility, embedded in everyday work. The local goals and incentives of Development and Ops are subsumed under the broader mandate of releasing code that delivers value to the customer. Work is not marked “complete” until changes are reliably running in production. Developers and IT professionals who work alongside one another on common goals develop mutual empathy. Morale improves as work is placed in broader context (IT is not simply being told, in a contextless vacuum, to “configure such and such server”) and teams are granted autonomy and accountability over their work.
The upshot of all this is that features are developed and deployed faster and with greater frequency, and the consequences of failure are, like the batches of work that preceded it, small and manageable. “Every company is a tech company” and “software is eating the world” blah blah blah, so it is perhaps no wonder that the DevOps framework has been embraced with such alacrity over the last 5-10 years…as have the workflow management tools that enable and reflect Agile/DevOps processes, like Atlassian’s first and flagship product, Jira. Jira was an internal tool that Atlassian co-founders Michael Cannon-Brookes and Scott Farquhar, who together have ~93% of shareholder voting power, created to manage the open source consulting projects they were staffed on. Their clients clamored to use the tool for themselves and in 2002 a workflow software company was born. At the heart of Jira is a kanban board, which, if you’re not familiar, is a visual representation of a workflow process that reputedly originated in Toyota’s engineering department sometime during the 1940s and is ubiquitous today. It tracks units of work as they migrate through progressive stages of completion.
In the context of DevOps, relevant stakeholders use it to, among many other things, manage code changes and ensure that one code deployment doesn’t interfere with another. Security issues are tracked in the same kanban board used by engineers rather than in separate tools accessible only by Infosec teams. The board can be supplemented with reports that plot, for instance, a moving average of the amount of time it takes to bring an issue from start to completion, allowing everyone to easily identify issues that took an abnormally long time, or integrated with chat-based collaboration apps – Stride, Teams – that create a public record of all communications.
[Here is the kanband board of Atlassian’s Build Engineering team, a group of 5 people who support internal development by providing and maintaining the build infrastructure. Note that this team has specified a maximum number of work units at the top of each column, preventing new issues from entering that sleeve until the existing bottleneck (like the third column with the red header) is cleared out, which keeps batch sizes small and prevents errors from compounding]
Jira first found traction among software developers before spreading over the last 4-5 years to non-software teams, branching into three different separate versions – Jira Software, Jira Core, and Jira Service Desk – addressing different use cases and enterprise groups. Taken as a whole, Jira is by far the most popular developer tool today (at least among customers of Okta, a popular cloud-based identity management product that gives employees single-sign on access to a multitude of SaaS apps). Among the 47% of Okta’s customer base that uses at least one developer tool, nearly half use JIRA. And that steeply sloping orange line in the below exhibit is Atlassian Cloud, a central hub from which administrators can provision Jira and Confluence users.