Agile Zone is brought to you in partnership with:

I am an independent software consultant with main interest in software architecture, web services and database design. I am using most of the time Microsoft technologies such as: WCF, ASP.NET MVC, Web API and MS SQL. Ok, to be honest my interest does not resume only to that, I am big fan of AngularJs, TypeScript, Node and Python. Mihai has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Agile: Abuses, Abuses, Abuses

08.19.2013
| 1229 views |
  • submit to reddit

This is not a new topic for sure but I have to write few words about it. The main reason for this article is the abuse (wrong understanding) of agile I have noticed while talking with various project managers in the past two weeks. First, allow me to quote Wikipedia about Agile definition:

"Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.".

Ok, so now it should be quite clear what Agile means. Scrum is one of  the most-used agile frameworks currently, at least based on my humble estimations, so here is the definition of it:

"Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as opposed to a "traditional, sequential approach". Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication between all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements."

After you read both definitions can you conclude that planning is useless? Why bother with it? It is a waste of time. This is why we are "agile" after all. No planning please.

Oh my! So there is no  planning, but what about some business requirements or some business models? Agile has a different approach when it comes to business requirements.  Many consider documentation as the worst method to communicate this information. I do not adhere to this principle.

I do agree that face to face and being at the whiteboard are invaluable communication strategies, but all the ideas and conclusions that result should be "written down on paper" to be used later on as a reference. To be honest I do not think that developers will memorize all of the details.

But all that is a waste of time, we are "agile" after all.  Some very general sketches will do the job just fine.  Plus, you and your team will get an email with a very short description about what has to be achieved. The following is a perfect example: "The payments module should calculate employees' salaries based on their rank and time spent in company, achievements, etc."  Not enough.... don't worry, if you are lucky there might be a screenshot or mockup attached to the email, you should be able to deduce the business logic from it. That should be enough for you and your team to complete this sprint with success, anyway 60% of the logic will be changed by the client later on.

Now we reach estimations.  They don't matter.  The client makes the estimations.  If yours fall on the same timeline, then lucky you.  Otherwise... we are "agile," we have to deliver quickly and respond to emerging requirements.  So what if the second sprint breaks the functionality from first sprint. You have a technical debt... c'est la vie. We are "agile," so just make it work.

Should you focus on the quality of your code also? Who has time for such things. We are "agile," so we don't care about such things. As long as the client pays and he is happy, we have to deliver. If something goes wrong, remember the golden rule "just make it work." You want to be creative, sure, just do it at home in your spare time. Here we have to deliver.

My dear so-called "agilists " the fact that you are falling from the top of a skyscraper with high speed and you are not hitting anything on your way down doesn't make you agile at all; your ultimate target is the ground, enjoy your crash.
Published at DZone with permission of its author, Mihai Huluta.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)