In software development, over the past decade or more, agile principles have sometimes been overtaken by strict adherence to agile methods (Scrum, Kanban, estimations, standups, etc) at the expense of flexibility and – ironically – agility. Some challenges in IT architecture need a more structured design process and aspects of DevOps are better suited to LEAN continuous improvement methods. The debate about where to use and not use agile methods in development continues, but in general, this is at least testable in the sense that we can judge from the quality of software products whether or not an approach worked.

However, we are now seeing the widespread adoption of agile methods in non-technical management domains within large organisations, and this is where the wholesale replication of agile methods outside the context in which they were developed can become problematic or even dangerous. Sonja Blignaut wrote a good piece recently (see below) about this phenomenon and suggested better ways to replicate practices than just lifting and shifting from other contexts. But increasingly in our work, we are seeing cult-like blind adoption of agile methodologies in areas without understanding the principles and values from which they emerged – scaled agile structures that look no different to hierarchical management, product owners who are not really product owners, the absence of meaningful ‘epics’ within which to organise stories, and islands of agile that lack the right interfaces to the rest of the organisation, to name just a few common patterns.

Agile works best in situations of change, where requirements are uncertain or changing. It should not be shoe-horned into conventional management planning and reporting structures just for its own sake, where these conditions do not exist. Small, focused agile teams are a great building block for better organisational structures, and we are deeply involved in helping large organisations make the most of them, but that need not mean these teams rigidly pursue agile methods at the expense of all other techniques.

Agility over agile.

And some further reading…