AGILE Development

What is the AGILE methodology? 
Some will tell you that AGILE is a way of managing change in a tempestuous workplace. This is an oversimplification. AGILE is a set of principles that allow Product Management to justify "creep" into an iterative scope of work. Further, it’s a justification for incomplete user stories to enter into the hands of the developers.

Things I hate about AGILE:
AGILE is nothing more than a translation layer added on top of Waterfall (a methodology consisting of a logical and predefined progression of steps).

Points:
This translation layer, AGILE, has “points” for a measurement of work. These points are meaningless, as one developer can complete a unit of work in x amount of time while another developer may complete it in x + y amount of time. Points are nothing more than an equation, or a distraction of time it takes to boil it down to hours or days. At some point, everyone has to do this unnecessary arithmetic.

Scrums: 
Regularly, usually in the mornings, organizations that run an AGILE shop have meetings they call “scrums.” While it should be noted that SCRUM is not distinct to AGILE, and that these meetings can be run efficiently, these meetings are usually not conducive to being effective or efficient. I’ve been participating in AGILE environments for over ten years and I would say that 85% of scrums were ineffective and/or inefficient. I’m not just referring to the pre or post conversations of fantasy football or ridiculous cultural/pseudo-political discussions that typically occur, but I am referring to the questions or comments that don’t concern the involvement of others that are present in the meeting.

Demos: 
Some will tell you that the sprint demo is “invaluable” to get management up-to-date about the goings-on of each sprint. This is absurd. This is a glorified show and tell with adults that have better things to do. This isn’t a training meeting, this is “hey, I made this button that Product Management wrote down in the user story, and that QA approved...and if you don’t like it…you’ll have to write a new story in ‘Cleanup’”. Product and Development Managers should already be aware of what’s being added, a demo is not needed. If a training meeting needs to be scheduled, it is a different style of meeting altogether.

Cleanup:
One eternal truth is that AGILE always has one or more cleanup sprints. Another definition of AGILE is shoving as much as we can into a sprint. Whatever we don’t get done, will simply move to the next sprint. I have seen this pattern at every organization in which I have been involved. These cleanup sprints typically involve developers working overtime for the mistakes that they and their product owners (typically by incomplete user stories) made in previous sprints.

Creativity: 
There is no room for creativity in AGILE. Everything in AGILE is tracked, how do you track creativity? You can’t, which is why management hates it. If you are lucky enough to have an R&D Department, they can’t use AGILE. It’s impossible. You cannot assign or predict points to creativity.

Developer Satisfaction:
By and large, developers (if asked by a non-manager) will respond negatively with regard to how they feel about AGILE. We are structured individuals, well most of us, the GUI/PHP folks are less so. We want everything predefined, we don’t mind doing a little digging - but we usually get burned by it.

The Eternal Excuse:
“You don’t know AGILE, bro”... or “that’s not AGILE, bro”. These assertions have been thrown around by stiffs that have been at less than three companies in their entire career. The truth of the matter is that AGILE varies from company to company. Why is this? “Well, they’re not doing it right…” Wrong. It doesn’t work out of the box, at all, and so companies have to modify it. Some claim that it was meant to be modified, but why would a methodology that is supposed to incorporate a significant degree of change have to be modified at all?

Summary:
As mentioned before, I’ve been doing AGILE for as long as I can remember. At first it was this cool buzzword. It was something different, and exciting. Years later, I noticed the same patterns in the form of problems. It doesn’t work for the long term. Companies that have been doing it for years have modified it into a Frankenstein style monster, and even then - they’re still left with problems. All of these thoughts that I have shared, I kept to myself for a long time until I visited my brother who is a DBA. Without prompting, he shared the same problems he was having. I then started opening my ears, and found that my colleagues (other developers) were sharing their same concerns. There are things to like about AGILE, certain parts of the manifesto are satisfactory, but overall I’d rather do something else.