Agile, Development, Software Design

The Good and the Bad of Agile Software Development


Agile or Scrum methodologies started as buzzwords in the software development industry and quickly fell prey to what all buzzwords do- managers who didn't try to understand the reasoning behind it and just took the elements they liked to try to fool their employees into working longer hours. It has since matured into a real process of real benefits, and many software houses (including ours) have used to deliver high quality software and increase communication to and with the customer.


The concepts behind Agile methodology (Scrum is actually a subset of Agile, but is often used as a synonym) are as old as the problems they try to solve: customers and managers want to know how a project is doing, the stakeholders in a project don't always know what they want later in a project until the earlier work starts, and nobody wants to waste time or end up with a broken buggy project. As it formalized in the late 90's, Scrum sought to break work into small but complete chunks, both so questions could wait until more info was available to be answered and so issues would be seen earlier and dealt with all along the development process rather than popping up at the end to cause delays and embarrassment.

In time, managers sought to incorporate some of these ideas into their existing processes as opposed to switching how they do things entirely. This makes sense of course- all people want to think that their ideas and work have meant something, so we all prefer to augment what we have been doing rather than throw it out and start over. Of course anybody would prefer to have the customer more involved in the software development and requirements process and also to produce fewer bugs. However, the developers on the front line realized that just being mandated to keep customers up to date and produce better code doesn't produce any results, so, in absense of other direction, they did the best they could. After months or years of these blends not working, many of these companies determined that Agile wasn't right for them and abandoned it in favor of the old way of doing things.

Lajos Moczar on gives a perspective on Agile that illustrates the rough takeoff it had. Despite having been involved as a developer, lead architect, and manager, his basic misunderstandig of the principles behind Agile has led him to conclude that it's just impractical. In observing that it's been implemented to value delivery overy quality, develoment over planning, and interaction over management, he's been mislead to think that this is the goal of implementing Agile, while he couldn't be farther from the truth. The crux of Agile is breaking down large projects into small and complete projects and tasks, each of which is completed independently of the other. Documentation, management, and planning are crucial to any project, Agile or not- the diference is that Agile projects only work on planning the immediate set of work, and leaves the rest of it to be planned and accounted for only when the next set of work starts.

GRS has implemented the principles of Agile as they were meant to be- we build complete, high quality pieces of software in short 2-4 week bursts. We only work on our current project, leaving the other items to be worked on for the next sprint; this not only helps us focus on what we're doing now, but also allows the customer to change his or her mind about what the next direction of the project will be without the penalty of wasted time and effort.