To agile or not to agile, that is the question

Agile has been all the rage for the last 15-20 years in the tech industry. Some companies invested a lot in

• getting their teams trained in Agile
• reinventing their whole software delivery model
• getting team members certified in Scrum

It definitely cost a lot in terms of time and money. But, did the transformation get results? In many cases, yes. But, in many others, no.

A lot of other organizations felt like they had to get onboard the Agile train, or they would not be able to compete. Unfortunately, many businesses didn't get much of a return on investment. Many teams ended up realizing that they were producing less while frustrating all the developers that were doing just fine before this Agile thing was shoved down their throats.

If it isn't broken, don't fix it.

Agile is not for everyone

Some projects are perfect for Agile, while others are not. Software has historically benefited from Agile, but other industries not so much.

There are many benefits to Agile:

• Improved Quality
• Adaptability
• More Customer Satisfaction
• Better Estimating and Predictability
• Reduced Risk

In agile teams, something is released regularly, which allows customers to immediately get something that they can see, touch, and feel. Feedback is then given back to the team and they can further iterate on the products.

When an agile team works for some period of time, they get to know each other's strengths and they continuously engage with one another designing, developing, testing, fixing, etc. They typically communicate every day, which lets each team member know what the others are working on and allows team members who are blocked to get some help from their teammates.

But, what about other industries?

Some version of agile can probably be applied to most projects. But, some projects are best delivered using non-agile methods.

When is Agile not the best option

Strict Requirements

When the requirements are very specific and there is not much room for ambiguity or change, Agile might not be the best choice. If a company delivers a big version of software once or twice a year and the requirements are well defined, it might be best to stick to traditional frameworks like Waterfall. Since the software is not released until the release date, developers are not releasing any code externally to their customers every two weeks as they would in a SAAS model with continuous delivery.

Some IT projects

We've seen several IT teams trying to adopt agile and completely fail. Many IT teams have long-term projects with specific delivery dates. Or, they often get interrupted as new priorities come up for new systems, new security measures, or issues that come up day to day. They are not able to reliable predict how much time they'll work on new projects. Yes, they can use Kanban-style boards to track their work and priorities, but the idea of regular Sprints is probably not the best option.

Old mindset

Some organizations are just stuck in their old ways and that often can be totally OK. If it works for that organization, there is no reason to bring in a new framework. We've seen teams within companies try to force their projects through an Agile Framework, and fall flat on their face.

Hybrid Models

There are some companies that use hybrid models, combining some of Agile's key features and Waterfall's methods. For example, if a company has to deliver a specific piece of software with generally pre-determined features at a specific time, but it has different ways of implementing those features, a hybrid model might work. In this case, they would still stick to some high level milestones as in Waterfall, but within those milestones, they would have some freedom to try things, get feedback and iterate.

All projects and all organizations are different. One framework cannot work equally well for all of them. Sometimes the answer is one, the other, or some combination of the two.