Why distributed Agile delivery is (sometimes) amazing
An earlier model for distributed working

Why distributed Agile delivery is (sometimes) amazing

2001 a co-location oddity

‘Co-location’ — the whole project team working together in the same place — is sometimes seen as a cornerstone of Agile delivery. “It’s written into the Agile manifesto, isn’t it?”

In fact, it isn’t — that simply states: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

And it is great to talk face-to-face; we look to do a lot of that. But that’s not the same as co-location, which comes at a cost.

Comms comes of age

Add that since 2001 (when the manifesto was written), great tools for distributed collaborative working have come to the fore, from video conferencing and screen sharing, to Google docs, the likes of Trello, Jira and Slack for open working with near-continuous communication. As well as specific tools for digital delivery like Github, Zepelin, etc. It’s a very long list with some absolute stars.

Also over the last two decades, employees are looking for more flexible and efficient ways to work.

Five reasons for distributed delivery

  1. Talent. We pick the most talented people from around the UK, selected because they are the best at what they do — not because they’re able to commute daily to a given location. Delivery teams aren’t a set of components to be plugged into a project. Their individual ideas, abilities and skills are key to a project’s success (or not). Talent may be intangible but it is crucial. Limiting your pool geographically is a barrier to talent.
  2. Inclusive. We work with a lot of people who can’t travel easily or daily. As well as those with a disability for whom travel is inherently difficult, many parents of younger children prefer at least some flexible and home working. And this can be a key way for returning parents (usually mothers) to ease back into the workplace. It could even be argued that mandating office-located working without a very good reason is discriminatory.
  3. Open, distributed working also means that our clients have more freedom in how they work too. And they can readily engage their colleagues (I’m trying not to use the “s” word — ‘stakeholders’), globally if needs be. Everything is already in place to see the emergent digital service that we’re all creating, and to share information and ideas. Knowledge exchange is not limited to a single location.
  4. Cost: distributed, flexible teams are more cost-effective for clients who for instance don’t need to find multiple desk spaces at their offices.
  5. Flexible teams. With a distributed model we can be far more flexible with our project teams, often at speed. For instance, when we needed the best web 3D coding and animation specialists for the RAF website, we integrated them into our distributed project with ease. Even though none of them lived near to us in central London, or to the RAF (or each other).

Agile Agile (so good they named it twice)

I once saw a highly respected Agile proponent (ran many successful projects for an EU government) asked about any projects which failed, and why. He could think of one “because the agency were so Agile, they were completely inflexible”.

For many (not all) projects, it’s time to move on from a co-location mindset. To embrace modern working practices, collaborative tools, staff and client freedom. To be inclusive of people who can’t or don’t want to travel to a specific location each and every day.

It’s time to be agile with how we do Agile.

Sandie Lowery

Director, Scientific Services, Six Degrees Medical

4y

Nice article Paul. It is the same for our comms agency where most of us choose to work from home. It definitely gives us a more responsive edge, and we probably communicate more effectively across teams via technology than we would if sat together.

Liam King

Lead Digital Strategist

4y

Thanks for taking the time to articulate this so well Paul. We’ve seen first hand the requirement for co-location without the buyer really thinking through the “why are we asking for this?” bit. I’ve worked in both (co-located and distributed teams) over the years and my judgement is that co-location is not the important bit. As you say it about getting the right combination of talented people for the job with the right communication and collaborative tools and process in place. After all we are discovering, designing and building digital services which enable other people to go about their business efficiently and remotely. So can’t we? Yes we can and do. I would also echo your points around geography and restricting the talent pool. Co-location on Government digital projects (unintentionally) discriminates against suppliers further afield. And as projects still largely cluster in London that’s not great for those of us in the provinces.

As teams grow a degree of decentralisation becomes inevitable. In a well connected world, insisting on co-location to meet some Agile dogma seems a bit odd. Perhaps its simply a way of still hiring in-house without increasing payroll and offloading the staff risk to the agency? 

To view or add a comment, sign in

Insights from the community

Explore topics