Atlassian, Sydney, Australia


An agile software development team puts its money where its mouth is.


The Project Turtleneck Team: clockwise from left, Mike Cannon-Brookes, Tim Moore, Andreas Knecht and Melanie Carasso, PhD, PMP

The Project Turtleneck Team: clockwise from left, Mike Cannon-Brookes, Tim Moore, Andreas Knecht and Melanie Carasso, PhD, PMP

Agile is the norm at Atlassian. Every development team at the software company uses some form of the methodology.

Still, even the “been there, done that” veterans of agile were thrown for a loop when co-founder Mike Cannon-Brookes dreamt up a project to create and implement a dashboard to show off the company's own software. Not only did he want to demonstrate the interactivity of the products, he wanted to do it in real time. He also needed to debut it at the company's first user conference, which was a year away and halfway around the world in San Francisco, California, USA.

“In a very short space of time, we had to go full steam ahead,” says program manager Melanie Carasso, PhD, PMP.

Impressive in vision, the project called for a break from the company's modus operandi.

“It was a little different because each product has its own roadmap, and the teams had worked mostly independently to that point,” Dr. Carasso says.

Pulling members from each team would require a new level of collaboration and integration.

“We had to get this really working across all the products, and it was technically challenging to do that in a consistent way,” she says.

The team dug in and even gave the project a clever code name: “We called it Operation Turtleneck because we wanted to make an impact, like [Apple CEO] Steve Jobs does with his turtleneck,” Dr. Carasso says.


“Turtleneck was important for two reasons,” says Mr. Cannon-Brookes. “First, we needed to show our customers that our products could integrate together using a common technology. And second, because our engineering team had to prove we could ship a large deliverable with a fixed deadline across multiple large teams.”


Be creative when rewarding team members—especially if they've been working long hours.

“Everyone was getting exhausted, so we started a daily agenda of reward and encouragement: cupcakes, massages, ‘managers are your slaves’ (where we bought coffees for our teams each day) and breakfast barbecues,” says Melanie Carasso, PhD, PMP, Atlassian.


To accomplish those goals, Dr. Carasso knew she had to pick a team that could fully exploit agile. As far as knowledge of the methodology went, she could start from a fairly even playing field. Although each team in the organization uses slight variations on the agile theme, there's a standard baseline all adhere to:

  • Daily stand-up meetings. Lasting just 10 minutes, these are structured for team members to briefly delineate the previous day's tasks and outline the current day's plans. “It's not designed to go on for a long time,” Dr. Carasso says. “If there are big problems, we'll talk afterwards.”
  • Continuous integration. One of the hallmarks of agile programming is integrating chunks of code as they are finished rather than doing so in one session. “We don't have long periods where somebody has not checked in their code—we're doing an incremental build every night,” she explains.
  • A close relationship between developers and testers. Atlassian automates as much testing as possible to give testers time to concentrate on more complex tests. As a result, the developers and testers work closely together. “We have a pretty small ratio of quality assurance to development, so we have to be selective about what we test manually,” Dr. Carasso says. “Our developers know that they need to take a lot of responsibility for their own code.”

Given the time and scope of the project, Dr. Carasso needed to choose her team leaders carefully. The two leads she had in mind were a dynamic pair: one a product manager with a passion for the company's vision, the other a senior developer with strong communication skills and an eye for detail.

“I really liked that one could really embrace the vision, and the other would be terrific at more detailed project management,” Dr. Carasso says.

The one drawback was that both worked out of the company's San Francisco office, adding a geographic wrinkle to an already complex project.

“We knew there was a risk that they were over there and we were doing the features here,” Dr. Carasso says, “but we had faith that these guys knew their stuff.”

The San Francisco contingent shifted its work hours to increase the window of communication. And the entire team relied heavily on Web 2.0 technology: IM (instant messaging), a dedicated chat room and collaborative software that provided a centralized location for the entire project.

“It was just constant communication,” Dr. Carasso says. “It doesn't matter where you're sitting when you can just hop on IM and constantly talk that way.”


Dr. Carasso concentrated on what she calls hazard removal. “Agile is different in that it is a lot less formal,” she says. “Rather than nagging at people to fill out documentation, my job is to get stuff out of the way so that the team can do its work.”

After a couple months of planning, the team kicked off development with what Dr. Carasso called the “dashboard hackathon.”

“We got to the point where we were ready to start implementing the framework,” she says.

It was time to pull people from other teams to collaborate on integrating products into the dashboard. To prepare, Dr. Carasso relocated some staffers to create an area for her team to sit together. She also flew in the San Francisco leads and moved everyone into the temporary headquarters for a week.

“I was sitting on a beanbag chair with my laptop for the whole time,” she says. “I had a pretty bad backache, but it was worth it.”

The team leads held a kick-off meeting, securing team member commitments for what could be achieved that week. The emphasis was on coming up with solutions that worked well enough, without worrying about coding to perfection. By the end of the week, everybody had hit their targets except for one team member, who had fallen victim to an unfortunate case of food poisoning.

Despite the team's previous success using Web 2.0 technology, Dr. Carasso says “that week of colocation was a great thing to do. You could just turn around in a chair and ask rather than sending e-mail or IMing.”

The hackathon also gave the team a much stronger understanding of the technical problems that needed to be solved, allowing them to accurately prioritize tasks and change course as needed.

“We essentially took a risk-focused approach, looking to solve the high-risk tasks first. If we couldn't get around the problem, we'd go to Plan B,” Dr. Carasso says. “We really had to be flexible and collaborative with the decisions, because we were sprinting toward this deadline that was not going to slip. We had to show whatever we had ready.”

By the time the conference rolled around, the team felt confident enough to push the marketing department for a live demo rather than a pre-recorded video.

“It was a heated debate, but we were very motivated to fulfill the original vision,” Dr. Carasso says.

The marketing powers consented to the gamble, and the program went off without a hitch.

“I was the most relieved person in the whole building,” she says. “All in all, it was quite gratifying. A lot of time when you have a team working on a big project, you can't always see the results. This was an extremely public finishing spot, and it was fantastic because we really got to see the results of our work.”

Those results instilled confidence. “For our engineers, it was a validation that we can set a big, hairy, complex goal, focus the entire company on it and achieve it,” Mr. Cannon-Brookes says.

The project also paid off with closer bonds across product teams—which could yield future dividends in flexibility and deeper expertise.

“This was the first project we did that involved cross-product cooperation, and it really cemented some good relationships,” Dr. Carasso says. “It helped establish a lot of collaboration between different geographic regions, and it made it easier for people to switch to different product teams. It's now more of a matter of course for people to jump to different teams.” —Carol Hildebrand




Related Content

  • PM Network

    The Next Agile Awakening member content open

    By Parsi, Novid, During the all-hands, anything-goes disruption of the global pandemic, agile has been both a reinforcement and a revelation.

  • PM Network

    The Certainty of Uncertainty member content open

    By Fewell, Jesse, As much as we yearn for a pre-pandemic return, it's naive to think the old ways of work will ever return—even for agile.

  • Project Management Journal

    Interruption in Agile Software Development Teams member content locked

    By Wiesche, Manuel Using agile approaches invites changes to the project and increases interactions between team members.

  • Research Summaries

    Taking Agile to Scale member content open

    This study explores the evolving impact of agile practices on large-scale software development programs with an emphasis on multiteam coordination.

  • Project Management Journal

    The Role and Characteristics of Hybrid Approaches to Project Management in the Development of Technology-Based Products and Services member content locked

    By Copola Azenha, Flávio | Aparecida Reis, Diane | Leme Fleury, André This research analyzes how organizations that develop technology-based products and services apply hybrid approaches to project management.