Agile profile in style

I am currently in the process of transitioning to a new role at my workplace. The change for me will be one of moving from a system administrator position to a software development role, which I am more classically trained for.

The team that I am transitioning to has been trying out various aspects of different agile software methods, most notably focusing on Scrum. Having no formal knowledge of Scrum prior to a few days ago, I took it upon myself to not only review Scrum, but to become familiar with agile software development in general and various agile methods including Scrum, Agile Modeling, Test/Feature/Behavior Driven Development, and Extreme Programming.

Overall, I have found, based on personal experience, that traditional sequential development methods (such as waterfall, which is what I was taught in school) are quite excellent in theory, and that's about it.

Agile development seeks to reduce risk in software development by producing numerous iterations, establishing open and frequent communication, accepting change requests happily and gracefully, and keeping the design environment open and available for review.

I believe that agile is really a success story in effecting change from the bottom up (rather than the traditional org chart flow from top down)... which is probably one of the many reasons why it has taken and will continue to take some time for it to become the most common industry practice. I get the impression, based on the reading I have done, that developers of agile methods tend to have a chip on their shoulder with regards to establishment and order and could possibly be classified as classic computer hippie types. Certainly, one of the many tenets of agile methodology is the lack of hierarchy and chain of command. Ironically, this counterculture image actually conflicts directly with the basic tenets of Extreme Programming (XP). XP is based on solid, tested, programming methods, but taken to extreme levels. Therefore, in a sense, agile embodies the most tried and true development methods that have been developed and refined over time.

Agile methods do seem to be quite useful and quite popular as well. So I began to ask myself, "when shouldn't agile methods be used?" Well, there actually are a few cases where certain agile methods should be discouraged. They are:

• Projects involving critical systems where critical is defined as relating to the people's health and safety (e.g. medical equipment, aircraft control and management, etc.)
• Projects involving non-senior level developers
• Very large scale development (although this is being researched in terms of scaling)
• Company or organization with strict command and control structures

Of that list, the one that jumps out to me is the requirement for senior level developers. I fear this because the effect of it is not immediately seen, but rather, would be pervasive and hidden from view throughout the project. To the customer, the effect would be a longer time to develop, which might make them question the agile method in the first place.

Of all the flavors of agile, I believe my organization made a wise choice in selecting Scrum. The process itself is fairly simplistic (a quick 4 page read), yet it embodies the principles of agile quite well. The key to implementation will be to abide by all aspects, rather than picking and choosing what "feels" right. However, this is not as critical as fully embracing all practices of XP (as noted in the intro here).