If you’ve worked as part of (or close to) an operations team, you know how hard it is to innovate while juggling the operational load. But this doesn’t stop your knowledgeable, talented team from coming up with innovative ideas, right?

I’d like to share with you some of the details–the successes and failures–of our attempts to continue to innovate while always keeping an eye on the ball. (An American saying that means continuing to take care of business.)

At Atlassian Support, our situation is no different. We support the full stack of Atlassian products from seven locations on different continents for more than 50k customers that have more than 10 million daily users who open more than 400 requests every day. Phew!

Still, one of Atlassian’s core values is “Be the change you seek.” In this case, it means that we can’t put off innovation despite how busy we are. We simply can’t let the obstacles to needed change stand in our way forever. In other words, we can’t be too busy to innovate.

So the question becomes, how does innovation–change that benefits the whole team–actually happen? There’s always the next critical thing to do at any given point in time. It can feel like fighting a fire that’s bearing down on your house… while remodeling the kitchen!

Idea 1: establish an “investment hour”

First, we came up with an idea called the “investment hour.” The investment hour was a small chunk of time (usually an hour per day) allocated to each person for a project of their choice. This idea had some initial success, but we quickly discovered the arrangement relied too heavily on personal habits and traits like time management skills and drive. There was too little accountability because it didn’t have an actual process, and it was too difficult to plan and coordinate.

Back to the drawing board we went.

Idea 2: form a projects team

Our next idea took us in a radically different direction. We formed a “projects team”: new developers hired externally with dedicated time to work on bigger projects. This approach looked good for big, long-term projects, but there was too little time for small improvements directly on the shop floor. This new projects team was just too far removed from operations and didn’t directly benefit from the support engineers’ knowledge and experience.


With these (failed) experiments under our belt, we did have something: experience. Could we use what we’d learned to help find a *magic* formula to release the innovative potential of our engineers? We knew we wanted to go big on the projects within support, but how?

Idea 3: find a role model

Here’s what we wanted to do:

  • Work within the team
  • Stay focussed and not get distracted by day-to-day operations
  • Deliver fast
  • Be responsive to changing requirements
  • Have flexible planning

For inspiration, we went to our software development team and asked questions. And that’s how we realized that scrum was the way to go! At the core of scrum are roles:

  • Product owner – who keeps the team focussed on building the right thing
  • Development team + scrum master – whose aim is to build the thing right
  • Stakeholders/customers/sponsors – who give feedback and ultimately… use the thing! (Which is, in fact, the whole point)

Idea 4: try scrum

So we came up with our very first scrum project: Wallboards for Support.

We worked in two week sprints, with one day of project work per person for every two-week iteration (5 work days in an iteration). And guess what? We found a formula that worked! We continued with it for four months and, naturally, this led to four months of uninterrupted and smooth execution, on-time delivery, and new projects galore.


We had challenges. For instance, engineers were constantly being pulled into operational work. But this time, however, we dealt with the challenge as a team and we came up with some structure for handling these situations. When this happened, other team members realized they needed to pick up the slack, plus they knew why they had to pick up the slack. (Team work = Dream work).

At last, after several iterations, we shipped Support Wallboards! And they are currently being used in every support-based office across Atlassian. 

atlassian support wallboards

Atlassian support wallboards office

Every support team across the globe was happy. But the scrum team was not completely satisfied. Why?

  • We couldn’t follow the textbook scrum because of time constraints
  • Having one day per two weeks to work on projects led to a lot of context-switching and affected focus
  • The team couldn’t do a lot of teamwork because each member had to work on a different day of the week

Idea 5: iterate and ship

Nevertheless, this was the closest we had come to a working formula for innovation work. Scrum projects were our first step in the direction of bigger and more structured improvement projects within support.

Flash forward, Atlassian now has an Operational Excellence manager to lead and coordinate future projects within support and other customer-facing teams. He has already implemented a new way of working on longer term projects and has added structure that has influenced resource planing for the team. Now each month, three engineers (from different support teams) are freed up to work on the most important project. As for methodology, we use a blend of scrum and lean methods.

Using innovation to take your service to the next level is easier than you think, but you must be willing to experiment and think outside the box.

And remember: these projects are an investment.

I hope this helps you work out your own way to deliver innovation within the framework of your services.

Inside Atlassian: using scrum to balance operations and innovation on the support team