What Can Go Wrong While Following Agile Methodology

Introduction

Most of the Job Postings you will see will have the term Agile Process mentioned somewhere in their Job Description. If you talk to Developers or Managers in your network, most of them will tell you that their teams are using Agile Methodology. So I believe it is fair to say that the term Agile Process is trending nowadays in Software Industry, and using Agile Process in your team is as cool as using AI/ML in your code. Agree? If your answer is yes(even mine is) then that is where the problem starts. When something is cool then people want to adopt it as quickly as possible. As we know that many companies which claim that they are using cool ML/AI algorithms in their code are just using if-else statements behind the scene. The same is happening with Agile as well. Out of all teams who claim to follow the Agile process are far enough from the process and just stuck at a place where they are not getting any advantage of Agile.

Prerequisite

This article is helpful for you if you have an understanding of Agile Methodologies, and your team is already using Agile Processes.

Reasons Why Agile Methodology Might Not Be Giving You Expected Results

Let's discuss a few mistakes that companies and teams do while following Agile Methodologies. If your answer to any of the below questions is yes then it is the time you need to work on improving the Agile Process being followed in your team.

Are You Jumping to Implementation Step Without Giving Much Importance to the SDLC Phases Before That?

Having small iterations and releasing changes to customers is one of the key points of Agile. This provides a great benefit of quick feedback from customers, so that if there is any gap between expectation and outcome then it can be identified at an early stage. However, sometimes teams misinterpret this and think that as they have the leverage to get feedback quickly so they should start working on implementation without putting much effort into requirement gathering, analysis, and design phases. This results in disaster when with time the project becomes unmanageable and no one has an idea of what needs to be done, how much work is pending, and how much is completed.

Suggestions for Improvement:

The SDLC rule for Agile is:

• An Epic should have a clearly defined requirement document,

• Except for Spike, and POC, all other User stories should be backed by a design document.

• The DOD of User stories should clearly achieve one or the other goal of Either a design document or a requirement document.

Does the Owner of Tasks Responsible Decide the Story Points of That Task?

Though it may look very small thing but not standardizing story points can impact not only your project delivery deadlines, but can damage your team's work culture to the core. Many teams believe that the owner of the task knows the efforts needed to complete the task so they are the right person to assign story points to the task. Though this looks right at first look, it causes issues as well. Let's understand this with a few of them.

• As story points assigned by one person would not work for another, such assignments would create a high coupling between the task and point assignee.

• There can be scenarios where a task can be done in a day by person A but person B would need 5 days to complete that task. So the performance of person A is 5 times more than that of person B. But if both will have the freedom to assign story points for the task which they are doing, then person B will assign 5 times more story points than person A, and if no scrutiny is in place then you will never be able to find the performance difference between person A and B.

• The completion of the project would depend too much on who is handling the project than what is the complexity of the project.

Suggestions for Improvement:

• Story point assignment is not an individual task. It is a group activity.

• The best way is to involve the whole team(or at least key members of the team) and ask them to provide the point estimation.

• After getting the estimated points, a team can choose to take the maximum, minimum, or average of all estimates.

Do You Believe That Closely Monitoring Story/Task Creation and Closing Is Waste of Time?

If Product owners and Engineering Managers are not monitoring new tasks added to Epics then it can lead to chaos and directionless progress of Epic. If stories do not have a proper definition of done(DOD) then those are going to contribute just to hide the inefficiency of the team. Let's understand the reasons why you must have monitoring on stories creation and closing.

• Not everyone in the team would have the same level of understanding of Epic and unscrutinized stories may not have the right context, connection with other stories, and meaningful definition of done. Such stories would contribute to nothing but confusion at the time of backlog grooming in evaluating Epic status.

• If multiple persons are creating the stories in an epic without coordination, then there is a chance of stories being created with duplicate/overlapping DOD. This will result in duplicate efforts by team members.

• Though in an ideal world we believe in the best of intentions and think that everyone wants to work for the success of the team and project, let's accept this with a pinch of salt that not everyone in your team would be equally motivated. It's not uncommon to find intentionally created stories that do not have clear DOD or are duplicate DOD. Such stories would be used to mark the efforts in a sprint without putting much effort into them.

Suggestions for Improvement:

• All stories which are getting created and closed have to be reviewed by either the Engineering Manager or Product Owner of the team.

Do You Think Sprint Retrospective Are Unnecessary?

Retrospective meetings are important to the Agile process as Health Checkups are for us. These are like health checkups. If you are going for regular health checkups then you will be able to identify abnormal behavior in the body at a very early stage and live a healthy life. Similarly, if your team is taking retrospective meetings seriously then you will be able to find any anomaly in the agile process at an early stage. If the answer to any of the below questions is yes then you can consider that you are not using these meetings efficiently:

• If any story is not completed in a sprint, then in place of discussing the reasons in detail your team just moves that to the next sprint or in the backlog?

• If DOD is not completed for any story, then you just close that story to mark the efforts and open a duplicate story for the next sprint?

• You don't revisit every story and compare story points assigned to the stories and actual effort invested in stories?

Suggestions for Improvement:

The following points have to be covered in retrospective meetings.

• Analyze how many stories took more or less effort than the estimated effort, and why that happened. This helps in correcting effort estimates in future sprints.

• If there are incomplete stories then analyze the reason behind that. For example delays due to other teams, unclear DOD, and unknown changes come while implementing the changes. This helps to identify which previous phase(requirement gathering, design, etc) needs improvement.

• If there are stories where some effort has been put in but the story is not yet completed, then change the DOD and create another ticket with an incomplete DOD. This action should have been taken only after getting the heads-up from team members including the Engineering Manager and Product Owner.

Conclusion

I have tried to cover the main reasons why following Agile Methodologies results in decreased efficiency of the team and provided suggestions to improve them. If your team is not committing any of these mistakes then congratulations, you are using the Agile Process in a manner it is expected to be used. If there is any point that you believe your team is not following then just try to follow the suggestions provided to improve in that area. I am sure you will love the results.