Guest post by Neil Usher, Chief Workplace Officer, GoSpace (www.gospace.com), Author of The Elemental Workplace (2018)

We should not be surprised. The term ‘agile’ – meaning able to move quickly and easily – has done exactly as it suggested it would. Used for so many things relating to work, organisations and the workplace, ‘agile’ is now ubiquitous. Logically we would apply it only to animate objects, but that hasn’t stopped us from using the term to label the physical workplace.

Following our earlier interchangeable use of flexible working (verb) and the flexible workplace (noun), we have done the same with agile working, the practice of working when, where and how we choose (or need) – and the agile workplace, a physical space created to enable people to work in this way. Ironically the increase in use of ‘agile’ in the workplace community was specifically intended to counter the confusion that reigned between flexible working with its raft of people-related policies and protocols, and the flexible workplace – but we have repeated the confusion.

We can trace the ideas behind the agile workplace (albeit not the sure of the term) back to a 1985 article in HBR by Robert Luchetti and Phil Stone entitled Your Office is Where You Are. This gave us the ‘activity-based workplace’ (ABW). You have to wonder if that was inspired by Marvin Gaye’s 1962 song Wherever I Lay My Hat (That’s My Home). The first use of the term ‘agile’ to describe a workplace however, is lost in the mists of time.

The software development community arguably laid claim to the term ‘agile’ in a practical and meaningful sense before the workplace community latched onto it. In 2001 a group of 17 enlightened developers frustrated with the failure of document-driven, heavyweight software projects met in Snowbird, Utah and published the Manifesto for Agile Software Development, consisting of four values and 12 principles. In doing so they claimed the term Agile (with an accidental capital ‘A’) and gave us a whole new approach to work – short bursts (sprints) of regularly appraised activity performed by small, close-knit teams, flexible enough to react to change as needed.

Interestingly, while the creators of the Manifesto did not specifically mention the workplace, two of the 12 principles describe the need of those involved to be physically together:

  • Business people and developers must work together daily throughout the project.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The expectations of software development teams of their workplace soon emerged as a result. This was an early challenge to the flexible/agile workplace, which at its heart focused on providing for autonomous, free-willed individuals exercising choice, whose primary state was working alone and for whom interaction was to be consciously arranged, unless it occurred by happy accident.

Agile was a methodology that was fundamentally team-centric yet where teams were temporary structures rather than etched in the stone tablets of the organisation chart. It extended this to the need for proximity with the customer, in this case the internal business – team- and customer-centric. For the curious, the approach and the implications are best summarised in the Spotify Engineering Culture film.

Agile teams are often organised in scrums – usually 8-12 people – performing a piece of work for 2-3 months at a time. They form part of larger sections of the organisation often called tribes or squads, cutting across traditional functions and drawing in contributions from each. Interestingly, the higher-tech the teams and their focus, the more analogue space is required – primarily work tracking and interactive space. In the workplace they have given us a new language of scrum walls, pre-scrum areas, stand-ups and pair programming. In the detail, they even prefer to work back-to-back instead of across the desk, throwing decades of space management practice out of whack.

So effective has the methodology become that we are now seeing many non-software functions – even whole organisations –realising that this approach can be effective for them too. Agile is starting to emerge from its niche and go mainstream. It also has variants within the software community in which it started – it is not a pure approach, but for the purposes of this evaluation, is coherent enough to consider as such.

It is worth therefore identifying the main differences in approach to the workplace of each term, so we can be clear:

Feature Agile agile
What is it? An approach to the workplace based on small teams working in close proximity at primary settings, close to their customers An approach to the workplace based on individuals working in loose teams and sharing a range of primary and secondary settings, choosing when, where and how to work
Underlying rationale Teams need the certainty of being able to work together for periods of 2-3 months Individuals can choose the appropriate work setting for their task from a shared palette
Primacy The team, able to locate within a defined and dedicated home The autonomous individual, able to choose where and how to work
Attendance Daily – teams need to work in close proximity Irregular – dependent on the needs of the individual
Types of occupier Initially software developers, now extending to various functions Predominantly knowledge-worker organisations, able to sustain higher levels of mobility
Planning basis Team area – a dedicated ‘home’ with enough primary space and a defined location Neighbourhood – a generally assigned area shared by several teams (that may split across neighbourhoods)
Primary settings Common desking provision, tech-enabled, long benching able to support pair working Variable, capable of supporting range of tasks from focussed to interactive
Secondary settings Limited palette, intended mainly for relaxation and social activities Extensive palette, for a range of work and social activities
Amenities Preference for social and relaxation spaces to be adjacent to team spaces – provided at a team level Central and larger scale, as a potential source of unplanned interactions between individuals
Team sizes 8-12 per scrum Variable – able to support teams of any size
Achieving collaboration Inherent in the team-centric design approach By arrangement – self-organising or using booking systems
Change challenge None – institutionalised approach, with a clear expectation that space will reflect work processes Significant – asking people to work in an entirely new way

There are clear and marked differences. We could usefully do with different terms to separate that which relates to a methodology and to a physical workplace without relying on the capital ‘A’.

What we are seeing from this confusion however, is a re-balancing of needs of the individual and teams in the workplace. A recent Steelcase report New Work, New Rules leaned heavily towards the Agile approach, including the assertion that teams need a home, and that for many the reliance on self-organisation has impacted effectiveness. This is being increasingly supported by credible academic studies.

When the 17 developers gathered in 2001, they probably had no idea the effect they would have on the workplace. In many respects, with their focus on face-to-face team interaction and in stressing the importance of the analogue in an increasingly digital world, they were giving the workplace a renewed reason for being. Providing a generic ‘agile’ workplace with a range of settings and relying on the convenience of autonomous individuals to make sense of it was a necessary step in the evolution of our thinking, but it is proving wanting with the pressure for teams to have the certainty of being able to work together.

Neil Usher

The best of the ‘Agile’ and ‘agile’ workplace sees dedicated team spaces, dynamically managed as they change shape, composition and collaboration needs, supported by a wide range of secondary settings and amenities. They are in effect now converging into something meaningful. Workplace and real estate leaders will need the skills and tools to manage this ever-increasing dynamism, as it’s moving beyond the capabilities of the time-honoured approach to space planning. They need to get agile, too.