Agile Is Not Always the Best Way Forward

For the past few years, Agile has been the buzzword in the realm of IT project management.

When it first came into the picture, Agile was considered a panacea for everything that plagued IT project management. This is because it had brought about a revolutionary change in how IT projects were executed. 

In 2018, 75% of companies reported accelerated software delivery as the #1 reason for adopting Agile, and for 46% of companies, the reason was enhanced software quality.

However, despite all the perks that it brings to the table, the methodology comes with its set of challenges. 

CIOs, CDOs, and CTOs who bear the onus of effectively defining, streamlining, and implementing various IT project management processes,  while also adhering to the Agile methodology, often run into certain obstacles. 

According to the State of Scrum 2017-2018, 51% of cases faced difficulty in adopting and scaling due to their organizational design and culture.

Let’s understand why Agile doesn’t generate the desired results for every organization: 

1. Developer centricity

Each organization is different, where the mix of developers varies with each project. Although some organizations may have experienced and seasoned developers to handle projects, most organizations have a mix of freshers and little to highly experienced developers. 

For developers with little experience and a lack of skills, Agile comes with too much responsibility. 

The methodology proposes that developers come up with user story points, which is usually a daunting task for junior developers. Freshers and rookies may not achieve accuracy even after multiple iterations as the tasks vary every time. They are likely to show a reduced sense of responsibility, given that senior resources are available to balance things. 

Besides, experienced developers have packed schedules and may sometimes fail to help at all. Considering that COVID-19 has widely forced the remote work culture, it may not always be possible for experienced developers to collaborate with juniors to work things out. 

2. Inertia of direction

Barring some pure IT service companies, the experience of migrating to the Agile way of working is quite painful for others. While it is very easy to go after the bright and shiny “Agile” way of doing things, the actual transition is quite painful and filled with resistance.

People are used to old ways of working in companies belonging to the old economy, such as manufacturing, pharmaceuticals, oil and gas, and banking. Therefore, it becomes extremely difficult and long-drawn to switch to Agile. 

CXOs need to evaluate the benefits and costs of this transition carefully. The recommended way is to identify the issues with the current process and tackle each problem individually instead of coming up with a bundled “Agile” solution. At times, it might be wiser to switch to better and less painful alternatives or not make a move at all than embark on this transition.

3. Change of roles

This is prominent in the case of project managers and business analysts who are expected to suddenly “fit” into their new positions. 

Despite the fact that the roles vary drastically, the closest match between the traditional IT project management and Agile is for a project manager to turn into a scrum master and a business analyst to turn into product owner. The project manager is responsible for planning, executing, and tracking projects, whereas the scrum master facilitates events, communication exchange, and the project team’s progress. 

Giving in to the confusion and chaos that the role change brings, this “new scrum master” often dwells on his old ways and starts planning and monitoring projects.

Similarly, the business analyst has to step up into his new role of coordinating and prioritizing, which was partly handled by a project manager in the legacy methodology. The growing involvement of senior management further intensifies the problem because 1) they have limited bandwidth and 2) they often tend to consider adherence to Agile methodologies not so important, which results in a lot of heartburn in the project team 

A case in point is when the senior management person moves past his/her role and assume, for example, the role of a designer or a product owner or a technical architect. This makes it challenging for the project team to do their job and may result in a lot of scope creep, deviation from the initial project objective, and dissatisfaction in the team.

4. Nature of projects

If appropriately managed, Agile can work like a charm in a product environment or in a setting where the work is quite similar to projects executed earlier. On the other hand, this methodology may not work so well in projects such as website or web applications development. 

The ideal way to handle web development projects is to freeze the entire design first. Breaking the design into different sprints may result in a lot of rework as teams go back and forth refining and modifying.

Why? 

It may increase the odds of revision manifold and sometimes result in design changes in the areas already rolled out as part of earlier sprints. A “finished product” of earlier accomplished sprints may suddenly become “unfinished”. 

Besides, Agile may also prove counterproductive for small projects that last 2–4 weeks, when compared with the customized approach that most organizations are currently following.

5. Burnout of team members

Agile comes with the added pressure of being “agile” i.e. delivering things faster. This is why the team members may feel pressured and distressed, ending up slogging to meet deadlines and thus making mistakes.

As soon as one sprint finishes, another comes around the corner which may lead to the team’s fatigue and burnout.

To Wrap Up

Going Agile means much more than just adopting the methodology. There is no denying that Agile has its advantages and it does bring speed and order in project delivery where it is a good fit. However, it also comes with its challenges that need every stakeholder to invest in it in spirit and action to make it successful. 

Agile should always be a well-thought-out and well-planned organizational decision.

“The fundamental unit of work in an agile transformation is creating the environment for Agile to be able to operate.” 

– Mike Cottmeyer, CEO, LeadingAgile

CXOs must first carefully consider and evaluate if and where they want to go with the Agile approach. 

Start with deciding which projects require the Agile treatment and why. Work out the right methodology or specific Agile practices for each project. Lastly, assign roles to people with relevant experience and dedicated attitude to avert or mitigate the impact of any challenges.