Why programmers don't like Agile? What went wrong with it?

The Agile movement was primarily created for programmers by programmers, that means technical people. In principle, it strengthened their position and focused on independent and creative teams that continuously learn, adapt and self-organise. Over time, however, Agile strayed from that track and shifted unexpectedly towards project management.

Programmers were one of those who saw that a traditional way of working to meet customer expectations, designing, planning and coding, didn't work well. They felt that they could do better in Agile. The new system made it possible to write high-quality code, around which the Agile idea revolves. In the past, this was called engineering excellence, which meant developers did a job they were proud of.

Quality, next to time and costs, is the primary Agile variable, which, determined at the beginning of the project, is not negotiable until the end of its duration. The reason why organisations embraced Agile was that it could create and deliver a valuable product. So they all had the same motives and a common goal.

Theory and practice

However, if organisations do not emphasise quality, likely, using Agile style and principles will not deliver up to half the benefits it offers. It gets even worse when programmers themselves use agility without technical quality. In recent years, many of them have expressed their concerns about agility in practice.

Robert C. Martin, one of the people who developed the Agile Manifesto in 2001, pointed out that it is – unlike Kent Beck and other creators originally envisioned – long used by an army of certified Scrum masters and people in business who don't understand his idea. As Robert Garrett suggests, the problem may be specific methods of Agile implementation, not in its core values. As a rule, a work of an agile is to consist of developing good-quality clean code and ongoing evaluation and correction of individual elements of the final product (not, as in traditional models – at the end of the project).

Negative elements of Agile according to its creators:

• obliging programmers to arbitrary estimates and deadlines, making it impossible to think carefully about functions they create;
• creating a rigid organisational framework, as in Scrum;
• an overabundance of documentation and bureaucracy;
• ignoring the topic of technical debt.

In an ideal Agile world, developers should have enough time to refine the existing code structure (refactoring) and carefully think about the function so that the software will be sustainable in the long run

Is Agile not working on the developers' side?

Speaking of how programmers may feel unwell at Agile, consider situations where they think Agile isn't working on their side. Agile's core values and principles are great, and no sane person can go against them. No sane programmer would say, “I don't want to provide useful software! I don't want to impress my customers! I don't want high quality, low-risk software!”

Negative aspects of Agile principles according to developers:

• arbitrary goals and unrealistic deadlines;
• bureaucracy and lack of space for developers' creativity;
• rushing programmers in their work.

Programmers believe that although a manager wants them to work in Agile, he often does not understand it or do not help the team. When Agile was introduced, it was intended to work from the bottom up, but has become a top-down approach. In this situation, it isn't easy to act independently. Programmers are required to do the work beyond measure, then tension in the team increases through constant pressure from above. If a manager is not using agile tools properly, it can lead to team micromanagement. This results in a conflict, not in the spirit of agility.

Agile teams don't need managers, although having them doesn't hurt, as long as they follow Agile rules

Agile is essentially about empowering teams to organise. In an agile team, developers can spot problems and are able to fix them. An agile team doesn't need to have managers, although having them doesn't hurt, as long as they are agile themselves. Therefore, many programmers believe that their lives would be more comfortable if managers learned Agile or individual implementation methods (Scrum, Kanban, etc.), thus taking over technical responsibility. They also complain that many managers use cycles to make their schedule more convenient, such as meeting the entire team instead of scheduling separate meetings with individual developers, wasting others' time. It is also not in the Agile spirit.

When teams do not follow a simple design and test-based programming practices, they are forced to deliver early, leading to a drop in quality. When quality drops, it is difficult to produce anything in a short time

Iterative means gradually

There may be other reasons why developers may not like Agile. For example, they think it's a “silver bullet”. They want to solve all problems with its tools. Another reason is probably that the role of Agile programmers is much more than just writing a code. Developers working in an Agile environment have to take much more responsibility.

Additional responsibilities of developers in Agile:

• taking responsibility for planning and managing one's own work to successfully complete sprints;
• efficient work of individual team members to ensure success of the entire team and to develop well-integrated solutions;
• in some methods, also working directly with customers to better understand and explain requirements.

Some programmers enjoy an additional responsibility, extra autonomy, and permissions they get in an Agile environment. Some, however, do not want this additional responsibility

“Agile” examples, specific to other implementations, and not always liked:

• daily meetings, so-called stand-ups (comes from Scrum) – as a rule, they are to be quick contact where a whole day gets planned. In reality, they turn into long meetings, which is something they wanted to leave behind 20 years ago. They take valuable time from programmers who would prefer to spend it coding. As a result, they feel unnecessary pressure to meet their sprint commitments;
• pair programming (comes from XP) – while many programmers may like it and find it productive, it isn't compatible with Agile;
• history formatting and iteration planning meetings.

Agile and managers

When you hire a development team, find out if they are using Agile and what they think about it. This can help you understand their approach to technical quality and whether they are capable of delivering high-quality designs

There is often an opinion among experienced programmers that managers do not value Agile enough or understand it, or use its tools in a wrong way.

Wrong practices of Agile managers:

• want to dictate a speed (or what needs to be done) in a given cycle;
• do not follow the process, they violate it, they change priorities during its duration;
• limit programmers' independence through their management style;
• do not require the typical Agile integration between team members.

“Saying that something can be done in time x when that is impossible, telling not to do x before y when x is needed first, telling the team what their obligations are, instead of letting them commit to what they can do etc.”

Technical debt – is a cause of the problem?

At one of the conferences, Robert C. Martin was asked if Agile could return to its original mission of bridging a gap between business and developers? “This can only happen if we start paying attention to an unnecessary bureaucracy that is taking place and the technical debt that keeps piling up. No sane programmer wants to write wrong, messy code. However, they are often forced to do so by business people who want to release new features as soon as possible.”

Technical (technological) debt is a phenomenon in which, due to the choice of an option seemingly easier and cheaper to implement, the total cost of choosing this option becomes less profitable in the long run than choosing a more time-consuming but objectively better and more refined solution.

Technical debt reasons:

• imprecise or evolving requirements during the project lifetime;
• the pressure to release software at an earlier date than assumed;
• product release when it’s not fully completed;
• focus on generating profits quickly;
• lack of compliance with standards and acceptable practices in initial stages;
• no refactoring in initial phases;
• too late changes in requirements.

The Software Craftsmanship

Is it possible to combine programming, perceived as professionalism and technical perfection, with expectations of business that wants software quickly and cheaply? The Software Craftsmanship is trying to go back to the original Agile promise, which, according to Kent Beck, was to bridge the gap between business and programming. In 2009, the Manifest Software Craftsmanship was created, which developed some principles of the Agile Manifesto. It results in a need for greater involvement of programmers in software development on many levels.

Manifest Software Craftsmanship principles:

• well-written software, not just working;
• continually adding value, not just reacting to changes;
• the entire community of professionals, not on individuals and interactions;
• productive partnership, not just customer collaboration.

“A programming project cannot be successful without the cooperation of good programmers who not only can create good quality software but are also able to help the business achieve what it wants to achieve by offering it right options, feedback and constructive criticism.”

The idea has already lost some of its shine in the sense that its popularity peaked in 2010–2011. Certainly, however, the manifesto left its mark on the field of IT, contributing to creation of the developer ethos.

Summary

Agile will not work where it is too strict with the project team and overall organisational culture. While a design team is agile-trained, and a company has a corporate culture, Agile may not be the best choice. Either method works if these factors are met. Conversely, when a method is imposed on an average design team and an unready organisation, Agile is likely to be worse than alternatives such as a waterfall or spiral approach. Because if there is a great team and culture, then the waterfall will work too.

Are you looking for an effective management method for your project? Read about the various methods you can choose from: traditional and agile.