TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Where does agile development fit on this next practice diagram? Well, since it is relatively new, there are not a lot of statistics for agile development projects. Based on the reading that I have done, I would place agile development in Q4 (next practice). From everything that I understand about agile development, it attempts, and to a high degree succeeds, in gaining a lot of knowledge -- especially about the functionality and behavior of a new program or system -- with less effort than you would ordinarily expend. My guess is that a typical agile development project would not provide as much knowledge as might be gained by a CMM Level 5 organization, but it represents a different way to get the information.
It is useful to look at the next practice quadrants as a way to compare CMM and agile development as it points out some interesting things to think about. By focusing on knowledge versus effort, it provides an analysis framework that can be used to think about alternative ways of doing things (see Figure 7). Various questions can then be posed (e.g., "What do we learn from this?"; "Is the knowledge worth the effort?").
 Figure 7 -- Agile development and the next practice quadrants. |
Though agile development may not be mature yet, it has come on strong in recent years, and any serious software development organization ought to look at it. The agile development people have taken a very Alexandrian approach to solving the software version of the Gordian knot. Instead of trying to unravel the traditional software ball of twine, the agile development gurus have simply sliced it in two. Everything that they feel doesn't contribute to direct user communication or the end product is out.
Agile . since Jun 23 . Index . DOCs TOP TOC
At 40, I resolved not to work on a project that didn't leave behind a tool. Social change simply takes too long.
-- Buckminster Fuller
From the first time I read the Agile Manifesto, I felt that the agile development folks had taken a bad turn. Their very first proclamation is that they value "individuals and interactions over processes and tools." Right there, I felt that the agile developers had boxed themselves in every bit as much as the CMM folks did when they focused so much on "the what" over "the how" of software development.
Software development, like so many things, is an integrated activity; you can't take just one piece of it in isolation. Those of us who spend our lives trying to get others to take advantage of technology are at the same time some of the most backward users of technology. Coding is not an art form any more than circuit board layout is; it is simply a means to an end.
Whether it is Java or COBOL, programming is still programming. As long as we do it principally by hand, we won't be able to make anywhere near the strides that our counterparts in hardware design have made over the years. Imagine if there were a Moore's Law for software. We would go generations beyond Windows XP, generations beyond Oracle 9i, and generations beyond SAP and PeopleSoft.
Software continues to be dragged into ancient discussions about programming style and programming collaboration. If we spent half the effort building and using better tools to support better processes, we wouldn't have so many Dilbert-esque discussions at technical meetings around the world.
Lots of people involved in the current software wars have failed to notice that while debating the right way to do OO design or refactoring, a large part of the world stopped doing development at all. Today, more and more of my clients are in the business of finding, modifying, and installing clumsy, bloated software packages because they got tired of cost and schedule overruns and functional underruns for major software projects.
I strongly believe that agile development will only have a really major effect on the software industry when it stops drawing the line in the sand that says, "Look -- we're people people, and we're not into tools or processes."
There is no other area of science or business that takes this point of view. Indeed, all of the advanced sciences and businesses invest more and more of their resources in leveraging technology to help them do more in less time.
I have been developing a requirements and prototyping methodology called agile requirements for some time now. It is built around the integration and use of state-of-the-art tools to help analysts, designers, users, and developers understand their problems in business terms and then, as automatically as possible, design databases, generate programs, and prototype those business requirements and processes. I consider this approach to be an advanced form of agile development, and I see it fitting on the next practice quadrant diagram high in Q4 (see Figure 8).
 Figure 8 -- Advanced agile development. |
All advanced approaches today are a synergy among people, technology, and communication. Choosing one of these elements over the other tends, like only pulling on one oar, to drive the software boat in circles. We need everyone pulling as fast as we can if we are to take advantage of what people are good at and what technology and communication are good at.