When should you consider moving to agile?

 

“Perfection is not attainable, but if we chase perfection we can catch excellence.” – Vince Lombardi

As far as traditional software development is concerned the waterfall model is considered to be one. It had been seen agile has been the most popular SDLC model adopted worldwide in the last decade. Teams have seen immense benefits by shifting their project management strategies to agile.

Transition is always difficult especially when you have been habitual to one thing for a long time. There are multiple reasons one can consider while moving to agile, but like there are certain pure objective reasons, there are certain reasons which do not consider an objective but influence the project anyway. In this article, I have tried to touch upon such reasons which could be flagged for the transition. 

Let us dive in...

1. Poor Requirement:

Stakeholders and/or requirements engineers sometimes incorrectly assume that a common way to implement a requirement is actually the only way to implement the requirement, they confuse the implementation with the requirement and inappropriately specify how to build the system rather than what the system should do or how well the system should do it.

They specify them in a very vague way.

If your requirement contains words like “Easy to use”, “Robust”, “Faster”, “Many”, etc. how are you supposed to test and mark it as passed or failed? 

A classic example of an ambiguous requirement is “

The system must have a USER-FRIENDLY user interface”. 

“USER-FRIENDLY” for someone might not be the USER-FRIENDLY” for someone else and is very subjective.

Since traditional project management is supposed to have all these requirements in the initial phase, it becomes very difficult to understand while implementing the idea of requirements. If somehow the developer manages to do so it is next to impossible to change them at a later stage.

It is neither a wise thing to do effort-wise nor financially.

Hence until and unless product owners are quite sure about your requirements and exactly know what they want and the workflow of the product is likely to be rigid it is the best option to go for agile. 

When you have the flexibility to do changes which by the way is the most emphasized section of the manifesto which adopts change, you could not find more right choice than agile.

2. Unrealistic deadlines:

Business representatives do not necessarily understand the extensive process of software development. They do not know how much time does particular implementation take, Hence there could be a chance of imposing unrealistic deadlines.

When asked which factors contribute to poor software quality, 40% of the 300 developers surveyed in the US and UK cited unrealistic schedules and 40% laid the blame on manual testing processes.

Similarly, unrealistic deadlines could have many reasons like government regulations, competitor software, client expectations, and more. 

Agile provides you the flexibility to work with the most important feature of the product. The product owner has control over the product backlog, he can switch the preferences between different functionalities, and the agile team is enabled to work on the most important functionality from the product backlog.

This provides team flexibility to know which features are important and control over to product owner what needs to be taken first.

3. Change in priorities mid-project:

Change is very fearful when it comes to traditional project management. 

When you have everything aligned with a prepared plan and suddenly in the middle stakeholders ask to take up certain features that could impact the team's momentum. 

Workflows are designed in a very linear manner and are mostly dependent and tightly coupled considering deployment as a whole.

In such cases, it becomes extremely difficult to change anything in the middle.

There could be many scenarios where due to market conditions or competitors had launched a new feature, priorities can be changed.

In the era of today's competitive economy, this is a very usual thing to be expected. 

So as discussed earlier when the product owner is extremely sure about the expected product and requirement does not stand any chance to change regardless of competency or any other factor for that matter, Teams should consider agile.

4. Lack of Quality Assurance:

When you are developing a complex procedural software product especially which has financial and security repercussions, it becomes mandatory to have it tested and fully proof before delivering it to the client.

Traditional project management systems consist of special phases of quality assurance but not necessarily all the catches can be predicted.

There could be many reasons as there are limitations to manual testing, resource crunch, and unawareness of the end-to-end functionality.

Agile by design enables the obligation to QA members to go through the quality assurance after each iteration.

5. Having a multi-tasking project manager:

Many of you have heard about context switching.‍Context switching is our tendency to shift from one unrelated task to another. According to the American Psychological Association, switching refers to the change in our “mental control settings" when we move to a new task.

Some organizations prefer to have the same manager for multiple projects which enforce him to switch his context, time, and energy every time he needs to have a look at the work that had been done.

When you have a traditional project management system, there are tons of things you need to consider, having a look at the project reports, managing resources, and their respective work, and checking the deadlines path, reporting to higher management about progress. These are quite time-consuming and exhaustive tasks especially if you have more than one liability to after.

Agile teams are self-organized and the roles and responsibilities of the agile teams have been clearly defined, be it scrum master or product owner, or any team member, So they tend to remain pin pointed focused when it comes to their work distributions. This structured way of roles and responsibilities not only provides you with values but also helps in managing them more efficiently. Also builds the emotion of trust and empathy in the team when you have kept all of them at the same level and created any silos by emphasizing your organizational designation hierarchy.

After considering all of the above reasons mentioned, I do not want to sound stubborn about it and form your opinion as agile is the only way or Agile is always better than traditional project management. When you have fixed requirement and the product owner totally know what he wants and has an estimate upon which the team can easily agree, almost zero chance of having a change in priorities in the middle, traditional project management is the best choice. It is not about which is the best among them, it is about which is the best suite for us.

We will discuss more agile methodologies in upcoming articles.

If you have ever worked in traditional project management and found some more interesting insights about it. I would love to hear out from you. 

Also, If you’re looking for someone to talk to about software development, agile methodologies, or the cloud in general or have any suggestions regarding my blog

Reach out on Twitter at @code_never_lies or drop a comment.

till then...

Happy Reading..!

Thank you

Aniket Kulkarni