TOP TOC 
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.
Agile . since Jun 23 . Index . DOCs TOP TOC