Why Agile sucks?
Agile and Scrum are our daily bread. Projects are run by a strict code we develop software by rules made before our time. We believe in them, we breathe them, we incorporate them into the process of making software. But get this — in reality, Agile sucks. This is a revolutionary statement. Coming from a company like ours, it even becomes a blasphemy. And like all revolutions, it originates from a single drop of disbelief.
Origins
Kitchen is a vital part of our company. Ideas clashes, solutions are exchanged among the teams, and sometimes even Bolo, our parrot, gives a little input. We like to believe his ideas are substantial. Once he witnessed a conversation between some of our developers. We have a small, but exceptionally skilled faction of Agile skeptics. They don’t think Agile and Scrum are the best solution for tasks at hand. Overall, they don’t seem to appreciate the chances this methodology gives to developers.
For example, it changes the mindset, and it doesn’t take prisoners. Either you can agree with it’s principles or you simply die… buried under a pile of dust and paper, with printed and never used guidelines for the project. But it still sucks. Traditional methodologies like waterfall gives stability. The constant iteration of a project in Agile makes your head spin and nothing basically gets done. There is no stable path for development; daily scrum makes it difficult to talk about something constructive, because you talk all the time.
The truth
Agile promotes communication between stakeholders. Every time you have a problem, a question or a code-based roadblock, it’s only natural to just ask. The project is being developed naturally, and there is no long-term plan for it. Because Agile assumes that long time planning is impossible due to everlasting circumstances, iteration and talking happens all the time. One just don’t simply go into a Mordor of code development armed only with mouth! Talking has never really taken down a troll (bug) or a dragon (roadblock). You have to be prepared for this and make every stage of development count.
You also cannot count on every project to go smoothly. Estimating the time needed for development, makes the difference. In Agile, every stage of the project is constantly under review. At any given point, it can be turned around and made to match the current objectives and wishes of the Client. In waterfall and other methodologies, everything is fixed.
Business and projects had existed long before Agile and Scrum. The world’s still spinning and it’s going to spin regardles of Agile mentors. Examples of that can be found virtually everywhere.
Let’s think about firmware. For this kind of project Agile is unnecessary. There would be to much talk and not enough walk, increment, as we call it. Job done, Client’s money well invested. Agile is too handy for this — firmware is not a project that needs intense planning and constant iterations.
A small, well managed team can develop a product in a timely manner. Also, people seem to forget the basic principles of Agile itself. Instead, they rush to judgment, following the dogmatic rules and processes. They over-simplify the process, making it hard to live with. The whole idea of Agile is getting things done with quality, over rules that makes the development simple and effective.
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.
Clients are also a problem. Or rather, they are people to consider at every stage of development. Clients doesn’t always want to be Product Owners on their side of the project. They leave the decisions, and sometimes even quality, to developers. And it’s understandable — taking part also takes time. There’s less room for the company, Clients have to cooperate with developers. They have to own the product, changes, and partially vision.
Meeting is also an issue. Not from Client’s perspective, but from developers point of view. They always make iterations of the project and talks about them, even though everything’s right. Meeting consumes time. It uses the most valuable currency in Agile, right after people — space. For example, in 8 hours sacrificed for planning, top developers can add a bunch of, quite vital, functionalities. Making the 8-hour planning for a month can be essential or it can be devastating. One of teams here at XSolve likes to cut the time spent on talking and it’s for the best. Agile is not a shrine, it’s just another tool.
The case blew in almost a year ago, with several articles referencing each other. 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 greatest of them all ‘The Anti-Agile Manifesto‘. It seems nowdays, it all makes sense, and eve more with every day. Companies tend to focus their work on tools not people and interactions between them. After all, it’s people who make software products, not JIRA or Pivotal.
Consequences
People in smaller companies or working on very specific, small software, don’t want to hear about Agile. They don’t want it, they don’t need it, and they sometimes even think, it’s pushy. All other ways of making it are wrong, Agile is right. And it’s always right.
The truth is, none of today’s tools existed when Agile was created. And it was created out of need, not out of the will to bend reality to it’s vision. My colleague wrote a piece about Agile being dead and we can safely assume, it really is.
To some people. To those, who cannot accept programming just for the sake of it. Or should I say — for IT’s sake. Code does not happen for the industry, not even for the Client. It happens for the end-user and it really sucks, when the way of making it is not followed properly.
Agile is not a dogmat. And it’s not dead, until we make it so.
Written by Jaroslaw Scislak
Originally published at www.xsolvesoftware.com.
