Don Wells

Position statement

The paper by Dr. Boehm describes a scale from cowboy hackers to Inch-pebble ironbound contracts. The former has a complete lack of both plan and design documents while the latter has plenty of both. There seems to be an omission in the scale. We are not considering the possibility of having a plan without a design document or vise-versa. This scale could be extended into two dimensions on this basis. The characterization of agile methods as being light on planning seems inaccurate. In my experience the real difference in planning between agile and convention methods is the emphasis on planning placed by agile methods as opposed to a plan for conventional methods. In Extreme Programming long rang plans span large amounts of time but contain few details, while short term plans contain plenty of detail but span very short periods of time. Each level of planing considers an appropriate level of detail and time span. See figure 1 below.

The next important step is to realize when a plan is no longer accurate and create a new plan. Instead of constantly striving to catch up to the schedule XP says, "this is where I am now. Where can I be in 6 months?" In XP a plan is always based on actual measured progress to date. Estimates not based on a measurement are guesses; estimates based on measurements are predictions. It has been my experience that conventional methods produce plans not based on what can actually be achieved but rather on what is desired, rarely are they the same.

Another premise is the requirement of "premium people" within an agile environment. It has been my experience that this is exactly wrong. Within an environment of constant interactions people are not able to go astray for long periods of time. No one works alone. If anything, plan driven projects require premium people more because team members are able to work in isolation creating a mess for each other. Two average programmers with good teamwork skills will contribute more than two isolated geniuses working at cross-purposes. I agree with the quote "A few designers sitting together can produce a better design than each could produce alone." However I disagree with the interpretation. A premium designer can easily create an excellent design alone. It is only in the case of average programmers that a boost in quality is required through collaboration. But there is something further to consider in the former case of one architect creating the design; will there be as great a compliance with that design as in the latter case where the entire team has created the design together? My experience has been that in the case of one person as architect there will be little compliance with the design. The result is unrecognizable as an implementation of the design. However when the entire team designs the system the code reflects the design as desired. The question then is do we need the design to be written in the form of a document if the entire team was involved in its creation and is intimate with the details in a way not possible with conventional methods?

Dr. Boehm asserts "The team will make irrecoverable architectural mistakes because of unrecognized short falls in its tacit knowledge." I can't help but wonder how one could have more knowledge before starting a project then while shoulder deep immersed in it? A plan driven approach does allow for expert reviews prior to construction beginning. But I don't see how this precludes an agile method making use of the same experts during construction at key decision points. It has been the norm to accept the customer who has been made available as the one and only customer. More and more this is being seen as an exception and not the norm. It is my position that the manager is ultimately responsible for tacit knowledge sufficiency by bringing in the correct customer or expert as needed and insuring long-term goals are met. There is indeed a real danger of getting the wrong customer or missing long term goals while satisfying an endless string of short-term goals. I do not believe this is a shortcoming of the method but a shortcoming of the manager. It is indeed much easier to get a document approved than it is to watch over a project and detect a need. This brings us back to the Constantine assertion "There are only so many Kent Becks in the world to lead the team." In fact there is only one Kent Beck and he does not lead teams at all! Should we throw away a methodology because it requires managers to have management skills other than creating Gantt charts?

In the section on refactoring we are given this statistic "20 percent of the problems causing 80 percent of the rework came largely from architecture-breakers." I have a very different conclusion than Dr. Boehm, it isn't about refactoring it is about the team understanding the architecture and being able to respond to change as needed. If the architecture is locked down by a few premium people at the beginning of the project then the average programmers on the team are going to create "architecture-breakers". What choice do they have? If the entire team understands the architecture and can change it based on needs that are not recognized until mid project than there will be fewer "architecture-breakers."

In conclusion I should contribute something other than just a critic of Dr. Boehm's article! I believe that agile methods can work on large teams if we accommodate them by altering our concepts of what coordination means. What if coordination meant something other than enormous amounts of detail captured into huge documents? What if there was some strong sense of what is built now and feedback that would help us predict the future? I disagree that the best way to account for future needs is to decide today what those needs might be. The best way is to stay as ready as possible to include any needs that might arise and that is what agile methods are all about. I admit to not having enough experience to say what application areas might not be amenable to agile methods. I do know that agile methods stress testing and therefore consistently produce code which is above the average in quality.

Figure 1.

Experience with Agile Methods:

3/82 - 2/87 Working at General Dynamics as part of the Artificial Intelligence lab we used ad hoc light methods to rapidly produce software where conventional methods would be too expensive. We experimented with iterative development, and collective ownership. We followed the discipline of knowledge engineering, which at that time meant having a customer in close contact guiding the project on a day to day basis.

2/87 - 4/95 Ford Motor Company, part of a 150 person team to create an intelligent diagnostic system. The project team was divided into many smaller groups each following a different method. The AI team followed an ad hoc rapid development method. We practiced iterative development, refactoring, collective ownership, and had customers integrated into our team.

4/95 – 6/97 the Chrysler Comprehensive Compensation (C3) project.

6/97 – 3/99 Ford Motor Company, VCAPS project. Applied XP to that project. Most practices were followed except onsite customer and planning game.

Currently at DaimlerChrysler advising projects on methodology and object oriented concepts. Some teams are more agile than others are.