Human-Centric Business Agility: What Fake Agile looks like

Fake Agile symbol illustration © 2018 Debi Prasad Mahapatra

What is Fake Agile, by the way? Fake Agile is something that looks like real Agile on the surface. But, deep down inside, it's NOT Agile. Fake Agile doesn't generally lead to the usual benefits of Agile. At its best, it's merely symbolizes a hope against hope that Fake Agile will lead to the desired Real Results!

Detection and eradication of Fake Agile is a particularly important part of establishing Human-Centric Agility[Link]. Here, this is a humble attempt to candidly describe what Fake Agile looks like. This is NOT a process or methodology around HOW to identify and eradicate Fake Agile to make room for Real Agile. Because HOW you achieve that is a very ‘context sensitive’ business. Neither is this a comprehensive list of all the issues that you will come across in a Fake Agile organization.

Fake Agility is sometimes deliberate. However, in most of the cases, it’s NOT deliberate. Where it’s deliberate, the team or the organisation involved has a conscious agenda to 'make it look like Agile'. Where it’s not deliberate, it's a simple case of lack of knowledge and experience around Real Agile. And, in many a case, it’s not always an entire organization that gets engaged in practicing fake agility. In those cases, many parts of the organization in question actually embrace real Agile while many other parts don't.

Organisations usually implement Agile using an Agile Framework. For this discussion also, a framework is required as a reference and an example. Scrum, which has been the most used Agile Framework for the longest period of time, and probably for a reason, has been used here as the example. Some of the commonly used practices which are not a part of the Scrum Framework as such have also been mentioned to build the context. It's not the case that Scrum leads to Fake Agile. No, it doesn't. This discussion is about what Fake Agile looks like when an organisation tries to implement Agile - but not in a very appropriate way - and happens to use Scrum. Now, let’s take a deep breath and dive in. It’s pretty deep! But, fortune favours the brave.

Non-Agile Agile Transformation

Agile transformation must be an Agile endeavour. However, if you take a close enough look at it in a Fake Agile organization, you will see that the Agile transformation itself takes the shape of a typical regimented non-Agile endeavour.

Agile transformation sans inclusion

Fake agile organizations don’t usually take everyone along in their organizational Agile transformation endeavour. Sometimes, while forming 'Agile Champions' groups, real Agile organizations also fall into the trap of not including colleagues from various function areas, departments etc. And, as a result, they lose the valuable opportunity to (a) gather and assimilate diverse experience-based 'point of views', (b) make the transformation process holistic and more relevant for the entire organization.

-- ❀ --

Disaster around selecting the Scrum Master

Suitable person for the role?

Do personal attributes of a person playing a role impact the effectiveness of that role? Let's explore. ‘Project Manager’ as a job title, for example, doesn't particularly and necessarily denote a personality type. Every human being is more or less unique. Except under exceptional circumstances, individuals generally change fundamentally little in who they are. However, more often than not, people choose, continue to stay and progress in a profession or a type of work or job based on who they are in terms of their belief system, perceived strengths, inclinations, taste or likings etc. And, more often than not, the longer they stay and the more they progress in their chosen profession, job, type of work or professional career (i.e., the more they do what they do), the stronger they become in their behavioural patterns associated with the profession, job, type of work in question because of learning and experience acquired and absorbed on the job leading to establishment of strong habits and behavioural patterns. And, it is generally believed that some people are more appropriate than others for some types of profession, job, work or professional career.

Exceptions and Force-fits

Of course, there are exceptions, and it’s not really impossible to find people, who have done other types of jobs for a long time to take up Agile (Scrum) roles including that of a Scrum Master and do reasonably well. In most of the cases, those people at least had the appropriate personal attributes and inclinations etc. In Fake Agile organizations, it’s also not rare to see people getting pushed or thrown into the role of a Scrum Master even when the people in question don’t believe that they are really suitable for or interested in that role or a career around that role.

Wrong selection leads to wrong direction

The Scrum Master Role is an extremely crucial piece in achieving real agility and avoiding fake agility. Scrum Masters are first the Agile Coaches for the team(s) they serve, and they are accountable for establishing Scrum; so that, the benefits of Scrum are available to everyone involved. So, if they are not the most suitable type of people with the right knowledge, beliefs, experience, inclinations, conviction, taste or likings, and mindset etc., disaster in the form of Fake Agile starts there. Who is responsible for ensuring that this doesn't happen, and what do they do to ensure that? Fake Agile organisations often shy away from identifying and giving way and space to the more suitable people to drive agility. And, in many a case, they shy away from doing that to conserve perceived-as-valuable ‘status quo’ in terms of ‘power balance’, ‘hierarchical arrangements’, ‘resource utilization’ and ‘financial arrangements’ etc. in a very bureaucratic and regimented way. Most of the Fake Agile organizations commit the same mistake when it comes to selecting someone to drive Agile Transformation. That’s where it becomes ‘penny wise and pound foolish’.

The missing conversation and the ‘benign’ Scrum Master

In a Fake Agile organization, Fake Agile also gets rooted when an experienced Agile Coach or a Scrum Master is hired from outside for a team, but an agreement between the team and the new Agile Coach or Scrum Master on how to apply or implement Scrum isn’t arrived at; the required conversation doesn't take place to resolve the tension. Eventually, the Agile Coach or Scrum Master gets fired, and someone very ‘benign’ - with no notable experience, knowledge, inclination, faith, and beliefs around and in the positive impacts of Agile, Scrum and agility - gets hired as a Scrum Master. So that, it becomes ‘easier’ for the team to ‘guide’ the new Scrum Master, without much hassle, to do things exactly the way the team likes, leaving Scrum and Agile lying dead somewhere, while the team defines and dictates the day-to-day work of the new Scrum Master. Fake Agile organizations have been massively successful in meticulously looking for and ultimately finding the ‘useful’ ‘Benign Scrum Masters’. That ‘success’ has not only been detrimental to the health and state of Agile in general, but it has been harmful also for the benign Scrum Masters in question.

In a Fake Agile organization, when a team finally fails to bring in a benign Scrum Master, and instead finds a fairly effective one, the team begins working on making the Scrum Master become a benign one. Once that is achieved, there is usually a bit of celebration around that instance of 'continuous improvement' achieved in which, through a process of 'conscious transformation', an effective Scrum Master was successfully transformed into a 'useful' one. And, then, the team starts to take a particularly greater pride in its transformed Scrum Master, and increases its reliance on the Scrum Master for more fork of 'suitable type'. Agile transformation is all about transformation. Isn't it?

Deformed manifestation of the role

In a Fake Agile organization, it’s not rare to find a Scrum Master continuously pushing, pressurizing, and nagging the team members to complete the work planned for a Sprint. And, while the Scrum Master does that, she believes that she is not only helping the team members tremendously by keeping them focused on completion of the work planned for the Sprint in question, but she is also helping the stakeholders achieve not only the expected, but also the best possible outcomes!

Everything except the most important duties

And, in a typical Fake Agile organization, it’s not difficult to observe that the Scrum Masters do pretty much everything based on the misplaced and massively flawed expectations around them, their role and their work. But, ironically, they just don’t perform two of their most fundamentally foundational duties listed below.

• Understanding Scrum: It’s not about understanding Scrum just in terms of its low-level details - the Roles, Events, Artefacts etc. - and the popular practices around it. But, it’s about gaining a considerably deep understanding around Scrum in terms of ‘why Scrum’, why Empiricism, why those Values, why those Roles, why those Events and Artefacts, why those elements have been combined in a specific way within the framework, etc.
• Helping and ensuring that everyone involved ‘really’ understands Scrum.

Just a change in the role-title

There are Scrum Masters, and there are people trying to ‘play’ the role of a Scum Master. In Fake Agile organizations, in many a case, when command-and-control type Project Managers, for example, play the Role of a Scrum Master, their language, their way of interaction etc. don’t quite change not only over months, but years. The team members continue to see them as command-and-control project managers ‘trying’ to tick all the boxes around the Scrum Master role.

Isn’t it about the role played right?

The idea is not about stopping Project Managers - and for that matter, anyone - from ‘becoming’ Scrum Masters or playing that role. It’s actually about playing that role in a reasonable way - the way it’s intended to be played. Playing the role the wrong way creates strong bad habits and profound wrong perceptions about Agile and agility in general, and Scrum in particular. Those habits and perceptions are oftentimes difficult to change. Also, many things known to be parts of Agile and Scrum could very well be applied purely mechanically without the accompanying spirit of agility, the mindset and the conviction around why something is done in the way it is done in real Agile. In a Fake Agile organization, when a command-and-control type Project manager is NOT playing the role of a Scrum Master, and there is an 'independent' Scrum Master, it’s not that hard to find the Project Manager dictating how the appointed Scrum Master does the job!

Lack of awareness impedes identification

Many of the Fake Agile organizations routinely fail to recognize, identify, appreciate, and use the experiences and capabilities of good Scrum Masters, if they happen to have any within the organization. Because those organizations don’t quite understand that role. And, many of those organizations don’t find those good Scrum Masters loud, visible, heavy-handed and table-thumping-type enough to be considered as ‘true’ capable leaders!

-- ❀ --

Who are your agents?

Right people for right results

As an organization, if you manage to deploy and empower the right people with (a) a deep knowledge of Agile Values and Principles (basically, also the ‘why’ behind everything), (b) a profound conviction around the benefits of Agile, (c) the right experience in applying Agile, (d) the appropriate personal attributes etc., not only do they show the organisation in the best possible light when ‘Agility Auditors’ arrive, but they also make the organisation truly Agile on the inside to generate all the real benefits of business-agility for all the parties concerned within the organization and outside.

On the other hand, like people usually do in Fake Agile organizations, if you choose to deploy people who are not the appropriate ones for the purpose, and empower them, for reasons best known to you, it's easy to anticipate the outcomes of that endeavour. Strengthened fake agility, of course, is one of the most probable outcomes. Of course, there can be exceptions. However, exceptions, at the end of the day, are exceptions.

When leadership lacks that knowledge

And, in order to be able to deploy the appropriate people, the top leadership itself needs to gather and develop an authentic and a deep understanding around Agile in terms of its WHYs etc. Once it's equipped enough, it may venture into the business of identifying, deploying, and empowering the appropriate people with support from other organizational forces. In many organisations, unfortunately, the top leadership doesn't have (a) a reasonably good knowledge around agility and (b) a strong conviction around its real benefits. In many a case, the top leadership believes that it has a sufficiently deep knowledge around Agile. But, it doesn't do enough to verify if it really has that deep knowledge. Since that verification doesn’t happen, no step ever gets taken to gain that knowledge where that knowledge is actually absent. And, the problem remains undetected.

Disbelievers galore

Most of the Fake Agile champions, practitioners or experts don’t really believe in the Agile values and principles. They don’t really believe that application of Agile values and principles can and do generate grand positive outcomes. It’s not their belief, passion, and conviction around the positive effects of Agile that make them work as Agile champions, practitioners, or experts. They get associated with Agile because of reasons best known to them.

They fuel Fake Agility

In Fake Agile organizations, fake practitioners - who, in most of the cases are not aware that they are 'doing' Fake Agile - fuel fake agility. Our habits are significantly more powerful than we sometimes realise. We pick habits based on who we are. And, with practice, our habits become only stronger over time. When a habitually loudmouth ‘always in a hurry’ command-and-control type highly visible regimented hardcore member of staff attempts to play the role of a Scrum Master, for example, it usually leads to a difficult situation, and not so pleasant an experience for everyone involved, including the member of staff in question. Do those organizations really understand why that role exists and what one should really do in that role?

Learning to unlearn takes effort

The more you have practised fake agility, the harder it becomes to come out of it and embrace real agility. There is really nothing to be happy about the fact that you have done it for some time now in a ‘perceived’ correct way and that’s why you ‘supposedly’ at least know ‘something’ about agility. Habits, including the not-so-desirable ones, once strongly established are difficult to change. Unlearning takes time and effort. Not only do learning and unlearning take time, but learning to unlearn also definitely does.

You need a people-person

When it comes to selection of your Agile transformation agent, are you selecting the suitable person who is trusted by people, who has the suitable communication style, who has a deep understanding around Agile values and principles, who is generally good at working with people, and has got the appropriate experience? You just can’t 'make' people trust and really work with someone.

Fake practitioners are impediments

In Fake Agile organizations, practitioners - who, in most of the cases are not aware that they are 'doing' Fake Agile - are detrimental to the art and science of Agile and Scrum. They, most of the time unknowingly, help block the ways through which benefits of real agility could be generated.

Agile on the surface

Most of the Fake Agile organisations appear elegantly Agile on the surface; but deep down within, those are extremely non-Agile and profoundly 'command and control' organizations. The longer you practice Fake Agile, the stronger you become at fake agility. It's just an illusion that the length of practice leads to strength in positive outcomes. However, length of wrong practices only leads to proportional negative outcomes.

Who is on your team of champions?

When a typical Fake Agile organization puts together a group of ‘Agile champions’ to drive Agile transformation, it typically includes quite a few non-believers and non-practitioners in that group. That, of course, limits the potency of the group in achieving the goal, whatever the goal means to the organization. On the other hand, when a similar group is created in a real Agile organization, it’s indeed a good idea to include a few influential, capable and well respected non-believers and non-practitioners in that group along with some influential, capable and well respected believers and real Agile practitioners. That would create an opportunity for the non-believers and non-practitioners to learn, get exposure to Agile and ask questions to address their apprehensions around Agile and agility. That’s also an opportunity for the believers and real Agile practitioners to look at the ‘big picture’ through the eyes of the non-believers and non-practitioners and learn in that process what needs to be done. That would ultimately lead to a slightly easier propagation and greater acceptance of agility within the organisation.

-- ❀ --

Scrum Master has the Easiest Job on the Earth 

In a typical Fake Agile organization, people have a massively flawed understanding around the role of a Scrum Master. And, many of them really believe that the job of a Scrum Master is actually the easiest one on the Earth. Well, if you really think that the job of a Scrum Master is so easy that one could do that in one’s sleep, you need to wake up, and open your eyes to the reality.

Perceived easy? There is a reason!

There is a reason why the job of a Scrum Master is perceived as the easiest one on the Earth. Because, in typical Fake Agile organisations, Scrum Masters, based on their own interpretation and knowledge of the role, and the organizational expectations around them, do only the relatively easier and more visible 'secretarial' and 'policing' activities in terms of scheduling the Scrum Events, supporting maintenance of some of the Scrum Artefacts, reporting, and ensuring that the Scrum Events do happen and are time-boxed appropriately etc. They don't usually do the relatively more difficult parts.

Coaching is anything but easy. Supporting Scrum as defined in the Scrum Guide is not particularly easy under all circumstances. Being a Servant Leader is not easy either. ‘Helping’ people outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t is absolutely easier said than done. And then, in the absence of any formal authority, ‘helping’ everyone ‘change’ those interactions to maximize the value created by the Scrum Team is one of the hardest things to achieve. It’s never easy to change how people behave. The intended services of any Scrum Master to the Organization, to the Product Owner and to the Development Team include quite a few very difficult parts. In that sense, the intended form of the Scrum Master job makes it one of the most difficult ones. By the way, how many Scrum Masters you have seen who render all the intended services in the intended way?

-- ❀ --

The strange concept of Cross-Functional Teams

Fake agile organizations find the concept of Cross-Functional teams to be a very strange concept. Those organizations lack systems thinking. They fail to recognise, in a software development context, for example, that specifying requirements, designing, coding, designing tests, automated testing, continuous integration, continuous deployment, documentation etc. are all parts of the whole in attaining agility in software development. There is always a wall between the programmers and the test engineers, for example, in Fake Agile organizations. And, that’s a reflection of the culture underneath and the strongly established wrong behaviours.

Agile Mindset belongs to the top

Many people in Fake Agile organizations believe that Agile Mindset belongs just to the top of the hierarchy within a business organization. However, the mindset is supposed to belong to all the levels in the hierarchy - well, as long as there is a hierarchy. A deep knowledge around Agile methodologies and practices is a crucial input for the formation of that mindset. Agile Mindset represents a way of thinking. And, a way of thinking profoundly influences the ways of working.

Perpetually dissatisfied primary beneficiaries

The Agile Values and Principles were composed, ‘by’ expert and very knowledgeable representatives of people directly involved in value creation, ‘for’ the people directly involved in value creation. In typical fake Agile organizations, it’s usual to find people - who are directly involved in value creation - perpetually dissatisfied about ‘doing’ Agile because of the massively wrong interpretations and applications of Agile in those organizations.

-- ❀ --

Why Start and Stabilize before Scaling?

Learning an Agile Scaling Framework is not equal to learning about the essence of Agile. Starting your Agile journey with a Scaling Framework, without good enough knowledge and experience around the foundational Agile Values, Principles, Frameworks and Practices - whether you realise, acknowledge and accept this or not - is not particularly a wise choice. For ‘Scaling Agile’, most of the Fake Agile organizations seldom take into consideration simpler minimalistic and lightweight frameworks that include a small number of rules, roles, and artefacts. Those very organizations struggle with Agile at the team level, and then, once they apply the scaling framework of their ‘choice’ - our choices generally reflect who we are -, they struggle with Agile at an organizational level. The entire organization starts to ‘look’ and ‘sound’ more Agile. Scaling just scales the problems up instead of solving those. Because of ‘that way of’ scaling, there is always a bit more noise and haze that make real problems a little more obscure, sometimes creating a basis for a bit of celebration.

Many of the Fake Agile organizations have started their Agile journey with a large, heavyweight, and complex Agile Scaling framework.  Those organizations have typically been reluctant to (a) first really understand what Agile is, (b) learn a basic Agile Framework well, (c) become reasonably good at implementing that basic framework, like Scrum, before they start dealing with a scaling framework. Scaling has its purpose and scaling has its place. But, it’s obviously close to disastrous if you actually start your Agile journey with a large, heavyweight, and complex scaling framework and get lost in the details pertaining to Scaling before you actually come even close to an Agile Mindset and Agile Culture. In some cases, ‘command and control’ is consciously nurtured under the banner of Agile when a not-so-suitable scaling framework is applied.

Large Frameworks for Large Organizations

Large, heavyweight and complex Agile Scaling frameworks have been sold to many large companies with taglines like ‘this framework is large and sophisticated, and is exactly suitable for a large and complex organization like yours’, or ‘this framework is comprehensive, has got fully defined processes and a large number of roles - exactly making it suitable for a large ‘process oriented’ (command-and-control oriented, traditional and rigid?) organization like yours’, or ‘this framework lets you retain your current structure and the ways of working etc. (with minimal superficial changes) while you are still able to ‘show’ that you are ‘doing’ Agile’. 

And, in many cases, it’s not that hard to identify that there was probably no real need for scaling Agile, or there were simpler, leaner, more inexpensive and inherently Agile scaling frameworks available in case there was a real need. Many organizations have been blinded by an unfounded but popular belief that some of the Scaling Frameworks are the next best things after the Agile Manifesto and the Scrum Framework, for example. And, of course, Fake Agile organizations routinely and consciously ignore the critical questions raised around the large, heavyweight, and complex Agile Scaling frameworks by very experienced 'real' Agile practitioners.

Probably, there do exist organizations that have been massively successful in really ‘being’ Agile, and they happened to have used some sort of large, heavyweight, and complex Agile Scaling Framework in their Agile journey. What we may not actually know is if they wouldn't be that Agile had they not used that large, heavyweight, and complex Agile Scaling framework in question instead of another small, lightweight, and simple Agile framework. And, it is also useful to understand whether those organizations actually did ‘start’ their Agile journey with a large, heavyweight, and complex Agile Scaling framework! If those organizations were Agile enough at their cultural core, to start with, they would be successful anyway in becoming Agile.

Even though, I believe that every Agile Framework has something great to offer and has something really valuable, when a ‘traditional’ organization goes ahead and stays with a scaling framework which is popularly suitable for ‘traditional organizations’, the organization in question (a) increases its likelihood to remain ‘traditional’ for a very long time, and (b) significantly decreases its opportunity to become a ‘modern Agile organization’ anytime soon.

Scary Simplicity and Comfort in Complexity

Many typically command-and-control Fake Agile organizations get easily scared by the simplicity of the lightweight Agile Frameworks like Scrum. Based on their mindset, beliefs and lack of knowledge and experience around real agility, they find it very hard to believe that something that simple could be of any real use for any serious business. Those organizations sometimes directly go for a large, heavyweight, and complex Agile Scaling framework, or add and combine so many other things to create their own customized version of a solid complex enough Agile framework perceived fit for any serious business.

-- ❀ --

When details become the devil

The devil is probably in the details. However, if you get blinded by the details, if you lose yourself in the details, if you miss the forest for the trees, if you get completely consumed by the details, you will always be dealing with the details and the devil. You will probably never get to see, know and work with the divine. In a software system development context, for example, it’s as useful as worrying and doing a lot about coding standards, coding styles, code review checklists, choice of programming languages, selection of tools and technologies before actually understanding reasonably well why the system in question is getting built, who the users are, what their real needs are etc.

Practitioners in Fake Agile organizations easily get lost in the details around the HOWs instead of being able to maintain a reasonably good focus on the WHYs. They focus on the lower-level details like tools etc. and believe that they are applying real Agile to their context. Those lower level details are just the means to address the significantly more important WHYs of real agility. It's a bit similar to focusing on implementation details before really understanding the requirements, architectural philosophy and the design involved.

Hidden in the Job Descriptions

It’s not that difficult to smell Fake Agile in the interestingly strange Job Descriptions and Job Postings or advertisements published by Fake Agile organizations around the Scrum Master role. The more a Scrum Master does what a Scrum Master is not supposed to do primarily, the less is left in terms of attention, time, energy and focus to do what a Scrum Master is supposed to do primarily. Those Job Descriptions and Job Postings or advertisements take it to a point where the Scrum Master role loses much of its resemblance with how the creators of Scrum thought and proposed or described the role to look like in real life! In some cases, those organizations also come up with very strange Job Titles for the Scrum Master role and include in the job descriptions what you would usually expect in the Job Descriptions pertaining to roles and job titles that have no resemblance with the intended Scrum Master role.

Which problem are you spending your life on?

In Fake Agile organizations, it's not fine if you refine. The command-and-control type Project Managers in a Fake Agile organization shout ‘stop refining now’, because the size keeps changing. You can clearly see that anger in their eyes and hear that frustration in their voice. They keep repeating “why can't you estimate it ‘right’ at once at the first 'given' opportunity? If you anyway have to refine your Backlog, because you are doing something seemingly funny that is referred to as Agile or Scrum, please do restrict refinement to twice at the most in a year”.

What is even more interesting is that the same set of Project Managers vehemently express their dissatisfaction and frustration when a more powerful and influential entity needs them to meticulously report and explain each and every delta between ‘their’ estimates and actuals. Estimation is useful. Estimates are valuable. What Fake Agile organizations don’t usually appreciate is that solving the ‘real’ problem - the reason 'why' a project is getting done or a product is getting developed etc. - is more important a problem to tackle compared to a problem in the form of some apparent weakness in estimates! Which problem are you willing to invest your life and your organization’s life in? The more you spend on one, the lesser you are left with to spend on the other.

-- ❀ --

A fair share of stress for everyone

In Fake Agile organisations, you can very easily smell 'power at play'. And, when ‘habitual controllers’ act as if they have given away control, they suffer and experience that stress, fear and insecurity around a sense of losing that control they are so accustomed to. And, that experience is usually very bad for their own wellbeing. So, it’s not only the team members, but the people who are the force behind generating stress for everyone also share a fair share of stress generated.

It's Agile! It’s supposed to be flexible!

People in a Fake Agile organization strongly believe so. And, they go ahead and skip Daily Scrum as per their convenience, the Daily Scrum doesn’t happen daily, they change the length of their Sprints frequently as per their convenience, they take a break and don’t start the next Sprint immediately after one Sprint gets concluded - while the work in question doesn’t actually stop; in some Sprints they do Sprint Review and Sprint Retrospective, and in some, they don’t based on their convenience, etc. It’s actually a very long list. Well, at the end of the day, it’s about flexibility. Isn’t it?

Empty Empiricism

This is true in case of pretty much every team and organization ‘doing’ Fake Agile. Those teams and organizations don’t quite understand Empiricism. And, their behaviours and practices very clearly reflect that lack of knowledge of Empiricism. Without Empiricism, Scrum is anything but Scrum -  Scrumpiricism[Link]. Lack of Empiricism usually leads to a lot of unnecessary stress and 'wastage of human and organizational lives' (described in the Wastage of Human Life and Organizational Life section below) within Fake Agile organizations.

You can shape but can’t see your future!

Most of the Fake Agile organizations fail to recognise that human-beings are not great at (a) estimating, and (b) predicting the future. Those organizations, however, spend a disproportionately massive amount of time, focus and energy on estimating and trying to predict the future, instead of falling back on Empiricism.

Not enough rigour in thinking

Let’s take a closer look at the Cultural Element ‘Thinking’ which is a part of the Human-Centric Agility Framework[Link]. Many people believe that thinking is like breathing; it's continuous and autonomous; you can't and don't usually stop it while you are alive. Like breathing, thinking, in the context of a business organisation, is kind of continuous and autonomous. However, becoming a ‘thinking organisation’ is not about the routine, regular, continuous, and autonomous thinking. It's more like those rigorous breathing exercises or Pranayama specifically designed and used to generate specific targeted benefits. Rigour in action alone is not enough. Rigour in thinking, if not more, is equally important. Fake Agile organisations typically fail at being reasonably rigours when it comes to objective mindful or deliberate thinking. Thinking usually takes a back seat in a Fake Agile organization. Fake agile organizations, many a time, move rapidly, but in the wrong direction.

Progress in the wrong direction

In Fake Agile organizations, many people mistake ‘making people unnecessarily hurry’ for ‘generating a sense of urgency’ and actually end up smothering any bit of real and good sense of urgency that happens to already exist. Making people unnecessarily hurry usually leads to a lot of unwanted stress. Agile is about pace, not haste. The conversations and actions really required for generating a ‘true sense of urgency’ don't take place, and the required type of leadership doesn't get demonstrated. That type of leadership doesn't quite exist in typical Fake Agile organizations.

In Fake Agile organisations, the thinkers - who generate practical ideas that have the potential to massively help the businesses in the grand scheme of things - are generally ignored and not encouraged. Doing is valued much more over thinking. Rigour in doing is celebrated and rigour in thinking is not.  There is usually a prominence of failure in balancing nourishment, growth, and utilization of valuable human intellectual capacity engaged in (a) ideation and (b) execution. Pretty much everyone becomes busy executing. More often than not, it is difficult to recognize that “every 'Ideator' or ‘Thinker’ has an 'Executor' within. Ideation is a massive amount of real and hard work. That work, however, is extremely silent and largely invisible. Without that 'Executor' within, an 'Ideator' just can’t be an 'Ideator'.”.

Why worry? We have got Agile to blame!

Fake Agile organisations misinterpret failures and blame Agile. However, if you take a close and objective look at the failures in question, you will easily discover that an attempt was made at ‘using’ Agile while there was no experience in Agile, no knowledge around agility, and no real expert to support and guide that ‘use’ of Agile was available. And, on top of that, you will also discover that there were years old strong habits around doing things in a non-Agile way. Well, Agile is easy to blame. Isn’t it? It anyway doesn’t get much support and protection in a Fake Agile organization. One must be extremely careful about those very popular and anecdotal statements like ‘we have tried Agile in the past, and that didn’t quite work’.

What is even more interesting is that many a time, project failures, for example, happen just because well-practiced and well understood fundamental processes pertaining to project management, program management, quality management, portfolio management etc. are skipped or not followed reasonably well with a belief that ‘Agile’ will take care of everything!

Not able to blame Agile? Blame people!

Fake Agile organizations are quick to blame the people, teams, groups and departments who apparently failed in applying Agile and generating the expected benefits from application of Agile. They don’t usually take into consideration why the failure occurred and whether the right knowledge, experience and guidance was available to the exercise of applying Agile. And, sometimes, people happen to believe that they are applying human-centric agility just because they are trying to apply a Scaling framework that includes some human-centric aspects. But, when you go closer and take a close look at it, what you see, smell and feel is nothing but fake agility.

More often than not, people are very good at the work they do. They have great positive intentions. They are very capable. They understand their job really well. What they sometimes fail to realize is how much more they could achieve, generate, and feel good about their work, benefit their stakeholders, customers and users only if they really applied Agile.

Performance Management and Fake Agility!

Most of the Fake Agile organisations heavily rely on outdated and massively flawed ways of performance management that encourage unhealthy internal competition over healthy and beneficial collaboration. And, that’s just one of the many problems rooted in a flawed performance management system.

-- ❀ --

Are you trying to fake it till you make it?

If that’s what your attempt is about, you may not really ‘make’ it any time soon. Just a set of micro low-level events, activities, and artifacts with a bit of Agile ‘appearance’ just can't make your business organisation Agile. You need to have the appropriate people engaged in supporting and driving your Agile Transformation. Organizational culture is a complex thing. People who don’t understand much how Agile takes shape in the context of specific organizational cultures, generally are not very effective in making organizational Agile Transformation really successful.

What gets looked at is what is easy to notice

Detection is difficult when what is looked at is what is easy to notice. It’s difficult to detect Fake Agile by examining the lowest-level easy to notice details. In Fake Agile organisations, lack of knowledge around Agile and agility generally leads to a lack of knowledge around what tools, processes etc. are required to support agility. However, in some cases, those business organizations may happen to have ‘good looking’ Agile-appropriate tools, processes etc. Without appropriate experience and knowledge, it’s generally difficult to detect Fake Agile just by looking at the low-level details. If you have agility in your organizational culture, you will have a relentless quest for the appropriate tools, processes etc. to support your journey in real agility. fake agility, in many a case, is more about a profound and exclusive focus on all those low-level details.

Undetected inefficiencies

It’s not hard to come across businesses organizations that know their business domain and customers really well. But, when you take a really close look, on the inside, you discover a lot of inefficiencies in terms of doing things in the ‘good old’ tried and tested ways where other possible ways have never ever been taken into consideration. This is exactly where adding Agile to the mix would lead to significantly better results for the business as well as its customers. Fake Agile organization typically fail to do that.

Superficial Agility

In Fake Agile organizations, it is not hard to find teams that look great when it comes to the low-level details. When it comes to practices, they could be really great at, for example, writing extremely good ‘user stories’ in terms of structure and content. That does, however, no way guarantee that the team has embraced an Agile mindset and there is a culture of agility. The very team may be seen in a Sprint Retrospective where a loudmouth table-thumping command-and-control project manager, perceived to be playing the role of a Scrum Master, ‘demands’ from each of the team members an explanation pertaining to why they were not able to complete the ‘assigned quota’ of Story Points! And, the distress experienced there by the team members is not very hard to notice.

And, in some other Fake Agile organisations, beyond the framework, when it comes to practices, you will find a profound confusion around the basic low-level details. For example, many believe that the ‘Definition of Done’ and ‘Acceptance Criteria’ are absolutely one and the same. And, in some other cases, you will find teams meticulously restricting the Daily Scrum to 15 minutes, doing it daily at the same place etc. irrespective of any focus on actually getting the intended ‘planning, review and collaboration’ benefits out of that event. Fake Agile organizations routinely fail to gather valuable feedback on a regular basis from their customers and other stakeholders. In some of those organizations, you may see Sprint Reviews getting done on a regular basis where you may not find any stakeholder whose feedback would be absolutely useful and important. Beyond these, it’s not hard to find many more interesting examples within Fake Agile organizations.

-- ❀ --

When culture becomes a curtain

In diverse national cultures and subcultures, how people work together varies massively. In those cultures, aspects like respect, perceptions around success and trust, relationships, collaboration, reputation, power distance, decision making, communication patterns, individualism and collectivism, conflict response, hierarchy, importance of harmony, influence etc. manifest very differently. And, that’s what exactly makes it a tricky business. Because of the cultural aspects in the mix, it may become slightly more difficult to detect fake agility. On the other hand, because of those very aspects, real agility may to an extent resemble fake agility in some cases when looked at from a distance. In either case, a closer and more attentive look is usually required to discover the reality.

Extremely low level of trust

With an environment that lacks empowerment, self-organisation - which is generally powered by autonomy and freedom of individuals -, self-direction, self-management, self-motivation, collaboration etc., a Fake Agile organization generally suffers from a very low level of trust at all the levels within the organization, and around the interactions and engagement with entities outside the organization. Trust not built within doesn’t usually get reflected outside.

Scum Masters or Project Managers?

Take your pick: Scum Masters or Project Managers? Many Fake Agile organizations unfortunately believe in and implement this: ‘We do Scrum. We have Scrum Masters; we don’t need Project Managers; let the Scrum Masters take care of project management as well’. Or, ‘We already have Project Managers; we don’t need Scrum Masters, let the Project Managers play the Scrum Master role as well’. And, in many Fake Agile organizations, the Scrum Master Certification, for example, is considered a Project Management qualification!

You don’t need Project Managers?

Project Management encompasses a specific set of competencies which is extremely valuable for business success. And, Fake Agile organizations don’t always fail to recognize that. But, things go wrong when Project Management competencies are force-fitted into the Scrum Master role. Good Project managers are extremely valuable for business organisations. Throwing them into playing the Scrum Master role may not always be a great idea.

Imposed Agility, and not inherent

Fake Agile organisations and teams try to ‘use’ Agile NOT because they believe in its ability to generate real benefits. Those teams and organisations attempt that, and of course very superficially, - knowingly or unknowingly - just because an entity more powerful needs or wants those teams and business organisations to ‘use’ Agile. These are cases where there is a mandate to use Agile while the teams and business organisations concerned really don't believe in the benefits of Agile, but choose, because of the mandate, to drag on with superficial Agile or Fake Agile. In some other cases, it’s about a ‘peer-pressure-induced’ self-imposition - i.e., ‘we too’ ‘do’ Agile, and we are not behind the game.

Empowered Disempowerment

In Fake Agile organisations, you simply wouldn't find empowered people, ownership culture and growth mindset when you listen to the conversations and observe the behaviours. Elements like ownership culture, people empowerment, growth mindset etc. are connected interdependent pieces of the puzzle.

What runs the show?

Fear, anger, complaint, coercion and criticism run the show. In most of the Fake Agile organizations, fear, anger, complaint, coercion, and criticism are the primary driving forces. ‘Criticism, coercion and complaining’ over ‘coaching, compassion, comradery, cooperation, and collaboration’ are so common in organizations that are not human-centric. In those organizations, fear smothers innovation while stress suffocates creativity. And, many a time, those problems go absolutely undetected. But, the important question is, are you honestly willing to identify and eliminate those problems?

In a typical Fake Agile organization, when a failure happens - for example, when a project fails -, people worry considerably more about how to tackle the blame-game, non-constructive criticism, potential unfavourable perceptions, negative impact on performance appraisal, political and opportunistic attacks etc. pertaining to the failure; and worry significantly less about what could be learnt from the failure, alternative plan of action for potential success etc. The first category of ‘worry’ rooted usually in the ‘Way of Working Smells’ is massively wasteful even when that may in some cases lead to the second category of ‘worry’. In Fake Agile organizations, human intellectual capacity, effort, time, focus, creativity, and energy are not invested in identifying and understanding 'real' problems and solving them. Instead, those are invested in identifying who to place the liability on or who was at fault, and not what!

Suffocated Creativity and Impaired Innovation

Fake Agile organizations fail to recognize that an environment of continuous learning supported by an ownership mindset, self-organization - which is generally powered by autonomy and freedom of individuals -, self-motivation, self-direction, self-management, self-empowerment, absence of command and control, coaching instead of coercion, and ‘trust and collaboration’ over ‘contractual obligation’ generally leads to a significantly greater degree of expression of creativity and much better resultant outcomes. And, those outcomes generally serve the businesses, their people, and their customers way better. All that leads to a better society. There is a lot to learn from how ants work together, how honeybees work together and accomplish great outcomes. Of course, more often than not, Human-Centric Business Organizations that really believe in Equality, Diversity and Inclusion also believe profoundly in Human-Centric Agility[Link].

-- ❀ --

How on earth is Agile related to EDI?

It may appear that Agile and EDI (Equality, Diversity and Inclusion) have got nothing to do with each other! Most of the Fake Agile organizations fail to recognize that ‘Agile and Scrum’ and ‘EDI’ profoundly complement each other. What have Agile and Scrum got to do with EDI? Whether or not you apply and like Scrum and Agile, a profound focus on Individuals and interactions over processes and tools, and a habit of face-to-face communication generally help in breaking barriers. Habits built around cross-functional teams build behavioural muscles better to embrace diversity in many forms. Strong and valuable habits built around the values like Openness, Respect, and Courage help immensely (a) in understanding, appreciating, respecting, and embracing diversity, and (b) in speaking up and preventing discrimination of any sort etc. While, on one hand, it’s easier to support EDI where real Agile is in practice, it’s also easier to establish Agile where EDI has strong roots.

Measuring what matters less

It is not rare for Fake Agile organizations to rigorously measure what matters less. They invest a lot of human intellectual capacity, effort, time, focus, creativity and energy in measuring the low-level and internal details pertaining to Agile and agility instead of measuring the Outcomes of Agile and agility depicted in the Human-Centric Agility Framework[Link]. Again, in Fake Agile organizations, the general enthusiasm around measuring the lower-level elements of Agile is usually huge, and the amount of knowledge available around what actually needs to be measured as per the Agile values and principles is ironically usually very small. Also, a misplaced but tenacious tendency to summarize complex things down to a number or something similar, where that summarization is not exactly useful or meaningful, could be an important indicator of fake agility.

Simplicity is extremely difficult to understand

Fake Agile organizations without any exception always find it difficult to understand the value of simplicity - the art of maximizing the amount of work not done. They relentlessly try to do ‘more’ without stopping and really thinking to evaluate if that ‘more’ is really better done than not done!

Is absence of benefits not indicative enough?

If the typical benefits of agility are not actually realised, that must be an enough indicator of presence of fake agility. It's like, if you place your thumb on a concrete block and hit that really hard with a heavy sledgehammer, how can it so happen that you feel no pain? But, if you really don't, there must be something massively wrong - a fake hammer? Or a fake action of hitting hard? etc.

What has Theory Y got to do with Agile?

Fake Agile organizations prefer to maintain, and make their people work in an environment aligned with the ideas pertaining to Theory X (by Douglas Murray McGregor) instead of an environment aligned with the ideas pertaining to Theory Y - i.e., “Employees are internally motivated, enjoy their job, and work to better themselves without a direct reward in return”.

Can you smell ‘The Smell of the Place’?

It’s in the context of the concept ‘The Smell of the Place’ by Professor Sumantra Ghoshal. Most of the Fake Agile organizations fail to recognize the fact that “Revitalizing people has a lot less to do with changing people and has a lot more to do with changing the context - the smell of the place - which companies create around their people.”. It’s the smell of constraint, “compliance, control, and contract” as opposed to (a) an exciting set of values in which every individual, all the time, is trying to do more, rather than less (a ‘Theory Y’ behaviour), (b) collaboration supported by self-organization - which is generally powered by autonomy and freedom of individuals -, self-motivation, self-direction, self-management and self-empowerment, (c) absence of command and control, (d) coaching instead of coercion, and (e) trust and collaboration over contractual obligation.

Scarcity of Servant Leadership

Non-Human-Centric Fake Agile organisations prominently lack Servant-Leaders and servant leadership. It's pretty much a lonely planet if you are looking for Servant-Leaders within a Non-Human-Centric Fake Agile organization. Either those leaders never existed, or they did and got eliminated. Or, in some cases, servant leadership as a way of leading was smothered to death. Both Agile and Servant Leadership are extremely human-centric. Servant Leadership prospers in the presence of real Agile, and agility flourishes in the presence of Servant Leadership. One more important bit: ‘Just the Scrum Masters demonstrating Servant Leadership’ and ‘servant leadership embedded in the very culture of the business organisation’ are two very different things. And, of course, a Scrum Master who is not a Servant Leader is not actually a Scrum Master.

Note: If you think and believe that you know and understand what Servant Leadership is, please, please take a step back, honestly challenge yourself and take a close objective look at it. You believe it or not, there is a high possibility, well, actually a very high possibility that you really don't know what Servant Leadership is. And, this is especially the case if you have not gone through and fully(?) understood Robert k. Greenleaf's foundational thoughts that form the very basis of Servant Leadership which could help you become a better human being and a better leader to make this world a better place.

-- ❀ --

Acronyms: An anti-Agile fashion formula?

Typical Fake Agile organizations believe that use of a massive number of acronyms help them ‘become’ Agile. In many a case, Fake Agile and acronyms go hand in hand. Unless it's about communicating with machines, unnecessarily using loads of acronyms is not a great idea when it comes to commutation amongst and with human beings. Acronyms are a departure from the ‘true natural form’ of languages which is inherently the more human-centric medium of communication to express and interpret meaning. Even machines are getting better at ‘processing and communicating’ using natural languages. Acronyms add processing overhead and potential ambiguity to human-to-human communication. That makes it non-Agile, as it drastically diminishes the value of face-to-face communication. Heavy use of acronyms potentially excludes newer members in an organization from understanding communications in the best possible natural way or the intended way. Fake Agile organisations usually fail to understand how use of acronyms, buzzwords and jargons lead to wastage of human intellectual capacity, create communication barriers, and negatively impact inclusion. Seldom do acronyms, buzzwords and jargons help build trust.

Whether or not you recognize it, the cumulative negative effect of unnecessarily used acronyms within all the teams and organisations in question is massive. Acronyms are many a times used to project sophistication, expertise, class, and fashion. And, when it comes to written communication, writing is getting faster and more assisted, storage is getting dramatically cheaper by the day, and processing ‘written content’ is getting even faster thanks to the technological advances. And, you are still willing to continue using loads of unnecessary acronyms? Why?

Is Agile a funny business?

Many of the Fake Agile organizations and teams actually believe that Agile is all about funny Retrospectives, funny ‘looking’ Scrum Masters (yes, there is sometimes an expectation that the Scrum Master must look ‘funny’ or ‘cool’) etc. Again, it's about missing the forest for the trees. With real Agile, of course, work is more fun and enjoyable, and so are the Sprint Retrospectives. And, many good Scrum Masters happen to have a great sense of humour. Of course, the Scrum Team should improve its processes and practices to make work more enjoyable. Making Sprint Retrospectives fun and likeable for the Scrum Team is always useful. However, Agile or Scrum is not about just fun!

-- ❀ --

Conformance over improvements

Fake Agile organizations value conformance significantly more over improvements. And, people within Fake Agile organizations seek feedback from people with more 'power' - not just in the Sprint Reviews, but in general - just to look better, more agreeable, proactively conformant and compliant, and aligned, and not for genuine improvements.

Reports over Results

Of course, there is value in reports. However, it's always about a reasonable balance between how much you invest in achieving the desired 'Results' or outcomes, and how much you invest in 'Reporting' those 'Results'. Fake Agile departments and businesses waste precious human and organizational lives on getting reports written that nobody almost ever takes a look at. That check, that conversation, that persuasion-attempt never takes place to put an end to this massively wasteful behaviour. And, in most of these cases, there is usually a background of command-and-control-induced fear and lack of psychological safety. Fake Agile organizations fail to invest the ‘human intellectual capacity, effort, time, focus, creativity, and energy’ - which they usually spend on wasteful reporting and other similar low-value activities - on activities that usually lead to creation of 'real value'. There is no glory in making reporting grand and not achieving more of what is being reported. Achieving the desired results and reporting on those results are two different concerns. And of course, those two belong to two separate problem-spaces. Again, this leads us to that interesting question. Which problem do you want to solve and to what extent? Which one are you willing to invest your life and your organization’s life in? The more you spend on one, the lesser you are left with to spend on the other.

Cost over benefit (value)

In Fake Agile organizations, it’s not rare to find a stubborn focus on cost, and a very weak focus on potential benefits (value). Usually the discussion starts with cost and revolves around cost. 

If we try to compare that with the context of daily workout or exercise, it’s very similar to a rigorous and meticulous attempt at finding out the cost associated with the daily workout or exercise in question, and not getting started with a daily workout or exercise routine until the cost is not ascertained preferably in a quantitative form even though the potential long term benefits (value) pertaining to daily workout or exercise is pretty well known. It’s not hard to come across similar painful deliberations around implementing DevOps, automated testing etc., for example, within Fake Agile organizations.

The focus on cost has its place and significance. However, where the potential benefits (value) clearly far outweigh the ‘approximate’ cost and are profoundly obvious, this stubborn focus on cost is not always particularly useful. Fake Agile organizations measure work predominantly in time and money (cost). They categorically ignore human energy, effort, focus, creativity, attention, ease, feel, happiness (wellbeing) etc. associated with the work getting done. Those organizations are usually blinkered to the ‘whole reality’ and the big picture.

-- ❀ --

Wastage of Human Life and Organizational Life

If you are investing human intellectual capacity, effort, time, focus, creativity, and energy in activities that don’t generally lead to creation of 'real value', that’s actually not investment; that’s wastage. You are basically wasting precious human life. And, by doing so, you are essentially wasting organizational life, diminishing immensely what the organization could achieve within its lifetime.

Those people who have been the force behind these wasteful activities - whether they are aware of that or not, whether they acknowledge that or not - are profoundly guilty of wasting away human-lives and organizational lives. Non-Human-Centric Fake Agile Organizations, knowingly or unknowingly, deliberately or accidentally, nurture, encourage and strengthen those behaviours that lead to wastage of human and organizational lives. Usually, Fake Agile Organizations lack Human-Centric Ways of Working in particular.

Stress kills

Many of the inappropriate ways of working lead to a massive amount of avoidable unnecessary stress. Stress can and does kill people.

And, what is even more interesting is that the people who are usually the force behind these wasteful activities and unnecessary stress actually believe that they are really helping people and organizations achieve significantly more. They continue to stay with that belief because of their lack of awareness, knowledge, sensitivity, and experience around Human-Centric Ways of Working.

Are they trying to be horrible?

Let’s be honest about this. In most of the cases, people whose behaviours sometimes don’t look very appropriate in the Human-Centric Business Agility context, don’t have bad intentions. They are not trying to be horrible. It’s usually just their worldview and experience etc. that make their behaviours appear not-so-appropriate in certain contexts. And, sometimes, it's purely situational. And, in many other cases, it's a mere matter of ignorance rather than arrogance. What is really required in those cases is a bit of help along with forgiveness. Those people are usually as well intentioned as the rest of us.

-- ❀ --

Questions for you

It’s already a long list of issues, and it’s not comprehensive. Many of these abovementioned issues, in one form or other, could very well be found in business organisations that have got nothing to do with Agile in any form - Fake or Real. And, of course, the issues don't always surround the Scrum Master role only. There are usually equally interesting issues that surround the Product Owner role. Are you, as a business organization, going to wait for the ‘Agility Auditors’ to arrive? As a responsible business organisation, are you not answerable to the next generations? Those generations would inevitably and eventually want to know what on earth stopped you from embracing real human-centric agility to create a better future for everyone. Will you be able to answer that question if you are still around?

Hopes for the future

 

Customers and Business Organizations

It’s probably not just a hope. Rather, it is a possibility that going ahead, customers will place an explicit expectation that they would like to do business only with business organizations who promote, apply, and demonstrate Human-Centric Business Agility. It's going to be about 'responsibly sourced products and services'!

Agile Frameworks

There is a hope that the present and the future Agile Frameworks will:

• Make explicit, bring to the forefront and strengthen their focus on the very basics of Agile and agility, which have been buried in misinformation, misinterpretation, ritualization, 'keeping things implicit', excessive commercialization etc.; so that, there will be lesser room for misinterpretations, misinformation etc. Those ‘basics’ have unfortunately been lost, diluted, forgotten and ignored to a certain degree over time. It's about getting the basics right again and making the basics explicit again!
• Have a particularly explicit and clear inherent focus on Ethics in terms of its generic and the broadest possible meaning; and make Ethics an explicit essential part of the frameworks.
• Not just associate Servant Leadership with or confine that to any particular role (or equivalent) pertaining to the frameworks in question, but will (a) make Servant Leadership an explicit essential part of the very frameworks and (b) aim at and facilitate embedding Servant Leadership in the organizational cultures.
• Have a particularly explicit and clear inherent focus on fighting Fake Agile; and make fighting Fake Agile (a) an explicit essential part or feature of the frameworks and (b) a requirement and an explicit expectation.
• Have a particularly explicit and clear inherent meticulous focus on 'prevention of wastage of human lives and organizational lives' (described in the Wastage of Human Life and Organizational Life section above) ; and make 'prevention of wastage of human lives and organizational lives' (a) an explicit essential part or feature of the frameworks and (b) a requirement and an explicit expectation.
• Have a particularly explicit and clear inherent meticulous focus on Human-Centricity in terms of its generic and the broadest possible meaning; and make Human-Centricity (a) an explicit essential part or feature of the frameworks and (b) a requirement and an explicit expectation.
• Have a particularly explicit and clear inherent meticulous focus on 'embedding Agile in the organizational culture' (as anything embedded in the culture persists and becomes a part of the greatest force within any organization); and make 'embedding Agile in the organizational culture' (a) an explicit essential part or feature of the frameworks and (b) a requirement and an explicit expectation.

Community of Agile Practitioners

If you are an experienced Agile practitioner, it's a hope that you will voluntarily do your best to help individuals, teams and organizations in their Agile journey in the best ways possible. So that, they are able to derive the best of the benefits possible; and all that leads to 'Better Lives', 'Better Business Results' and 'A Better Society'. It's not going to be exactly easy, of course. But, that would definitely be your best service and contribution to Agile and agility.

There is a hope that we, as a community of Agile practitioners, will continue to help each other in strengthening ‘Agile ways of working’ that lead to Better Lives, Better Business Results and a Better Society, where it’s not a case of ‘one at the cost of other’. We mustn’t have to drop one to pick another. We, the practitioners, will be able to embrace all the advancements achieved so far around Agile and agility. And, we will be able to fall back on our collective community wisdom and experiences.

Every Agile practitioner has a fair share of ethical responsibility for contributing enough towards making the ‘world of work’ a better place. There is a hope that we will come together to make that happen.