Isaac Loloey — Fri, 07 Jan 2011 20:38:27 GMT

I really enjoyed your article. It makes some very valid points, which I have made myself in the passed. I am a certified Scrum Master myself, and I often encounter these problems and abuses.

I wanted to add that there are some of your points that are well accommodated by Agile / Scrum / XP.

For instance:

(1) From the section “Mine 2: The requirements gathering process is not defined”.

Scrum does have a requirements gathering process. Requirements are documented in the form of User Stories, and managed in a product backlog.
Although it is true that one of the biggest abuses of Scrum/Agile is that people think that it eliminates documentation all together. This is a common misconception and untrue.

(2) In the section “Mine 3: Pressure to cut corners” the author implies that Agile does not consider the clients needs in the development cycle.

“This can and does lead to impulsive design. ... you’re not adhering to user centric principles which suggest you should test ideas with end users before committing them to code.”

In the eXtreme Programing (XP), a different flavor of Agile, practitioners advocate having an “On-Site Customer”. A concept emphasizing the importance of the client’s needs.

“With XP, we get extreme about customer involvement. we’ll mandate that the customer be on the project full-time for the duration and be located on-site with the team.” – Stewart Baird

Refer to the following links:

http://www.informit.com/articles/article.aspx?p=30187&amp…
http://www.extremeprogramming.org/rules/customer.html
http://www.agilemodeling.com/essays/activeStakeholderPart…
http://www.xpexchange.net/english/intro/onSiteCustomer.ht…

(3) The following comment from the section “Mine 4: The temptation to call it “good enough” – “Agile condones releasing whatever we have so long as it works. Sometimes, that means doing what we can get away with, not what is ultimately best for the user. Equally, if we do decide that a feature isn’t right yet, it’s amendments get fed back into the requirements backlog where temptation strikes again.”

The truth is, that in every process people are guilty of releasing a product just because it fulfills the requirements. This is nothing unique to Agile. Iterative development is beneficial to meeting deadlines, otherwise products would never be released.

There are several points here that I do agree with like:

“Agile is also good at avoiding feature bloat by encouraging developers to do only what is necessary to meet requirements.”

and

“Because Agile requires a lot of engagement with the client (i.e. at the end of every iteration, which can be as little as a week) it mitigates the risk of going too far toward creating something the client doesn’t want.”
We often see that different tasks do have dependencies on each other. Development being dependent on design, QA being dependent on developers. Creates a constraint for tasks to be done simultaneously.

Boxes and Arrows: Comments by Isaac Loloey