The Difficulty With The Success of Software Development Teams

The following is a snippet from a post that originally appeared on the new Altmetric Developer Blog. To continue reading the rest of the post. Authored by mudge.

Last Friday, I attended Scale Summit 2016, my fourth time at the conference formerly known as Scale Camp. I make no secret that it is one of my favourite conferences with its open space technology format, the high calibre of attendees and its use of Chatham House Rule.

I spent the morning participating in two sessions:

• “Breaking down barriers between teams”
• “Code sharing in large organisations”

Richard Dallaway wrote up his notes from the former and both Anna Shipman and Barrie Bremner have shared their thoughts on the latter.

As I’ve spent the past three years attempting to grow a software development company, there was a common theme between these two sessions that fascinated me:

How do you measure the success of a software development team and, in turn, improve it?

The first session began with a discussion of how to encourage collaboration between teams (e.g. between different teams of developers, operations, product owners, etc.), break down organisational silos and consolidate tooling across an organisation.

The second session focussed on promoting code re-use within a large organisation, with the aim of reducing the amount of duplicated software built by separate teams.

Software development is rich with ideas and processes aiming to optimise efficiency and deliver better results, but has a somewhat spotty history of applying these practices. In such an environment, there is an ever-present risk of cargo culting:

McConnell describes software development organizations that attempt to emulate more successful development houses, […] by slavishly following asoftware development process without understanding the reasoning behind it.

With this in mind, in both sessions my first question was similar:

• Why should we break down the barriers between teams?
• Why should we share code in a large organisation?

Without a clear motivation for using it, how can anyone be truly convinced of a practice? A team forced to collaborate without incentive to do so beyond “our managers told us to” seems unlikely to truly benefit. What’s more, without clear reasoning, it’s hard—if not impossible—to measure the success of any endeavour. Sure, the teams are talking more but why is that a good thing?

The push for increased collaboration between developers and operations staff lead to the DevOps movement, which aimed to spread knowledge of and responsibility for the deployment software and its on-going maintenance. The pattern of developers “throwing code over the wall” to operations staff, who were suddenly responsible for its performance and uptime, contributed to antagonism between teams and increased both the risk and cost of failure.

Breaking down the barriers between these teams had some key goals in mind:

• Reduce the risk of failures when deploying software
• Reduce the time to recovery when failures do occur

We could similarly evaluate improving communication between product owners and developers, e.g.

• Reduce the amount of unnecessary software written due to misunderstanding
• Reduce the cost of software and ship higher value features in a more timely fashion, by sharing the complexity and risk of the backlog