Whether ‘big A’ Agile is achieved or not is largely dependent on the operating culture and leadership capability of any organisation trying to implement it, writes Frank Harkin.
The owner of a small software company once came to me with a unique problem. As well as selling software he also provided training and support in how to use it.
But what he couldn’t understand was why the training often worked well and sank in, but in other cases, didn’t, meaning the client’s subsequent use of the software was patchy, or floundered altogether.
Understandably, his focus was on getting to the bottom of the variance in the customer experience, and how his company could address that by improving the delivery of their training.
My response was to ask if [he thought] the problem wasn’t his training but rather of the organisational cultures of the clients he was working with.
From the look on his face, it seemed he hadn’t. I went on to suggest that if his software was high quality and the training provided consistently, then perhaps poor uptake could be due to the clients’ staff and culture, and an unreadiness for change.
Such is the case with the current debate many organisations are having about whether to “go Agile”.
When I first started to hear about Agile as a process, I thought it was just that, a process, and with people trying to explain the difference between Agile with a ‘big A’ or a ‘little a’, and saying things like, “it’s going to change the way we do business”, I wondered if it might be something of a fad.
As I dug deeper, though, and even did some Agile training myself, I came to understand its appeal – and was reminded of my conversation with the owner of the software company.
Of course, there’s much more to Agile than a piece of software and its accompanying training, but whether ‘big A’ Agile was achieved or not, I surmised, is largely dependent on the operating culture and leadership capability of any organisation trying to implement it.
While attending Agile training one message I heard was that it won’t work everywhere and is not a silver bullet for every problem.
This is logical because in some organisations the decisions required, or problems faced, may lack the complexity required to necessitate an Agile approach.
Whether you use VUCA, or its updated acronym of D-VUCAD (meaning Disruption, Volatility, Uncertainty, Complexity, Ambiguity and Diversity) or Cynefin (with its emphasis on sensemaking and its five decision-making domains of Simple, Complicated, Complex, Chaotic and Disorder) to help define your workplace habitat and decision-making protocols, if complexity isn’t present then an Agile approach may not be the answer.
If, on the other hand, you’re an organisation being disrupted, digitally or otherwise, it is easy to be drawn towards Agile methodology.
Its requirement to work in a series of paced sprints, providing regular outputs to partnered customers, from teams that are “all-in”, and lead constructively, promises the possibility of futureproofing an organisation.
One of the most popular aspects of Agile is the nature and delineation of roles within the Scrum framework. Here, the Scrum Master has certain requirements including responsibility to ensure the values and principles of the Agile Manifesto are in place and being adhered to.
Having one or more of these Scrum Masters in place means teams can work to the best of their ability, whilst removing any impediments or outside distractions.
This is leadership by any definition in that it creates an environment where success can be achieved, and indeed, some organisations find it easier to shift to Agile because it resembles their pre-existing leadership style and/or culture. To succeed, Agile needs a level of organisational readiness, willingness to change, and constructive leadership.
On the other hand, if the culture is non-adaptive, defensive and focused on power, then trying to implement Agile processes will almost certainly fail.
I prefer to think of Agile as more a philosophy of work, incorporating certain processes, disciplines, and approaches, rather than just a process.
Like the software training I mentioned above, the successful uptake of the Agile philosophy requires the right conditions of culture and leadership at the receiving site.
Key among those conditions are whether an organisation’s people are change-ready and willing to embrace the constructive culture in which the Agile philosophy flourishes.
The reason I call Agile a philosophy is because it is founded on four sets of values with twelve principles that can be mapped to each of them.
As a consultant interested in the relationship between values, styles of thinking and behaviour by leaders and the resultant culture that takes shape, Agile as an ethos, appears to have the genuine capability to affect change.
Under the right conditions, Agile shifts the focus onto performance and what motivates people, by defining desired values-based behaviours.
As seen in the twelfth and final principle, the focus is on being even more effective, and regularly adjusting team behaviour to achieve that.
A premise of Agile is thus the view that people not only want to be given the time and opportunity to become more effective, but also believe they can achieve that and improve. Hence Agile’s use of iterations and reviews because they provide regular opportunities to reflect and act.
As a consultant of Human Synergistics I would propose that all four Agile value sets have universal human appeal because they are constructively worded with an equal focus on people and performance.
The four values of Agile align closely with the values reflected in the Circumplex model that we use to help measure effective performance for individuals, teams or organisations. The first set of values focuses on individuals and interactions, over processes and tools. The deliberate emphasis is on people over things however processes and tools aren’t excluded and are still valued – just not quite as highly.
‘Over’ is not meant to be interpreted as ‘instead of’. The possibility of some healthy friction between the two aspects is welcomed, primarily because customers should always be at the centre of those interactions.
The second value set is ‘working software over comprehensive documentation’. The emphasis here is on the basic premise that the software/solution/product works, and while there will be supporting documentation that might allow for replication, repair or refinement, it needn’t be exhaustive.
For example, when we drive a car, we all want and expect the wheels to turn and take us from A to B. Very few people would insist on reading the car’s manual from front to back before taking it for a drive. Indeed, some of us freely admit we never refer to the manual in the time we own the car.
Agile’s manifesto also promotes ‘customer collaboration over contract negotiation’. At the heart of this is having a strong partnership with the customer and operating towards them in a humanistic manner.
Rather than potentially having an adversarial situation develop at some point in the project timeline, Agile requires a higher frequency of contact between the development team and client to alleviate that possibility.
Principle Four captures this ethos by stating ‘business people and developers must work together daily throughout the project’.
If you couple this idea with Principle Six, that ‘the most efficient and effective method of conveying information… is face-to-face’, it follows that Agile works best if an organisation has a culture that’s open to performance feedback, and customers who are also willing to provide it.
To appreciate my point as to the core appeal of Agile, consider this: what might happen if the coach of a sports team adopted Agile’s fourth value statement about ‘Responding to change over following a plan’, and told her players to pay more attention to what’s happening during the game rather than following her pre-match game plan? Without her providing vocal direction from the sideline would the team naturally self-organise? Would communication between the players increase? Would playing this way be more satisfying for them? Would on-field decisions be taken that the coach hadn’t included in her original plan?
Within this scenario, for this positive outcome to occur there would be one cultural artefact above all else that would need to be present in the team – trust.
The players would have to trust each other, and trust that the coach wouldn’t respond too negatively for moving away from her plan; and the coach would have to trust them to do the right thing on the field, not just because the situation has changed and requires it, but also because she believes they want to operate in a culture where they can determine the outcome of their own performance.
Without genuine trust, Agile will struggle. Customers must trust a process that requires their regular (even daily) availability and affiliation with a development team, whose expertise to get the job done they must have faith in too. Product owners must trust the Scrum Master and share with the team the definition of ‘done’, and then let the team get it done.
The Scrum Master must let the team work to the best of their ability, and improve that ability where needed, while clearing obstacles to getting it done, and team members must trust those they work with to be able to get it done too.
In turn, Agile also offers acceptance: giving individuals clear roles that put their skills and expertise to best use, while at the same time letting them be part of a wider squad or tribe who are collaborating for the greater good.
It teaches us to trust our colleagues, and ultimately fosters trust in ourselves.
Frank Harkin is a senior consultant at Human Synergistics New Zealand.
