Agile Illusions

In the era of buzzwords and information overload, it is easy to be confused and overlook the connotation and essence behind the jargon. Based on the conversations, I have had in the last few years, I have realized that one of the popular slang called Agile, has led to a few illusions among the beginner practitioners or aspiring students. I also understand that there are way too many agile misconceptions to count, but I have listed the 5 illusions that I think are common:

Illusion 1: Agile is a magical potion.

Agile is not magical. One is likely to fail to the same extent in agile as in waterfall. There is nothing special about agile that it would solve our problems that something else (agile’ s alternative) can’t. I have seen outstanding waterfall teams which deliver better outcomes than mediocre agile teams, only because of proper administration of the process. At the end it all comes down to the team and the people who are part of the team. They balance, integrate and apply both agile and non-agile processes to meet the requirement from time to time. It’s not magic, instead its pragmatic.

Illusion 2: There is a right size for a user story.

There is no one size fits all. Every team has a different measure of what the right size of a user story is. Usually I have followed the acronym INVEST to guide me to size the user story but based on experience, I have seen that the size of a story is based on the knowledge and experience of the development team working on it. If the team lacks domain knowledge, the user story becomes bigger due to additional details, which eventually helps the developer working on the story card with context.

If the team is experienced (with the domain knowledge and number of years of development) they don’t usually need detailed explanation of each user story or the acceptance criteria. The same logic is applicable to estimating the user story as well (but that’s out of scope of the topic of this article).

Illusion 3: There is only one right way of doing agile

Wrong. There is no single right way of doing things in an agile way. Some teams prefer Kanban, others do Scrum. A few who want flavors of both use ScrumBan. The style of agile the team follows depends on the team, the team’s requirement, the business unit, the organisation and the organisational strategy and goals. The guys at Spotify were not happy with the existing flavors that the so called agile offered. So, they created their own. Now this model inspires others. A few places I have worked add new agile practices to already existent traditional waterfall processes. It has worked wonders for them. In reality, the teams/organisations must identify the reason why they need a change and once they identify the real reason behind the transformation, it will be relatively easier to pick which flavor of agile will boost the business agility the most.

Illusion 4: I do stand-ups, or I have a certification; I am Agile.

With the advent of the new lingo of Agile and DevOps, it is not crystal clear of what they represent and the individuals have a few fables that follow. Agile is something that is not mastered by just doing stand-ups or reading a book. Even though these two are an integral part of the entire process, but doing only just these does not guarantee the transformation. Merely reading a book doesn’t compensate the importance of hands on experience that is important for comprehensive understanding of the fundamentals which help facilitate the agile mindset and help with the organisational transformation beyond being just some argot. Having a certification is a good thing, but just having a certification without the practical hands on experience would not do justice to enabling the agile mindset.

Illusion 5: Agile must be implemented in a big bang transformation

There is always an element of risk involved when an organisation that does not practice agile, tries to follow the trend. The risk is even greater if they plan a big bang approach across a large portfolio or programme or the entire organisation. Based on what I have seen and experienced, the employees of the organisation continue to do the same things they did before with a belief that they have become agile.

Business transformation is a slow and evolutionary process which involves change in policies from the managements’ perspective and change in the ways of doing things from an employee’s context which is sometimes filled with resistance if rushed too quick. Hence, a big bang transformation is not the best way to go forward. 

A famous quote from Albert Einstein, “Insanity is doing the same thing over and over and expecting a different result.” summaries why some agile transformation fail. The staff is doing the same thing they did before but expecting different and better results.