7digital Development Team Productivity Report 2013

For those that are interested in this kind of thing I’ve posted the 7digital Development team’s latest productivity report on our developer blog here.

Hopefully useful stuff if you’re looking for data to back up why things like TDD, Continuous Delivery etc. are good things to be doing.

Advice on running 1-2-1s

I’ve find 1-2-1s to be hugely valuable, I think it’s the most important thing I do.


How many times have you been in the situation where you were stuck on a problem and simply by starting to explain it to someone you solved the problem in your head? The point there is talking is a good thing in itself.

1-2-1s are also extremely good at catching problems early, often before you realised they were a problem. Retrospectives are great way of raising and solving issues, but they’re much more about the team than the individual. There are also a lot of things people are not comfortable saying in those kind of situations.

Here’s some simple advice for anyone running 1-2-1s:

1. Get the conversation flowing

It doesn’t really matter what about. Some people will be straight out of the gate venting all their ills (which is great!). Others find it harder to open up. There are lots of simple questions you can ask to get things flowing. Have an artillery of questions which come from different angles, which can also be useful if the conversation dries up.

Here’s some really simple ones I find work well. Try not to ask too specific questions:

  • How’s it going?
  • What have you been working on?
  • How’s the team getting on?
  • How have you been getting on since the last time we met?
  • Anyone pissing you off? Are you finding it hard to work with anyone?

2. Listen!

Once the person is talking try not to interrupt them or (something I’m really bad at) try to finish their sentences. When an interesting point comes up try responding with another question.

Often a conversation which starts as trivial will often evolve towards a pain point with the curious phenomenon that the person hadn’t even realised it was a problem until now. It’s important to try to allow the person to talk uninterrupted to allow this to happen.

Listen out for the issues. This is something that takes a bit of experience, but try to keep an ear out for (often subtle) things the person says which can be signs of greater concerns. When something does appear on the radar don’t interrupt, but when they’ve finished talking try and bring them back to it and see if there’s anything more to it.

If they’re ranting don’t stop them! It’s emotional and irrational by nature. Let them get it out of their system. Once they’ve calmed down they’ll be able to think more clearly.

3. It’s not your job to solve their problems, but help them to solve their own

Telling people what they need to do to solve a problem is generally not very effective. If you have thoughts, pose them as suggestions and ask what they think. Even better start by asking them what they think could be done about it?

No preaching!

4. Follow up

The next time you meet up (& this is why it’s important you are consistent with who you have your 1-2-1 with) follow up on the things you talked about last time and see if there’s been any improvement.

My “Agile Adoption is Fool’s Gold” talk from QCon London is now up on InfoQ

I did a talk at QCon London 2012 about my experiences with introducing Agile practices at 2 organisations (7digital and BBC Worldwide). It’s now available to watch on InfoQ:


I regularly refer to my notes being available including links to many of the things I mention. You can access them here:


Some recommended reading for management types

I’m a bit of a management junkie as well as a programmer, which is fortunate as I’m now in a position of senior management (although I have to admit I still prefer coding to management). I wanted to recommend some good management reading to people in my management team – particularly regarding organisational strategy and leadership as we’re a small company growing up fast and need to think about these things more seriously now. I was also keen that nothing I recommended was too polemic, software development oriented or, ideally, containing the “A” word (although one ended up doing so).

I asked Twitter and the books below are the ones most recommended or looked most interesting for us. It’s by no means an authoritative list or supposed to be the “best” of anything. I just thought it was interesting enough to be worth sharing more widely.

The Goal

The Goal is a management-oriented novel by Dr. Eliyahu M. Goldratt, a business consultant whose Theory of Constraints has become a model for systems management. It was originally published in 1984 and has since been revised and republished every few years, once in 1992 and again in 2004. This book is usually used in college courses and in the business world for case studies in operations management, with a focus geared towards the Theory of Constraints, bottlenecks and how to alleviate them, and applications of these concepts in real life.[1] This book is widely used in leading colleges of management to teach students about the importance of strategic capacity planning and constraint management. 

Most recommended by those polled. I’ve also read it and think it’s great.

Managing the Unexpected

The unexpected is often dramatic, as with hurricanes or terrorist attacks. But the unexpected can also come in more subtle forms, such as a small organizational lapse that leads to a major blunder, or an unexamined assumption that costs lives in a crisis. Why are some organizations better able than others to maintain function and structure in the face of unanticipated change?

Authors Karl Weick and Kathleen Sutcliffe answer this question by pointing to high reliability organizations (HROs), such as emergency rooms in hospitals, flight operations of aircraft carriers, and firefighting units, as models to follow. These organizations have developed ways of acting and styles of learning that enable them to manage the unexpected better than other organizations. Thoroughly revised and updated, the second edition of the groundbreaking book Managing the Unexpected uses HROs as a template for any institution that wants to better organize for high reliability.

David Harvey, CEO of Vyclone and industry veteran recommended this because ” (1) it’s full of good stories, (2) it’s backed by _a lot_ of research, (3) no mention of the Agile or Lean words…”

How to Manage and How to Lead

Both recommended for being short, pragmatic and accessible. Thanks Marcin :)

Adrenaline Junkies and Template Zombies:Understanding Patterns of Project Behaviour

In Adrenaline Junkies and Template Zombies, the six principal consultants of The Atlantic Systems Guild present the patterns of behavior they most often observe at the dozens of IT firms they transform each year, around the world. 

The result is a quick-read guide to identifying nearly ninety typical scenarios, drawing on a combined one-hundred-and-fifty years of project management experience. Project by project, you’ll improve the accuracy of your hunches and your ability to act on them. 

Any book where DeMarco is involved is essential reading in my opinion. Not heard of this one before. Thanks Captain Crom!

Managing the Design Factory: A Product Developers Tool Kit

This text on product development combines the analytical tools of queuing, information and system theories with the ideas of organization design and management. The author aims to answer such questions as: when should we use a sequential or concurrent process; should there be centralized or decentralized control; and should the organization be based along functional or team lines?

Supposed to be a bit theoretically heavy in places, but worthwhile none the less. I hear Reinertsen’s name referenced regularly and know a couple of people who have been on his course.

Management 3.0

Management 3.0 is a course, a book, and an approach to inspire team members, team leaders, development managers, IT directors, project managers, Agile coaches, and HR managers, who face the challenge of transforming their organizations to an Agile mindset. We do that by providing guidance and practices, and by applying complexity thinking to the craft, art, and science of Agile management.

I’ve read this and really liked it. It’s obviously very “Agile” oriented, but starts by covering a lot of management theory and most things covered in the book could be applied far more widely than just software development.

How we do “innovation time”

This article is cross-posted from Blogs From The Geeks, the 7digital development team blog:

Assuming you had consent from up above*, you’d think it’d be a breeze to get an initiative like innovation time off the ground. Surprisingly at 7digital it took us three attempts before we got something to stick and speaking to someone else recently I found they’d had a similar experience. As we’ve had our “innovation time” initiative running successfully for over a year now I think it’s worth sharing how we’ve got it to work.

In our first two attempts we found the main reason it failed was putting too many barriers in the way.  We didn’t think it was right that you could work on production code, you shouldn’t do it on your own, it should be justified and approved by your peers, like a business case. Innovation really hates these kind of things. Ironically we thought having “sensible” rules like this would ensure people didn’t waste their time on things we didn’t think could be classed as innovation, but they were based on a fundamental misunderstanding of how innovation occurs.

If you’re even slightly aware of your history regarding invention and discovery you’ll see a large proportion came about by happy accident, mostly when trying to prove something completely different. It’s such a common event it has its own name – serendipity. I strongly believe you’ve got to have a really open mind and shouldn’t have any particular expectations or goals in mind apart from innovation itself.

So for our third attempt we tried to really strip it down. Here’s the rules we agreed:

Conditions of use of innovation time

  • There is no jurisdiction on how you use the time.
  • If you’re working on production code, or any application or tool which supports production code, you must do it properly i.e. follow the development team standards.
  • If you’re working on something unrelated to production code or existing applications you may work in any way you like. However if you wish for whatever you produce to be used in anger it must meet the usual standards (i.e. either write it to expected standards to begin with or rewrite it afterwards).
  • We should put anything suitable in the public sphere e.g. on GitHub and hosted where appropriate.


  • You have 2 days a month you are able to request for innovation time.
  • Innovation time does not accrue – if you don’t take your allocation in a particular month it does not carry over.
  • If someone else does not use their allocation you cannot use it in their place.

Requesting innovation time

  • Request time through whosoff.com as “DevTeam Innovation Time” (we set up a special leave type).
  • It’s to the discretion of your lead developer (or head of development) to approve. (e.g. they may not approve if they consider that the ability for the team to function effectively will be compromised due to too many people being off or we’re really busy with something and need all hands on the pumps).


  • You must create a wiki page with the details of what you did and what you learnt.
  • For each day you take against a particular activity you should have a diary-like entry with the date and who was involved.

Using our leave booking system was a particularly inspired move. It means innovation can be managed just like holiday – it shows up in everyone’s calendars and allows everyone to plan around your absence. It also means we can pull out stats on how much time people have been taking:

Interestingly out of a possible ~456 days in 2011 189 were used, making it “4.74% time”. Another particularly surprising observation was people took less innovation time when they were not feeling motivated about their usual work (we had a very painful database migration in the summer).

It really helps that we’re very team focused at 7digital (pair programming is really good for this) so it’s no great loss when any one person is away for a short time. It also really helps that we try very hard to work at a sustainable pace.

As for what’s been done we’ve had some really interesting and diverse projects. Many of them have simply been around investigating new technologies and ways of doing things rather than new product ideas (but we’ve had some of those too). I think in this respect a lot of the benefits are intangible, but that’s one of the interesting things about innovation – if you tried to measure it you’d kill it stone dead.

*I’ve no intention of going into the justification for initiatives like innovation time here. That would be another, very long article :)

The Robber’s Cave experiment

Someone reminded me of the Robber’s Cave experiment last night. It was quite an amusing study with a serious motive of showing how easily opposing in-groups and group hostilities can form. It also showed how having superordinate goals can counteract this phenomenon.

Basically, if you’re finding yourself in the situation (as, lets face it, we often are) of taking sides and forming prejudice about other teams or groups a la Lord of the Flies you’re succumbing to base, instinctive behaviour which was probably quite useful when we hunted in packs, but has little value in modern society.

Next time you find yourself in this situation, think about what superordinate goals you share with the “opposing group”, so that rather than back slapping each other about how amazing your group is and how weak and feeble they are, you can all work together to get what you want.

Lead a session – a great path to self-improvement

As you might know I’m Programme Chair for the SPA Conference. In the past I’ve also done this for XPDay and presented or run sessions at both (and others). I find it a hugely rewarding activity, particularly because it feels like I’m giving back to communities which have helped and inspired me so much in the past. However there are plenty of other reasons why running sessions or presentations at conferences or community events is a good thing:

Free entry
Having a session accepted at SPA means free entry. In some cases like Agile 2012 (submissions close Feb 19th) this also includes travel and hotel expenses.

Use it as an excuse to learn something like a new language or concept
My friend Willem did this at SPA last year – he wanted to learn Puppet so he organised a session about it and went away and learnt it.

Try your ideas out in front of smart people
SPA particularly attracts a wide range of people, most of them very smart and experienced. Running a session around an idea or technology is a great way to exploit their knowledge (people are generally more than happy to do so if it’s an interesting idea).

Improve your self-confidence and communication skills
There’s nothing like standing in front of 15-50 extremely smart people – and being appreciated for doing so – to boost your confidence. Having considered myself deeply inferior to the likes of those who presented at conferences I was tricked into submitting some proposals only to find they all got accepted. Even more amazing was they actually went down really well.

If I see on someone’s CV that they’ve presented sessions at community events they rise up in my estimations greatly and I’m sure that’s the same for pretty much anywhere.

SPA Submissions finish at the end of January. You only need to have the idea formulated now. The conference is in July so you’ve got 6 months to make it sweet. Get it in this by Sunday and you’ll benefit from the feedback process which starts next week.

What are you waiting for?


Productivity = throughput and cycle time

This article is cross posted from the 7digital Blogs From the Geeks:

I see lots of articles and discussions on how you measure the productivity of a development team. Having worked with cycle time and throughput for a few years now I’ve come to the conclusion that when combined these very simple measurements are a highly effective gauge of productivity.

Cycle Time

We measure cycle time as the count of working days between work starting (“in progress”) and completion (“done” or “live”) and is shown below per item over time. The chart below also shows a trend line (going down, nice) and error bars for the standard deviation:

Ideally you want to see the trendline on your cycle time chart going down, but more importantly you don’t want to see it going up. Shorter cycle times suggests we’re delivering value to the organisation quickly and do not have money unnecessarily tied up in inventory (unreleased code). It also means we’re more predictable and able to respond quickly to change.

To be truly useful (and much more difficult to game) cycle time has to measure the time it takes for things to really be done, not some “potentially shippable” nonsense. It’s also very simple to measure – you just need to track when the work starts and when it ends. We say a piece of work starts when it’s taken off the top of the prioritised queue and done when it’s been released to production (and verified). Sometimes we’ve done the analysis and requirements before hand, sometimes we haven’t (I don’t really care to be honest as we never allow more than 5-10 items in our prioritised queue so it’s not like we’re doing loads of unnecessary up front analysis or consider it a huge time drain).


We measure throughput as a count of items completed per month:

Obviously the more work we do (with the same man power) the better (but probably less bugs and more features).

Individually these measurements are useful, but can be misleading if considered in isolation – cycle time going down is great, but if you’re only delivering one piece of work a month it’s not so great. Throughput can go up or down, but could be because you’ve more or less people in your team.

It’s hard to say if productivity can really be measured by just cycle time and throughput and being witness to metrics being gamed in the past (or causing undesirable behaviour) I’m wary of trying to improve them directly. However as a couple of really simple measurements we can track over time they’re a really good guide to support or refute anecdotal evidence as to whether anything we’re doing is having an impact on our ability to deliver. A great example is the two charts above. In around Sept/Oct they show one of our team’s cycle times going down and throughput going up, which was largely a result of changing tack and spending a considerable amount of time improving the build process and removing/fixing flaky tests.

What can you try to increase your team’s throughput and reduce cycle time? What can these measurements tell us about the impact of X happening?

There are of course many other ways to judge the effectiveness of a team and I wouldn’t want to get too caught up with just these ones, but it certainly pleased me greatly to see how the team above’s measurements improved and it certainly corroborated with the mood of the team since they managed to turn things around.

I’m of the mind increasing throughput and reducing cycle time is A Good Thing™. It generally means we’re getting more done, more quickly.

There’s something very fishy about the UK Agile Awards

Awards are a very interesting thing, especially the motivation for giving them. I’m particularly uneasy about the UK Agile Awards, which ran for the second time this year with the results being announced a few weeks ago. As far as I can tell pretty much all of this years winners have a relationship with one of the sponsors. Lets go through each of the winners and see:


Agile Project or Programme Manager of the Year: Chris Berridge

Works for Emergn, who were a sponsor.

Edit: Correction, Chris works for Maersk, who worked with Emergn, who were a sponsor.

Best Agile Project or Innovation: “Fixing the Flaws in Government IT” – The IfG Report 

IfG worked with Indigo Blue closely on the report, who were a sponsor.

Agile Consultancy of the Year: Indigo Blue

Who were a sponsor

Best Agile Team: The Guardian

Worked closely with Indigo Blue on their major redesign a year or so back, who were a sponsor.

Most Agile Aware Organisation: Simply Business

Not found a link, but not looked that hard. Anyone?

Edit: As per Paul’s comment below Simply Business are associated with Emergn, who were a sponsor

Most Engaged Management Team: IPC Media

A sponsor

Best Use of Agile in the Public Sector: DWP

Working closely with Emergn, who were a sponsor. I also find this one particularly irritating as they haven’t even delivered anything yet! As one of the principles of the Agile Manifesto states, “Working software is the primary measure of progress.”

Best Use of Agile in the Private Sector: BSkyB

Not found a link, but not looked that hard. Anyone?

Best Agile Coach/Mentor: Dot Tudor

Works for TCC, who were a sponsor.

Most Valuable Agile Player (UK)

Keith Richards, who was a sponsor.


I’ve no doubt that some of these organisations were approached after they were nominated, but looking at who the sponsors were for the previous year it’s mostly the same faces. Hmm.

Well… if it’s that easy then I hear by announce the Rob Bowley “Agile as Fuck” Award and the winner for 2011 is…