Last year we published data on the productivity of our development team at 7digital, which you can read about here.

We've completed the productivity report for this year and would again like to share this with you. We've now been collecting data from teams for over 4 years with just under 4,000 data points collected over that time. This report is from April 2012 to April 2013.

New to this year is data on the historical team size (from January 2010), which has allowed us to look at the ratio of items completed to the size of the team and how the team size compares to productivity. There's also some analysis of long term trends over the entire 4 years.

In general the statistics are very positive and show significant improvements in all measurements against the last reported period:

  • a 31% improvement in Cycle Times for all work items
  • a 43% improvement in Cycle Times for Feature work
  • a 108% increase in Throughput for all work items
  • a 54% increase in Throughput for Feature work
  • a 103% improvement in the ratio of Features to Production Bugs
  • a 56% increase in the amount of Items completed per person per month
  • a 64% increase in the amount of Features completed per person per month

 Download the full report here (pdf)

The report includes lots of pretty graphs and background on our approach, team size and measurement definitions.

A brief summary of the last 4 years:

  • Apr09-Apr11* Cycle Time improved (but not Throughput or Production Bugs)
  • Apr11-Apr12 Throughput & Cycle Time improved (but not Production Bugs)
  • Apr12-Apr13 All three measurements improved!

 *The first productivity report collated 2 years’ worth of data.

It’s really pleasing to see we’re finally starting to get a handle on Production Bugs and generally things continuing to improve. It’s interesting to see this pattern for improvement. We haven’t got any particularly good explanation for why things happened in that order and curious if other organisations have seen similar patterns or had different experiences. We’d expect it varies from organisation to organisation as the business context has a massive influence. 7digital is no different from any other organisation in that you have to be able to balance short term needs against long term goals. If anything else our experiences just further support the fact that real change takes time.

We must add the caveat that these reports do not tell us whether we're working on the right things, in the right order or anything else really useful! They're just statistics and ultimately not a measure of progress or success. However we’re strong believers in the concept that you’ve got to be able to “do it right” before you can “do the right thing”, supported by the study by Shpilberg et al, Avoiding the Alignment Trap in IT.

We hope you find this information useful and can help other teams justify following best practices like Continuous Delivery in their organisations. We would of course be interested in any feedback or thoughts you have. Please contact me via twitter: @robbowley or leave a comment if you wish to do so.

Anonymous
Tuesday, February 3, 2015 - 03:08

Guest Blog by John Nye on His First Week at 7digital

I have recently started at 7digital and already there are a few things of note that may seem small, but highlight the differences in attitude 7digital take over other companies I have worked for. Below are a few thoughts from my first week at 7digital.

Day 1 - Meet the team

After an incredibly frustrating start, owing to a 4 hour delay on my train journey, I was introduced to everyone, given my security pass and directed to a new starter guide that had a series of tasks that needed to be completed. These tasks ranged from installing software to getting added to email groups to reading up on the 7digital handbooks. So I logged into my Ubuntu machine and started going through the list... wait... Ubuntu?

Thoughts from the day:

  • Incredibly welcoming bunch.
  • Locate an Ubuntu book!

Day 2 - Empowerment

sharri.morris@7digital.com
Thursday, May 8, 2014 - 17:28

Astro Malaysia held it’s annual GoInnovate Challenge Hackathon on the 10th-12th October at the Malaysian Global Innovation & Creativity Centre (MaGIC).

Hopefuls from all over Malaysia massed together for an exciting challenge set by Astro - to build a radio streaming demo. The demo product was meant to redefine the way we watch, read, listen and play with content in two unique hacks to be completed within a 48 hour deadline. Astro offered substantial rewards to those whose ideas that came out on top!

Day 0: Demo - Friday evening

Attendees ranged from junior developers to start-up teams, so long as you’re 18 years old, you can take part!

To begin the Hackathon, entrants were fully briefed and given access to the APIs of both 7digital and music metadata company, Gracenote.

7digital’s lead API developer, Marco Bettiolo, flew in to act as Tech Support for the hackathon.

This photo shows Marco presenting a demo of a radio style streaming service he had previously built.

Day 1: Get Building!

According to the brief, hackers had to choose one of two innovative challenges:

sharri.morris@7digital.com
Tuesday, May 6, 2014 - 17:43

Managing session lifecycle is reasonably simple in a web application, with a myriad of ways to implement session-per-request. But when it comes to desktop apps, or Windows services, things are a lot less clear cut.

Our first attempt used NHibernate's "contextual sessions": when we needed a session we opened a new one, bound it to the current thread, did some work, and unbound the session.

We accomplished this with some PostSharp (an AOP framework) magic. A TransactionAttribute would open the session and start a transaction before the method was called, commit the transaction (or rollback if an exception had occurred), and dispose of the session after the method had completed.

It was a neat solution, and it was very easy to slap the attribute on a method and hey presto - instant session! On the other hand it was difficult to test, and to comprehend (if you weren't involved in the first place), and to avoid long transactions we found ourselves re-attaching objects to new sessions.

These concerns made us feel there was a better solution out there, and the next couple of projects provided some inspiration.

sharri.morris@7digital.com
Friday, July 19, 2013 - 14:55

Blue and green servers. What?

As part of the 7digital web team's automated deployment process, we now have “Blue-green servers” It took a while to do, but it's great for continuously delivering software.

This system is also known as “red/black deployments” but we preferred the blue-green name as “red” might suggest an error or fault state. You could pick any two colours that you like.

How it works is that we have two banks of web servers – the green servers, and the blue servers. Other than the server names, they’re the same. Only one of these banks is live at any one time, but we could put both live if extra-ordinary load called for it. A new version of the site is deployed to the non-live bank, and then “going live” with the new version consists of flipping a setting on the load balancer to make the non-live bank live and vice-versa.

Why?

Why did we do this? Mostly for the speed. The previous process of deploying a new site version was getting longer. The deployment script would start with a server, upload a new version of the site to it, unpack the new website files, stop the existing web site, configure the new website and start it. Then move on to the next server and do the same.