Who does agile really benefit?

Agile and related methodologies have been praised for improving communication and increasing efficiency. But are they truly benefiting everyone on the team?
251 readers like this.
A bunch of question marks


Everyone wants to improve their experience at work.

Whether that takes the form of increasing efficiency, reducing confusion and anxiety about what needs to be done, feeling like your ideas and feedback are heard and respected, or simply knowing that the projects you work on are making an impact, there are seemingly endless ideas about how the nature of work can be improved for employees and employers alike.

Within the world of software, agile practices have been among the most talked about ways of improving processes. But are they all that they're cracked up to be?

Proponents of agile laud the focus on the individual, the mandate to build working software on fast timetables, and the ability to quickly and easily respond to change. The processes themselves, like kanban boards and daily stand-ups, are praised and evangelized by many who have made the switch to agile practices on their team or organization.

But agile is not without its critics. Detractors say agile can be a time waste when too much energy is spent maintaining the process itself for the sake of process, and that it's simply incompatible with certain personality types, working styles, and the demands of some types of jobs. They may even feel micromanaged by the frequent check-ins. While agile may work for management, it doesn't work for them.

So what do you think? It's clear that agile is continuing to see adoption across the software industry. But is it benefiting everyone? And if not, who is the real beneficiary?

User profile image.
Jeff Mackanic has been at Red Hat for more than nine years and is currently responsible for the creative services team at Red Hat. After several stints with varying levels of success at many e-commerce companies, Jeff became one of the original employees at Akopia, which delivered ecommerce solutions based on the Interchange platform.


There's a difference between implementing "Agile" and being agile. If you find energy wasted on maintaining a process I dare to say you are doing it wrong. Go back to the basics and stop implementing a boxed solution.

I agree with you and I found out from experience that not knowing how to efficiently apply Agile is the indicator of failure.

Not having proper analysis and proper planning for iterations that can fit in 2 to 4 weeks increment is the cause of Agile failure.

We have been developing successful software for a long time whether using a Waterfall or an Agile approach.

Either one of two approaches would work as long as we follow good software engineering principles in performing requirements Analysis, planning, using good coding techniques and applying solid quality testing.

Most of the failures using an Agile approach is the lack of efficient requirements analysis sessions.
During the requirements analyst process, at a minimum, someone needs to analyze these 5 major areas for building software solutions whether your team practices waterfall or agile:

1_ Defining the expected data output
2_ Defining the data input needed 
3_ Defining the activities to produce the output
4_ Defining the roles who perform the activities 
5_ Defining the activities business rules

Without performing good analysis on these major areas, the software your team is trying to build will have a high risk of failure....

In reply to by jimmysjolund

First don't treat the agile method like a noun. I know you hear that all the time line, but it's true. As a noun, it's treated like a strict set of rules. So you have to follow rules a, b, c... And if you don't follow that, then stop everything until you do. human communication (unless in military terms, which also breaks under pressure) does not work like that. Development requires sharing of ideas and debate. Now treating agile methods like a guideline, and adapting it to how your individual team communicates can help. For that to work you need a clear leadership structure, and those leaders to be smart and confident enough to steer, not take by the hand, their developers to keep on track.

I have seen agile done very well and very bad. My experience was when it was done bad it was basically adopting sprints and doing nothing else that would be recognized as agile. The product as a whole was still managed using waterfall. On the good side, I have seen it go very well and produce some great results. KPI's were a well groomed backlog and a good working relationship with the PO. In the good examples, the teams were coming from more traditional process based orgs and they adapted well and we found information sharing and cross team assistance and information sharing ware great. only time the truely agile teams found any issue typically was dealing with non-agile teams and being slowed by waiting on their processes.

I don't see anything wrong with a waterfall practice as long as it has been followed by good software engineering principles, like efficient analysis and good quality planning and testing.

Before Agile existed, successful software projects have been built and deployed worldwide... They only failed when they lacked good software engineering principles like efficient analysis or planning or quality testing.

Agile will also fail if it does not follow good software engineering principles.

In reply to by Lhasadad

It justifies the jobs of managers, who tend to be a waste of resources. In addition, Agile always stays a step ahead by virtue of the mantra "if it does not work for you, you are doing it wrong." Another ridiculous fad of the industry, assuredly not the last one.

I worked with agile as a DBA and I can only say that agile is not well suited for the infrastructure projects. However, I was forced to do precisely that. I stayed with the company for 6 months and then looked for another job. Agile is good for projects with quickly changing requirements. Unfortunately, code quality frequently suffers. There is no time for peer review and for project design review, only "sprints", "scrums" and "scrum meetings". As a DBA, I have to say that I am unimpressed by the agile methodology. The people who benefit the most are the people who sell certifications for Agile PM.

Hi Mladen

I agree with you that the only beneficiaries from Agile are the ones giving certificates and selling books that have new buzzwords that confused the software engineers.

I am going to be honest and dare other IT professional to be honest as well.

I have been a software engineer for over 30 years and have obtained my scrum Master certificate to find out the following :

1_ A requirement was renamed User Story.
2_ Development tasks plan was renamed Sprint Plan.
3_ Improvement meeting was renamed Retrospective.
4_ Team Lead was renamed Scrum Master.
5_ Team communications was renamed Stand Up.
6_ A 2 to 4 weeks plan was renamed a Sprint.
7_ Business Stakeholder was renamed Product Owner.
8_ Stakeholder Review was renamed Sprint Demo.
9_ SDLC phases were polarized as Waterfall, this is so UNTRUE

The following critical roles were removed from the team:
A_ Project Manager
B_ Business Systems Analyst

Honestly stated, Agile has created confusion to the IT industry and sooner or later will either be replaced or adjusted to help IT professionals execute all the phases of SDLC more efficiently in performing Planning, Requirements Analysis, Design, Coding, Testing and Deployment.

I am not a fan of buzzwords, I follow good efficient software engineering principles to build reliable software solutions.

Following AGILE doesn't not build reliable solutions, it's the software engineering work effort needed to tackle each phase of SDLC depending on the project size and team needs for what artifacts are needed to be able to build the reliable software along with good planning for project delivery.

Let's not follow a process just because it's the trend, or a cool buzz word, make sure your team follows good software engineering practices whatever framework you want adopt.

Your comments to my reply are greatly appreciated.

In reply to by Mladen Gogala (not verified)

Good communicates starts with managers who respect their employees. If your managers are jerks, no amount of buzzwords will help. If they're not jerks, then buzzwords don't matter.

I follow the Structured Analysis and Design by Edward Yourdon and Tom DeMarco.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.