Agile is fragile. Handle with care !!!

This article going to be little longer and a bit offensive as well.? So if you get easily offended please raise your hand and “Bhangda pawoji fir”

Have you ever been to those motivational conferences where one over-enthusiastic person shouts on top of his head on the stage and everyone watches him mesmerizingly? His energy is contagious. He tells you great stories, talks about failure as a stepping step to success, etc. But they all have one common line/theme which goes something like “Believe in yourself and just repeat, Yes, You can do it”. I have been there once. It was the time when the "Dhoom" movie was released and those superbikes were the dream of any bachelor. The motivator made his pitch so passionately that by the time his speech was over I started believing “Yes, I believe I am John Abraham”. Now, I was 62 Kg in weight and 6 feet in height at that time. Anyone can count my rib bones from outside and still, I dared to think I can be John Abraham. Nothing wrong with that, right? Well, one needs to understand John given his life for health and fitness, and on the other hand, I watch the pogo channel for hours because the remote was 6 feet away from me. Just because of this belief I went to Gym and on the 4th day, I tore my ligament.?

So, what is its relation with Agile? In my view, these motivational coaches give you half baked picture. I mean no matter how hard Rajpal Yadav tries, he can’t be Khali. They forget to tell you that you need to assess where you stand and then start your journey. Now, many in the audience for some reason get carried away and later become entrepreneurs, leaders, developers, Product Managers,s, etc. and they just think. “I have to believe that Agile will solve all problems”. They didn’t realize how injurious it is for them and the organization.

So, What is wrong with all these over-enthusiastic people? How in the name of agile they are hurting organizations? Let's first start with defining what Agile methodologies mean. There is literally so much verbal diarrhea on the internet that google might spend 20% of their computing on indexing the Agile Gyaan.

For me, it is as below.?

Agility is an ability that allows you to change direction with minimum impact on momentum. The process which utilizes this ability of people in delivering things in incremental order is the Agile Method

By no means, it is accurate, and nor do I claim so. But it served my purpose for a long time. Now, Let's understand what is wrong with applied Agile methodology in many places. Imagine you have to start a new project. You had a management level meeting where you committed your customer that, yes, we can do it. You immediately assemble a team. 4 Junior, 2 Senior developers, 1 TL, 1 EM, 1 Solution Architect, 1 TPM, and 1 Product Manager. The ideal pizza team. Now let see how these people are (I went through all these phases)

• Your 2 junior team members are fresher and they are still in awe of the cafeteria. They still figuring out how the hell reverses SSH tunnel work and where to get access for production machines.
• Two seniors developers who just read some design patterns. They already started believing how shitty architecture they are working on. Who were those idiots who written this code?
• Your TL is sitting silently and figuring out, “Friday to chal raha tha, Monday ko kya ho gaya”
• You EM is like, Been there, seen this, F**k it, one more shit to take care.
• Your PM with steve job wallpaper on his laptop and lost in UI and following some random product gyaan medium article. He is in clear belief that changing this button color and its position on this portal will solve all his ARPU and some funnel ratio problems.
• TPM is writing one more mail about ETA cribbing about developers, who told him that they don’t know the issue and have no idea by when it is going to get a fix.
• Solution architect who figuring out how two rectangles joining with a dotted arrow will reduce the overall cost. :)

They all are hard-working people, experts in their own rights. But when they decide to adopt Agile fashion (I don’t know when we started calling the method fashion :) ) they do this. First, create EPIC, then start putting stories in JIRA, setup up sprint grooming and Retro session in their calendars, and schedule standup meeting at sharp 11 AM and BOOM …. We are Agile now!! Yippyyyy.

There is one last thing we need to cover before going further. Let's try to see how this project can be delivered in two different models with the same set of people.

Delivering in waterfall model

In the ideal case, this is how the waterfall model looks like. The three major issues with the waterfall model are

• By the time you deliver the requirement, it is already too late.
• There is no mechanism in place to cater to the changing requirement.
• Having clearly defined boundaries results in a very rigid system. Changes in such systems (either team member skill sets, mentality, or system itself) become complex and tedious.

But the advantage is clarity to people who work on it. There is a pre-defined handshake and most requirements are frozen before design and development start. This makes it very predictable.

Now Agile FASHION Model

We have the same requirement as above and the same people working in the team. So they do exactly the same things but faster as they have a smaller window for deliveries (fondly know as Sprints).

La la la la lallaaaa.. la la..la la la... First 10 sprints no one has any dam clue what they are building. By the time they realize they try to mold it in their own way. Finally, they sort of delivering something similar(Maybe not).

This mirage gives the impression that we are building fast but what we are building is something we still have to wait for eternity.

Executing waterfall model in every sprint is not funny.

by Shri Hritik Roshan in ZNMB

Few point to note here

• It is like a suspense thriller for customers. They can never guess what we going to deliver.
• No one guesses what will the end product because we are designing incrementally.
• Difficult to provide feedback as there is no functional thing to test.
• Everyone is working hard and sometimes overtime to deliver this thing without knowing what they are doing.
• Again if you see everyone working in isolation as there is no overlapping and discussion about the final product. It is not required as you can see from the picture.
• Everyone thinks other is taking care of final outcome.

It's like building a house with legos. Each block is of definite shape and can be tested for its quality but doesn't make sense unless all piece put together.

Now let see how it's creating chaos in your organization and what you need to do to stop it. There are two major areas that get impacted.

1. People
2. Culture

People

• The team will always remain in constant confusion as they do not have the bigger picture in mind.
• There will always be planning issues as all team members were never get involved in every phase of sprints.
• Having fix window of deliveries create unnecessary pressure on team members either to deliver sub-standard quality or subject them to burnout.
• The Product Manager will never know what will be wrong with the final product and where he needs to intervene.
• The architect will be clueless and do not understand what went wrong even though every piece was as precise as it can be.
• TPM will always be in a constant hustle to resolve collaboration issues, replanning and asking unnecessary questions.
• They all will learn that agile means building fast.

Agile doesnt mean building fast. It mean try to maintain your momemtum while adapting changes.

How to control it?

1. Have people in a team who have overlapping skills. You do not want the Product manager to do something which the developer does not understand. The Product Manager might be an expert in customer experience but Engineer/TPM/EM needs to fill in the shoes on regular basis.
2. Look for the team member's elasticity. Do not allow them to interfere in every area. Best to restrict them to 3 or fewer areas. Having more freedom can lead to different problems.
3. Agile needs frequent direction change and dealing with ambiguity. This seriously frustrates the team members and burnout them very fast. It's like footfall where experience players know where to pass the ball and when other members can reach there when the time comes. If you are not in their league or trained enough, you are bound to injure yourself and your team. So hire the right set of team members. Remember, One should be seasoned, resilient and adaptable in such delivery models.
4. Last and could be controversial but do not try to sync release and sprint cycle. Also do not always try to have a sprint of 2 weeks. These are not fundamental constants. Choose wisely based on the granularity, nature of the project. I mean by some people's logic we can have 5 sprints in a week. Remember the thumb rule

Only release the features which can be tested by customer without your zoom call .

Cultural

There are a thousand issues that can breed up. Just want to mention the top three here. These issues will seriously damage the culture in your organization.

• Given this agile fashion model leads to an isolated execution it discourages collaboration. This leads to less trust in people and more finger-pointing.
• Less innovation and problem-solving appetite. Not having overlapping skill lead to very less or no challenge by your peers or juniors. This leads to a narrow point of view and stagnation in learning.
• Given everyone work hard but delivery is not as per expectation, performance management becomes the ground of favoritism.

If your employee are constatnly complaining about firefighting chances are you are executing project in agile FASHION

How to control it?

1. Make sure the team has a clear long-term goal. There will be the shift of goalpost by margin but Don't make goalpost shift 100 yards every week. This you can do by involving the team at the start of projects and "Explaining to them what you want to achieve rather than telling them what you want to achieve".
2. Make sure you build a culture where people can understand the difference between lack of clarity and dealing with ambiguity. Dealing with ambiguity doesn't mean you don't have clarity at all. It means you have multiple hypothesis and which will work is still not clear.
3. Let team members fill each other shoes in sprints and note down their feedback. Take them seriously and convince them if you don't agree with some data points.
4. You must have some boundary line defined in your execution model. Leaving them in the open field makes them directionless. You can do this by putting constraints like Budget, Process, Meeting duration, etc.

Let's now imagine How it should be done.

Here every sprint planed has a defined goal and functional release which can be validated and tested by customers. This also given clarity and a sense of achievement to the team about what we are building. Note- The team still had to deal with ambiguity.

Building in an agile way is fragile in nature and needs to handle carefully. It requires high collaboration, the right balance, and a sustainable amount of heat to achieve the result. Lacking any of it will hurt your organization in multiple ways.

Build fast and fail faster is fine, but build what and learn what from failure is equally important