Last week I posted part 2 Atlassian’s Agile software development process. Part 1 was the week before. This week I deliver the next iteration. Update: part 4 now available.

Continuous Integration


Continuously building and automatically testing our software is essential for quality. We have many dozens of combinations of editions, distribution types and different versions of supported servers and JDKs on the subversion trunk as well as the stable branch. That’s for each product. We need continuous integration servers with muchos grunt. Just for Jira (not including plugins) we have a high end four way continuous integration server (and a second box on order). We have prominent displays advertising the health of our builds and tests (green is good, red is bad) and we take every opportunity to laugh and point at other teams whose builds may be currently failing. Of course we use Bamboo for continuous integration! CI Newbies should start with Martin Fowler’s canonical introduction.

Small Releases

Iterations are one week long, releases are 6-12 weeks long, depending on the product and the scope of the release. While some customers like high release frequency, others have aversion to the perceived upgrade overhead that our releases push onto them. Some customers are not comfortable receiving notification of a new release too frequently, nor of falling too far behind the latest available version. Releasing less often is an option, however we would still fight to ensure that we produce production-worthy software at the end of each iteration.

Making the software available for download often seems to engineers as an undeniably good thing. Low latency is good, right? If you don’t want it just don’t upgrade, right? Well it’s more complex than that. This topic is on high rotation for debate at Atlassian.

On Site Customer

We have thousands of customers, but everyone in the company is also a customer of our software. We self host. We eat our own dog food. In fact Atlassian lives on its own dog food. Dog food is yummy. It’s critical to understanding how the software should be improved.

Nevertheless we sometimes struggle to see things from a customer’s unique point of view. We know how we use our software but people use our products in all sorts of crazy situations beyond our original expectations. So, having recently filled specialist roles, we are growing coherent product management. These folks will become our customers on site.


Refactoring is about not getting into technical debt (or slowly getting out of it as the case may be). Like with many of our practices we have practice champions whose job it is to monitor and report on team performance for a specific practice. For example the Jira refactoring champion is currently Dushan, a black belt in karate. Mostly the team accepts that checkins of, say, copy and pasted code could put us in hospital. It’s tough but fair.

Next time…

In part 4 I plan to cover the remaining XP practices and also two practices we think are essential to Atlassian’s Agile process that are not part of XP. Unfortunately, because the topic of sociopaths is the lowest priority item in the backlog for this series of posts, I’m going to have to push it off until part 4. I have to cut scope, I’m at the end of my time box and I have to ship what I’ve got. Sorry about that. Next time for sure 😉

Atlassian Agile Process part 3