Agile Doesn’t Have to Mean Sloppy
Whether it’s software, product development, or a series of novels, just because something is done quickly doesn’t mean that it’s not well thought out.
My last blog post on the benefits of shorter release cycles generated some conversations on twitter pertaining to whether or not small, focused releases result in “continuously crappy buggy software.” I’m following up to contend that agile doesn’t have to mean sloppy.
What is Agile?
To understand why agile doesn’t mean sloppy, it’s important to understand example what agile means. The term ‘agile’ as it applies to software development was introduced 10 years ago in the Agile Manifesto, which reads as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
The inability to quickly incorporate feedback and change direction highlights the biggest weakness of waterfall-esque methodologies. If you’re in the business of responding to change, a three-month release-cycle just isn’t going to cut it.
How about a nice game of chess ?
In addition to the manifesto, the progenitors of the agile movement developed a set of principles. Two of these principles directly address software quality: “working software is the primary measure of progress” and “continuous attention to technical excellence and good design enhances agility.”
You can’t consider yourself agile by going through the motions, paying lip service to short iterations, and treating testing as little more than a necessary evil. From the outside, it might look like agile, you might even call it ‘agile,’ but you most certainly will not be delivering “working software” that ascribes to “technical excellence” and “good design.” To reach that point, every iteration (no matter the duration) should still go through the full development cycle: planning, requirements analysis, design, coding, unit testing, and acceptance testing. Those last two steps are important and bear repeating: Every iteration needs to go through unit testing and acceptance testing. Every time. No excuses. If you’re not doing that, you’re not agile.
