ACCESS TO THE EXPERTS

The Journal of Information Technology Management

January 2002 Vol. 15, No. 1 The Great Methodologies Debate: Part 2

Resolved “Today, a new debate rages: agile software Traditional methodologists development versus rigorous software are a bunch of process- development.” dependent stick-in-the-muds who’d rather produce flawless Jim Highsmith, Guest Editor documentation than a working system that meets business needs.

Opening Statement Rebuttal Jim Highsmith 2 Lightweight, er, “agile” methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise Agile Software Development Joins the when they try to scale up their “Would-Be” Crowd “toys” into enterprise-level Alistair Cockburn 6 software.

The Bogus War Stephen J. Mellor 13

A Resounding “Yes” to Agile Processes — But Also to More Ivar Jacobson 18

Agile or Rigorous OO Methodologies: Getting the Best of Both Worlds Brian Henderson-Sellers 25

Big and Agile? Matt Simons 34 Opening Statement

by Jim Highsmith Who wants to fly a wet beer mat? rigorous (or whatever label one expect significant variations in the What is the opposite of a Bengal chooses) methodologies — a others. High-level CMM organiza- tiger? For answers to these and “chaordic” perspective, “collab- tions tout their ability to achieve other intriguing questions, read on! orative” values and principles, and their planned goals most of the “barely sufficient methodology.” A time (99.5% was reported in one As I’ve read through the articles chaordic perspective arises from article on a new Level 5 organiza- for the two methodology debate the recognition and acceptance of tion [1]). Agile developers would issues of Cutter IT Journal, I’ve increasing levels of unpredictability counter that this level of predict- wondered at times about the in our turbulent economic world ability is a sham — either the “debate.” It seems that no one and that traditional plan-then- result of overpadding the plans or wants to be thought of as rigid, execute methods based on eliminating any risky (turbulent) stiff, or inflexible, so the agile stability and predictability will be projects from the portfolio. To agile bandwagon has become very the debate rages unsuccessful in this environment. developers, responding to change popular. Several of the articles in This perspective on turbulent is more important than conforming this issue — one by Ivar Jacobson, change has a profound impact to a plan. In a moderate- to high- a principal author of the Rational on how agilists approach project change environment, responding Unified Process, and those by management. Two concrete ramifi- to those changes and achieving Alistair Cockburn and Steve Mellor, cations of trying to manage in an 99.5% conformance to plan are both authors of the Agile Manifesto unpredictable environment are incompatible goals. This “perspec- — seemed to be more focused on that (1) while goals are achievable, tive” difference doesn’t converge, explaining away the differences projects themselves are often nor should we want it to. The than explaining them. I don’t mean unpredictable, and (2) the foun- issues surrounding highly changing to imply that this convergence is a dation of many process-driven environments and how to respond bad thing, just an interesting one. approaches, the goal of repeatable to them will remain fruitful ones However, don’t be lulled into the processes, will be unattainable. for debate. conclusion that the debate has Jeff Sutherland directly addressed Second, as Alistair Cockburn abated. By converging on some this “predictability” issue in last points out in his article, sometimes issues, others are highlighted. If month’s issue. the differences are in emphasis. there were no differences, there By project unpredictability, I mean Agile developers, as described in would be no debate, and the that the traditional measure of the Agile Manifesto, have a laser response to these two issues of project success — conforming to focus on people issues, hence the the Journal has shown that there scope, schedule, and cost plans — second characteristic of agile are certainly debatable issues is an unrealistic goal. In highly development: collaborative values in this agile versus rigorous volatile environments, the best we and principles. Cockburn’s article methodology arena. can hope for is to focus on a single contains words like “team,” I think there are three categories characteristic — scope, schedule, “community,” “reflecting,” and of issues related to the agile versus or cost (usually schedule) — and “amicability.” If you were to ask

2 January 2002 ©2002 Cutter Information Corp. him about tools, he would prob- agile chaordic perspective, one Cutter IT Journal® ably say, “Oh yes, you need good, that suggests creativity and innova- Cutter Business Technology Council: ‘light’ tools also.” Cockburn tion occur in a slightly messy envi- Rob Austin, James Bach, Tom believes strongly in automated ronment, not a mostly structured DeMarco, Jim Highsmith, Tim Lister, Ken Orr, Dick Nolan, Ed Yourdon testing tools, for example. How- one. It comes from the complex ever, his emphasis is probably adaptive systems concept of Editorial Board: Larry L. Constantine, Bill Curtis, 80% collaboration and 20% process balancing “at the edge of chaos.” Tom DeMarco, Peter Hruschka, and tools. A barely sufficient methodology Tomoo Matsubara, Navyug Mohnot, eliminates non-value-adding activi- Roger Pressman, Howard Rubin, On the flip side, consider the Paul A. Strassmann, Rob Thomsett ties and minimizes documentation emphasis areas in Ivar Jacobson’s (and cost), but most importantly, Editor Emeritus: Ed Yourdon article. In the first sentence of the Publisher: Karen Fine Coburn the “barely sufficient” emphasis second section, he states that soft- Managing Editor: Karen Pasley supports the concept of collabora- Production Editor: Linda Mallon ware development is a highly tion (and the idea that too much Client Services: Christine Doucette creative undertaking and then structure adversely impacts Cutter IT Journal® (ISSN 1522-7383) recommends enhancing the collaboration) and is driven by is published 12 times a year creative environment by applying by Cutter Information Corp., a chaordic perspective. tools, processes, and automated 37 Broadway, Suite 1, Arlington, MA 02474-5552 (Tel: +1 781 648 8700, knowledge bases to the 80% of So as you read these articles and or, within North America, the work that he labels as repeti- try to reach a convergence of ideas +1 800 964 5118; Fax: +1 781 tive. Jacobson’s solution involves that might work for your organiza- 648 1950 or, within North America, +1 800 888 1816; Web site: working on the non-creative piece tion, keep these three viewpoints www.cutter.com/consortium/). in order to free up time for the in mind: a chaordic perspective Cutter IT Journal® covers the more creative work. Cockburn on the turbulence and change software scene, with particular emphasizes how to improve the that project teams face, the extent emphasis on those events that will creative piece. There is some to which a collaborative set of impact the careers of information technology professionals around combination of both, a conver- values and principles resonates the world. gence of ideas, that most orga- with your organization’s culture, ©2002 by Cutter Information Corp. nizations will employ. However, and whether or not a barely suffi- All rights reserved. Cutter IT Journal® the tough question is how to cient methodology would be is a trademark of Cutter Information balance, because the two areas “enough” for your company. Corp. No material in this publication may be reproduced, eaten, or are not independent. Too heavy an distributed without written permission “There is no opposite to agile emphasis on tools and process — from the publisher. Unauthorized software development,” writes even if the 80% “repetitive” work is reproduction in any form, including Cockburn in our first article. “The photocopying, faxing, and image the target — can adversely impact scanning, is against the law. word ‘agile’ depicts where people the “collaborative” environment choose to focus their attention. Subscription rates are US $485 a year and thus creativity. Too light an in North America, US $585 elsewhere, Alternatives to agile software emphasis on tools and process, payable to Cutter Information Corp. development arise as soon as they Reprints, bulk purchases, past issues, and the team will spend all its time focus their attention elsewhere.” and multiple subscription and site fighting fires and have little time to license rates are available on request. He argues that there is no opposite be creative. to agile, that non-agile is a non- The concept of a barely sufficient thing. In so doing, he suggests methodology attempts to answer altering the debate from the the question of how much “struc- correctness or incorrectness ture” is enough. It derives from the of approaches to software

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 3 development to a debate about “abstract” forms. Mellor concludes development, 80% of the work where we place our emphasis. Do that few would argue over the remains repetitive, routine work we emphasize predictability or need to sketch out ideas, or that is amenable to automation maneuverability? Do we empha- over the benefits of executable through standard processes and size community or predictability? models, so the prime area for automated tools. Furthermore, he By altering the debate from debate is over blueprints. He views the RUP as an extensive either/or to where to place our goes on to discuss the progress knowledge base upon which emphasis — which may change in executable models, such that teams can draw as needed. By from project to project based on debate over blueprints may soon systematizing and automating the the problem domain — Cockburn be a non-issue. 80% of the work that is routine, helps frame the debate in collegial, Jacobson contends that the Ivar Jacobson, vice president of respectful ways. He then charac- remaining 20% that is creative Rational Software and a primary terizes the four critical factors in will then be even more effective. author of the Rational Unified “would-be-agile” development as Process (RUP), recommends Brian Henderson-Sellers outlines (1) short iterative development combining “rich” and “light” an approach, the OPEN process, subprojects, (2) frequent reflection elements to form an agile process. that he believes can accommodate and feedback on practices, (3) He argues that “light” and “agile” both agile and rigorous compo- working together in close prox- are not equivalent and that rich nents under one framework. He imity, and (4) attending to the tools and process help yield flex- agrees with the camp that says amicability and morale of the ible, creative, and rapid develop- one size doesn’t fit all, but he community. ment. The term “barely sufficient cautions that the opposite In “The Bogus War,” Steve Mellor methodology” should actually approach of custom building contends that the war between contain a brief qualifier; it should processes for each project is too agile and UML processes “is be “a barely sufficient method- expensive. The OPEN Process caused, or at least made to appear ology for the job at hand.” Alistair Framework utilizes a metamodel, more serious than it is, as a result Cockburn’s Crystal Methods — a repository of processes, and of mistranslation of a word. The Clear, Orange, and so on — are usage guidelines as components mistranslated word is ‘model.’” examples of barely sufficient in constructing a process to fit a Mellor’s article therefore falls methodologies for different particular situation. into the category of the debate problem domains. Orange (for Finally, Matt Simons addresses surrounding “barely sufficient a 40-person team) is “heavier” one of the key issues in the debate methodology.” He goes on to than Clear (for a 6-person team). surrounding agile development — define three categories of “model” Cockburn begins with minimal project size. While a significant — sketch, blueprint, and exe- process and tools and scales up, amount of the press surrounding cutable — using the example of while Jacobson begins with an agile approaches has focused on “models” in airplane development. extensive knowledge base — the small, colocated teams, Simons A sketch might be the “back of the RUP — and customizes down. reports on one of a growing num- napkin” variety; a blueprint is more There are certainly advantages and ber of successful agile projects detailed, but still at odds with the disadvantages to each approach. that are in the 50- to 100-person finished system; and an executable Jacobson writes that while category. The project, done at is when the model and code are creativity drives software consulting firm ThoughtWorks, equivalent “concrete” rather than

4 January 2002 ©2002 Cutter Information Corp. involved 75-80 people over an While the ThoughtWorks project REFERENCE 18-month period and delivered was staffed with more people, 1. Ferrarra, Linda, and Cathy approximately 750,000 lines of it was completed in nine fewer Timko. “The Telcordia Java. Simons discusses how months than the industry best in Technologies Road to Quality.” ThoughtWorks used the baseline class, while matching best-of- Cutter IT Journal, Vol. 13, No. 2 practices of XP and then added class numbers in total effort and (February 2000), pp. 28-34. additional collaboration practices productivity. Not bad! to handle the larger team size. In the second issue on the “Great Just for fun, I wondered how this Methodology Debate,” you’ll find project stacked up against industry another wealth of lively, thought- averages. Since I didn’t have provoking, and entertaining arti- access to Cutter’s metrics guru cles. My thanks to all the authors at the time I was writing this, I for their wonderful contributions. pulled out my copy of Software Assessments, Benchmarks, and Best Practices from Capers Jones (Addison-Wesley, 2000) just to get a “ballpark” feel for the project. (Note: There are many unknowns ThoughtWorks Project Versus Industry Norms and assumptions in this quick Metric Industry Average Best in Class ThoughtWorks Project assessment. For example, I just assumed that 75 people worked Staff size 57 48 75 full time on the ThoughtWorks Schedule 36 months 27 months 18 months project for the entire 18 months — probably an erroneous assump- Productivity in 4.82 7.62 7.5 FP/staff month tion.) The table below shows the statistics for a 10,000 function point Total effort in 2,075 1,312 1,350 (FP) outsourced software project. staff months

Is Risk Management Going the Way of Disco?

Guest Editor: Bob Charette

Risk management is a white-hot topic. It is hard to pick up a magazine or newspaper that doesn’t have a story with the word “risk” spread from title to last paragraph. But as risk management becomes more popular, will it go the way of previous good ideas — from fashion, to fad, and then trash heap? Do the debates over the

next issue definition of risk signal risk management's good health or impending demise? Tune in next month as we debate whether risk management is doomed or here to stay.

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 5 Agile Software Development Joins the “Would-Be” Crowd

by Alistair Cockburn What is the opposite of a Bengal that their way of working actually working. Pausing and reflecting tiger — a Siberian tiger, an ele- was agile, repeatable, predictable, after each subproject, they have

focus? phant, a gnat, or a puddle of defect-free, or fun. opportunities to fix mistakes in water? None of them, of course. their way of working and try out Let’s take a fresh look at would- The phrase non-“Bengal tiger” new ideas for becoming more be-agile and would-be-(some- is uninformative, just as is non- effective. thing other than agile) software elephant, non-gnat, or non-water.

your development. Early and regular delivery also Being a non-something doesn’t allows the people to get feedback depict anything. about the system in operation Similarly, there is no opposite to WOULD-BE-AGILE SOFTWARE and, particularly, which of their agile software development. The DEVELOPMENT initial thoughts were mistaken. word “agile” shows where people “Agile” refers to maneuverability, The deliveries also provide points choose to focus their attention. the ability to respond to changes at which they can uncover and

what’s Alternatives to agile software in the environment. Would-be-agile react to new requirements, development arise as soon as software development means whether those come from users’ they focus their attention else- that the team decides to focus on reactions or from changes in the where. They might focus instead being able to incorporate ongoing business environment. on rigorous, predictable, repeat- requirements changes without A common recommendation able, defect-free, traceable, or great trauma. among agile methodologies, even fun software development. therefore, is to run small (3- to 12- The important thing is to identify Core Elements of Would-Be-Agile The standard mechanism for week), time-boxed subprojects the focus of their attention, not to reducing the trauma of ongoing and to reprioritize the require- create a negation of a label. requirements changes is to break ments after each time-box. This That’s still not right. There is really the project into subprojects, each gives the projects half of the agility only would-be-agile development. ending with delivery of running, they need. Or, for that matter, would-be- useful sections of the system. This The other half of their agility rigorous, would-be-predictable, early and regular delivery provides comes from replacing some of would-be-repeatable, would-be- the team with feedback about their written documents with traceable, or would-be-fun both the development process enhanced informal communica- development. and the system being developed. tion among team members, Would-be indicates that the people Early and regular delivery helps shifting the group’s organizational involved in the project aspire to a build safety into the project. By memory from external to tacit certain focus. Before the project delivering several useful releases knowledge. they can say that they intend to within a short time span, the spon- External knowledge is the kind work from that focus, but it is only sors, customers, and developers we can look at in paper or online after the project that they can say gain confidence in their way of

6 January 2002 ©2002 Cutter Information Corp. documents. Examples are the To make it work, the team project plan, the requirements members build not only on sitting All project teams rely on document, interface definition close together, but also on main- tacit knowledge, usually to documents, design documents, taining open communication a far greater extent than meeting minutes, design review among themselves. The tacit they suspect. results, test plans, test scripts, knowledge base doesn’t track very defect reports, and many others. well if people are being secretive Tacit knowledge is the kind people with each other. of the team, depending on where retain in their persons. It includes the organization chooses to focus In other words, group amicability, not only what each person knows its attention. (Yes, Virginia, the morale, and community become about the project plan, require- organization might actually choose first-order concerns for the group. ments, design, and so on, but also not to focus its attention exclu- To the extent these are in place, who they know to talk to, when sively on the agility theme.) the informal communications various people are available, the channels may suffice. To the extent social and technical conventions Short Subprojects they break down, the communica- in place. Ward Cunningham tells of using tions suffer, and so does the ultra-short subproject cycles All project teams rely on tacit team’s maneuverability. while writing code for Wall Street knowledge, usually to a far greater companies. Given the fickleness This, then, is the biggest difference extent than they suspect. Agile of the stock market, there was no between agile and other sorts of methodologies, though, place a telling on one Monday what the development processes. Agile deliberate reliance on tacit knowl- critical business need might be the processes put the topics of people, edge. Through the use of informal next Monday. Therefore, the team community, amicability, and communication channels, such as ran each project to be just one morale front and center. Standard colocated teams, pair program- week long! process descriptions don’t have a ming, or daily stand-up meetings, place for discussing these topics. they demand that the people on On Monday, team members would meet with their sponsors to the team keep each other abreast It is this line of thinking that select the top issues for the week. of ongoing changes to the plan, brought developer Andrea The programmers bid what they the requirements, the design, Branca to write, “Other processes could accomplish in the week the code. may look agile, but they won’t (often not a complete system, of feel agile.” When it works, it makes agile course, but enough to get some teams far more maneuverable. A initiative to a functioning stopping Variations in Agility short discussion at the stand-up As we have seen, four characteris- place). At the end of the week, meeting can suffice to indicate a tics of agile processes are: they completed their initiative, change in corporate policy or sys- delivered it, and paused. The tem goal. A discussion between a n Using short subprojects following Monday, they would find few developers informs them of n Reflecting on their practices out whether the market still craved changed requirements or a change that initiative, as they repeated the n Working in close location in the design. Not having to update exercise. If the pressing demand the external knowledge base n Attending to community was for some other piece of soft- means they can make many With these four characteristics, ware, they worked on that instead. changes in a short time period. we can look at ways to vary, Since a piece of software might not get touched again after Friday, When it works. strengthen, or weaken the agility it was critical that each subproject

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 7 be sized to complete and reach people (24 programmers), we a stable, final state on Friday. The longest I have ever seen spent one to two hours in the cafe- subprojects work well is four teria after each delivery. (This is That was an extreme situation, perhaps a commentary both on of course. Still, the longest I have months. German workers versus American ever seen subprojects work well is workers and the insurance four months. It seems that if they every subproject. Although reflec- industry versus the retail industry.) are longer than that, the people tion workshops were not cast into We only gathered a subset of the aren’t able to focus on their work the 12 key XP practices, in point of team — just the analysts, say, or properly. Even in four months, a lot practice most XP groups do insist just the team leads and selected can change about the business. on holding such workshops at the programmers. However, we did it Longer subproject periods make end of each iteration. twice per subproject, so that we the group less agile. SCRUM and XP call for short, daily could change our process in the Setting up and tearing down stand-up meetings, in which fast- middle of a subproject. subprojects is not free. There is breaking planning, requirements, XP iterations are so short (three planning and setup work to be design, and also team communica- weeks), that once after each itera- done at the beginning, and inte- tion issues can be brought to light. tion for an hour may be sufficient gration, test, and delivery (and (They are held standing up in time for reflection. A dot-com possibly training) to be done at the order to keep them short!) company using Crystal Orange end. Therefore, choose a duration Such reflection is core to having Web calls for delivery every of time that balances the need to the group’s process track its needs. second Thursday and holds a respond quickly with the overhead To vary, weaken, or strengthen this one-hour reflection workshop cost of setting up subprojects. characteristic, the team can make with all 50 employees the (Friday) SCRUM recommends one-month the reflection workshops longer or morning after. subproject lengths. Extreme shorter, more or less frequent. Programming (XP) recommends Working in Close Location An eight-person German project three weeks. Crystal Orange used Crystal Clear and XP simply team using Crystal Clear with three months. You can see that the require that people work in the three-month subprojects chose to exact duration varies by circum- same or adjacent rooms. This hold reflection workshops after stance and preference, with 16 obviously only works for teams up each quarter’s delivery. To have weeks as the outermost boundary. to 8 or (with a stretch) 14 people. extended peace and quiet for their None of the other agile methodolo- workshop, members of the team Reflecting on Practices gies is so adamant on this point. The Crystal methodology family is went to a village well outside of All agile methodologies are, the most adamant about having town for two days. They spent however, sensitive to colocation, the members of the team get the first day team building and since they rely so heavily on rich, together and discuss what they reflecting on the previous quarter’s fast communication channels. are doing well and what they work, and the second day jointly Using those communications should change. Jim Highsmith creating a plan for the next quar- channels allows them to reduce (Adaptive Software Development) ter’s work. During the second year the external documents they have recommends a product feedback of the project, they shortened the to construct and maintain. meeting, so the product require- workshop to a single day. ments can be refined on an In contrast, on my first Crystal To vary the agility, vary the quality ongoing basis. Both of these Orange project, which also used of those communication channels meetings happen at the end of three-month deliveries but had 45 and vary the balance between

8 January 2002 ©2002 Cutter Information Corp. external and tacit knowledge. It Internet lines, using NetMeeting two-day team-building course. is not the case that to be agile, the and a telephone between them. He’s not sure to what extent it team should produce no paper- They report that while it is not as really builds teams, but it obviously work (external knowledge). good as being in the same room, helps. At the very least, he says, External knowledge storage has it is much better than program- the people get to meet each other various advantages, the least being ming alone. socially and come to understand any contractual obligation for the that the company considers team You can see that running a project team. Information on whiteboards quality an issue important enough across countries and time zones and in documents has a sort of to spend money on. creates a real obstacle for the “stickiness” to it that allows people would-be-agile team. Fiddling with Of course, the best team building to refer back to what was decided. the issue of spontaneous, rich comes from succeeding, which The would-be-agile team, there- communication is a key part of gets us back to the theme of fore, needs to adjust the amount deciding how agile to be. short subprojects. Along the way, of knowledge that should reside though, the members of the in conversation and personal team have to find ways to memory versus sticky or archiv- Running a project across express their fears and wishes able form. It is extremely rare that countries and time zones for the community. the answer to the communication creates a real obstacle for Varying this characteristic of question might be “all oral.” In the the would-be-agile team. the agile process is done by the other direction, due to the very project sponsor, project manager, real requirement for tacit knowl- or someone on the project with a edge and the overall weakness of dominant personality, who can our current forms of documenta- Attending to Community The daily stand-up meetings and either initiate or kill such discus- tion, I have never yet seen a situa- reflection workshops give people a sions. The amount of community tion where the answer might be chance to voice their concerns or present, or even the amount of “all external.” This means that the suggestions regarding the group’s attention paid to community, is organization and the team must amicability. I recall visiting one XP so dependent on the personalities decide on how much of each project on a Tuesday morning and of the people involved that it is appropriate. Usually, a little listening while a programmer often is more accidental than external knowledge goes a long described a concern and a wish. orchestrated. way, and so less is needed than is He said that when he came in on usually believed. Monday, he found the code vastly For communication channels, changed from Friday. Could people WOULD-BE-(SOMETHING OTHER some people are experimenting please let others know if they THAN AGILE) DEVELOPMENT with having team members sit planned to work on the weekend, Not all project teams aspire to in different areas of the same so everyone would be alert to being agile. If they do not, they building, connected with Web- changes on Monday and would must announce where they are cams and chat software over a know whom to talk to? This is the actually focusing their attention. high-speed intranet. While this sort of attention to community that They might strive to achieve is obviously not quite as rich as slips through the cracks in stan- predictable, repeatable, cost- sitting in the same room, they dard process descriptions. optimized, rigorous, traceable, claim fair success with it [1]. defect-free, fun, or laid-back One South African executive likes Others have experimented with development. Let’s look at some to take new teams off-site for a pair programming over high-speed of these in turn.

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 9 Predictable Development Having the goal of improving the projects and staff are similar In would-be-predictable develop- predictability presupposes two enough. ment, the team focuses on hitting things: first, that the project assign- Would-be-agile development can a cost, time, or defect window. An ments, technology, and project still inform would-be-repeatable example would be a fixed-time, teams are similar enough across development. Rarely is any project fixed-cost project. People bidding projects for measurements to as similar to a previous project as on such projects may abandon the transfer, and second, that the a subproject is to a previous sub- advantages of the agile mecha- metrics are measuring the correct project on the same overall proj- nisms in exchange for predictability. things on the project. ect. The assignment is very much Unfortunately, the world is not kind To most project teams engaged in the same, the technology is the with respect to predictability these a series of projects where the aim same, the people are the same. days. Unless the organization has is repeatability, it does not matter if Repeatability improves over the already done the same kind of either of those presuppositions is subprojects, which help for the project with the same people in not met. Their asserted goal is to next overall project. The ideas of the same technology, the team will achieve repeatability, and so they agile development also predict be hit by unpleasant surprises must evolve metrics that will new project metrics to be tried: somewhere along the way. transfer across people, technology, communication distance, fre- and assignments. quency, and richness, as well Therefore, there is an advantage as measures of community and to mixing some would-be-agile Personally, I don’t think there are amicability. in with would-be-predictable many project series that fit the development. That way, when presuppositions, and I don’t think Cost-Optimized Development the inevitable surprises do hit, a the metrics are yet measuring the Would-be-cost-optimized develop- team that has been attending to correct things. (For example, I ment calls for strategies almost short subprojects, reflection, have not yet seen such projects opposite to would-be-agile communication, and community measure and report communica- development. Correctly executed can recover more quickly and tion and amicability within the would-be-agile processes cost with less cost. That is a contribu- team.) One very senior developer more than correctly executed tion of an agile process to the hypothesized for me that where would-be-cost-optimized proc- other would-be processes. repeatability is being achieved, it esses. That is, agile teams expend is being achieved by making the more work-days in fewer elapsed Repeatable Development process so slow and heavy that days, while cost-optimizing teams Would-be-repeatable development the time spent inventing and expend fewer work-days in more is usually done with the intent revising ideas is negligible in the elapsed days. of improving predictability, and cost of the entire project. usually with an added intent of The cost-optimizing project coordi- shrinking the time, cost, and/or Far from being a glib attack on nator arranges for workers to show defect window. would-be-repeatable projects, this up only when their particular skills idea may be correct: to generate are needed, and to leave again as repeatability within a project soon as their work is done. To the series, create an overall process Unfortunately, the world is extent that the project coordinator large and costly enough to dwarf can avoid being hit by unpleasant not kind with respect to the inevitable mistakes the devel- surprises during the project, this predictability these days. opers will make. Then, the risk is careful scheduling allows him or greatest on the first project and her to optimize salary costs. Since diminishes after that, as long as some number of mistakes will

10 January 2002 ©2002 Cutter Information Corp. certainly be made, the project surprises...”) and is the very reason coordinator may arrange for people are responding so favorably The reason that would-be- people to show up perhaps two to would-be-agile development cost-optimized projects so or three times, to reduce the projects. rarely succeed in their goal defects to acceptable amounts. There probably are circumstances is that surprises pop up at You may recognize in this descrip- in which surprises can be mini- all stages in software tion several other fields besides mized and plans made to optimize development. software development where this costs. They are likely to be the strategy is used. I immediately same circumstances that permit technologies within a very liberal think of building houses and predictability and repeatability. set of guidelines, and generally publishing books. In both cases, works to keep them from feeling there is similarity across projects Rigorous Development pressured. This is would-be-laid- and great incentive for minimizing Would-be-rigorous development back development at work. costs. In house construction, the is a false lead. Few people try to goal is to get things right on the be rigorous for the sake of being Other groups feel that the only first pass; publishing houses use a rigorous. Rigor is hard. Usually, way they can keep their devel- fixed two- or three-pass schedule. a group works at being rigorous opers motivated and producing because they think it will help excellent software is to make the You should see that this form of in some other way, such as development environment fun. serialized development will be predictability, repeatability, defect Programmers in these organiza- lower in cost than having the reduction, or fun. (XP done prop- tions, who are likely to be working people around for longer periods erly is rigorous. In an odd twist, on aggressively state-of-the-art of time, starting work early, and people practicing XP tell me that projects, may tease and compete doing rework as they learn their the extra rigor makes program- with each other. Rewards include assumptions were incorrect, as is ming both more defect-free and playing competitive computer done in would-be-agile develop- more fun!) games like Doom, even within ment. A bit of further thinking standard working hours. shows that the serialized develop- On occasion, a manager or ment also takes longer than the sponsor will advocate more rigor I think it should be obvious that concurrent development, since in development as a catch-all would-be-laid-back and would-be- no team is allowed to start work prescription meaning to “get fun processes are fully compatible until the team feeding it is done. better” at something. Therefore, with agile development. The latter In fact, correctly executed serial- you should probably choose to be are even likely to raise morale and ized development takes the would-be-something-else, not communication, although the longest time of any correctly merely would-be-rigorous. intense competition in some executed strategy, at the least cost. places may affect amicability Laid-Back or Fun Development to some extent. The reason that would-be-cost- A university organization can’t optimized projects so rarely afford to pay its programmers succeed in their goal is that much. To attract and keep anyone SUMMARY surprises pop up at all stages in of caliber, it has to offer other The values and strategies of the software development. This invali- attractions. The group I am think- “Manifesto for Agile Software dates the presupposition for cost- ing of allows its programmers Development” are only supposed optimizing (recall: “to the extent to work at any time of day or to confer agility on the team. Agility that the project coordinator can night that suits them, lets them shows up in the execution — or it avoid being hit by unpleasant choose their own projects and

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 11 doesn’t. The same is true of the they make the opposite tradeoffs Alistair Cockburn is a Senior Consultant values and strategies of the other between elapsed project time and with Cutter Consortium’s Agile Project Management Practice and a contributor sorts of processes. Conversations the work-hours used. Would-be- to the Agile Project Management Advisory about these different approaches agile strategies should work well Service. He is Consulting Fellow at would be a lot less heated if every- with would-be-fun strategies. Humans and Technology, where he helps one was clear on the fact that they clients succeed with object-oriented projects, including corporate strategy, are would-be processes: would- project setup, staff mentoring, process be-agile, would-be-predictable, I hope that by considering development, technical design, and would-be-fun, and so on. design quality. He is the originator of the all of these approaches as Crystal family of methodologies, and Calling them would-be this or that wanting to produce an effect he has over 20 years’ experience leading projects for companies in the US and makes it clear to all where the rather than promising to around the world. He is the author of project sponsors are focusing produce an effect, we can Surviving Object-Oriented Projects and their attention — responding to Agile Software Development and has make progress in evolving late-breaking surprises, hitting a written papers and articles for a variety of trade journals. cost window, retaining staff, or and blending strategies. whatever they may choose — Mr. Cockburn has developed courses in project survival, methodology develop- and thereby diffuses much of the ment, requirements writing, OO design, hype currently surrounding would- I hope that by considering all of and project management strategies. be-agile development. It allows these approaches as wanting to He has been invited to teach and talk us to talk about why the sponsors produce an effect rather than at the Software Technology Conference, Object World, Software Development, aim for that quality, what strategies promising to produce an effect, and OOPSLA. He has taught OO con- might work, what might get in we can make progress in evolving cepts and design to hundreds of execu- the way, and how to blend the and blending strategies. tives, managers, and programmers worldwide. priorities. Mr. Cockburn can be reached at Humans Would-be-agile development REFERENCE and Technology, 7691 Dell Road, Salt centers around handling late- Lake City, UT 84121. Tel: +1 801 947 1. Herring, C., and M. Rees. breaking surprises. That leads to 9275; Fax: +1 775 416 6457; E-mail: “Internet-Based Collaborative [email protected]. the strategy of building the project Software Development Using from subprojects (incremental Microsoft Tools.” In Proceedings development), enriching informal of the 5th World Multiconference communications between people, on Systemics, Cybernetics and and emphasizing the tacit rather Informatics (SCI’2001). Inter- than the external knowledge base. national Institute of Informatics Would-be-agile strategies can be and Systemics, 2001 (http:// blended into would-be-predictable erwin.dstc.edu.au/Herring/ development to reduce the cost SoftwareEngineering0verInternet- of handling the surprises that SCI2001.pdf). inevitably crop up. They are antithetical to would-be-cost- optimized development, since

12 January 2002 ©2002 Cutter Information Corp. banishing the “blueprint” ©2002 byStephen J.Mellor. Allrightsreserved. model the build to cheaper be also must it useful, be Forto model a distribution. weight affect they extent the exceptto issue, an not obviously is fittings interior of Forlack model. the example, the of accuracy the with fere inter- not does aspects other these removing that provided respects, other in thing real the as same the be not need it but accurate, aerodynamically be must model fly.will The it well how stand under- to airplane an model may Forhand. we at example, issue the see to clearly more the information certain away abstracts model A “model.” is word mistranslated The word. a of mistranslation the of result a as is, it than serious more appear to made least at or caused, is war this that contend I processes. agile several the of those and UML of proponents the between “war” a is there told, Today,intended. was what are we with odds at quite connotations have may other,word the the of vocabulary the into translated party,when one but to innocent quite appear may word a of use The parties. between negotiations diplomatic during mistranslations or misunderstandings of quence conse- Warsa as started have by StephenJ.Mellor The BogusWar the bogus war.bogus the of genesis the is This processes. different connotes and usages diverse denotes one each and “model,” of meanings three least at are there because discussion the enters mistranslation The thing. real the building than cost behavior,lower at correct verify to it use or model, the with experimentway, may we this In thing. real the build to than construction. construction. for plan a of embodiment the is blueprint the thing: real the build to needed properties key describing document a as blueprint a of commonly,think More we example. one is tunnel wind a in airplane the of model physical The as model the is word the for denotation second A mat? beer wet a fly to wants Who delivered. nor maintained neither is sketch The idea. an out try to is sketch the of purpose The be. to intended it is nor complete, not is sketch The interact. two the how describing two or equation an flow,write air and indicating lines few a show mat, beer a of back the on wing a of shape the out a is “model” word the for denotation One THREE MEANINGS e sketch . We. sketch blueprint . model. a computer,a as inside entirely way,this just in built was 777 Boeing The shape. a making for instructions into it transform and shape a of rendition computer a takeToday,to possible literally is it shape-that-flies. the to related problem the of aspect one the in detail every in complete is model body,the the yet up make that screws and bolts, plates, metal the case this in inputs, other requires transformation The airplane. ical phys- real, the into transformed be can airplane the of model The an as model the is word the for denotation third The crowd. agile the for angst most the causes that use this is It developers. the namely users, primary blueprint’s the than other agent some to blueprint the of delivery assume frequently approaches two last These level. abstract more a at it understand can thing real the of tainers main- the so posterity for print blue- the maintain may we Third, match. they so thing real the and blueprint the maintain could we Alternatively,system. finished the with odds at be will blueprint the case which in dictate, conditions as thing real the building advisory, as blueprint Wethe treat may Vol. 15,No.1 executable . 13 Under this interpretation of their plans for the code. No one “model” as an executable, a fights over a beer mat. Even the most agile use program in a high-level language sketches to outline their Blueprints. The connotations of — Java, say — is a model too. The a model-as-blueprint cause plans for the code. No one Java program can be transformed conflict. The very idea of a “blue- fights over a beer mat. into the real thing (byte code). print” evokes images of factories The builder of the model, the and manufacturing, together with programmer in this case, need not build an executable UML model, uncreative drones. “Heavyweight” know how a Java compiler works, we have described the behavior methods and processes have nor what the compiler does to of our system just as surely as certainly encouraged the idea make a program run. Of course, we had when we wrote a program of model as blueprint. The manu- the byte code produced by the in Java. facturing analogy is drawn repeat- compiler is itself a model that can edly in the Software Engineering Many of the principles of Extreme be replaced by ones and zeroes, Institute’s Capability Maturity Programming (XP) and the Agile one layer of abstraction removed, Model (CMM), for example. But we Alliance involve process and and those ones and zeroes in turn know software is a highly creative customer relationships and their define the desired behavior of the new-economy thang, not at all like management, not code. As such, underlying hardware, yet one old-fashioned manufacturing. the agile process principles for more layer of abstraction away. the construction of code apply This contrast is the heart of the At each layer, information is just as well for the construction of agilists’ view of models as “heavy.” added that is inherent to the executable models. For those prin- In an environment that is 80% subject matter involved. Java byte ciples that do mention “code,” construction and 20% design, like code can be produced only with executable UML models serve just manufacturing, it makes sense to knowledge of the Java virtual the same purpose. view the blueprint as the plan that machine, and ones and zeroes is predictive of the construction can only be produced by making work to be done. To the contrary, WHAT IS EXECUTABLE UML? decisions about registers and software is known for its creative Only recently has UML become memory organization. aspects, more like 80% design and executable. Earlier versions of 20% construction. In this case, UML had but seven simplistic CONNOTATIONS developers need to be adaptive and incomplete actions, such rather than predictive in their rela- The different denotations of as Create, SendSignal, and (my tionship to any model, effectively “model” affect how we think personal favorite) “Uninterpreted- putting the kibosh on the use of about using one; that is, each String,” which taken together do models as blueprints. meaning for “model” connotes not allow for modeling computa- tion. However, in 1998, the Object different processes. Executables. An executable UML Management Group (OMG) model, as the name suggests, is Sketch. Few agile exponents are released a request for proposal executable. An executable UML so rabid as to be unwilling to for a Precise Action Semantics. model can be compiled into sketch out their classes and use A consortium of companies, code using a model compiler. The cases, sometimes called “stories,” led by Project Technology, Inc., construction of an executable UML and perhaps even use UML to do Kabira Technologies, and Rational model has the same connotations it. There’s no fight here: even the Software, proposed a set of actions as writing code, though at a higher most agile use sketches to outline sufficiently complete to specify level of abstraction. When we computation, which has recently

14 January 2002 ©2002 by Stephen J. Mellor. All rights reserved. been adopted by the OMG. The topics are abstracted away and actions in the submission include managed instead by an executable After convincing someone LoopAction, ConditionalAction, UML model compiler, analogous that the model is executable, and actions for collections and to a programming language they go right back, half an non-traditional control structures. compiler.1 hour later, to treating the The action semantics specification It would seem, therefore, that the model as blueprint. differs from 3GLs in that actions battle is over. Executable UML is are specified to manipulate only the code for the system, and the graphical structures of the UML UML elements, such as attributes principles of the Agile Alliance can model and coding with less flexi- and state; to constrain sequence be argued on their merits, without bility. The urge to express code in minimally; and to allow the specifi- calling UML onto the battlefield. the model leads misguided UML- cation of computation indepen- based developers to demand still dently of the data structure. For a more modeling constructs in UML CONTINUED MISINTERPRETATION more detailed description of the to allow them to “say more” and Unfortunately, this is not yet to be. requirements for the action “be more flexible.” semantics, see [1, 4]. It seems difficult to achieve, and especially to maintain, recognition This view is akin to writing a The action semantics specification of the notion that the model is a program in a high-level language does not define a notation. Rather, complete aspect of the system. — Java, say — and then adding vendors can specify syntaxes that After convincing someone that the tags to the various elements of target specific markets; some model is executable, they go right the program to indicate the register could even be graphical. Vendors back, half a hour later, to treating to use or the stack location to can also supply in-built operations the model as blueprint. Some of employ, organizing the program appropriate to their target usage, this maddening behavior comes into components to make best use such as net-present-value compu- about because of the several of memory segmentation for a tations, string manipulation, or connotations of the word “model,” particular hardware configuration. matrix multiplication. but it also comes about, I believe, Every new construct in a computer To atone for the addition of still because we all have so much requires extension to the program- more stuff into UML, executable invested in code and coding. ming language to “say more” and UML subsets UML radically, by “be more flexible.” The fundamental misunder- creating a profile. A profile is the standing is the false notion you It is surely reasonable, if one UML mechanism for creating need to do everything twice. First, holds this view, to argue that it’s defined subsets of the UML for you build the model, and then you easier just to write the system in specific contexts. Profiles support write the program on the model, assembly code and dispense the notion of UML as a family making all the decisions about the with programming in Java. It’s of languages. software structure either in the not obvious what value the For the purposes of executable model graphic or the logic. This program adds, and the entire UML, there is no requirement false notion adds to the perception process seems “heavy” because to model the structure of the that the model is getting in the there are two components to software, such as deployment way: you’re trapped inside the manage: the program and all those diagrams, tasking structures, and tags. Worse, when we need to the several forms of queuing of 1For a description of executable UML transport the program to another messages between classes. These and how to use it, see [2]. For an platform, we have to revise all example of an executable UML model the tags and reorganize the for a real-time system, see [9].

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 15 components to take account of a It takes a program, written in an different organization of physical executable language, and turns When invited to attend the memory. the program into a different repre- inaugural meeting of what sentation that has the same func- Obviously, the argument above became the Agile Alliance, I tional behavior. There are multiple should not be taken seriously, yet introduced myself as a “spy.” model compilers, each targeting a this is exactly the argument used different software platform. by code-centric folk to justify not for the application, based on its using an executable UML. For example, one model compiler performance characteristics. might apply to applications that High-level programming languages can benefit from a high-volume, such as Java are intended to distributed, concurrent, transaction- abstract away the details of reg- UML AND MODELING SOFTWARE safe implementation with rollback STRUCTURE ister usage, stack location, and the of incomplete transactions. This organization of physical memory. A reasonable objection to this kind of model compiler is suitable In other words, the programming entire line of reasoning is that for telephone billing and stock language makes the programs UML has continued to grow, trades, for example, but it is independent of the hardware plat- especially to include additional not suitable for an embedded form. Adding tags to the program modeling elements to capture system [3]. 2 to do the compiler’s job defeats software structure. Because UML the whole purpose of the exercise. Alternatively, another model com- is intended to be a family of piler might apply to embedded languages that can support the Similarly, adding code or a multi- systems with very tight memory visualization of software artifacts, tude of tags to a UML model and speed requirements. There these additions are inevitable. defeats the purpose of executable are no tasks and no operating However, by carefully layering the UML, which is to make the exe- system. The resulting code runs semantics of the system-modeling cutable UML model software directly on the silicon [8]. portion of UML, we can restrict the platform–independent. In other deleterious effects of this growth words, the executable UML Still another model compiler might to those who prefer to use heavy- modeler expresses the content of apply to problems that require weight processes.3 an application without any refer- multitasking, concurrency, and ence to its implementation envi- persistence but be optimized in ronment. There is no mention of the sense that it does not provide ENDING THE WAR CORBA, no mention of JavaBeans, sophisticated capabilities such I have recently become a peace- no mention even of distribution of as rollback [7]. nik. When invited to attend the classes into tasks. The model inaugural meeting of what became The programming language compiler takes care of targeting the Agile Alliance, I introduced produced by the compiler and the software platform just as a myself as a “spy.” As an author of other services such as JavaBeans programming language compiler two methods that rely heavily on and CORBA would need to be takes care of targeting the hard- modeling, one of which uses UML, known only if the generated ware platform on which the I felt compelled to ascertain what code has to interface with other program runs. components. 2See, for example, a response to the The model compiler makes these UML 2.0 Superstructure RFP [6]. MODEL COMPILERS decisions about the software plat- 3For example, see another response to A model compiler is like a form. The job of the developer is to the UML 2.0 Superstructure RFP [5] that programming language compiler. select the correct model compiler layers the definition of UML.

16 January 2002 ©2002 by Stephen J. Mellor. All rights reserved. the opposition was up to, all the REFERENCES AND WEB SOURCES 7. Project Technology, Inc. better to derail their evil plans. Yet 1. Mellor, Stephen J., Stephen R. DesignPoint MC-2020 as I read more and listened care- Tockey, Rodolphe Arthaud, and (www.projtech.com/prods/ fully, I found myself in agreement Philippe LeBlanc. An Action mc/mc2020.html). with much of what was said, as Language for UML: Proposal for 8. Project Technology, Inc. well as hearing many echoes from a Precise Execution Semantics, DesignPoint MC-3020 my own work. “UML 98.” (www.projtech.com/prods/ There are elements of the agile 2. Mellor, Stephen J. and Marc mc/mc3020.html). movement I still find distasteful. J. Balcer. Executable UML: A 9. Starr, Leon. Executable UML: The allergy to “documents” is one. Foundation of Model-Driven A Case Study, Model Integration, The most important document of Architecture. Addison-Wesley, LLC, 2001. all is the one that describes the forthcoming 2002. design not chosen and the ratio- Stephen J. Mellor is the coauthor of two nale for that decision. That simply 3. Kabira (www.kabira.com). methods, one of which can be used in cannot be self-documented in the an agile manner with UML. 4. Object Management Group code. My skin crawls at some of (OMG). Action Semantics for the His work has emphasized the engi- the touchy-feely “interactions” UML, Request for Proposal. OMG, neering of high-assurance systems, talk that seems to require the especially in real-time and embedded 1998 (http://cgi.omg.org/cgi-bin/ developer to be emotionally one environments. Most recently, Mr. Mellor doc?ad/98-11-01). has been working to make UML with the customer, and as for the executable by, first, incorporating actions communist notions of collective 5. Object Management Group into UML, and, second, as coauthor of ownership and the 40-hour week, (OMG). Updated Joint Initial UML the upcoming book Executable UML: The Handbook. well, these are cause for, er, 2.0 Infrastructure Submission. heated discussion. But with OMG, 2001 (http://cgi.omg.org/ Mr. Mellor is cofounder, with the late Sally Shlaer, of Project Technology, Inc., respect to the use of agile cgi-bin/doc?ad/01-08-34). a company focused on tools to compile processes and executable UML, 6. Object Management Group UML models, where he now serves as there should only be peace. vice president. (OMG). Updated UML2 Infrastructure Joint Initial In his copious spare time, he is also a member of the IEEE Software Industrial Submission. OMG, 2001 Advisory Board. (http://cgi.omg.org/cgi- bin/doc?ad/01-09-02). Mr. Mellor can be reached at Project Technology, Inc., 7400 N. Oracle Road, Suite 365, Tuscon, AZ 85704. Tel: +1 520 544 2881; Fax: +1 520 544 2912; E-mail: [email protected].

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 17 A Resounding “Yes” to Agile Processes — But Also to More

by Ivar Jacobson

Agility has become today’s buzz- support the individual developers in We worked with mock-ups and story- word when describing a modern software development. The product boarding to design the user interface software process. Everyone is would include a knowledge base — the team had now grown, with the agile. An agile team is a nimble described as a large number of rules addition of a creative and experienced formulated in a rule language, a UI designer. We also identified all team able to appropriately respond compiler generating executable code significant risks and worked through to changes. Change is what soft- from the rule language, and a rule them all. To verify our work, we imple- ware development is very much engine — not exactly something I had mented and were able to run the use about [1]. Changes in the software done before. The company was a start- cases that mitigated the risks. This being built, changes to the team up company funded with seed money took about three months, during which members, changes because of only. We needed to get a first workable time we iterated the solution twice. product through the doors as quickly new technology, changes of all There was some significant rework as possible, to be extremely focused. kinds that may have an impact on during this period based on customer the product the team builds or the In the first phase, we developed a interactions and for technical reasons. tools over tedium project that creates the product. vision in writing for the first product That was no surprise to me. We had to Support for changes should be release. We needed as a team to know adapt our solution as we better under- built into everything we do in soft- where we wanted to go. We also stood what we were doing before we needed to get consensus on this vision thought we had something we could ware, something we embrace with sales so that we would get some- grow from. At the end of this phase, because it is the heart and soul of thing we believed we could sell. We we felt comfortable in committing to software. An agile team recognizes were, in particular, explicit on what a release date. We still didn’t know that software is developed by indi- we wouldn’t do. We knew that the exactly what we would deliver, but viduals working in teams and that released product would not be all we we knew it much better than after the the skills of these people and their said; it would contain something less first phase. ability to collaborate are critical to and maybe something more. This took The third phase was basically grow- about a month, and I grew the team to the success of the project. ing the product in several internal seven people; four of the team devel- releases. Thanks to having spent so For the purpose of illustration, here oped the compiler, the rule engine, much effort on the skeleton system in is an agile project as described by and generic GUI, and three of them the second phase, we could grow the developed the knowledge base. The Svante Lidman, a project manager product quite smoothly. That doesn’t team members were very competent at the Swedish software company mean that we didn’t have to do some in their respective roles. Jaczone AB:1 changes, but no major ones. We could In the second phase, we developed a move forward as we had committed. I took over the job as project manager skeleton executable system from We didn’t do all we said we would do in November 2000, at which time the which we could grow to the first at the end of phase two, but nothing team consisted of four people. They product. We worked out the software we cut off was very important. Since I had developed a simple prototype architecture. We decided on a soft- was absolutely committed to releasing barely demonstrating the feasibility of ware platform (C# and .NET). We a “defect-free” product for our first the idea: using intelligent agents to described each use case and made a customers, we spent the necessary simple object model using UML (we time on peer reviewing and testing of 1For the record, I am a member of Jaczone AB’s advisory board. knew Rational Rose, so we used that). each internal release.

18 January 2002 ©2002 by Rational Software Corporation. All rights reserved. In the fourth phase, we released the a process that helps the team to However, even in projects where product to a handful of customers achieve its goal, but that project the focus is on code, people have committed through contracts to work may be described using a prede- different approaches to good with the product. During this phase we fined process. The key is that you coding standards. What most didn’t expect to find many bugs — and continually adjust the process as people thought was good code we didn’t. We wanted to know if the excitement that customers felt when you go by reflecting on what you’re some years ago is considered we demonstrated the product would learning, what works, and what bad code today. Thus people hold during real use. Does the product doesn’t. In this article, I will spend time arguing these things. give the value that we expected? Is discuss some other properties of a With a strong, good leader, there anything more we need to do good process that go beyond what these problems may be smaller. before making the product generally is commonly thought of as “agility.” However, most teams won’t have available? This is where we are such a leader. right now.

The process that Lidman describes A PROCESS SHOULD EMPOWER is a light version of the Rational YOU TO FOCUS ON CREATIVITY In every project, a large Unified Process (RUP) [2, 3]. It I believe that software develop- portion of the work done by ment is the most creative process was chosen because Lidman and developers is not genuinely his team didn’t need to invent that we humans have ever creative — it is tedious, something new; they believed that invented. I also believe that it would create working software processes or tools can never routine work that we should fast with very little documentation. replace true creativity. However, try to automate. Being based on the RUP, the not everything we do when process itself was designed to be developing software is creative. Aside from process issues, we also changed and to support changes In every project, a large portion of spend considerable time on many in the product as normal occur- the work done by developers is not other small, technical issues. For rences. Moreover, they wanted the genuinely creative — it is tedious, instance, if you want to apply a product to grow and the team that routine work that we should try to pattern, there are many small steps developed it to be able to grow in automate. The problem is that the you have to go through before you many dimensions: size, geographic creative and the routine work are have instantiated the pattern. distribution, customers, and so on. interspersed in micro-steps, each These small steps could, with These are some of the properties I such step only lasting from maybe proper tooling, be reduced to require of an agile process. tens of seconds to tens of minutes. almost a single step. As the title of this article suggests, Since these two kinds of works are I don’t think anyone would argue I am a strong believer in an agile interleaved, the developers may with the fact that some portion of process. No one can afford to still have the feeling of being the work developers do is non- develop software by slavishly engaged in creative work, but creative. I have discussed how following a predefined process. fundamentally they are not. large the portion is with colleagues Instead, the project should follow Some of you would probably argue from several camps, and based on that, in fact, you don’t do the my own experience and these unnecessary work. You focus on discussions, I believe it is as large No one can afford to solving the business problem and as 80%. That number assumes a develop software by ignore much of the other work that light programming environment. slavishly following a does not deliver business value. There is no significant difference if predefined process. This is, of course, partly true. you develop with or without reuse

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 19 of existing components. Reuse A GOOD PROCESS ALLOWS YOU mentors are very valuable but not should reduce the total work, but TO LEARN AS YOU GO — WITHOUT easy to find. it doesn’t significantly reduce the SLOWING DOWN THE PROJECT Since we are all different, we non-creative portion of the work. Developing software has never should ideally be allowed to learn I have only seen one very old been as hard as it is today. in our own way as we go — from scientific study on this subject You need to have a knowledge teachers, from mentors, or from and would welcome one based base that is larger than ever reading. Traditional education has on current practices and tools. before. You need to know about consisted of attending some basic operating systems, database To make software development classes, possibly reading a text- management systems, program- truly agile, we need to attack and book, and then learning by ming languages and environments, reduce this 80% of the work effort. watching or being instructed system software, middleware, I don’t think we can eliminate it by a more experienced person. patterns, object-oriented design, entirely, but we may be able to get component-based development, Just taking some classes on from 20/80 (20% creative content and distributed systems. You also different subjects — for instance, and 80% non-creative) to 80/20. need to know a software process, in using a programming environ- The way to attack it is to under- a modeling language, and all kinds ment, in a methodology, in testing stand in depth, not just on the of tools. And if you succeed in — is a poor start. Software devel- surface, what is not genuinely learning something, you can be opment is much more than that. creative. Then, once we under- sure it will soon change. Change is Going away to different classes stand it, we can eliminate it by the famous constant in software! that are not correlated with a training, mentoring, and proper bigger picture — such as a soft- software tools. Developers will be There is simply no way you will be ware process — is not efficient. able to communicate and collabo- able to learn all this before you rate creatively, supported by new start working on a project. You Learning from a more experienced or improved tools to verify that have to learn a little before, but person is very effective, particularly they are consistent, complete, most of it you will need to learn if that person is a mentor. How- and correct. as you go. ever, it is hard to get good mentors — competent individuals with If developers can rely on such The way we learn is very different unusual personal skills. There is tools to eliminate much of their from individual to individual. Some always the risk that a good mentor not genuinely creative work, they learn different things better than may be given other project respon- will be in a much better position to others. We learn at different sibilities or that time pressure maximize the time they spend on speeds, and in different ways. may force him or her to leave the developing business solutions. This Some people learn better by mentor role. Moreover, someone use of tools will also increase the reading, and others by listening. taking on the role of mentor may quality of the developers’ lives. Who will teach us? Teachers give veer into inventing his or her own They will be able to spend more classes and mentors participate in process, which certainly will slow time doing the creative work projects with the role of being down the project. they enjoy and less time on the available to help the team while routine or repetitive work they Thus having a mentor on site going. As we know, not everyone dread. This would enable the (maybe only part-time) is a good is a good teacher or a good agility we all are looking for. It investment, but we need to reduce mentor, and even fewer can be would empower people to do the risks I just mentioned. What both. Good teachers and good the maximum amount of should we do? creative work.

20 January 2002 ©2002 by Rational Software Corporation. All rights reserved. In 1986, I had a dream. I wanted to book equivalents right off the bat. (I will return to this point in the create a knowledge base, not just Rather, he or she would get an next section.) Moreover, since a book,2 for everyone that could overview of the whole approach in you can learn as you go without play a role in a modern software order to understand how to go slowing down the project, it is an project: component-based, object- from a business problem to a agile process. oriented, use case driven you deployed system. The individual – Despite all this, the authors of the name it. Whereas a book may developer would have the base RUP books will probably never win be a nice introduction, it cannot on which to grow when he or the Nobel Prize! possibly provide depth in all areas. she went into a project that had I also wanted this knowledge to already started. grow as we learned more, to A “GOOD” PROCESS ALLOWS YOU change as we better understood TO BE FAST — WITHOUT HAVING how to develop software — to Is the RUP a light process? TO REINVENT THE WHEEL enable us to throw away what was No, the RUP is very rich (in For years I have claimed — with bad and incorporate new, good content), but you can use it perhaps a twinkle in my eye — experiences. Moreover, the knowl- that the fastest way to create soft- in a very light way. edge base should be able to adapt ware is not to develop anything itself to new technologies as they yourself but to reuse something became available. Since then, that already works. This approach To make that dream a reality, the technology has exploded — the is not just very fast, it is also cheap. Objectory [4] process was created. Internet, J2EE, .NET, new middle- It delivers software that works. In Objectory grew for more than 10 ware, and much more. Later practice, however, you may still years and evolved into the RUP in versions of the knowledge base need to develop something new 1998. What I just described has should accommodate such in many situations — at least the become a reality in the RUP. innovations. “glue” between the components With the RUP, you can go into any that you can reuse. In other words, what I had in mind depth you wish. It is possible for was to derive knowledge equiva- We don’t develop our own oper- you to skim the surface in learning lent to 15-20 books dealing with ating systems, database systems, about a particular topic, or it is relevant subjects like require- programming languages, and possible to delve deeper to get ments, architecture, design and programming environments any- very detailed information. It all implementation, user experience more. We usually start with a depends on your situation and design, business engineering, software platform and some needs. You have it at your finger- testing, software reuse, configura- middleware as a base — not much tips, just in time. You can often tion management, and project more. However, much more can avoid having to ask questions that management. For ease of use, this be reused. no one has the time to answer and information would be written in a can avoid asking repetitious, dumb common style with consistent Process. You shouldn’t have to questions that consume the time terminology. Of course, no single reinvent a process. Instead, you of good mentors. You don’t need individual would read all of these should use a well-proven process to worry about being disciplined designed to be reused. This is 2I feel that books (such as my own by the teacher/mentor (shades of what we at Rational call a process books) can give no more than an second grade!) until you do it right. framework. A process framework overview of an approach. They don’t Is the RUP a light process? No, the tell the entire story, and they don’t is both generic and specific. It enable the team to do the entire job. RUP is very rich (in content), but is generic by being based on a There is much more to it than that. you can use it in a very light way. number of sound best practices;

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 21 these best practices must (if components — into your design design, self-documenting code, applicable) be integrated and (with the appropriate tools to do and we tested like hell. “Implicit” provide a common vocabulary so, of course). refers to all the diagrams we drew and presentation. The process on the whiteboard that were What is unique about this process framework is specific in that it thrown away by the cleaner.3 framework approach is that you can be successfully specialized or can get a product team quickly up Sure, there were some successes tailored to any application area, to to speed. The team can focus on — thanks to the incredibly good any type of product (pacemakers, solving the business problem people that made them happen. claim systems, auction systems, instead of having never-ending However, incredibly smart people banking systems, command and discussions about what needs to are a scarce resource. Moreover, control systems, etc.), and to any be done — that just slows down projects that didn’t succeed were platform being used. It must also the project. You may still need a in the vast majority. reflect the competencies of the mentor who assists the team as developers, the maturity and size If the software community is ever it goes, and you still need compe- of the organization, and whether going to be more efficient — tent people on the team. The the work is distributed or not. developing good software fast with process doesn’t replace them, the desired quality — we need Since the process framework is it empowers them. tools to help us do more by doing generic, it contains more activities less. Using only light tools will hold and artifacts than any individual us back where we have been all development team would apply. A GOOD PROCESS USES TOOLS these years. For a particular software product, TO DO MORE BY DOING LESS you create a process by picking Whatever you do, in order to be I agree with the idea that we want and choosing from the framework. efficient, you need good tools. a process that is very light. In fact, I Good tools are tools that are want a much lighter process than I This is what the RUP is about. It is developed integral with your have heard people speak about. It a process framework from which process. The process and the will be light because tools will do your team, with the help of special tools go together. To take a real- the job — you will be doing more tools, can create its own process. world example, if you want your by doing less. I want much more in Software. You shouldn’t have to carpenter to drive nails in a wall, my tools than the light tools that go reinvent the same software over he needs a hammer, not a screw- with a light process. Thus, my tools and over again. You should use a driver. If you want your baby to are not really “light” tools, and to process that helps you harvest eat on her own, give her a spoon, tell the truth, my process is in components and incorporate not a knife. The same goes for reality rich. However, thanks to my existing components — legacy software. not-so-light tools — my powerful systems or other reusable We obviously need tools for tools — that go with the rich programming (coding, debugging, process, the process will be compiling, etc.). Let me call them perceived as very light. And that If the software community light tools (even if I can hear many is all that counts, as long as the is ever going to be more people object to my calling these process is still agile. efficient — developing good tools “light”). Light tools must go 3Parenthetically, I can’t understand — software fast with the with a light process to be agile. given that we have good tools — why desired quality — we need Even so, we have been using light we would throw away something that tools for more than 40 years now we needed to create the first release of tools to help us do more by a software product. What we needed and got “implicit” requirements, doing less. for that release we will probably need “implicit” architecture, “implicit” even more for the next release.

22 January 2002 ©2002 by Rational Software Corporation. All rights reserved. These tools were part of my 1986 LOOK OUT FOR dream. Such tools would help you An agile process relies on THE NEXT BIG THING to create requirements, use cases, tools for whatever you do A process framework with tools architecture, design, tests — every- from “womb to tomb.” significantly empowers you as a thing a developer does. What you developer. The knowledge base would create is not documentation about good software that comes better with every release. It is part but models. When you created a with the RUP continues to grow, of our vision for the future. use case, for instance, it would be the process framework becomes part of a model that would actually We use the RUP, UML, and tools to easier to understand and to use, become a collaboration among support it. We have created light and more and better tools evolve. objects and eventually code and specializations of the RUP, which You should be making this effort. test cases. With proper tools, we are supported by light tools. There However, many others will not would get to the point that “the are even lighter versions, but we make these investments. They will models are the code,” or “the code will not suggest that you water jump for light processes with light is the models.” Of course, all these down the process. Rather, we tools and assume that good people work products would be explicit. will convince you to keep our can work wonders. They will rely They would not disappear as the best practices: develop iteratively, on light development practices whiteboard drawings did when the manage your configurations, find that have been around under other project was over. You would have the right architecture first, refactor names for decades. The problem them for the next project. when you don’t succeed, and so is that software development will on. Within these invariants, your Thus, the tools do the job for you. still be hard. In fact, it will become team can create the process it Once you have created the archi- even harder. We will see many wants. It will be a rich and light tecture (in the form of the archi- software companies fail. For those process, a process that is per- tectural baseline), you also have others that won’t make these ceived to be light even though executable code. Once you have investments, there is to my mind below the surface it is very rich. created the design, you have 80% only one way out that dramatically On top of all this, you can scale up or more of the code that imple- — not just marginally — changes your process to a larger team, to a ments it — without having had to this picture. It is the next big thing. team of teams distributed around think about it. The majority of your the world, and to a product with test cases follow from your design. In 1980, I wrote a letter to the pres- many different features allowing a Integration tests are created from ident of Ericsson, the essence of lot of customization. Still, your light your use cases. And on we can go. which was that the component- version will not and shall not be You use blueprints to express your based approach we were then burdened by this ability to scale architecture and your design in a using would evolve into a world up. We call this “right-sizing” way similar to what engineers standard. We should now go the process. have been doing for hundreds of forward by (1) developing our modeling language, (2) evolving years. We have a standard for An agile process relies on tools for our process into a world standard making these blueprints — we whatever you do from “womb to supported by tools, and (3) devel- call it a modeling standard (i.e., tomb.” An agile process is rich and oping expert system support on top UML). Of course, you use code, light — perceived to be light, even of process, language, and tools. too, but just to express what is best if it is very rich. It is thanks to the expressed by code, namely actions rigorous tools that go with the rich I realized that expert systems (or operations, methods). process that the process becomes could not be powerful enough light. You will be able to do more Does this sound like magic? Well, to do the job (1) before we got by doing less. And there is more we do some of this today. We get a standard modeling language to come. like UML, (2) before we had a

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 23 I wouldn’t support this without Dr. Ivar Jacobson is vice president of Twenty years later, we can believing in it and believing that process strategy for Rational Software Corporation. Dr. Jacobson is the founder take the next big step. It is we can get there soon. And we of Objectory AB in Sweden, which “intelligent” agents. can only get there thanks to the merged with Rational in 1995. He is one existence of UML, the RUP, and of the three original designers of the supporting tools. Unified Modeling Language (UML), knowledge base like the one in which was officially adopted as a stan- the RUP, and (3) before we had Let me conclude by saying that dard by the Object Management Group (OMG) in 1997. supporting tools. Twenty years although I have in this article later, we are there; we can take primarily discussed processes from Dr. Jacobson’s seminal contributions center in five major areas, beginning the next big step. It is “intelligent” an agile perspective, we expect with the architecture-centric approach agents. much more of a process than just to software development. Developed at agility. We want it to empower you Ericsson beginning in 1967, this approach We can put a layer of agents on to solve your business problems was adopted by the telecommunication top of the RUP and its tools. These standard SDL. Emphasizing use case– and to satisfy your users. We want agents are programmed to trigger driven development, the process was your systems not only to work 24/7, an early example of component-based for different events. They recognize but to grow gracefully as the world development. By 1987, Dr. Jacobson had patterns and anti-patterns; they developed this development process into changes. To get there, you need a suggest resolutions. They assist Objectory, which he expanded in the process framework, a modeling early 1990s to include business engi- the developer dynamically in using language, and supporting tools, not neering. After several more generations, the knowledge base. They suggest the least of which will be the “next and after joining forces with Rational, the next micro-activities to be Objectory evolved in 1998 into the big thing,” intelligent agents. performed, many of which follow Rational Unified Process (RUP). from the context of the work being Dr. Jacobson is the principal author of done and do not require anything REFERENCES five influential and best-selling books: Object-Oriented Software Engineering — creative by the developer. The 1. Jacobson, I. “Language Support A Use Case Driven Approach; The developer is empowered to “think” for Changeable Large Real- Object Advantage — Business Process and not be bothered by all the Time Systems.” In Proceedings Reengineering with Object Technology; small pieces of work that today Software Reuse: Architecture, Process, of OOPSLA’86, special issue of and Organization for Business Success; constitute what we usually call SIGPLAN Notices, Vol. 21, No. 11 The Unified Software Development “the hard work.” (November 1986), pp. 377-384. Process; and The Road to the Unified Software Development Process. He is The process will be very agile. It 2. Jacobson, I. “Object-Oriented the coauthor, with Grady Booch and Jim Rumbaugh, of The Unified Modeling will be perceived as a very light Development in an Industrial Language User’s Guide and The Unified process, but it is based on very Environment.” In Proceedings Modeling Language Reference Manual. rigorous tools. Obviously, you learn of OOPSLA’87, special issue of as you go. It can easily adapt to Dr. Jacobson can be reached at Rational SIGPLAN Notices, Vol. 22, No.12 Software Corporation, 18880 Homestead different roles that people play, (December 1987), pp. 183-191. Road, Cupertino, CA 95014. Tel: +1 408 and it can scale up as needed. 863 9900; E-mail: [email protected]. 3. Jacobson, I., G. Booch, and Does this “next big thing” sound J. Rumbaugh. The Unified Software like science fiction? Maybe, but Development Process. Addison- I don’t think it is far ahead.4 Wesley, 1999. Am I saying this because I am personally involved in it? I can 4. Kruchten, P. The Rational understand that I risk my credi- Unified Process — An Introduction. bility, but I have to take this risk. 2nd ed. Addison-Wesley, 2000 (see also www.rational.com/ 4See www.jaczone.com. products/rup/index.jsp). 24 January 2002 ©2002 by Rational Software Corporation. All rights reserved. OPF: will build to suit ©2002 byBrian Henderson-Sellers.Allrights reserved. situations. of variety wide a for models process configure to used be can OPF the how show will I and [10], engineering method situational or engineering method called often approach, of kind this exemplarof an is [3] ProcessOPEN Framework(OPF) The heavyweight. and weight light- both including created, be can processes of kinds different of range wide a which from form plat- flexible a provides itself that framework a coexist; can agile the and rigorous the which in work frame- a present I article, this In regulars. the by built one to kids” “whiz of team a by built software from demands, precision lower with systems to systems critical safety- from circumstances: all in perfect be will that methodology single a create can we that dream impossible an seems it Indeed, conditions? specialized certain in right only is right, being in each, that possible it is cause, their of rightness the about adamant are extreme each of ponents pro- While time. that at existing methodologies OO “rigorous” more the of some of “heaviness” perceived the to reaction a as ago years few a appeared They software. building to approach new a offer to appear ologies method- OO lightweight, or Agile, by BrianHenderson-Sellers Getting theBestofBothWorlds Agile orRigorousOOMethodologies: leads to a higher CMM or SPICE or CMM higher a to leads knowledge Organizational viduals. indi- of knowledge the than rather organization the of knowledge the in embodied is that one is process organizational an of notion the and on, move people But people. good less than help less need well may people Good work. daily their in them helps it that feel and process the like teams development software the all in participants the if successful be to going only all, after is, process The process. people the mention to not — on so and work, you which in domain the of criticality safety of degree the culture, mony,”organizational your “cere- of degree your working, of way your suits ideally that one is you) (for process perfect The company. every for perfect be hta that Weexpect therefore shouldn’t diverse. are teams development software the in individuals the of sets skills the And diverse. are opportunities and needs business-level specific address to create they applications The diverse. are technology of world changing rapidly today’s in developers software of needs The ONE SIZEDOESN’TFITALL single process single involved in executingthe in involved would ever would would be more appropriate, then appropriate, more be would RUP where situation different a say,to to, XP suited ideally ation situ- a from move you and change characteristics organizational your if that is 1 Figure in processes of suite the with problem obvious An applications. possible the of subset a only to limited been has scope Their boxes. these from escape never can and “heavyweight” or “lightweight” as labeled and holed pigeon- are Methodologies debate. rigorous versus agile the created has that mindset the essentially is This 1). Figure (see set skills product/ organization/software of each for one processes,” “standard of suite a create to is approach second A effective. cost not and feasible hardly is This organization. individual each for process perfect a scratch from create can Consultants pursue. can it) of part OO the (here, industry software the that alternatives several are There options? the are what then, process,” “perfect personalized your get to order In occupation. fruitless a be to appear would development software for process single a seeking and all, fit doesn’t size one words, other In knowledge. individual does than capability process of level Vol. 15,No.1 type 25 EXEMPLIFYING METHOD ENGINEERING USING THE OPF Process A Process B Process C etc. One good example (there are many others) of the third option Suitable for Suitable for Suitable for A1, A2 B1, B2 C1, C2 described above is the OPF, described most recently by Donald Isolated islands — no transitions possible Firesmith and myself [3]. The OPF as organizations change and mature contains three major elements: (e.g., CMM, SPICE) n A metamodel, which defines Figure 1 — A suite of processes, each only suitable for a highly restricted the rules of the process set of circumstances (after [7]). components you have to do a major process two, critical elements: the exis- n A repository of process refit and literally throw one tence of a repository of process components, which are process out and introduce another. component descriptions and for instances of each metalevel There is no chance for software each of these process components process element process improvement. to be an instance of an element in n A set of usage guidelines that a metamodel. Process construc- The third option is the one I are helpful for constructing tion is then a matter of selecting advocate here — creating a and tailoring the process from the process components itself to a specific problem set of process components, and creating the configured and and organizational context underpinning them with a meta- “personalized” process, which model, and using these compo- In the metamodel of the OPF, may itself then be further tailored nents, as in a constructor set, there are three major metaclasses: (i.e., minor modifications to the to piece together the complete producer, work unit, and work specifications as abstracted from methodology/process. Since such product; these are supplemented the repository). a constructor set is equally useful by two other top-level classes: in building something small, by stage and language (see Figure 2). using only a few components, or building something large, by using Stages almost all the process compo- provide nents, then changes in the organi- macro organization help to Guidelines zation can be accommodated to the within the single process frame- Essential Producers For each element (represented work. Software process improve- process by box), OPEN permits the components user to select how many and ment is also strongly supported by which instances will be used. The OPF documentation such a flexible approach. perform produce provides a comprehensive list of suggestions on the best selections together with guidelines on their best create organization. Work evaluate Work METHOD ENGINEERING units iterate products maintain Method engineering focuses on are creating process components or documented fragments [2] and then putting using

them together in such a way as to Languages support individual circumstances [11]. This requires one, preferably Figure 2 — The basic metatypes of the OPEN Process Framework (OPF) (after [3]).

26 January 2002 ©2002 by Brian Henderson-Sellers. All rights reserved. Producers use work units to create work products. Calendar time predefined OPEN sequencing is done by the applica- concepts + relationships process tion of stages, and languages are used to document the resultant metamodel work products.

Each of the five top-level classes in Instantiation Figure 2 has subclasses (still within the M2 or metamodel level). There predefined are many kinds of work products: repository OPF Repository for instance, documents, metrics, of process requirements, architectures, components of process components, applications, and components so on. Subtypes of the work unit metaclass are fewer, the main used as source for ones being activity, task, and tech- creating a Construction nique. Producers are described as specific process either being “direct producers” or “indirect producers,” the former being either tools or persons user created “perfect” Endeavor-specific playing roles, the latter being orga- process process nizations and teams. Finally, stages may be phases, cycles, builds, or milestones, and languages include Figure 3 — Creating an endeavor-specific (enterprise or project) process (after [7]). natural languages, modeling languages, and implementation portions of the process. This is of high/low ceremony, and size of languages. referred to as process construction the team. (see Figure 4). Each of the above metaclasses There are also a number of usage generates instances, which are Since many such process guidelines provided as part of the “process components” stored in instances can be created from OPF to help the inhouse process the model-level (or M1 level) the one framework, we can create engineer. They are divided into repository (see Figure 3). This a family of processes for various three parts: construction guide- repository thus contains myriad industry demands. These might lines, tailoring guidelines, and, possible process elements, all fully range from critical safety software of less interest here, extension described and ready to be used in to background financial proc- guidelines. creating your process. In addition, essing, real-time stock market users can add extra components modeling, and so on. Construction from their own best practices. The decisions need to take into Since many such process account myriad variables pertinent process engineer within the orga- instances can be created to the development organization. nization will select appropriate from the one framework, process components and put them These include, but are not we can create a family of together to form an actual process, restricted to, CMM level of matu- or process instance, within the rity, available skills, available tools, processes for various given guidelines (see below) and criticality of the software, quality industry demands. ensure compatibility between all level desired, time scales, degree

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 27 The advantages of the “constructor Personalized OO ‹‹ instance of ›› process set” approach are manifold. The OPEN process M2 constructed process has been is tailored created by members of the to meet the needs M1 generates of a specific offers organization themselves. They instances for advice on thus have “ownership” of the Project resulting OPEN process. Everyone has bought into the process because they have had the oppor- tunity to contribute to its formation 1 1 describes throughout the period of process Class library of process Usage M1 components how to use the guideline construction. In addition to local

contains instances of ownership, there is also global support, because the framework 1..* and repository from which your Producers process has been constructed are identical to the ones used by many M2 produce perform 1..* 1..* other companies worldwide. You 1..* Work can thus participate readily in user Work 1..* create, units 2 products 1..* evaluate, group meetings, and your new or document hires will potentially have the Figure 4 — Process component instances are generated from the M2 metamodel necessary skills gained from a (OPF) and stored in a repository (M1 level) prior to construction to form individually worldwide “community standard” configured and tailored process instances. rather than the use of an idiosyn- cratic, inhouse approach. Construction Guidelines Tailoring Guidelines A process construction guideline Once the process framework has As I have shown here, the OPEN helps process engineers both to been instantiated and use on real approach supports a high degree instantiate, when necessary, the projects has begun, the develop- of flexibility in process construc- development process framework ment team frequently recognizes tion. Use of process components (metamodel) to create process the necessity to fine-tune the from the repository (created by components and also to select the process. This is called tailoring; both the OPEN Consortium best process components (from the OPF contains tailoring guide- members and the end users) leads the repository) in order to create lines to help process engineers to a highly tuned process that is the process itself. Specifically, undertake these minor modifica- suited to your individual, local guidance is provided on the selec- tions of the instantiated process needs, which may be agile or tion of appropriate work products, components. heavyweight. producers, and work units, as well as advising on how to allocate Extension Guidelines tasks and associated techniques Finally, extension guidelines are to producers and how to group provided to permit alterations to 2 the tasks into workflows, activities, the metamodel itself. This is not For instance, we regularly hold an and so on. Finally, developmental part of normal process construc- OPEN “birds of a feather” gathering at international conferences such as stages (including phases and life- tion and therefore outside the OOPSLA, and there is a listserv cycles) are chosen. scope of this article.1 discussion group hosted on the OPEN 1For further details, see [3]. Web site at www.open.org.au.

28 January 2002 ©2002 by Brian Henderson-Sellers. All rights reserved. EXAMPLE PROCESSES Having selected appropriate activi- provide the necessary support To construct an agile or a rigorous ties, the project team can then for each task. identify what tasks might be appro- instantiation of the OPF, there are To make this use of the two priate. While OPEN’s tasks are like a number of features you must matrices more real, we will now activities in the sense that they recognize and steps you must consider a couple of examples — describe things that have to be follow. Firstly, the overall architec- a rigorous/heavyweight process done (but not how to do them), ture of OPEN is one in which a instance and an agile process they are different in that activities number of activities (types of instance. work unit) are connected together are conceptual in nature while tasks are linked to a project to form a problem-specific or “Heavyweight” Process Example management mindset — being the organization-specific OPEN First let us consider the construc- smallest unit of work that results in process, as described above. tion of a more rigorous or heavy- a deliverable and can be managed. Permissible sequences of events weight process. The types of or paths through the process are The relationship between activities activities you might select are prespecified by the organization’s and tasks is many-to-many, and shown in Figure 6. Here project process engineer to meet the the OPF construction guidelines management is identified as a demands of the endeavor (see provide a matrix template to assist specific activity, whereas in other, Figure 3). A project team can only the process engineer in making small process instances, it would move between activities when it these connections (see Figure 5). be integrated across a number of has met both the postcondition of A similar matrix template is also activities. Roughly speaking, if the activity about to be left and the applied at the next stage, which is there is a team responsible for precondition of the activity about the determination of which object- something, it is likely to require to be started. This is the contract- oriented and/or component-based an identified activity in OPEN. driven lifecycle model used by development techniques might be Similarly, testing is identified as OPEN [4]. The process engineer most appropriate to select from an activity rather than being an creates these contracts, and they OPEN’s toolbox [8] in order to integral part of one or more consist of testing criteria, deliver- other activities. ables, quality standards, and so on. Activities in OPEN, which are The heart of OPEN: Activities and Tasks modeled as objects, are coarse- Tasks say what is to be done grained descriptions of what needs Activities to be done. The combination of Activity A Activity B Activity C Activity D Activity E activity objects and forward and Task 1 M D F F F Task 2 D D F F D backward linkages forms the Task 3 D D O O D Task 4 F O O O F process. The actual scheduling Task 5 F M O D F Task 6 R R M R O comes from the planning activities Task 7 D R F M O Tasks Task 8 D F M D D and tasks and the project man- Task 9 R R D R R Task 10 O D O O R agement elements embodied Task 11 F M O F D in appropriate tasks. A specific process instantiation may concen- 5 levels of possibility trate on a single project or on For each activity/task combination, M = mandatory R = recommended a program of several projects, choose from one of five levels of O = optional which introduces new foci such possibility from Always to Never D = discouraged as domain modeling and reuse, F = forbidden as well as resource allocation. Figure 5 — OPEN matrix linking activities to tasks (after [5]).

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 29 being whether a technique is effective and efficient in gaining Requirements Engineering closure on the task for which it is being used).

Architecting Although I have described the process construction in essentially a top-down fashion, there is no rule to say that this is the only way. Design Often it can be better to start with a focus on what deliverables are needed, then ask what tasks and Implementation techniques are going to be useful in facilitating their creation, and Testing only then group tasks into appro- priate higher-level abstractions of

Project management the activity. Integration “Lightweight” Process Example In the lightweight example, we identify only four major activities: Evaluation

Extra project activities and reuse management coding, designing, review, and testing (see Figure 9 on page 33). The associated tasks and tech- Deployment niques make up a relatively small list and are more informally deter- Figure 6 — An example of an OPEN process instance for a larger-sized project with mined than in the formal matrix explicit project management and testing (after [3]). template approach above. They The next step is to identify appro- Finally, you must identify tech- include, for example, those recom- priate tasks for each of these niques that facilitate accomplish- mended in Extreme Programming activities. This is done by com- ment of the tasks. As with the [1] such as pair programming, the pleting the matrix template of selection of tasks, you use a matrix planning game, system metaphors, Figure 5. While the activities are to select techniques (see Figure 8 and refactoring — all elements that written across the top, the possible on page 32). Which techniques have been “borrowed” for inclu- tasks are written down the left- you select can depend not only on sion in the more recent versions hand side (see Figure 7). Then one suitability for the job at hand (the of the five values of possibility is accomplishment of the task) but (text continued on page 32) assigned (although I only use the also the preferences and skills of two extreme values in Figure 7). the various development teams If an inappropriate task is inadver- and team members. Another Although I have described tently selected, then the line corre- consideration is the degree to the process construction sponding to this task will comprise which your organization wishes to in essentially a top-down all “Fs” (see Figure 5) and can standardize on specific techniques fashion, there is no rule to then be eliminated. or considers the technique used to be immaterial (the only criterion say that this is the only way.

30 January 2002 ©2002 by Brian Henderson-Sellers. All rights reserved. Task Activity 1 2 3 4 5 6 7 8 9 10 Undertake feasibility study Y Undertake project planning Y Manage human resources Y Identify project roles and responsibilities Y Analyze user requirements Y Maintain trace between requirements Y Y Y Y Y Y Create a software architecture Y Prototype the architecture Y Develop capacity plan Y Y Construct the object model Y Identify classes, objects, roles, types, interfaces Y Design the database model Y Design the human interface Y Refactor Y Integrate components Y Code Y Plan integration Y Y Plan testing strategy Y Y Design test suite Y Code test suite Y Execute tests Y Report on test results Y Deliver product to users Y Train users Y Identify appropriate reusable work products Y Develop reusable work products Y Manage library of reusable components Y Y Undertake program planning Y Identify program funding Y Evaluate quality Y Undertake postimplementation review (a retrospective) Y Evaluate the design Y Y Evaluate the potential components Y KEY: 1. Requirements engineering 2. Architecting 3. Design 4. Implementation 5. Testing 6. Integration 7. Evaluation 8. Deployment 9. Project management 10. Extra-project activities and reuse management

Figure 7 — Task/activity matrix values for the “rigorous” OPEN instance (only a subset of exemplary tasks are shown).

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 31 Technique Task 1 2 3 4 5 6 7 8 9 Cost estimation Y Critical success factors Y Beta testing Y Regression testing Y Defect detection Y Abstract class identification Y Contract specification Y Generalization and inheritance identification Y Qualification, examination, specification, transformation, Y aggregation (QESTA) Granularity Y Rule modeling Y CRC card modeling Y Pattern recognition Y Dialogue design in UI Y Usability testing Y Y Class internal design Y Implementation of services Y Implementation of structure Y Checklists Y Computer-based training Y Lectures Y Roleplay Y Workshops Y Genericity specification Y Revision of inheritance hierarchies Y Class/type indexing Y Library class incorporation Y KEY: 1. Undertake feasibility study 2. Construct the object model 3. Design the human interface 4. Code 5. Evaluate the potential components 6. Train users 7. Develop reusable work products 8. Manage library of reusable components 9. Evaluate quality

Figure 8 — Part of the completed task/technique matrix for the “rigorous” OPEN instance. Only nine illustrative tasks (from Figure 7) are shown. (The full matrix would comprise several pages for such a heavyweight process.)

of the OPF [3, 6, 8]. In this newer, CONCLUSIONS heavyweight processes. This is agile environment, you may also The OPEN Process Framework has accomplished by using a process wish to augment these OPF been shown to offer extensive flex- metamodel from which to gen- process components with new ibility in support of a wide range of erate process components and ones of your own. process types — from small agile then constructing the process itself processes to larger, so-called from these components. Thus, rather than seeing agile and

32 January 2002 ©2002 by Brian Henderson-Sellers. All rights reserved. Object-Oriented Programming (JOOP) (June 2001), pp. 34-38. Design 10. Ralyté, J., and C. Rolland. “An Assembly Process Model for Method Engineering.” In Advanced Information Systems Engineering User (CaiSE 2001), Lecture Notes in Code Review Computer Science 2068. Edited by K.R. Dittrich, A. Geppert, and M.C. Norrie. Springer-Verlag, 2001.

11. Rupprecht, C., M. Fünffinger, H. Knublauch, and T. Rose. “Capture Test and Dissemination of Experience About the Construction of

Engineering Processes.” In Figure 9 — An example of an OPEN process instance for a lightweight Advanced Information Systems or agile process Engineering (CaiSE 2000), Lecture heavyweight processes as two 4. Graham, I. “A Non-Procedural Notes in Computer Science 1789. ends of a discontinuous spectrum, Process Model for Object-Oriented Edited by B. Wengler and L. the OPF supplies an underpinning Software Development.” Report on Bergman. Springer-Verlag, 2000. framework in which both can not Object Analysis and Design, Vol. 1, Brian Henderson-Sellers was the only coexist, but effectively trans- No. 5 (1995), pp. 10-11. first director of the Centre for Object mute, the one into the other, as the 5. Henderson-Sellers, B. “Activities, Technology, Applications, and Research demands of a project or an organi- (COTAR; 1994-6, 1999-present) and is Tasks, and Techniques in OPEN.” zation change with time. Thus professor of information systems at the COBOL Report (May 2001). University of Technology, Sydney. His software process improvement interests are mainly in OO methodologies becomes possible within the one 6. Henderson-Sellers, B. and process, metrics, project manage- process framework of the OPF. “Enhancing the OPF Repository.” ment, and company migration to OO. Dr. Henderson-Sellers is involved in Journal of Object-Oriented several metrics projects, leads the OPEN Programming (JOOP) (October Consortium, and is involved, through the REFERENCES 2001), pp. 10-12, 22. Object Management Group, with the 1. Beck, K. Extreme Programming ongoing changes to UML and the new initiative toward a Software Process Explained. Addison-Wesley, 2000. 7. Henderson-Sellers, B. “Process Flexibility and Process Engineering Model (SPEM) standard. He has published a significant number 2. Chroust, G. “Software Process Construction.” COBOL Report of papers and books under the auspices Models: Structure and Challenges.” (December 2001). of COTAR, as well as making a large In Proceedings of Conference on number of international presentations. Software: Theory and Practice, 8. Henderson-Sellers, B., A.J.H. He is a columnist for the Journal of Simons, and H. Younessi. The Object-Oriented Programming (JOOP) edited by Y. Feng, D. Notkin, and and a frequent speaker at industry OPEN Toolbox of Techniques. M.C. Gaudel. NCP, 2000. conferences. Addison-Wesley, 1998. 3. Firesmith, D.G., and Dr. Henderson-Sellers can be reached at The University of Technology, Sydney, B. Henderson-Sellers. The 9. Henderson-Sellers, B., B. Haire, and D. Lowe. “Adding Web P.O. Box 123, Broadway, NSW 2007, OPEN Process Framework: Australia. Tel: +61 2 9514 1687; E-mail: An Introduction. Addison- Support to OPEN.” Journal of [email protected]. Wesley, 2002.

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 33 Big and Agile?

by Matt Simons If you pay heed to most of the arti- that you are replacing a legacy learn how to work together. Going cles and books that have been application. Even if you aren’t, into production that first time will written on agile development, you you may not be able to put bits teach you all sorts of lessons about probably wouldn’t even consider and pieces into production as what you might do better when attempting it on a mid- to large- you go. Instead, you will need to you take on the next one. The sized project. All the experts seem wait until you have created some- earlier you can learn these lessons, to qualify their recommendations thing that provides real business the better! Due to their smaller size with something to the effect of, value, something that will allow and more self-contained nature, “This will only work for teams of users to migrate completely to choosing modules as your initial 10-12 developers.” Maybe they the new system for entire tasks or target may allow you to get some- don’t have to. processes. You will be faced with thing live sooner. the choice of whether to develop For the past 18 months, we at Threads are end-to-end processes agile in the large modules or threads. ThoughtWorks have been selec- that touch most or all modules tively implementing agile methods Modules are the functional areas of the system. An example of a (inspired mostly by Extreme of a large application. Billing, thread through a back-end leasing Programming) on a project to build accounting, and order entry are system is: lease entry and booking and deliver the next-generation some typical modules. Modules — billing and invoicing during life back-end leasing system to the are usually reasonably self- of lease — end of lease options — marketplace. The project team is contained, with interfaces to other lease termination. A thread is reasonably big (40 developers, modules in the system. If you are limited in some way: for example, 10 analysts, 15 QA, 10 customers, able to identify a module of your by lease type or by customer. One a few PMs) and the software is system that fills a critical need by of the advantages of choosing a complex (750K+ lines of Java itself or doesn’t rely heavily on thread as your initial go-live target code, lots of complicated business other modules, it may make sense is that in order to realize it, you rules). Most importantly, the appli- to choose this module as your first must develop just enough of most cation is in production, and it prob- “go-live” target. Implementing the pieces of the system and make ably wouldn’t be if we had used a module will allow your team to them work together. In doing so, different approach. you minimize the risk of devel- oping a component that is incom- One of the imperatives of patible with another part of the MODULES VERSUS THREADS system, and you remove the need agile development is to get One of the imperatives of agile for a separate “integration” phase development is to get software software deployed into down the road. Another benefit is deployed into production as production as quickly that your initial delivery is likely to quickly as possible. If you are as possible. have much greater business value, building a large system, it is likely since threads often map to the

34 January 2002 ©2002 Cutter Information Corp. operations of entire divisions or cards and test scripts) and have departments in a business. From the bandwidth to test and deliver The care and feeding of a the development team’s perspec- the working software you are release plan that contains tive, it is often easier for the constantly creating. In addition to 500+ story cards is at least members of a large team to work developers, you will probably need a full-time job. on a thread, since their efforts will the following roles: be spread out over a wider code base and they will be less likely to Domain Experts organize the list of story cards into get in one another’s way. Finally, You will need dedicated, full-time, prioritized iterations. This person is after implementing a thread, you on-site people to play the role of also perfectly positioned to facili- will be much more capable of esti- customer. You will need more tate scope review sessions and to mating the size of remaining devel- than one in order to answer the ensure that the project is meeting opment work since everything else constant questions from the the critical business objectives at in the system should be more or system analysts and to work with every point. less a variation on a theme. the planners to prioritize the flood of new story cards that are con- Iteration Tracker stantly being written by project The release plan manager tees up A team of 20 or more participants. On our team of 40 a list of potential story cards before each iteration. During the iteration developers working on an developers, we had a dedicated team of five domain experts. planning meeting, the team esti- agile project can generate mates to determine which cards incredible momentum and System Analysts will play in the current iteration. produce code at astonishing Direct interface between domain From that point forward, the itera- velocity. experts and developers may not be tion tracker guides the story cards possible (or effective) on a large through actual development. The project. Instead, build a team of tracker measures progress on a Overall, building modules first is “software development” experts regular basis, resolves any issues probably faster initially, but threads who communicate and work well that arise, and maintains commu- are probably better in the long run. with business experts as well as nication between the teams Except in special circumstances developers. This team is respon- working on the new functionality. (such as when you need to get sible for writing functional tests for At the end of the iteration, the something into production fast or each story card that is “played” iteration tracker feeds incomplete lose your funding), it is wiser to based on the understanding of the story cards back into the release choose threads as your initial business need that they have plan to be dealt with in subse- go-live target. gained through interactions with quent iterations. domain experts. On our team, we had about 10 system analysts. QA Team ROLES “Keeping everything working” is A team of 20 or more developers Release Plan Manager the main charge of the QA team working on an agile project can The care and feeding of a release on a large agile project. Once generate incredible momentum plan that contains 500+ story analysts and developers have and produce code at astonishing cards is at least a full-time job. completed a story card, they hand velocity. It is important to structure The release plan manager is it off to QA and move on to the the rest of your teams so that they responsible for facilitating card- next iteration. QA’s job is to will be able to feed your develop- writing sessions and for constantly continue to run the functional tests ment machine the inputs (story working with the customer to (manually at first, automated over

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 35 time) as the software evolves. It is to a large project, but be careful your first few a little bit longer — critical to maintain the ability to about the rate at which you add three or even four weeks. Once deploy after the end of any itera- team members, as adding too everyone becomes more comfort- tion, and a disciplined regression many at once can slow down able with the flow of the project, it testing process is the only way to development velocity. is actually quite painless to reduce ensure that this remains possible. your iteration length. As you approach a major delivery Our QA team started small (four or the end of the project, your QA Each iteration begins with an itera- to five people) and grew to nearly team should grow proportionally. tion planning meeting. We have 20 by the time the application was Depending on your situation, you found that not only is it possible, it ready to go into production. may be able to transfer analysts or is critical to invite the entire team developers to QA as you approach to the iteration planning meeting. BUILDING YOUR TEAM a major milestone. If domain experts and system analysts are not present, devel- One of the tricks to pulling off agile opers will not be able to ask the development on a big project is to We have found that not only questions they need to refine their start small and grow. However, you understanding of a story card and need to be judicious about how is it possible, it is critical to make an accurate estimate. If QA you size your teams based on invite the entire team to the team members are not there, they where you are in the project. iteration planning meeting. will be blindsided with new func- The analyst team should start off tionality at the end of the iteration, at nearly full strength so you can and it will take more time for them If you know your project is going quickly attack the problem and to take over the testing of the new to eventually need 50 developers, generate a full complement of functionality. you may be nervous about starting story cards. The development with such a small number of Running a successful planning team should start off mid-sized. developers. Don’t be. If you lay meeting for 50 or more attendees A core group of around 10 devel- down solid practices, the velocity requires preparation and careful opers can come to a common you will achieve when your team facilitation. Analysts should meet understanding of the architecture numbers 50 will more than make ahead of time to come to a and logistics of the development up for the time you spent at less common understanding on each process. Also, when the system than full capacity. of the stories scheduled for the is small, the members of a large coming iteration. They should also development team have a ten- prepare test scripts to describe dency to get in each other’s way. ITERATIONS each story card they own. During The QA team can start small, since Shorter iterations provide the most the meeting, everyone should there will be a small amount of rapid feedback on your progress, receive a copy of the list of stories. functionality to regression test and they allow you to constantly Analysts briefly describe their card at first. adjust your course. It may be and then a facilitator elicits tasks Once the analysts have an under- counterintuitive to think that a from the developers. The first few standing of the problem and the large team can operate on very sessions may be a little bit rough, developers are successfully pro- short iterations, but with practice but eventually your team will learn ducing working software during it is certainly possible if everyone the most efficient and painless way each iteration, you can begin to shares a common understanding to navigate through the planning scale up your development and QA of the events of each iteration. If meeting. Our first planning teams. Pair programming is a great your team balks at starting out meeting lasted two full days, way to introduce new developers with two-week iterations, make but after a few months, we were

36 January 2002 ©2002 Cutter Information Corp. able to get through it in roughly story cards during the iterations half a day. contained within each increment. Regular delivery of the Proxy users (systems analysts or software under development other groups that represent the is critical to validate that the DELIVERY user group) test the software after functionality you are building Regular delivery of the software every iteration. Real users test the is meeting the business under development is critical to software after every increment. validate that the functionality you Planning (through adding, needs. are building is meeting the busi- removing, and reprioritizing the ness needs. As mentioned above, story cards in the release plan) can evaluate the value of the soft- it is not practical to deliver big happens continuously. ware at any point and make a systems after each iteration. decision to put the software into Until a full end-to-end thread Instead, you will need to figure out production. exists, the “end-of-the-increment” a regular schedule of delivery and testing sessions will be limited to an overall release plan. You may unit testing and feature confirma- wish to plan your deliveries similar WHY BOTHER? tion. However, once a critical mass to what is shown in Figure 1. Our experiences using agile of functionality has been devel- methods on large projects have Here you can see that the project oped, these sessions should proven that it is possible. This is broken into iterations, incre- become actual exercises in user article provides some of the details ments, and releases. An increment acceptance testing. Once you have of how to do it. The only question is designed to meet a clear built a critical mass of business we haven’t answered yet is, “What business objective. This objective functionality (represented by an are the benefits of choosing to is met by playing the appropriate asterisk in Figure 1), the business

Month Month Month Month Month Month Month Month Month Month Month Month Month Month 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Planning

Discovery Increment 0 Increment 2

Increment 1 Iteration 1 Iteration 2 Iteration 3 Increment 2 * Increment 3 UAT

Increment 2 Objectives Increment 4 UAT

- Activate operating lease Increment 5 UAT with 1 asset - Generate monthly billing Increment 6 UAT - Print invoice System Release 1

Figure 1 — Iterations, increments, release.

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 37 work this way for my large into the effort (point A on Figure on Figure 2, this means that your project?” 2), members of the agile project development team is writing and have been developing software for delivering software for almost the For purposes of illustration, we three months, have completed a entire duration of the project. will compare the agile approach number of iterations, and have a Team members constantly learn described herein to a more tradi- very good idea of how fast they and improve and increase the tional approach to a large software can finish story cards. Estimating velocity at which they can project (see Figure 2). A traditional the remainder of the project is complete tasks. By the end of the software engineering approach simply a matter of writing the story project (when everything becomes proceeds through distinct phases, cards and adding up the estimates. most critical), your development usually something along the lines Three months into a more tradi- machine is well exercised and of analysis, design, code, test, tional project, you have completed finely tuned. A seasoned team is implement. Agile approaches a lot of documents and maybe a much more able to respond to compress all of these phases into few prototypes, but you still don’t last-minute requests or changes. each iteration. have any estimates on how long it In contrast, many traditional takes your team to produce work- projects confine development to Better Estimates ing functionality. Agile methods a short phase of the overall project. At the outset of a large project can give you more accurate Developers may only have several (the planning and discovery project estimates sooner. months to practice using their phase), neither method is better tools, technologies, and processes. at making accurate estimates for At the end of an agile develop- the time it will take to develop Practice Makes Perfect Development on an agile project ment project, you have more- software that meets the business starts almost immediately. As is experienced developers who are objectives. However, three months shown by the arrows at point B

Month Month Month Month Month Month Month Month Month Month Month Month Month Month 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Planning

Discovery

Increment 0 Analysis Design Code Test Implement

Increment 1

Increment 2

Increment 3 UAT D A Increment 4 UAT

Increment 5 UAT Ca Ct

Increment 6 UAT

WGS v2 Release 1

Agile B Traditional Figure 2 — Agile versus traditional.

38 January 2002 ©2002 Cutter Information Corp. more likely to be able to do what it complex system, it is very difficult takes to deliver a large system. for users to conceptualize the Changes to either the core system based on paper docu- technologies or the system Prove Out Architecture/Technologies ments. But put them in a room and architecture can be Earlier let them take it for a test drive, and There is significant risk, especially disastrous in a traditional you’ll get 10 pages of feedback in when working with new technolo- project where the actual an hour! Agile methods constantly gies, that the products you choose put software in front of users and development is compressed will not live up to the marketing constantly adjust based on user into a short time frame. hype surrounding them. In addi- feedback. This practice reduces tion, it is not uncommon to make the amount of time you spend being left with nothing at all. From mistakes when designing the building superfluous functionality that point forward, the business system architecture before any and ensures that you don’t build can make a decision at any time to development has taken place. functionality that doesn’t meet the stop development and realize the Changes to either the core tech- business need. value created up to that point. nologies or the system architecture can be disastrous in a traditional Business Value Earlier Big and agile — it may seem like project where the actual develop- Finally, and possibly most critically, a contradiction in terms, but the ment is compressed into a short agile approaches provide business teammates and clients I have time frame. Agile approaches value sooner. Consider a project at worked with have become firm reduce this risk by allowing the point D in Figure 2. At this point in believers that not only is an agile development team to prove out a traditional project, you would approach possible on big projects, the technologies and architecture have a large amount of documen- it is actually the most effective way it has chosen early in the project tation and some undetermined to go about delivering large soft- (Ca instead of Ct, as shown in amount of untested software. If ware applications. Figure 2). If changes need to be for some reason you were forced made, there is much more time to cancel or reduce the scope of Matt Simons is a project manager for to recover, and the impact on ThoughtWorks, Inc. Mr. Simons has the project at this point (or at any experience as both a member and the overall project schedule is point prior to final delivery), you leader of project teams building and minimized. would likely be left with absolutely implementing mission-critical software nothing to show for your time applications. He recently finished working on a project that used an agile Reduce Risk of False Features and money. However, if you were and Missed Functionality approach to plan, build, and deliver a developing based on an agile J2EE-platform-based back-end leasing Inevitably something will be lost in approach, at point D you would system to a large corporate client. the translation between the busi- The project involved nearly 100 team have eight months’ worth of ness need and its implementation members (including 40 developers). production-ready software. in software. The only true way to Furthermore, the functionality that Prior to joining ThoughtWorks, know what you’ve screwed up is Mr. Simons lectured at Chiang Mai had been developed up to that to get the software in front of real University in Thailand, where he point would be the functionality published a book on business communi- users and let them use it. In tradi- that the business chose over all cation. He is a regular speaker at soft- tional projects, users may not get ware development conferences and a other scheduled functionality. a chance to test working software contributor to industry journals. Once you achieve a critical mass for many months. Instead, they that provides actual business value Mr. Simons can be reached at may be asked to review and sign ThoughtWorks, Inc., 651 W. Washington (as discussed above), you remove off on requirements documents or Blvd., Suite 6000, Chicago, IL 60661. the risk of stopping the project and E-mail: [email protected]. analysis artifacts. In a large and

Get the Cutter Edge free: www.cutter.com/consortium/ Vol. 15, No. 1 39 Topic Index utrI Journal Cutter IT September 2001 November 2001 December 2001 February 2001 February January 2001 January 2002 January October 2001 August 2001 March 2001 June 2001 April 2001 May 2001 July 2001 Reorganizing ITforE-Business Security Developing WirelessDistributedApplications ProjectMulticultural andInternational Management Implementing anE-BusinessStrategy The War forITTalent Applications Internet-Based Web Engineering:AnAdult’sGuidetoDeveloping Enterprise ApplicationIntegration Testing E-BusinessApplications The Future ofSPI Customer Intimacy BI andCRM:CriticalSuccessFactors forAchieving I The GreatMethodologiesDebate:Part II The GreatMethodologiesDebate:Part B2B Collaboration Burnout Preventing IT Mobile/Wireless XP andOrganizationalCultureChange Testing Open Source Design forGlobalization Security Web Services BusinessIntelligence and Knowledge Management The Technology Mythin Going theWay ofDisco? Is RiskManagement Issue Themes Upcoming www.cutter.com/summit/ Cambridge, MA02139,USA University Park Hotel@MIT 29 April-1May2002 “Business Technology Times” inUncertain Summit 2002 www.cutter.com/workshops/extreme.html Early birdspecial:registernowat Cambridge, MA02139,USA University Park Hotel@MIT 28 April2002,9:00-4:00 with Kent Beck Extreme Programming Events

http://www.cutter.com/ or +1 800 964 5118