Operating Agile is fine for start up’s and small independent teams with clear autonomy. However more and more larger organizations are attempting to go Agile with varying degrees of success. A lot of the challenges within large organizations come from the management bureaucracy that is prevalent, and built up, through many years evolution. Managers in positions of long standing typically adopt a command and control mentality with processes, meetings, reporting lines all structured to support this ‘absolutist’ model. Attempts at Agile typically involve the establishment of the eponymous team and limited independence – the prevailing management relationships, requirements and influences still remain. The result is a team operating Agile in name only, needing to ratify and vet key decisions and attend checkpoints in the legacy way, with little to no clear autonomy and hence, no improvement in delivery speed or quality. Agile is all about doing more quicker and better, remember.
Absolutism is a clear and historic human trait. Read any work of history and you will see Absolutist leaders dominant throughout history (Andrew Marr in his History of the World tome outlines the historic evolution of Absolutism extremely well) and it is only human nature for this to manifest itself in organizations – bureaucracy after all is one of mankind’s most successful inventions. However the Agile manifesto emerged and began to fundamentally tackle some of an organizations key assumption – the concept of a ‘minimum’ viable product viz-a-viz the finished solution, responding to change rather then stoically following “the plan”, engaging with customers during development rather than contractually selling the resultant solution. Critical to all of this is the establishment of a team with the autonomy to drive the manifesto and make their own decisions.
The Agile Weekly crew (podcast 131) advocate clearly autonomy as a critical success factor within Agile, and the many ways autonomy is blocked within organizations and what can be done to sensitively introduce autonomy. They also go on to challenge some of the current thinking on Agile team roles and how some Agile teams are re-introducing non-autonomy through process-driven roles such as the SCRUM Product Owner.
However autonomy is anathema to the absolutist manager, no matter how much he or she may advocate a new way of working. “Lets get some SCRUM training and we’ll be Agile, right?” Wrong. Sending people on courses (and there are many Agile courses advertised) is NOT what Agile is about (although I am a CSM by the way….). The Agile manifesto advocates individuals and their interactions over process, so why do a lot of organizations trying to become Agile introduce yet another process, such as SCRUM?
Agile has historically grown out of software development but is being increasingly used in other service delivery scenarios. Frameworks such as SCRUM, and others, will continue to evolve but must enable an Agile approach, not dictate it. Do organizations want to be good at SCRUM or good at delivering services?
Trust is at the heart of any transformative change, confidence that the correct new path is being adopted and courage to see the process of change through. This is often why published frameworks are followed. Assurance from those experienced in Agile transformation to “man the tiller” as it were through the choppy waters of organizational change (which the move to Agile is fundamentally about) can often help. As someone who has introduced Agile to FTSE100-scale organizations I know how rough that sea can get! However a fundamental stand-back by the absolutist management team is essential to allow Agile to flourish. So the next time your CxO, Head of, or Manager butts in to your Agile efforts tell them to “back off”.