Collaborating Across an Enterprise: Quarterly Planning at Twitter with JIRA and Confluence

[#1]

Twitter began with a sketch on a piece of paper. A status update. A site for people to share the latest happenings in their life.

Over the years, this evolved into a platform where people share things that are a part of their everyday life, as well as Breaking News.

As we saw ourselves growing across the world in different geographies and markets, being used by people of different languages, we had to scale out the service as well as the engineering teams to support that.

What happens if you don’t scale?

Twitter's Fail Whale

This image was drawn by an Australian artist and was used by Twitter.com when the service was down to show that we’d stuffed up – an example of something that happens when you don’t scale.

And this is something that happens when you do scale.

We reached this number shortly after the US Presidential Election.

And then the following August (2013) we facilitated almost 10 times the volume.

 

The rate and pace with which we were growing was why it was so important we were staying on top of the growth of the service and scaling the company as a result.

So how did we do this? Company Alignment – it all starts with a vision

You’ve got all these people, and you are managing to solve all of these technological problems around scaling the service, how do you scale the people?  

It all starts with a vision. Our vision was Tahrir Square.

 

At Twitter, we wanted to foster and facilitate the communication, discussions and conversations that took place in Tahrir Square, around the whole world.

Our vision was to be the global town square.

We broke that vision down into our goals – our Objectives and Key Results (OKR’s)

The Objective = where do we want to go?

Key Results = how will we know when we’re getting there?

So when we looked at our company goals, we started right from the top, with our company objective/s, and below those company objective/s we had our Key Results.

This vision was so important because as we cascaded down and fed back up, we had alignment across the whole company – and of course the alignment is what packs power and effectiveness.

Structuring with Tools

The tools are what gave us the structure to enable us to change the behaviour across the organisation – and at scale, changing people’s behaviour very quickly in a manner of months was super important.

At Twitter, we used the following tools to do this;

JIRA, JIRA Agile, Script Runner, Confluence and the Confluence Presentation Macro

The Approach  

It was extremely importing for us to have consistency. The way we achieved this was through JIRA Agile, which allowed us to input all of the data in the same way, every time for every team.

JIRA

• Epic Issue Type
• Prioritise Epics
• Workflow
• Fields
• Links

Epic Issue Type

• Each Team had their own Project (1 Project = 1 Team)
• Our Epics represented our Key Results
• We captured the Fix Versions (what quarter were we trying to satisfy this Key Result?)
• We provided Components – (quite often teams will have Key Results that relate to different components over time)
• Linked Issues (what are the incoming and outgoing dependencies that we have?)
• Epics were ordered from most valuable to least valuable in the Epics column

Prioritise Epics

Each team will have their own agile board (Scrum board). Down the left hand side of that board (Epics column) is where teams are able to drag and re-order their Epics based on most valuable to least valuable Key Result.

Workflow

Beyond the Epic and the ordering of that Epic, we had a special workflow.

A lot of the workflow that we had for our Engineering Teams at Twitter, involved a lot of automation. So what we did was create an entirely separate workflow just for the Epics.

Some of these included;

• Open (it’s on our backlog, or an idea for a future quarter)
• Accepted (something that we were going to commit to delivering this quarter)
• In Progress (something committed to the current quarter that we were working on)
• Shippable (this was something that we used for our teams who were on iOS and Android development, because in that scenario, they may have delivered a piece of work, yet it was waiting for delivery to the Play Store or the Apple App Store)
• Resolved (the final state that all of the Epics would end up in)

** One thing to note: the Resolved step changes the Epic Status field to Done and takes that Epic (Key Result) off the team’s board

Fields

A few key things to note here.

The Assignee was generally the Engineering Manager of the team responsible for delivering the Key Result and the Reporter is quite often the Product Manager or the Product Owner for that team.

The Key Results field was really important for us. It was the second part of that question “how will we know that we’re getting there” and that’s what we were looking at achieveing throughout the aurter.

Links

This is where we looked at the incoming and the outgoing dependencies.

This visualisation of dependencies enabled us to have key discussions prior to the beginning of a quarter, if we could see that the thing we were depending on from another team in order to reach our Key Results, would not be delivered in time.

Having these links helped us align as a company and make sure that we are all on the same page.

Confluence

Confluence was how we shared what was going on with the whole company.

We had pages for Company, Group and Team Goals.  On the Company and Group level, the objectives and Key Results were laid out in predominantly text – there was no JIRA integration here.

As we got down to the Team level, we illustrated each of the major areas across the organisation, and the team’s within those.

When we got to the Team level, we created a page for every team’s goals, and that page pulled in the following things;

• The team’s goals
• Status, Summary and Key Result – (Jira Issues Macro which pulls the information in directly from Jira whenever the page was loaded)

Setting up the JIRA Issues Macro in Confluence

 
Presentation Macro for Confluence

Throughout the quarter we had check-ins: what’s this team been up to and how are they progressing towards their goal?

This is where the Presentation Macro for Confluence came into play.

 

At Twitter, we had a Weekly Launch Meeting which gave every team the opportunity to present what they have been working on, demo their work and provide a status update to a higher level.

Here is an example of what it looks like in the Presentation macro mood. It is based on a Jira Issues Macro and the results out of Jira. This meant that any time you went into a presentation you were automatically getting the latest information.

Watch the full Summit 2013 talk: Collaborating Across an Enterprise

[Usamah zagaar]

I love this idea