TOP TOC 
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.
Agile . since Jun 23 . Index . DOCs TOP TOC
In writing this article, I have come to the somewhat disturbing realization that, in my own organization, we have evolved a form of agile development. For one thing, we don't have much in the way of formal documentation. As the sole user/designer, I basically explain what I want on a white board and my partner Randy develops a prototype of what I have asked for. After I play with the prototype for a while, we revise the solution and come up with another version.
In general, this works well for us. We're small, we know what we want to accomplish (we've been at it for a very long time), and we're working in a very complex systems environment -- trying to interface between the internal metadata of two very sophisticated development tools.
A good deal of the success of this current venture is due to the experience and the style of the user and programmer here. Randy is a marvelous programmer who knows (or can pick up) just about any programming language or database management system. He is also fearless and self-taught. Once he gets his teeth into a problem, I'm confident that he will figure it out.
Then there's the chief user: me. I've been in the software development business since the 1960s, and I've been working to develop more powerful tools for modeling business problems and automatic design for the past 25 years. Although I sometimes don't know exactly what I want the final product to look like, I'm sure I'll recognize it when I see it. Finally, the problem is not huge. The key to the tools that we're trying to develop is integration and ease of use. That makes us an ideal candidate for a form of agile-like development.
But there are a number of pieces of agile development that we don't employ, such as test-first development and pair programming. Moreover, we're still going to run into the problem of documentation, which we haven't done as we've been going along.
Now I also feel the need to comment on a previous attempt to solve the same problem. Back in the 1980s, a larger organization (which I would characterize now as CMM Level 3 or 4) and I attempted to do what Randy and I are doing now with just two people. We used a strict methodology, imposed on us both by our customer and our own marketing, and we failed to produce very much (though we did learn a lot about how not to do what we were trying to do).
Even then, I was pretty sure that the approach would not yield success. Part of our difficulties had to do with the problem domain. No one had ever done what we were attempting to do (they still haven't), and the base technology wasn't there. In the mid-1980s, there was very little in the GUI tools or standards, no one knew which way the industry was going, and many of the database tools and code generators had yet to be invented.
What I'm saying -- from my personal experience -- is that heavy methods don't work as well when there is lots of uncertainty about the technology or the problem. Agile methods work much better when the user and the developer make it up as they go along. On the other hand, there are large classes of problems that are simply too big to be done by such small teams. And coordinating lots of tiny teams of two or three is just as big a problem as coordinating teams of 10 or 20. Scaling agile development is likely to make it look more like CMM than many agile developers want to admit.
In the end, there is no fundamental conflict between CMM and agile development. The objective is producing better software. There is no one way to do this. CMM and agile development both have a lot to offer. CMM plus agile development plus better tools is likely to produce a hybrid that will make for better software for everybody.