Reactions to Agile

I mentioned last time that my teams are now using Agile practices in our software development efforts. When you say something like that to another developer (or development manager) a range of responses often occurs -

"Sounds like you guys are hacking", or

"Agile uses strange new-age, communal development practices", or

"Agile only works for small, open-source efforts, not bigger projects", or

"Agile doesn't work when you're told the date you have to ship to customers (or clients)"

Basically, you can sum up the reactions to that of skepticism. Agile seems like something that is too good to be true - you can abandon the heavy structure and process found in most development efforts for a highly iterative, reactive model. People schooled in formal process/project methods would call that hacking, no doubt.

But there lies the first misconception about Agile and the various approaches to Agile that have developed around the world. The first thing to understand is that there is no one way to do Agile software development. There are several different mainline approaches and undoubtably many hybrids that are in use in the field. The one that many developers first learn about from magazine articles, hearsay and so on is the method popularized by Kent Beck called XP or Extreme Programming.

Beck describes XP as the following from his book Extreme Programming Explained:

XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop software

Later he goes on to state that:

XP is a discipline of software development

Note the use of the phrase "software development" as a way of placing XP's emphasis on the development part of a project. Although XP has mechanisms for dealing with how features are selected for implementation, and for estimation of those features, it focuses most of its attention on how developers can collaborate to develop those features more productively and with higher quality by introducing 5 principles:

• Rapid feedback


• Simplicity


• Incremental change


• Embracing change (i.e. change is a good thing)


• Quality

Rapid feedback stresses getting responses from the intended users of software as quickly as possible. This feedback is both to assess the features that were developed, and to guide what features will be developed next. This replaces the mentality of assuming that all features can be determined at the outset if only enough effort, people or time is expended.

Simplicity stresses building the simplest thing that could possibly work. That is, building only what is absolutely necessary to fulfull the expectations of the users. Many if not most software development efforts struggle constantly with how much effort to expend on architecture, infrastructure to handle assumed future features, new technology, flexibility, customization, and so on. Basically, developers are smart people and they like to show it by creating an application that can readily adapt to changing needs. They also like to work with new technology and use the latest architectural/design approaches. Left uncontrolled, this can quickly spiral into a system that is overly complicated and tragically is never as flexible in the end as was initially assumed.

Incremental change stresses making changes to a system bit-by-bit rather than the proverbial "big-bang". As features are suggested by customers, and changes are identified by the developers, these changes are introduced as time proceeds rather than all at once which would likely destabilize the system in the process. This value is one that would likely annoy developers particularly those that see the end design, architecture or whatever if only they could scrap the existing system (or part of it) and just.. rewrite it!

Embracing change stresses the concept of the developers assuming that change is inevitable in any system that is growing. A system that does not grow is either dead or dying. However, grow does not mean that it is only adding ever new features on top of existing ones. It also means it is modifying existing features for changing needs, and pruning ones that no longer are needed. In essence, it's the realization that a software system is never "done". Instead it is in a constant state of flux as it reacts to changing demands on it by users. This changes the time horizon for developers by focusing less on the destination and more on the journey.

Quality stresses the need for a system to be of high (or release) quality at all times. In a typical system, quality passes through stages where early on in its development, quality is very low as the system is constructed. Later as more of it is "finished" quality increases as features work as intended and defects are gradually identified and removed. Finally, at some future point (like just before the scheduled ship date), the quality is at an acceptable level and is ready for use by users. Gee. If it worked that well, we'd have no need for any other process. Too bad we know that this is almost never the case. Projects routinely spin off into the 95% complete level for 2 years because bugs are found at the rate they are fixed, or a project runs off a cliff with the bug rate increasing faster and faster even as bugs are fixed. I've been very fortunate to never have worked on a small or large project that suffered the fate of the latter, but I have seen projects in my midst that have. It's not a pretty sight.

Next time I'll talk more about the ways that XP provides techniques to support these principles.

Homework: Read Extreme Programming Explained by Kent Beck

Technorati Profile

Posted by Mark M. Baker at 10:14 AM  Permalink