Agile Software Development

As I am currently in a transition phase out of my current job, I have been looking at my résumé a lot. I noticed that I do not have the word "Agile" on it at all. This is interesting to me because it was something that I tried to promote just a few years ago. I think that has a lot to do with how I view software development now. While listening to a .NET Rocks round-table podcast a few months back, the question, "Is agile dead?" was posed. The answers were pretty interesting, but the one that stuck out to me the most was something along the lines that agile isn't dead, it is just the way we do software development now.

On the shows's page, a listener, "bashmohandes," made a comment that I have been thinking about for a very long time:

I don't think Agile is dead, but I think it got ruined by companies that think they are doing it but they are just fooling themselves, or using it as an excuse to keep changing requirements on the poor developers.

Most of the places I worked at, have some remnants of agile methods, like daily scrums, but pretty much nothing more, no fixed size sprints, or spring planning meetings, or retrospective meetings at the end of the sprint, or pair programming.

Specifically, that companies are "using it as an excuse to keep changing requirements." While I am leaving my current position, this is something that I have been struggling to keep from affecting my team. There are a few people in place who could fix this—but they don't. In fact, I don't think they know how to. It was recently told to me that we develop software in "a more waterfall approach." This made me laugh a bit as we don't even follow waterfall. That whole requirements gathering thing is a joke. The developers are currently expected to read the customer's ever changing mind and it is difficult to pin them down.

My current project has been around since the 70s and supports a major command of the USAF. The failure of the application means that troops and supplies are halted and commanders can lose situational awareness of their fleets. But, even with how critical this application is, there is hardly any structure when it comes to defining requirements and paving a path forward. Listening to the podcast really hit home. So many managers seem to want a "spray on agile" solution as if it is some sort of magic. Well, it isn't and "spray on solutions" don't work. In fact, they make things worse.

On the web development side of the shop, I have been able to focus everybody's attention on unit testing, pair programming, and actually talking with the stake holders. Unfortunately, the planning portion is still lacking. Our side of the house has been strategically made void of information silos. Unfortunately, on the COBOL side of things, they still exist. Each COBOL programmer works at their own pace, makes changes, and throws them at the web team to handle. Cause we're agile.

While I believe that true agile is the way to go in software development, I also take a pragmatic approach to things. When initially implementing an agile methodology, it is usually very difficult to get everybody on board, up front, and willing to make all the changes necessary to truly support the change. But, it is important to keep going, keep adding things, keep changing, keep growing, keep learning. It really takes a substantial commitment from management, the customer, and the development team, to realize that they are all in it together.