I often get asked about how we use our own tools for software development here at Atlassian. Since it is fast becoming the norm to work as a distributed team at Atlassian, I thought I’d take a moment to share some of our experiences in working more efficiently across time zones and geographies. I’m highlighting FishEye and Crucible as we’ve spawned a new team in Gdansk over a year ago, so it’s a good example of a distributed effort.
1. Release planning
Planning begins when the Product Manager (PM) creates an overview page for the next release. The PM consults with the team at least once per quarter in a separate ‘Roadmap Meeting’ to ensure buy-in, to communicate any strategic shifts, and mainly to hear from the development team on what they believe are the top priorities. We then create ‘stories’ that richly describe what, why, and how the feature is actually used by customers.
The PM uses Confluence to manage all input centrally regardless of where the team member sits. A vote on the release candidates ensures the key stakeholders have a voice into the planning process and the overview page that’s been vetted.
Here’s what a spec summary looks like:
2. Spiking and speccing
The completed overview page kicks off the 2-week sprint which we call ‘Spiking and Speccing.’ This step is about defining how the feature will function, how it will be implemented, how it will be tested, how much time it will take, and it will close with a recommendation for continuing with the feature or not. The output is a fleshed out spec for each feature which has:
- Been peer reviewed
- A task list breakdown
- Rough estimates for each task
- A QA and test plan
- A list of risks and mitigation for each
- Often changed quite a bit from the original idea or plan
- Been vetted by the PM, Development Manager and key stakeholders
3. Feature buddies
A feature buddy is your feature champion. They are your second pair of eyes, ears, and hands that help ensure the feature you’re leading is on time and of high quality. And if you pair up leads and buddies in different geographies, you also encourage cross-pollination of ideas across time zones and even cultures. Collaboration tools play a big role here.
- Confluence is used for initial feature spec review, discussion, and clarification. It’s also used to articulate larger problems, and RFC from teams.
- JIRA is used for sprint planning, status reporting, and customer support.
- Crucible is used for code reviews. This has been very important for knowledge sharing about the code.
- HipChat is used for daily stand-ups.
4. Project plan
Once all the specs have been reviewed and finalized, we create a project plan that lays out who is doing what and when. It helps us visualize what the release will involve. By posting on our intranet (we use Confluence) we also get quite a bit of discussion on scope, timing, and risks of the feature development.
We can also factor in developer resource needs arising from Support, bug fixes, and vacation plans. All these inputs make for a solid project plan that’s got much greater execution confidence. Here’s what a project plan looks like:
5. QA Kick-offs
Our QA kickoffs involve quite a lot virtual conference interaction for the distributed team. The QA Kickoff happens once the Spiking and Speccing is complete and the document goes final. Teammates vet the features and specs further as they try to find holes in the planned implementation, the planned UX, and to devise a test plan for the feature.
This meeting is also a final gate for the feature (before development begins) and is used to establish the quality bar before product can ship. Notes from the QA Kick-off meeting are left on the Spec for the feature. This allows anyone not present in the meeting to also chime in with suggestions for test planning.
6. Sprint planning
With four releases per year, we simply must plan carefully what’s in and what’s out for each release. At this point, the specs already have the task breakdowns, and for each spec in Confluence we create one Epic in JIRA. Then below this Epic, we create the tasks which the engineer has identified in the speccing sprint.
The first sprint on Spiking and Speccing gives us good information to consider de-scoping or even dropping a particular spec if it’s not worth jeopardizing the overall release schedule. Sprint planning therefore really allows us to fix a release date with much higher confidence.
By the way, we’ve learned that sprint planning is best done separately in each office first. It turns out that trying to do live sprint planning across many time zones and cultures is too tricky. So once all tasks and stories are planned and in the next sprint, the planner will look at JIRA Agile and ensure each Task has been story-pointed and resource availability has been factored.
7. Daily stand-ups
At the end of each workday, we leave a #standup message in HipChat. This is the best place to ask questions that have arisen during the day or to flag any blocking tasks or issues. Since the last retrospective, developers also report their Review Inbox count. This encourages people to get their reviews done on time as often developers may inadvertently block progress if they’re not performing their reviews on time.
8. Sprint demos
Since our time zones are such that there is never an overlap between 9am and 5pm, there’s always one team working outside these hours. A work-at-home option helps those people bridge the gap. We use BlueJeans to connect to our Polycom Virtual Conference system so that people can join from home or anywhere. And simple things like ensuring that the ‘Demo Agenda’ page contains information about each demo really helps to save time in the demo meeting or allow people to view/interact with the demo themselves.
We’ve even made a simple Confluence Blueprint for this!
9. Staying connected
All of this has not been achieved purely via VC links. We’ve traveled a lot between the offices as nothing beats face to face. We’ve tried to ensure that during each visit, there was at least one Release Event for the team which is a blend of fun, team building, and work. It’s been invaluable not only for getting to know each other but also for learning how each person works. We’ve found it’s important to understand different communication styles, personalities, and cultures when 95% our communication is written.
10. Continual improvement
We’re thrilled that all these practices have helped us achieve a big milestone — FishEye and Crucible are now driven entirely from Gdansk instead of Sydney. This shows the level of trust between the two teams is extremely high, and exemplifies how distributed development teams can work well. But there’s always room for improvement.
For the past 12 months, we’ve met as a team, twice per fortnight – Tuesdays for demo meeting, and Wednesdays for planning. We’ll try merging these two meetings into one to improve efficiencies. It will require more prep ahead of the meeting but should lead to time savings. If the trial works, we’ll adopt the practice as it’s all about continual improvement. Time zones do continue to remain a challenge but with teleconferencing, onsite visits, and attention to good communication we can steadily improve there too.
The efforts by both teams to stay connected, and focused on achieving the same goals have definitely been worth it. The high level of enthusiasm within the FishEye and Crucible develop team to make a difference and continually improve how we work together has been a highlight. It has certainly been an equal effort all around with the team in Gdansk continually pushing just as much to improve the process and product as the team in Sydney does.
Also, thanks for reading this far. What techniques do you find most useful to help your distributed team collaborate most effectively?