LinkedIn’s Engineering Process using JIRA

LinkedInThe first session/lecture I attended at Silicon Valley Code Camp 2008 was “LinkedIn’s Engineering Process using JIRA.” The speaker, Daniel Francisco, Project Manager for LinkedIn’s Content Distribution and Networks team (CDN), gave a brief overview of CDN’s engineering process and LinkedIn’s agile software development methodology.


First, I must give credit to Daniel as he did a great job during the presentation; he effectively answered questions and clearly understood the technical aspects of the content presented.

Three points I took away from this lecture:

  1. What JIRA is and how it can be used
  2. LinkedIn’s development and release practices/methodology
  3. Challenges faced by Daniel and tips and recommendation based off his experience

1. What JIRA is and how it can be used

JIRA is basically a web-based bug and issue tracker. Using JIRA you can attach files, add screen shots and URLs, and estimate the time required to resolve an issue. You can also create sub-tasks, allowing you to break issues down into manageable pieces. You can move tasks and sub-tasks around by clicking and dragging. Further, by using a plug-in called Greenhopper, you can get a graphical card based view of issues by project and release.

2. Development and release practices / methodology

So great – now we know that LinkedIn uses JIRA to track bugs and issues, but what about development enhancements, new features, etc…? Well, it turns out that LinkedIn actually uses JIRA for that as well. They use JIRA as a main repository of engineering and product tasks. Daniel stated that JIRA allows for flexible definition of new fields to meet dev team, product team, and web dev needs.

I thought the customizations were pretty interesting as it seemed to me that the JIRA platform was mainly for tracking issues but purposely made flexible enough to become a full project management tool. Below is a screenshot of creating an issue using JIRA:

JIRA (screenshot of creating an issue)

JIRA (screenshot of creating a issue)

I do find it a little strange that you can pick “Enhancements” and “New Feature” from the “Issue Type”. The way it’s being used just doesn’t seem to fit the architecture that the software seems to have been originally designed for. It’s almost as if the “Enhancements” and “New Feature” options were added on later to fit into the “issue” and “bug” architecture. However, this is a petty interface complaint about a tool that seem to provide a lot of very useful functionality. It’s worth mentioning LinkedIn was initially using JIRA just for bug tracking. They started using the Greenhopper plug-in in October 2007. The JIRA website advertises the following:

JIRA lets you prioritise, assign, track, report and audit your ‘issues,’ whatever they may be — from software bugs and help-desk tickets to project tasks and change requests.

JIRA Dashboard Screenshot

JIRA (screenshot of dashboard)

As mentioned the LinkedIn team also extends the JIRA functionality with the Greenhopper plug-in. They use Greenhopper to quickly create issues which can now be presented visually with the card based view. Categories that are being used for the cards are:

  1. Bug
  2. Sub-Task
  3. Engineering Improvement
  4. Scalability Improvement
  5. Product feature
  6. Product Enhancement
  7. Web Dev

Want some more details about LinkedIn’s development practices?

  • Usually there are about 25 people on a team with about 17 engineers (director of engineering, architect, project manager, engineering leads, and of course software engineers)
  • CDN uses an agile engineering process where items are added to the backlog and reviewed on a weekly basis for scheduling into a weekly release.
  • Typically releases are made every 3 or 4 weeks / team.

At weekly meetings among the track leads the following occurs:

  • Existing releases are reviewed and rescheduled if resources and priorities dictate.
  • Backlog is examined and re-prioritized. Outstanding action items on backlog are identified and assigned.
  • Once a spec is in place on a high priority item on the backlog, it is scheduled and assigned to an engineer.
  • Prior to the triage meeting the assigned engineer will create manageable subtasks and commence work on the card.
  • Progress on the card is updated continuously so that a release can be tracked day by day via Greenhopper’s burn down charts.
  • Where dependencies do exist project management coordinates

3. Challenges faced, tips, and recommendations

Daniel explained that the biggest challenge he faced was cultural:

Getting the team to consistently use the new process & tools takes a champion on the team to promote its use and keep the team on track.

Words of advice

  • Keep the process and tools flexible
  • Use one tool for tracking across product, engineering, web dev, & design
  • Use off the shelf tool (more support available)
  • Share best practices

Afterthoughts

LinkedIn seems to be doing a lot of good work and have been able to implement an agile iterative development methodology that seems to be working for them. However, this is not to say it would work for everyone’s needs.

Even for successful companies, many of which are Fortune 500 companies, I’m constantly amazed to hear ‘bad’ or in some cases ‘really bad’ development processes being followed. LinkedIn is no exception although they may have a lot going right. For example, when I asked the speaker how task dependencies are tracked, I got the answer (from another LinkedIn employee assisting) that the teams are small enough to know which tasks are affected by other tasks and who they need to talk to. This may be fine and working for now, but this will fall apart quickly once the company becomes larger with many more thousands of employees and tasks. The speaker did show how the software can track task dependencies, but it seems this feature is not being consistently used.

Final Review

The session was great and definitely worth attending. JIRA seems like a really useful tool, but it isn’t open source or free. Further, extra plug-ins will most likely also cost money. I won’t go into the pricing details; quickly looking off of their website, the prices do seem reasonable. Also, non-profits can use the software for free. Overall the tool seems useful if you can afford it, otherwise there are free open source alternatives like Bugzilla and Scarab.

This entry was posted in Silicon Valley Code Camp 2008, Tech Events, Technology and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


8 − = two