The Manifesto and Principles

The intention of the proposed Manifesto [1] is a simple statement which highlights the key aspects of "being" agile:

Show progress by working solutions, and continuously adapt to customer needs and feedback

In this case, it emphasizes the importance of working solutions as the measure of progress and to continuously adapt to customer needs and feedback as we don't know the final outcome until we reach it. For instance, we directly see how agile frameworks are intended to differ from traditional waterfall-like ones where a working solution is the final outcome and adaptions to changes viewed as deviations from the "plan". Note, this doesn't imply that "traditional" methods are poor, only that whenever we're dealing with a moving target it may not be the best approach.

To put some flesh on the bones, I also added a few Principles [2, 3] to describe a few crucial ingredients to be expected from an agile framework (Note: a few minor linguistic changes have been carried out with respect to my original articles [1, 2, 3]):

• A solution is working when a customer says so
• A customer is anyone who depends on a solution
• Agile progress cannot be predicted, or planned, only verified in retrospect by a customer
• Agility must be based on, and nourished by, trust in the team and customer
• An agile framework shall focus on why, before how

The first three principles focus on the what-part, that is, the solution, of an agile evolution from an idea to the final outcome, and the last two on the how-part in the sense of everything that makes the solution possible (see [1, 2, 3] for details). In a true agile fashion, the phrasing of the principles will probably change over time to better nail the intended semantics. For instance, as will be discussed in future articles, the concept of "trust" is multi-faceted, and in many frameworks, the "why"-parts may be hard to differentiate from "how" things are done.

So, why did I want to revisit the original Agile Manifesto and Principles? The simple answer is that to me, even before the Coronavirus and the era of working from home, the whole thing felt like a mix of philosophical visions and detailed, almost religious, practical commandments. Hence, my revision of the work is only to try to boil it down to a few essentials, and not at all question any of the existing agile frameworks. Moreover, in the light of the Coronavirus, the intention was also to highlight that aspects like co-location of teams and detailed schedules of ceremonies are, according to me, not to be considered prerequisites for agility, but chosen approaches by some of the implementations.

The post-COVID adaptions

The Coronavirus has clearly challenged many agile teams by forcing the members to work from home and rely on modern communication and collaboration techniques to stay agile. However, it's also worth noticing that, for instance, according to a recent HBR article [6] it's not clear if working from home is that bad for everyone, and I have also seen surveys saying that many want to spend around 1/3 of their time working from home to achieve a better work-life balance.

Considering the proposed manifesto and principles, the key questions, in my opinion, are how to establish and maintain trust in a team and in relation to the customers if we fork the co-located team, and why trust is so important for agility? Or, to push the conclusions by Gren and Lenberg [7] that agility is about responsiveness to change towards:

Is agility all about trust?

The importance of trust, especially in virtual teams, has been addressed by, for instance, Breuer et al [8] as it may foster behaviors like information sharing, open discussions of lessons learned, help-seeking, and social contacts. All considered important for agile teams, and highlighted by many agile frameworks as key outcomes of a successful agile transformation.

However, as discussed in a LinkedIn post [link] by Prof Weibel, transparency, considered an antecedent of agility, can be a two-edged sword leading to a "hiding behavior" if it is viewed as "(en)forced". Hence, behaviors like information sharing, increased availability, and a feedback culture might lead to distrust, and reduced agility, whenever any of the involved parties perceive it as being an indication of a wish of control [personal communication Prof Möllering (Reinhard Mohn Insitute of Management), see comments in LinkedIn post]. At the same time, the behaviors might increase the trust in an agile team, when they are viewed as voluntary.

In the next article, I will begin the effort to dissect the concept of trust in the setting of agility and what we can do to stay agile even from home, or in a new era of distributed agility.

Please, don't hesitate to share and comment on this article, as evolution only comes out of open discussions and lessons learned.

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.