In my experience, perhaps due to my intellectual make-up, I seek for understanding beyond the superficial reality of it just is. If I am exposed to a concept or approach that offers a new way of seeing the world, to me, I can only truly embrace it with conviction when I feel I understand. In very complex disciplines such as depth psychology or quantum mechanics, there are many phenomena that just is, that exist before our eyes but whose explanation eludes those seeking knowledge of how and why they are. In these situations it seems enough to harness the phenomena without understanding, especially when the benefits of using them are great. Stanislav Grof, the founder of transpersonal psychology, admits that it is not possible to explain why certain conditions of the mind manifest, or indeed how his psychological modality achieves some relief in his patients. The fact Grofs suffering patients can attain relief through his therapeutic approaches is enough for Grof – he may never understand why, but his goal is to relieve suffering, and if something works without being explainable, so be it.

While some concepts in our universe cannot be explained, only observed, in our discipline of software engineering the phenomena we face are not so esoteric, and are often explainable and observable. We are fortunate in that we can develop the right level of understanding to grow with new concepts as we discover them; the greater challenge for many is in the commitment to learning in a busy world. Yet, exposure to new models of thought, new paradigms of practice, ultimately requires deeper knowledge which has to be attained through experience, intellectual inquiry and time. Of course, the first step is to realise that a new concept or idea is different to that which we compare it against, and to appreciate that we cannot successfully project existing mental models onto the new idea and hope to completely understand; at some point we need to allow the formation of new models, which as a process could potentially shatter previous belief systems and whole ways of thinking – these shifts may be too great for some, yet for others, be they individuals or organisations, it can mean progress.

Understanding the Chasm

One can be forgiven for thinking that choosing an approach such as agile development might be as simple as learning a few new simple rules and practices. In some respects, at the superficial level, this may be true; but it’s not so simple. Any organisation that makes the decision to learn agile development, is not just stating the forgoing of traditionalistic values, principles and practices, but is committing to the endeavour of education and discovery of new paradigms and mental models that jeopardise the very survival of its present identity. In some respects, at a deeper level, this is exactly what happens to those that cross the chasm.

A step onto the road of agility can mean the want to make progress, to seek the pastures of greater success where the software endeavour itself has been civilised and socialised into the organisations culture and way of being. To an establishment rooted in hierarchy, deterministic projections and control and command management cultures, the land of agility can often seem like a nice sunny place one might visit for a short holiday, but would not wish to spend much time there. “Those people over there…they’re not like us”. Through diplomacy and noble struggles the two can conjoin on a foundation of understanding, on the bedrock of recognition that differences abound, the cause is common; to achieve success with software development, to discover the key behind the software code. This is Right Understanding.

To my mind, it is important to remember that there will be great times to be experienced by many new teams that discover agile development. And of course, there will be times when difficulty arises, when the team is faced with a problem that rocks deep to the heart of their being, when fear itself manifests and challenges them to step back, to return to what it knows, to old habits that are predictable and safe.

Agility means going slower than we used to, rattling off feature after feature like a helicopter machine gun, ripping through the heart and soul of the victim that is the very code our project and life depends on; thunk, thunk, thunk…in go the features. Stand back – do we have a flatliner? The focus is quality, not quantity. Agility means stepping into a world of uncertainty, a world where a plan starts to fade as soon as the ink reaches the parchment, a place where both chaos and order are allowed to exist as respected adults. Command and control is substituted for a healthy respect for the people, no longer are they seen as cogs in the machine of corporate strategy. The people are left to self-organize, to act and react to the forever existing impetus of uncertainty and change; adapting, reacting, embracing. Through shared vision, shared goals and passions, customer, developer, manager, all come together in a collaborative, respectful honour of the reality that software construction is hard, but together through united understanding, a difference can be made; but there must be change.

Commitment 

To have longevity with agile a commitment is needed to develop enough understanding to know what to do and how to behave when the journey brings adversity.  Agility is not just about programming, its about creating a foundation of values and ethics from which to interact with our customers, our employees and other teams.  Its about understanding that while there is uncertainty, this breeds innovation from within (if cultivated), further allowing that organisation to act, adapt and ultimately create new differentiation in a dynamic business environment.   Courage and strength come from a commitment to developing the right knowledge and theory behind the principles (surely its an obligation?), so that the team can be supported by their leaders in the face of adversity.  Agililty is a new paradigm, and it does require new understandings – right understandings.