I hate Geometry.
Actually, I do not hate the concept of Geometry – I’m rather partial to shapes and appreciate the need to calculate the areas, perimeters, volumes, et al that they represent. What I hate about the subject – or should I say “hated” (past tense) since I haven’t had a Geometry class since the mid-1980’s – were the proofs I had to do in order to get full credit for my work.
I’m a results-oriented person. I’m usually far more concerned about getting things done right than getting things done the right way. Sometimes I think there’s a bit too much focus on the process of how things are done and not enough focus on the quality of the result that comes from that process.
This is one of the reasons why I am vexed by the frequent bastardization of real agile development where the need for a speedy process overtakes quality initiatives.
Right Path vs. Right Answer
When done right, agile is not a problem. When done wrong, agile is the problem.
The intent of agile is to break a project into X-number of pieces so that instead of one group trudging through an entire project, many groups - or scrums - develop the parts of an application in a fraction of time. Not only should this make the development process more efficient, but it should also allow developers the time to scrutinize the work they do so the result is of a greater structural quality.
As certified SCRUM master and Agile proponent Charlie Martin recently posted over at Software Quality Connection, however, far too many companies use agile as “window dressing.”
…people learn the phrase “agile methods” and think they sound cool, but they adopt only some of the window dressing – something I’ve called “cargo cult agile.” There’s this general notion that as long as you do some of the things that “agile people” do, you’re using agile methods.
What can be even more insidious, though, is when people think of “agile” in terms what agile methods don’t do. Agile minimizes upfront design, so obviously you’re being agile if you eliminate upfront design. Agile minimizes process, so you just eliminate process.
The result is what Dilbert‘s boss summarized as “No more planning and no more documentation. Just start programming and complaining.
Martin points out that this half-hearted approach to agile actually is contrary to the tenets of the true Agile Manifesto, which preaches the minimization of overhead, adapting to change, putting interaction, collaboration and communication ahead of process and, perhaps most importantly, comprehensive concern over the quality of the resulting software.
Martin says that achieving quality in an agile environment can be hard; that it takes discipline.
It means saying “No,” and often you’re saying No to your boss. No, you can’t come on Thursday and get an additional feature on Friday; put it into the user stories and we’ll schedule it. No, you can’t shorten the schedule by two weeks unless you choose which user stories you don’t need.
Unfortunately, in this day and age such discipline can be difficult to justify and developers may need to support their need to slow down the process. One thing they could do is to incorporate automated analysis and measurement into the build process to identify issues as they go. These issues can then be translated into financial terms (along the lines of how CAST calculated technical debt in its CRASH study in December), which can place developers and management on common ground for discussing the need to place more focus on structural quality of the software rather than committing all efforts to a “just get it done fast” attitude.
After all, and with all due respect to the late John Downs, my ninth grade Geometry teacher, the quality of the result is more important than the process.