TOP TOC 
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.
Agile . since Jun 23 . Index . DOCs TOP TOC
In my years in software research, I have found that most knockdown, drag-out fights are almost always about homonyms. The really heated discussions occur when two people (or groups) mean very different things by some word or phrase. For example, "objects" (or "object-oriented") means one thing to people trained in and committed to OO and often something very different to those brought up in another form of programming.
The same thing is true about the term data warehousing or requirements engineering. In practice, the same term may mean a number of things to a number of different people all engaged in the same conversation, which creates, as you might imagine, huge opportunities for both confusion and misunderstanding. If you're lucky and no one has become rich by exploiting this confusion, you can finally sit down at the table and discover that, in most areas, you actually agree with the people you've been fighting with.
But misunderstanding what the other guy really means makes communication difficult, to say the least. As I learned from long years teaching in this field, it doesn't matter what you say; what really matters is what the other guy hears. I remember listening to a public radio interview one day where the interviewee was one of the most renowned language teachers in Hollywood. The interviewer asked him who made him so successful. I think the answer should be posted on every training room in the world: "Well, I always figured if someone did get what I was trying to teach them, it was my fault." We all need to take that attitude when trying to communicate with others, especially others with whom we are in strong disagreement.
As a rule, technology folks are not good communicators. And, over a period of time, especially when what you're communicating is complex (and it usually is) or people reject what you're telling them (which they often do), your critical words and phrases begin to take on emotive characteristics.
At a certain point in a long-term debate, for example, the word object comes to mean good. So when certain people say OO programming, they are really saying good programming. This makes it difficult, if not impossible to talk about alternatives, since, of course, non-OO programming means bad programming, and who in their right mind would want to talk about bad programming?
In a similar fashion, the word agile currently has lots of meanings; some of them are in common use in our latest software war. But the emotive use of agile as in agile development is of recent vintage and may or may not mean what agile means in common discourses. To me, agile conjures up visions of acrobats and gymnasts or organizations that can quickly change. It is not clear that this is what those who talk about agile development really mean.
Or what about quality? Quality is another one of those key phrases. The word quality occurs frequently in CMM material. Who wouldn't want to develop quality software? Clearly, quality means good -- nobody would want to develop non-quality software. But does quality software mean that we have to have tons of paper documentation?
Everyone, or nearly everyone, in the software business wants to do better; it's just that different people have different visions of what better means. Some people think that better means more control and less variability. Others think better means quicker, with less paperwork.
What should we be doing? Most CIOs and lots of systems development managers would like to do better but they are deathly afraid of fragging.19 They are afraid that if they institute a change that either their programmers or users don't like, they're toast. Programmers are a tough group, and in many organizations, they have keys to the company jewels.
Personally, I am skeptical about convincing many CMM Level 3 organizations to become agile. I am also skeptical about trying to sell the value of business modeling and design documentation to a shop that has bought into agile development.
But everyone can learn. If we are a large CMM Level 3 or 5 shop, we should be constantly questioning whether we need every bit of paper that we currently require. What if we substitute prototyping for user interface screens on paper? Wouldn't that be better?
What about agile organizations? Maybe they could begin to look at some of the metrics that CMM shops keep and see whether they wouldn't be useful even in an agile environment.
My personal feeling is that the most important thing that we can do is to keep an open mind. Software is not religion. We don't need priests; we need artists, architects, and engineers. We need people who can build quality (here's that word again) software again and again. We need to be able to promise something to someone and mean it.
I think that agile development is a truly disruptive technology. I think that most organizations can learn something about doing a better job at software development by studying agile development and that most organizations can also learn something from studying CMM. And, I think that much better ways of developing software are on the way.