Agility Can’t Be Planned

18th July 2015 Pete George no responses Agile, Scrum

In his Scrum – A Pocket Guide, Gunther Verheyen talks about the danger of seeing agility as something that can be planned: “Time-plans create the illusion of deadlines and a final end-state. Agility has no end-state. Agility is a state of continuous improvement, a state in which each status quo is challenged, by our own will or by external turbulence.” In my experience, this is something that many organisations struggle with, particularly those which start out with good intentions of transitioning to Agile from a more traditional “industrial paradigm”.

One organisation I’ve been working with recently is a good example of this attempt to plan agility. On the face of it, the organisation had some admirable goals. In 2013, they started a project to support their agile software development teams, by transforming their physical environment. The £6million project was planned to be completed in Oct 2015 and involved turning about 530 static workstations, arranged in call-centre style rows, into horseshoe-shaped desk formations with mobile IT. The intention was to improve six areas: concentration, communication, collaboration, co-location, community and correct IT.

The aims are very much in line with Agile values and I have often commented myself that it is a very positive sign of the times that a large organisation would spend so much time and money simply to move desks around to accommodate collaborative group working. However, my observation is that their attempt to plan for agility is likely to be unsuccessful.

It may be that once the project is complete, there will be improvements in the six areas, but at the expense of agility, which may ultimately create less effective delivery. As a simple example, once complete, teams of six will be able to be co-located to work together because the desks will be arranged in a horseshoe formation of six. However, if a project needs seven people, the team will not be able to be easily co-located and one person will have to work elsewhere, because the desks cannot be moved. Co-location and collaboration were seen as the goal, but lack of agility may mean these values are compromised in the long term.

More importantly, though, is that the transformation project doesn’t seem to be creating any room for future change. In the future, if the prevailing thought is that lightweight teams of four are the way forward; or actually everyone should be working from home; or whatever numerous other options might occur, another £6million project will likely be needed to change all the desks around again.

This blog isn’t really about criticising this one project. It may well be successful and may be the perfect model for long enough to get a good return on the current investment for this organisation. I’m merely using this example to highlight Verheyen’s point. The key concept behind the agile paradigm is that the future is unknown and therefore we need to create a controlled working environment that is agile enough to exploit potential and manage risk. The primary goal, therefore, needs to be to create ongoing agility, and not to assume that agility has an end-state.