Why agile is struggling in India - Complete Article

There are too many failures in agile development in India. It is way too far to measure the failures.

Though some projects looks “complete” there are some “but” expressions can be identified.

· What was built was not the customer wanted

· The quality of product what we built was poor

· They took far too long to build

Here is the big question. How can one approach work magic for one group and fail miserable for others?

I tried to probe deep into this issue.

Fake Agile:

In most of the projects, the outfit looks like an agile but the person inside the outfit is really not. Agile has its fair share of skeptics and detractors. These are people who have a much different Agile experience – one characterized by chaotic processes, lower quality, miscommunication and numerous other problems. As you might expect, these people tend to have extremely strong opinions on what they consider to be the shortcomings of Agile.

Here is the example from the software testing blog:

“This system is bloated with meetings, excel spreadsheets and anemic of any real documentation. Agile and the people who support it are full of themselves and their aversion to documentation is detrimental to real active communication. The disinterest to documentation presumes humans will retain meeting to meeting barrage of verbalized ideas. Agile is full of egotistical self congratulating ideologies over used buzz words like “flexible” and “living”. People can’t remember what they said from one over stated meeting to another.”

Old habits die hard:

Based on my observation, agile seems to “fail” whenever it is forced on a team or organization that is accustomed other methods. In India, the transition from conventional method to agile is not smooth. Many people assume that agile is faster, better, and cheaper, actual results vary greatly. Many organizations are diving into the Agile movement without a clear understanding of what it is, and what the consequences of adoption may be. There was a survey conducted with 200 participants. 64 % participants said that Agile development was harder than it was initially seemed. 40% of participants found no obvious benefit to the practice.

The process of “going Agile” must be clearly explained and outlined (more on this shortly), otherwise your development practices will change, but in name only.

Many projects are attracted towards the idea of frequent delivery. It is basically a waterfall behaviour hiding behind the new suite ‘Agile”

It is not enough to change the jargon but is really required to change our way to collaborate.

The deep down objection to agile in India is, it challenges our hidden assumptions which we cherished as “best practice”. A developer may cherish his best practice by delivering stable & testable code to QA on time. So from his perspective, it is tester’s job to efficiently find all the bugs which is considered best practice by a tester.

But agile development is challenging these “best practice” assumption. On agile teams, we prevent those bugs by specifying the feature as a team using testable examples, and then we build those behaviours in small slices. Now the developer must break the best practice what they conserved for years together. When he/she fails, agile development fails miserably.

Mind set and culture:

An another reason why agile is struggling in India is because of unrealistic expectation. What we believe commonly is that agile is a process, a set of practices & tools. But in fact, it is really more of a mind-set and culture

Process is depends on the company, the product & the personnel. So it is expected that when it misapplied, it will fail whereas mind set & culture can transcend those factors.

Would we take a same approach to develop a web page & a complex scientific application? Certainly not. Would we take a same approach in a team of 6 members that we would with team of 60 or 600?, Likely not. Different situations obviously call for different approaches.

It is easy to see that we need to take different approach developing a web page as compared to developing a complex scientific application. We must recognize that there is a difference & must follow 2 different approaches. A very simple process is sufficient to develop a web page whereas more complex & rigorous methods could be appropriate for scientific application.

· A team new to iterative development commits to finishing 5 stories in 2 weeks. At the end of the 2 weeks only 3 are done. But instead of confronting the failure and learning from their mistake they congratulate themselves on completing 3 and then have the next 2 automatically go into the next iteration. Or perhaps they decide to add a week to the sprint to claim success because failure is too painful and unsafe to accept and confront. The opportunity to learn from their failure is lost and one of the main feedback loops in iterative development is disabled.

· A team in a meeting are sharing what they are working on, and one developer shares a block that it has been difficult. Another one scoffs at this and says “I can’t believe you’re stuck on that; it would have taken me five minutes.” That team member and many others now are emotionally unsafe and will hesitate to share in the future and cover up their difficulties and failures. Little learning and innovation can happen on this team.

Developers on a team are working on multiple tasks and doing their best to reduce work in progress by working on one thing at a time. Their manager is in a hurry and keeps asking them for status on different tasks. If it were safe, they would have a conversation with their manager describing their situation and continue on their path. If they were not, which is often the case, they will drop what they are doing and work on whatever the manger is focused on now. The inability of the manager to experience a perceived failure in lack of progress on multiple issues has led him to pressure his team. And their lack of safety with their manager has kept them from performing the most effective actions for the team.

A team fails to improve the quality of their software in an iteration and many defects escape. In the retrospective, many on the team are blaming each other or justifying that they can’t do the right thing because it would take too long. Their lack of personal safety in admitting failure of a task is keeping them from examining the failure together and learning from it.

So to crystallize,

· Teams new to agile methods need to be safe enough to be able to learn from failure.

· Agile methods throw failure in our face at every single turn giving us the potential for accelerated learning.

· That failure itself makes us feel unsafe and inhibits our ability to learn from our failure.

· Agile doesn’t come with built-in safety mechanisms.

· And if we want better results we need to find ways of creating safety as a platform for agile adoptions.

If we expect agile to perform, miracles, or instantly transform our software development process, then we might likely to see the major failure

Department Fragmentation:

Team is more powerful part & most essential part to have successful agile development. It is completely wrong to say that “We have an agile test team”. If all they do is test, then it is really not agile. The team factor is fragmented here.

What if the agile principles are followed by team of all but not by QA? What if the testing team member wants to participate in early development process & what if the technical team resist?

Agile teams frequently deliver high quality software, and that includes testing. An agile ‘feature team’ needs all the skills it takes to deliver software, and that includes programming, analysis, and testing skills, regardless of who performs these tasks

Mature agile teams know there isn’t a sharp line between ‘my job’ and ‘your job.’ There are just tasks we need to complete, and everyone brings different skills to the table, so that we can complete them as a whole team.”

As mentioned previously, Agile is not a playbook. It’s not a set of directions. It’s not a checklist. It’s a mindset and a culture – and it needs buy-in across an entire organization in order to succeed.

Not Iterating:

Iteration is the key value that the agile development brings to the software development. What we think of iteration, we break the project into 2 weeks of sprints or iteration. It can facilitate the iterative development but we are not actually iterating.

The key of iterating is developing a product a little bit at time. It would be accurate to describe the process of iterating on a product as evolution of a product. It is universal fact that things change gradually over a time. Those small changes add up to a result in a big change.

How drastic it would be if the evolution worked the way most agile software built? Imagine, if you will, a fish that swims in the ocean and has some little fish babies that are born with fully functional legs. Then, those legged fish babies grow up and have fish babies that have wings. The additional features would not do any good to them nor would they be designed properly, because instead of adapting and changing over time, they just suddenly appeared.

Features should not be built in a single sprint or iteration. It is as silly as legs showing up on a fish in a single generation.

Instead, features should be evolved and grow over time. A feature shouldn’t be pushed into a single sprint or iteration and then be done. A feature should start out small and develop and evolve over time as feedback is received and customers or the product owner tries it out.

Far too many times, I see Agile development projects mistake having iterations with actually iterating the development of the product.

Don’t try to ship a completed feature at once, let it evolve over time.

Fat logs:

It is very important to breaking things down into small, easily digestible pieces.

The main reason why this is so important is because it prevents procrastination. Procrastination usually occurs when either we dread some large task that will be difficult or we don’t know what to do next.

If we can break a big project up into small parts, it will seem easier to accomplish and will have clear steps of progression.

In some software projects where the person creating the backlogs or work items is not considering the work enough before giving it to the team.

Fat logs are backlogs that are not broken down small enough and often are very vague in what needs to be accomplished.

Fat logs are notoriously difficult to estimate and waste time when trying to explain and understand them. It is critical that fat logs be broken down into smaller actionable backlogs before being given to an Agile development team or a large amount of time will be wasted.

Not letting the team to be a team:

There are many dynamics that affect how teams act and interact. There are many ways to foster a healthy team and many ways to create unhealthy teams.

A healthy motivated team has synergy; a unhealthy gaunt team can be less effective than all of its members are on their own.

The key to having a healthy motivated team is letting them be mostly autonomous. Regardless of your political persuasion, you would probably agree that when a country invades another country and sets up an unelected government to oversee the people, there are going to be problems.

The same thing happens in agile development.

It does not mean that they shouldn’t have accountability. But if you want to run a software project in an agile way, you have to let teams self organize and self manage to some degree.

When big brother is always watching and interfering, team dynamics become very different. Naturally, teams usually develop their own cadence, leadership and roles which is called norms. However, when outside forces directly interfere with how the team does things, and they don’t have the power to decide their own fate, team members begin to realize that they need to look out for themselves.

Conclusion:

The struggle of agile in India can be changed if we are ready to accept the transition; if we are ready to be really agile by changing our mind set and culture; if we are ready to acknowledge and learn from agile failures; if we are ready to increase the synergy by working as a true agile team!

Abstract:

There are too many failures in agile development in India. It is way too far to measure the failures. Though some projects looks “complete” there are some “but” expressions can be identified. Here is the big question. How can one approach work magic for one group and fail miserable for others? I tried to probe deep into the struggle and identified that we are not really agile. I coined the term fake agile. We are hidden waterfall in a new jargon “Agile”. We are attracted towards the jargons “Frequent delivery” without understanding what is real agile. We expect agile to perform magics. When we consider agile as a process or set of directions then it is obvious that it will fail when misapplied. The true agile is really a mind set and culture of people. This factor will transcend the other factors such as the company, the product and the personnel. It is more interesting that agile is actually challenging what we cherished as our “Best Practice” for years together. Agile throws failures right on our face. We are not really to learn from past agile failures. Another major factor which causes major struggle in agile development is that we are not really iterating. What we assume iteration is breaking down project into 2 weeks of sprints or iterations. But we forgot that agile is gradual and incremental as evolution. We actually create fat logs. Fat logs are backlogs that are not broken down small enough and often are very vague in what needs to be accomplished. We are trying to ship a completed feature at once. The team is the vital force in agile. When someone says “We have agile test team”, the fundamental of agile synergy is fragmented. What if all team members follows agile principle but not the QA? What is the QA wanted to be a part of early development process but the technical people resist? The struggle of agile in India can be changed if we are ready to accept the transition; if we are ready to be really agile by changing our mind set and culture; if we are ready to acknowledge and learn from agile failures; if we are ready to increase the synergy by working as a true agile team!