All the reasons Agile sucks!

At XSolve Agile and Scrum are our bread and butter. Projects are run by a strict code – we develop software by rules established long before our time. We believe in them, we follow them, we incorporate them into the process of producing software. But listen to this – in fact, Agile sucks. This is a revolutionary statement. Coming from a company like ours it is a blasphemy. And like all revolutions, it emerges from a single drop of disbelief.

Origins

Kitchen is a crucial part of our company. Many arguments take place here, ideas are exchanged among the teams and sometimes even our parrot Bolo provides a little input. We like to believe his ideas are insightful. Once he even witnessed a discussion between some of our developers who represent a small, but exceptionally skilled wing of Agile skeptics. They do not share the opinion that Agile and Scrum are the best solution for tasks at hand. Overall, they seem not to appreciate the possibilities this methodology gives to developers.

First of all, it changes the mindset, and it doesn’t take prisoners. Either you agree with its principles or you simply suffocate under a huge  pile of paper with printed and never used guidelines for the project. And it still sucks. Traditional methodologies like waterfall offer stability. The perpetual iteration of a project in Agile makes your head spin and nothing gets done. There is no stable path for improvement; daily scrum makes it challenging to talk about something constructive, because talking is all you do.

The truth

Agile promotes communication between stakeholders. Every time you have a question or hit a code-based wall, it’s only natural to just ask. The project develops naturally without any long-term plan. Because Agile presumes that long term planning is impossible due to everlasting circumstances, iteration and talking takes place all the time. One does not simply go into Mordor of code development armed only with words! Talking has never really defeated an orc (bug) or a Nazgûl (roadblock). You need to be prepared for this and make every stage of development count.

You also cannot rely on every project to go smoothly. Estimating the time needed for development makes a big difference. In Agile, every phase of the project is under constant review. At any given point, it can be turned around and rewritten to match the current objectives and wishes of the Client. In opposite to waterfall and other methodologies where everything is fixed.

Agile is a wisdom. You have to use it and also use it right. If not, it can easily be turned into burned  down library full of valuable hints.

Business had been built long before Agile and Scrum where even considered. The world is spinning and it’s going to spin regardless of Agile mentors. Examples of that can be found virtually everywhere.

Let’s take a look at firmware for example. For such a project Agile is unnecessary. It would involve much talk but not enough walk, increment, as we call it. Job done, Client’s money well invested. Agile is too handy for firmware projects. They do not demand intensive planning and constant iterations.

Final product can be developed in a timely manner by a small and well managed team. Unfortunately people tend to forget Agile’s basic principles. Instead of getting things done applying rules that make the development simple and effective they rush to judgment, following the dogmatic rules and processes. They over-simplify the process, making it hard to work with.

Agile is wisdom which not used properly can be more of a burden than help.

Clients can also be a problem or rather, they are people to consider at every stage of development. Sometimes clients do not want to be  Product Owners on their side of the project. Developers take over the decision making process and sometimes even quality and it’s reasonable – involvement consumes time. Company gets less room, Clients have to cooperate with developers. They have to own the product, changes, and partially vision.

Meetings are also an issue. Not from Client’s perspective, but from developers point of view. They always make iterations of the project and discuss them, even when everything is right. Meetings consume time and the most valuable currency in Agile, right after people – space. For example, instead of 8 hours of planning, top developers can add a bunch of crucial functionalities. Spending 8 hours a month planning can be essential or it can be devastating. One of XSolves teams likes to cut the talking and the result are great. Agile is not a shrine but yet another tool.

The case blew wide open almost a year ago, with several articles referring one another. First was Dave Thomas with his ‘Agile is Dead‘. Followed by ‘Angry Developer Version‘ and ‘I Want Agile Back‘. It came to ‘I Don’t Want Agile Back‘ and the best of all ‘The Anti-Agile Manifesto‘. It seems now that it all makes sense and even more with each day. Companies have a tendency to focus on tools and not people and their interactions. After all, it’s people who develop software, not JIRA or Pivotal.

Consequences

People in smaller companies     who work on very specific, small pieces of software are not interested in Agile at all. They don’t need it, they don’t want it, and they tend to think it’s pushy. There is no other right way of work than Agile. And it’s always right.

As a matter of fact none of today’s tools existed when Agile was released. It was created out of need, not out of the will to bend reality to its vision. One of our colleagues wrote an article about Agile being dead. We can safely assume it really is.

Of course not to everyone. It is long dead to those, who do not accept programming just for the sake of it. Or should I say – for IT’s sake. Code does not take place for the industry, not even for the Client. It is developed for the end-user and it really sucks, when it is not produced properly.

Agile is not a dogma. And it’s not dead, until we make it so.