In a group of friends (all of us in the 20+ years experience range), one of us casually commented that one cannot expect good quality with the use of Agile processes. The argument alluded to how Agile methodologies prescribed cutting on elaborate requirements documentation, and starting to code even before having the complete design in place. The inherently poor design that is caused would “obviously” result into more bugs, code instabilities, floods and earthquakes.
While I countered the argument in the group, I kept wondering how many people must be holding this wrong notion in their minds. As the Agile2019 conference runs on the other side of the globe, I keep wondering how many such conferences would be needed to clear these perceptions.
The problem is that we are habituated to creating rituals out of everything, and agile methodologies are not spared from that. Having mugged up the rigorous waterfall process from the software engineering text books during our student days, we approach the new agile processes with the same mentality and kept looking for hard dos and donts to memorize. I have seen a Scrum Master who was completely hung up on the scrum team size and was not willing to accommodate an extra team member for that reason. Like muscles, if the processes become hard, they do not stay agile anymore, do they?
Agile processes, in the first place, arrived to challenge the rigour of waterfall, to supply lightweight alternatives to the ritualistic processes. These alternatives give us more choice on our menu, and let us choose the best buffet dish as per our needs and apetite. Across the world, people enjoyed this freedom to choose and pooled in their experience about what works and what doesn’t. That experience is the basis of the guidelines that we have today (and then they keep changing as more experience pours in). These guidelines are in no way laws carved in stone, and you could twist and tweak them as long as you understand their essence. That’s what keeps the agile processes agile.
Before ending the article, let me address the original comment on poor design. The Agile answer to that is to have the realization of technical debt you incur as a result of speedy development, and then to reserve effort to deal with this debt. You can then tighten the screws around the quality as much as you want.
To tell you the truth, I expect this answer to be well-known among all the practitioners. Yet we forget to it in practice many times, and give birth to such incorrect perceptions. Comments?
Further reading:
- “Stop being ignorant! Agile is not synonymous of crappy quality” – by Luís Gonçalves
- “I can’t take this agile crap any longer” – comment on Hacker News.
this blog is very helpfull, thanks for sharing and information.