The Ego vs Agile Methodology
Agile methodology has spread globally into many project-based work environments. However its practitioners do not often account for the conflict between its key tenets and the tendencies of the human ego. In my opinion, to implement agile successfully, its practitioners need to be aware of this conflict and develop ways to deal with it.
What is the Ego?
If you Google the definition of the ego the search results are: ”a person’s sense of self-esteem or self-importance”; “the part of the mind that mediates between the conscious and the unconscious and is responsible for reality testing and a sense of personal identity.”
The ego is simply a person’s self image, consciously and unconsciously and is formed over a long time. It is developed consciously but subsequently operates unconsciously.
There is nothing wrong with having an ego. Practically everyone has an ego and the term “I don’t have an ego” is technically incorrect. Almost every sane human being has some sense of “this is who I am”. The ego’s main function is to enable us make quick decisions based on who we each believe we “are”. So if you believe you are fundamentally an “honest person”, when you are asked a question you will quickly and easily choose to answer it honestly and would actually have a difficulty choosing to lie. Any suggestion that you are a liar will also bring a sensitive reaction as it contradicts your self image.
The problem with the ego is often when people have either a “very sensitive ego” or an “inflated ego”. A person with a very sensitive ego will get very offended when their self-image is challenged or contradicted. If they believe they are the smartest person in the room, and that self-image is sensitive, then any fact or opinion that suggests they are wrong will not simply hurt their ego it would inflame it. Similarly a person with an inflated ego, that exaggerates their positive qualities or underestimates their negatives, will easily get offended when there are facts or opinions to the contrary i.e. that they are not.
Often, a person with an inflated ego also has a very sensitive ego, but this is not always true.
What is Agile?
Once again let’s, for simplicity, rely on Google. The search engine says “Agile” relates to or denotes “a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans”.
Agile methodology is thus built on accepting ambiguity and frequently adapting plans.
Before Agile became popular, projects were predetermined before commencement and then rigidly implemented. Project teams would spend a lot of time and resources gathering “requirements” and creating a “final” project plan, Then the project would commence and the plan would be implemented until it was “done”.
Too often however, the client or user would receive the “done” project and realize their “final” requirements were inaccurate. Then the project would wind up needing to be “redone” resulting in massive WASTE of time and resources.
Agile methods are built on the insight that there is inherent ambiguity and that flexibility is valuable. We simply CAN’T know the answer until the project is done, but we can find out by asking a lot of questions and testing out hypotheses quickly.
The Agile way of doing things borrows from many manufacturing innovations designed to eliminate waste such as kaizen and lean manufacturing; these are iterative and flexible innovations. It therefore seeks to eliminate wasted time and resources by adopting flexibility.
Project requirements are taken as ambiguous from the beginning — as merely hypotheses of what the answer is. The agile team selects hypotheses and builds inexpensive and quick “tests” to prove or disprove these ambiguous hypotheses. In some cases, these tests require prototypes. Resources are deployed as minimally as possible, and fidelity is not a priority. The goal of the iteration is to minimize risk by gaining more clarity and reducing ambiguity.
Sometimes a decision could even be made to abandon the project entirely based on the results of these interim tests, Though more often tests result in an adjustment or pivot.
The point is, with agile, the premise is “we don’t know but we will test”. Ambiguity is constant.
The Ego vs. Agile
Now that we have looked at both, let’s look at a few examples of how the ego’s tendencies are misaligned with the tenets of Agile methodology
And these are only a handful of examples of misalignments. If you ask an Agile or scrum coach or practitioner, they have probably witnessed the ego’s tendencies conflict with the practice of Agile either by themselves or by another project teammate. Sometimes it’s the client’s, or user’s, ego that creates the conflict with Agile.
Since I am not a trained psychologist or therapist, I will defer to those professionals when it comes to prescribing solutions to dealing with human ego’s.
However, I believe awareness and understanding of the ego is half of what is needed if anyone wishes to be effective practicing or implementing Agile methodologies. I believe Agile practitioners ought to take time and become aware and versed about the ego; what is it is; how it tends to operate and how to deal with its issues when they are using Agile to deliver a project.