Distributed Development : Avoiding The Fog

I've written about the challenges of distributed development as have many others, so I'm not going to bore you with another spin on the types of problems which crop up and new and improved ways of fixing them. What I am going to do is make a controversial statement and then try and pull a Houdini and explain myself out of it.

Communication can make for an opaque development process.

Ok, here I go.


I have recently observed a software project which has gone way over schedule and budget with a view to find out why things had gone awry.

On the surface, the project looked like it should have succeeded. It was scoped well, estimated by the team and had experienced developers and testers on it.

To unravel the mystery of what went wrong I began with some qualitative research. I spoke to all the team members to get their perspective and discovered there were the usual culprits causing headaches like flaky third party APIs, scope creep and resourcing hiccups, but they weren’t the smoking gun I was looking for. The issues just didn’t stack up to the vast amount of additional effort required to drag the project over the line.

I then began to look at the data. We use JIRA to manage our development workflow and Agile plugins like Greenhopper to manage the pipeline of work from the backlog through to completion. I started to trawl through issues, boards and it was at this point I entered ‘The Fog’.

The Fog was sprawling mass tickets with incorrect statuses, missing estimates and assigned to the wrong people. I joined stand-ups and discovered there was a lot of communication happening. The standard questions (what did you do yesterday? what did you do today? any blockers?) were discussed at length during stand-ups.

The problem was they didn't relate to the Agile Board or even tickets themselves. The software project became a long dialog relying on qualitative evidence of progress. Since people are ultimately optimists and don't like bad news, the harsh truth never really came up until the end when it was impossible to ignore anymore. And when it did, it wasn’t a fun ride.

After more digging I constructed what I believe is the narrative which led up to the rude awakening.

It was as follows:

1. The scope of work was broken down into into Stories and Tasks to complete a Story. The problem was that they weren't granular enough to be completed and closed off within a sprint. 
2. Stories started spanning multiple sprints which started to make a Sprint a useless timebox. 
3. The team dropped working in sprints and just worked on tickets. 
4. With no timbox constraint to marshal work through the development process, the team started working on multiple stories, tasks and bugs at the same time. 
5. With the loss of focus and the growing amount of work, the team began thrashing and stopped keeping Jira update with things like ticket status, priority, time spent / time remaining. 
6. This problem snowballed causing a loss of visibility of how much work had been completed and how much work there was to complete. 
7. The project slept walked into client acceptance testing and after a few very ropey deployments, the shit finally hit the fan. 
8. The team finally triaged everything in Jira and had a shock revelation of how much work there still was to complete. 

After this much pain and late nights ensued! 

The people who really suffered from this were the development team who had to sacrifice weekends and evening to address the deficit and I take my hats of for their hard work to put things right again. 

This tale, however, does emphasis the importance of quantitative evidence of progress in software projects, rather than qualitative evidence. 

Qualitative conversations which don’t produce quantitative output cloud the development process, making it more opaque. Producing quantitative output (updating ticket with correct status, time remaining, etc) has an admin overhead and developers generally don’t like admin. But as this tale illustrates, it is essential to have an empirical view of the project. Without it, they will be the ones who ultimately pay the price.

Like any escape act there is always an obvious way to get out of the artists predicament. In a similar fashion I will simple revise my statement with a couple of qualifiers.

Unfocused Communication in Distributed Projects makes for an opaque development process.