Scaling Out Delivery

As agile becomes more widely adopted by organisations both large and small inevitably questions are asked as to how this can work at scale, we have seen the birth of this phenomena with the advent of various frameworks built around the concept of agile at scale.

I believe the thinking around several of these frameworks is flawed and moves us further away from the pillars of agile that attracted us to it in the first place.

Segmenting the Orange

The thirst to adopt agile at scale is mostly fuelled by the results that are seen when using it at a smaller scale, the key thing to keep in mind when trying to grow that success is recognising what it is we are actually trying to scale.

It is very easy here to fall into the trap of assuming benefits of scale in software development that simply don't exist, the purpose of trying to scale out agile delivery shouldn't be about trying to justify the addition of more developers.

Without proper segmentation of the deliveries they are working on having multiple teams of a handful of members is no different to having one large team.

The reason to create a new team shouldn't be to justify adding more developers to a project whilst paying lip service to the idea that a efficient team has a maximum number of participants.

The reason to create a new team is because we have identified an independent delivery of software that can be worked on in isolation, divide and conquer is an old adage but its applications are many.

Obviously in the long term teams will need to consume the output of what the others are working on but the aim should be to maximise the number of different areas that can be under active development without creating inter-dependency between teams to deliver over the short term.

We are trying to grow the number of distinct outputs of teams not the amount of output in any one particular area.

The Grand Plan

As the scale of development increases there will be an increasing need for some co-ordination, which one could call planning, to be in place to ensure everyone moves towards a common target.

When trying to scale agile it can be very tempting for the waterfall illusion of control to creep back into our thinking.

The co-ordination thats established between teams has to be of a loose nature that has the ability to flex with changing circumstances.

This always carries negative connotations assuming this means expect things to be late but actually it can be positive, an agile mindset is very much to ship when something is shippable.

Better segregation between the deliveries of teams can enable a multitude of different cadences of iteration to be in place where opportunities to ship present themselves more frequently not less, not all will be visible or obvious to the user but all will move the product forward.

Philosophy not Frameworks

Needing to find ways to work at scale is an inevitable reality but its important to distinguish mechanics from mindsets.

Agile is not a framework for software development it is a philosophy, a mindset, a way of thinking.

Quite often some of the pillars of agile such as face to face communication or the preference for working software over documentation are the first things to suffer when we are trying supersize our organisation.

Its therefore important that whatever the mechanism we use to scale out delivery we recognise when we are betraying the principles that as agile practitioners we are supposed to hold dear.

One of the best ways to adhere to this is to make sure practices don't become rigid and that we continue to garner feedback and input from the those at the coal face.

We must avoid the temptation of thinking that to operate in an agile way at scale requires a different approach to adopting agile at any other time.

We don't need to re-invent the wheel or go back to the drawing board, the principles of the agile manifesto still hold and our job is to ensure they aren't eroded as the number of participants grows and the allure of falling back into a waterfall pattern become attractive.