Continuously adapt to customer needs and feedback

In the previous article on a post-COVID Agile Manifesto and Principles, I concluded that in an agile world a solution works when the customer, that is, anyone who depends on it, says so and that the progress of a solution’s evolution only to be verifiable in retrospect by the customer. Hence, the focus was on the solution, or the artifact, evolving over time by the teams’ efforts. But to make this happen we need a team culture, climate, and behaviors suited for the journey.

In this article, the time has come to dissect the second part of the proposed post-COVID Agile Manifesto that an agile team should “continuously adapt to customer needs and feedback”.

This article is the 3rd in a series on adapting the Agile Manifesto, its Principles, and implementations to a post-COVID world where working from home will be more common than before the Coronavirus entered the scene.

The articles are not intended as a claim of one organizational setup or way-of-working to be better or worse than any other, as each has benefits as well as problems heavily dependent on where, when, and how they are applied. The purpose is to invite to discussions on benefits and problems, as well as myths, paradoxes, and misconceptions with past, current, and future organizational models.

Also published in this series on post-COVID agility you find reflections on a post-Covid agile manifesto and principles for the “working solutions”.

... customer needs and feedback

Paraphrasing the Danish philosopher S Kirkegaard, I believe that agile evolution “can only be understood backwards; but it must be lived forwards”. That is, the outcome of an evolutionary step can only be judged based on the customer feedback, and the next step has to follow from this and any additional needs. But, it’s not only the solution that needs to evolve in line with customer expectations, expressed as feedback and needs.

From a psychological perspective, the uncertainty of the evolution of a solution will for most individuals and teams challenge a natural need of being able to understand the current situation and predict one's future. There’s a slogan often mentioned in relation to agility that one has to “embrace uncertainty”, but science has shown that this is not as easy as it may sound and the need of “safeness” to be deeply rooted both in the human biology and (Western) culture.

To be frank, I think the men and women who wrote the Agile Manifesto and its Principles, underestimated the social-psychological challenges with being “agile”. Their way to try to manage some of the problems was to rely on time and space to do the work, by even state them as principles referring to frequent face-to-face meetings, often implemented as scheduled ceremonies and co-location.

If ceremonies and co-locations only are "means", what is then the core challenge they try to address that is unique when it comes to "agility"? To understand this, we have that the human need of feeling "safe" goes hand in hand with taking "risks" - we feel safe when there are no risks, or at least we believe we know how to mitigate and manage them. Clearly, the outlined evolutionary step-by-step process from an idea to an unknown solution oozes risks both for the agile team and the customer, hence something that will make us feel unsafe and potentially jeopardize a smooth collaboration.

So, if we could mitigate, or at least learn to live with, the risks, we would potentially be better suited in an agile world both as an agile team and customer.

Agility is about trusting your fellow human beings

I think risk management is as crucial as eating and sleeping to the human organism. For instance, we invented weapons to reduce the risk of starving, or be killed by enemies. We came up with contracts, including rewards and punishments, to try to ensure expected outcomes when we had to rely on non-family collaborations, and project-based organizations and waterfall-like development frameworks to try to predict expected outcomes as highly achievable.

All of these approaches boil down to that disclosure of information, reliance on others, and being willing to spend time together are all key aspects for collaboration which are highly influenced by trust - you're more willing to take risks with those you trust. Or, the less you trust someone, the more you try to safeguard your expectations with contracts and procedures.

Before continuing, processes and frameworks are not only about human safety, as they also try to mitigate another human fallacy - we cannot do several things at the same time, and even worse when we're many people at the same time depending on each other.

So, for me, the key principle of being agile is to deal with uncertainty through trust:

Agility must be based on, and nourished by, trust in the team and customer

Or, the less trust, the more playbooks and ceremonies, and ultimately we end up with a new waterfall-like or bureaucratic organization.

How trust is established and maintained in an agile team is the focus of a forthcoming article, but let's return to the proposed manifesto phrase "customer needs and feedback" as it's the most important, and possibly only, way for an agile team to learn about the level of trust in the relationship with the customer. Hence, it will be the basis for improved trust-based collaboration within the team and with the customer, and thereby being highlighted in the manifesto.

Continuously adapt to ...

As discussed, in my opinion, to be agile is not a process that can be expressed as a framework with ceremonies etc, but a continuous cognitive and behavioral adaption to a changing environment. As soon as we try to package “agility”, and the foundation of trust, as a process, we are no better than any traditional waterfall-like development framework.

Being agile doesn’t mean there is no need for “frameworks”, but not as prescribed routines, organizations etc because they are as useless as the “documentation” hysteria which we criticize other views to be obsessed with. Still, successful agile evolution is about being able to become “we” among the development team and the customer and develop a shared culture and behavior based on trust resulting in a “safe” environment mitigating the inherited uncertainties of being agile.

This leads to the last, and probably most controversial, principle:

An agile framework shall focus on why, before how

To exemplify where, according to me, existing frameworks have gone wrong let’s look at the almost religious commandment that an agile team shall be co-located. Companies re-organize and even build new offices to achieve this, without even asking themselves why. I don’t know why the authors of the original Agile Manifesto and Principles made an (implicit) point of co-location, but if we take a huge step back we know from social psychology that a we-feeling in a group has many positive outcomes both at an individual and group level. Moreover, we also know that co-location may support the establishment of this feeling, but also that it’s neither necessary nor sufficient to turn a group into a team. Hence, a framework to become agile should begin by describing what it wants to reach and why, before proposing any means on how to achieve it. In the case of, the misunderstanding, that agility requires co-location, we have an example where good intentions end up as prescriptions with little evidential support.

Reflections

In three articles, I have tried to initiate a discussion on a post-COVID Agile Manifesto and Principles which should be a foundation for frameworks and implementations in the spirit of being “agile”.

I agree with those claiming that agility is about “being” and not “doing” in the sense of frameworks stipulating processes of actions as a one-size-fits-all. However, this doesn’t mean that becoming agile will not result in a culture of behaviors and routines that may resemble processes in a framework. The point, and also the key to being agile, is that those evolve over time out of communications of needs and feedback, and not as something pushed into an organization as commandments - an agile framework shall support, but not stipulate.

In the next article, I will sum up the proposed post-COVID manifesto and principles and look at the next steps towards adapted frameworks in the spirit of agility.

All views expressed in this article are my own and do not represent the opinions of any entity whatsoever with which I have been, am now, or will be affiliated with.

The author has more than 20 years of international experience in supporting organizations to utilize Information Technology to achieve business excellence. His assignments span AI and data analytics in pharmaceutical research to e-commerce and supply chain management in the fashion industry. Often with a focus on digital transformation combining traditional management with approaches like Lean, Six Sigma, Kanban, and Agile to reach new frontiers for development.