Agile Frameworks and Practices
Why Agile Transformations ‘struggle’ Part 2
I recently wrote the first part of this series in which I opined that one of the reasons Agile adoption initiatives (so-called transformations) so often fail — is because there is all too often no compelling, widely shared objective/s that justify the investment.
In this, the second part, I will discuss my views and experiences of agile frameworks and practices.
Let us first go back a few decades to the 1980s and ‘90s. A number of people were starting to seriously explore how software development was done, and trying to find better ways of doing so. Takeuchi and Nonaka had, in 1986, published their now-iconic HBR article on the new, new product development game. Ken Schwaber, Jeff Sutherland and others were already thinking along similar lines but the HBR article sparked the term Scrum.
Kent Beck and Ward Cunningham were, at the same time, writing up a guide to what became known as Extreme Programming, while Alistair Cockburn was developing his Crystal suite of methods. Others were doing similarly brilliant work that was all encapsulated in the famous Manifesto, with its Values and Principles.
I mention this because all of this extremely clever thinking came about because of a perceived problem with the way software development was being managed. Because of the hardware, languages, devices and tools available at the time, software development was considered to be an engineering discipline, requiring careful up-front, detailed planning. This was because computer time was precious and code was written out on paper first before being typed into the computer. Programmers had to get it right first time, because the turnaround time for fixing coding errors was measured in days.
This engineering mindset led to project management methods characterised by linear phases, each marked by contractual ‘sign-offs’ — what we think of now as traditional, plan-driven or ‘waterfall’ methods. Mistakes (or even just changes in requirements) late in the project were seriously damaging to the plan. Don’t get me started on the subject of change control!
Agile — or ‘lightweight’ — methods as they were initially known, were the answers to this problem of software projects being big, lengthy, contractual, plan-driven and prone to failure.
All agile methods or frameworks are solutions to a problem. They were invented because someone thought things could be done better.
With this in mind then, consider how agile adoption initiatives are typically run. A sales team from a consultancy convinces the client organisation that they need ‘an agile’, and that Acme Consultancy* have just the people to help. A small army of consultants and coaches are engaged to work with the development teams, conduct training courses and help them adopt the practices of the chosen agile framework/s.
Some time later the client organisation takes stock of what has happened, and only 18% of them are actually very satisfied, with a further 42% “somewhat satisfied”.
We can therefore safely conclude that 82% of the time, the problem, to which Agile was supposed to be the solution, was not fully solved.
In the previous article I argued that a lack of clear objectives for the initiative was one reason for this, resulting in culture clashes, lack of management support, and resistance to change.
The second major reason for this failure to fully address the problem are the agile frameworks themselves. Acme* Consultants are experts in their field — they are certified professionals in Scrum or SAFe or LeSS or any of the others. So that is what they implement in the client organisation: what they know and are good at. The so-called transformation becomes about adoption of a rule book that declares organisations must adopt specific roles, hold specific meetings at set intervals, maintain specific artefacts, display certain behaviours and hold dear specific values…
In very few cases do the Acme* Consultants take the time to consider the organisational context over which they are mandating adoption of these rules.
“Does the team they work with build and deliver elements of a software product? No? Never mind; they need to identify their Product Owner anyway.”
“Management wants to see project progress in spreadsheets or slide decks? Nope, you are all going to be using Jira now.”
“Are team members all working on the same product increment? No? Never mind, they still need to hold a Daily meeting. Standing up. Or in plank position ;-).”
“Jargon? Don’t worry, I will explain everything.”
The implementation of specific practices and meetings and the imposition of new roles for people when they are not specifically required creates resistance to change, and can even make the team worse than before. How many times have we heard developers ask to be excused from a meeting because they have “real work” to do? How often do managers complain that they are now more removed from their teams than before?
I challenge you now to do an online search for “why agile transformations fail” and find one article that does not blame the client organisation in some way. Agile is fine, they say; it’s the organisation that isn’t ready / willing / able/ hasn’t got the right culture.
I am not saying the opposite is true. If change is needed, change needs to happen. But only where it will make a positive difference. Many times in the past, I have been asked “what is agile best practice for this situation?” Of course, the answer is there’s no such thing. ‘Best’ practice is dependent on the practice being universally applicable. If it isn’t then we should be looking for ‘good’ practice that solves the current problem.
Agile transformations are all too often, not trying to solve any specific problems at all. The solution — the agile framework — becomes the objective, almost as if the absence of an official agile method or ‘way of working’ is the problem to be solved. And organisations spend millions of dollars on these initiatives, with some widely publicised failures, especially in the public sector.
It is time, therefore, that we stop trying to force specific methods and practices across entire organisations. In some places agile ways of working can yield huge benefits, but only if each practice, role and event are solving a problem, or contributing towards a specified organisational objective. If not, we need to be little more discerning, more understanding and cognisant of organisational context and environment. Change is disruptive. As professionals, we need to ensure that the benefit of the change outweighs the cost; to be less dogmatic and more framework agnostic.
It is time that we at Acme Consultancy* practice less consultancy and training, and a lot more coaching and mentoring. It is time that we become not only more objective-led, rather than solution-led, but also more driven by Principles than practices.
*Acme Consultancy does not exist and is merely representative of any one of a number of such companies who offer similar services to those described.
If you have thoughts or experiences with this, please leave a comment. I would love to hear your views.
In the third article in this series, I will discuss the concept of being Principle-driven in a little more depth.
