Agile which came into existence due to the shortcomings of traditional project management methodologies have found widespread acceptance across the globe. But, it also has its fair share of criticism, especially from programmers who are central to everything that happens in Agile. And there are instances where top companies like Google where programmers resent Agile development. In short, Agile is something that reduces the cost of change and uncertainty in a project.
When an organization jumps on the Agile bandwagon for obvious reasons, often senior management is caught off guard by their programmers who resent Agile. In many organizations, there is this usual pattern seen, when all of sudden senior management and leadership believe they need to embrace Agile development and have gotten off on the wrong foot. Below mentioned are the top reasons why programmers hate Agile development.
*There are points which also address other than programmers as well.
Same Old Stuff Being ‘SOLD’ with an Agile Label:
With Agile’s widespread acceptance, there are companies that are selling Agile and are taking advantage of people who know very little about Agile. Not only are they looking to make some easy earnings, but they also have very less idea about Agile and are repackaging the same old thing with an ‘Agile’ label on it. But then these kinds of companies are very easy to find out and you should avoid unethical salespeople who come up with their own Agile agenda. Do your regular due diligence about Agile and you should be fine.
Agile has Excessive Usage of ‘Jargons’:
What are the story points that were ticked off on the burndown charts? In our last sprint, our velocity went up a notch higher than ever before. How many tickets were resolved? And where are we with the retrospective meeting? Anybody who is new to Agile would have probably faced a first-ball bouncer as per the cricketing analogy. In fact, this would have been an over of bouncers where everything went over your head. Seriously, what is up with all of this jargon? Many programmers feel these jargons are unnecessary.
Agile = End of Freedom:
Programmers believe implementing Agile in an organization is the end of freedom. But then they do not know when Agile is implemented well, there is more freedom than ever before. Enterprises need to get the message straight as there will be misconceptions of Agile being yet another way to impose control on them. A simple solution to avoid this confusion is to talk to programmers before implementing Agile methodology and emphasize how it will affect the whole organization than programmers alone. Because Agile promotes incremental architecture and is improved over time this directly equates to providing better value to the customer.
The Misconception of Programmers Thinking that They are Not Good Enough:
The first thing that comes to the mind of programmers when you implement Agile without informing them, they will think that they are not good enough about how they go about their day-to-day activities. As an organization, if you want your Agile implementation to succeed then you need to inform everybody about the same and be sincere about it and explain to them how it will affect the whole organization and not just programmers. If not the message will be taken in the wrong way as “us vs. them” and there will be a lot of friction in the future.
The Agile Consultants Will Have Their Own Agenda:
When you implement any new methodology in an organization, it is not like you will train your key personnel first and then ask them to implement it. The first thing any organization does in situations like these is to bring in an external consultant who knows Agile, but the problem is there are many Agile salespeople who are there to make a quick buck and sell the same old things under the label of Agile. Without knowing what your programmers are doing, they just straightaway point out all of their flaws and give generic advice. And when something goes wrong, the first person to take the blame will be the programmers. Hence, programmers are a little skeptical about Agile implementation.
Doubled-Up Programming!:
This is not such a big problem, as many organizations won’t even introduce it. At first glance, it might seem like you are paying double for the same services, but there is a definite value in this. Programmers have apprehension about pair programming as both the teams are working on the same thing and there will be differences for sure. But, this doubled-up / pair programming is something that is not used regularly and programmers should not worry about it.
When Stand-Up Meetings Become an Interrogation Period:
Many project managers fail to understand the essence of stand-up meetings and turn them into a question-and-answer period. When a stand-up meeting becomes an inquiry period, then it is not Agile anymore. As a project manager, if you feel enticed to turn a stand-up meeting into an interrogation / cross-questioning session, you will have a lot of unhappy programmers who will not cooperate down the line.
Careless Adoption of Agile:
Organizations have the habit of carelessly adopting Agile just because everywhere people are talking about Agile. When managers out of the blue say “WE are adopting Agile” and in meetings down the line keep on asking about “how are we going with this Agile thing” will give you a lot of blank faces, and starting Agile in this manner will surely fail big time.
Not only this careless adoption of Agile will fail, but your programmers will be disappointed that they were not consulted while taking a decision on Agile adoption. Agile needs widespread cooperation to incorporate this big change, and key personnel need to be consulted before taking an important decision.
Lack of Commitment from Senior Management Towards Agile:
A band-aid approach towards Agile is the last thing that you want on your hands. Agile needs prolonged commitment. It needs to be handled with care during tough transition periods and needs proper budgetary support. And depending on the size of the organization, you will begin with one highly experienced Agile consultant (not the sneaky salesperson) to see your organization through the transition. Even the number of tools that will be used will be increased drastically and this needs to be carefully embedded in the organization and its work culture to see a profound impact of Agile. Again a half-hearted approach from the organization towards Agile will leave your programmers frustrated.
Programmers Believe Agile Prescribes “Doing More With Less”:
This is a very sensitive subject to touch upon, “Doing more with less” is a fallacy and it needs to be stopped by organizations who believe they are keeping a close tab on operating costs. In fact, organizations taking this approach are shooting themselves in the foot. Agile at times can be perceived as a way of doing more with less. Agile gives you a lot of benefits when implemented properly and “doing more with less” is not one of them.
Though we may see widespread adoption of Agile in enterprises across the globe, it needs to be implemented carefully with proper consultation from all the stakeholders who will be a part of this change. Especially programmers, who are central to everything in Agile, get them on your side by getting their views about this big change and you will see there will be a lot less friction towards this new way of product/software development.
