Atlassian Agile Process part 4
Chris Mountford, JIRA Developer talks about AtlassianNovember 28, 2007
In this final part of my series on Atlassian Agile Process I wrap up and reveal XP's fundamental weakness. Oh and I cover socoipaths! And Ninjas. But no pirates. See also Part 1, Part 2 and Part 3.
Some Other XP Practices
Let me get the rest of XP out of the way. Sustainable Work Hours, Collective Code Ownership and Metaphor are XP practices we don't give much thought to. The first two we embrace completely and the third we pretty much ignore. Then again, Bamboo has a metaphor: Telemetry. Perhaps Metaphor is more important towards the beginning of a system's life.
Extra Practices
The following essential practices for our process are not defined in XP:
Specifications
Purists and detractors mistakenly think specifications are in conflict with XP ideals. We aim for our specifications to be both minimal and complete. Which is a blend of just enough documentation and turning the knobs to eleven (for that extra push over the cliff). They are written in Confluence to a template with a checklist for the dozens of essential aspects to a new feature. The checklist includes things like security, user interface design, caching, remote APIs etc. From the spec comes a stack of task cards.
Training
Alternating fortnightly with the process improvement meeting I mentioned in Part 1 the JIRA team has an hour for internal training. Confluence has a similar regime. Cross-team involvement is growing. In addition to team-internal technical talks, Atlassian has recently started larger cross-team developer training events. For example last week we were treated to one on GWT by the dynamic duo, Bruce Johnson and Joel Webber who were in town at Google Sydney. Increasingly training goes on outside the software process.

Hiring
Hiring, I think, should be a specified part of any development process. It's something I've been involved with for a long time and something I've learned about through making mistakes. Hiring also has a huge impact on your process.
Our agile process requires people to spend the effort to listen and talk to each other, working closely. You have to be a people person to like it. It doesn't suit sociopaths. Accidently hiring a sociopath is going to make XP impossible. Trust me, I know. To me this is XP's fundamental weakness. Of course if you only hire ninjas, you probably don't need much formal process. Ninjas just do what needs to be done.
Hiring great people is something we take very seriously at Atlassian and we try to make it quick and effective. Our interviewers are busy developers and our favourite candidates are going to get other offers. The hiring process involves screening, phone and face to face technical interviews and a coding test. We are conservative. We would rather err on the side of not hiring someone. Of course the problem is Ninjas are very hard to find.
We also do a lot of things to keep people happy once we have hired them. We have an awesome work environment and excellent tools. We are also hiring right now! Sociopaths need not apply.


2 Comment(s)
Hi Chris
Great posts - thanks for the insight into your process.
Since you have two...no wait...three offices around the world now, how do you collaborate globally?
Is development for any product done in multiple locations? Wondering if you have got your feet wet with Distributed Agile.
Also, any thoughts on making the task cards virtual instead of the wall - to increase visibility outside that one room? The last company I worked with had a distributed team and we used Confluence to create our task cards - but I felt that limited the impact of the cards and were ignored easily.
Thanks again.
By Apurva Kothari at January 25, 2008 6:57 AM
Guess I could use Greenhopper for the virtual cards - just saw it:)
By Apurva Kothari at January 25, 2008 6:59 AM