SCRUM messages from comp.lang.smalltalk and comp.object - this is an unedited archive From: Robert McArthur Reply: mcarthur@morakot.nectec.or.th Date: Wed, 21 Dec 1994 07:32:13 +0700 (GMT+0700) Subj: OW tutorial ____________________________________________________________ Jeff, I saw yr posting on comp...talk about the tutorial for ObjectWorld. Thought yr comments about project breakdown etc. were *exceedingly* on target... would 'preciate seeing anything you've got that you feel like letting out ahead of time. By way of a personal intro, I've been involved on and off for the last 8 yrs in building training and adv-design courses for comm'l OO packages. Am currently leading a ST project building a subscription DB for int'l publishers -- an interesting war story as it is one of those apps that have (literally) eaten up millions of $$$ with nothing useful coming out at the end, whereas we're up and running after 3 m-yrs starting from *no* direct ST experience. Thanks in advance... Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Thu, 26 Jan 1995 18:39:40 Subj: Re: OO Project Management ____________________________________________________________ >I am researching modeling techniques for object-oriented development >projects and was wondering what experiences people have had in using conventional >project management tools (e.g., Primavera Project, Microsoft Project,...) >in modeling OO projects. In particular, how does one depict iteration and >reuse within these project models? How successful have such models been in real >project planning? I have used Microsoft Project on numerous OO projects over the years. It does the job barely, and with a lot of overhead, because it is the wrong metaphor. For a good overview of Smalltalk project management, one of the best papers to read is: Pittman, Matthew (1993) Lessons Learned in Managing Object-Oriented Development. IEEE Software, Jan 1993, pp. 43-53. Usability studies, however, have convinced us that only one paper in the literature describes the rapid application development environment achieved with Object Studio (the combination of Enfin Smalltalk and Synchronicity Business Object Modeling and Persistent Object Mapping). Read this next: Takeuchi, Hirotaka and Nonaka, Ikujiro. The New Product Development Game. Harvard Business Review, Jan/Feb 1986, pp. 137-146. Takeuchi and Nonaka describe the SCRUM methodology (a Rugby term) which we use internally. It is significantly different than anything you have seen because there is no project management schedule, only a committed delivery time for a release. The Japanese auto and electronic companies are using it to clean our clocks in the global economy. Did you notice that U.S. auto companies had a banner year and still lost market share in 1994? Small teams are given objectives to meet in a fixed time frame. They take the existing software (you never build anything from scratch) and small projects (2 days to 2 weeks per person) are assigned as SynchSteps. SynchSteps are dynamic pulses generated against the existing code structure that causes mutations (as in a biologic organism). A project team is typically 3 developers, 3 QA people, 3 doc people, and one or two users. They meet daily and all agree on steps completed and next steps. For large projects, small teams of this size build components and a SCRUM of SCRUMs meets less frequently to work out interfaces between components. Developers must be outnumbered on the team by QA and documentation people or they generate too much code too fast (malignant functionality). The code evolves like a biological system via punctuated equilibrium. You can read about this process as modeled by Denny Hillis on a Connection Machine in the book "Artificial Life." When enough mutations occur in multiple parts of the organism, the system shifts to a higher plateau of functionality. We say at this time that a "package" is emitted. This will be a new piece of the software system we are building. For example, we are adding Use Cases to the Synchronicity product at this time and when the package appears, an objective for the release cycle is met. A release cycle, typically six months, is built of packages which are loosely defined as objectives at the start of the release cycle. Management must release control of the team and let it function as a self-organizing entity that grows a system like a plant. We have found that we get dramatically more functionality in less time and a much cooler product with this approach. This approach rationalizes the comments that Fred Brooks made in 1987 in his paper "There is No Silver Bullet". There, he stated that the only way to speed up development was to grow a prototype like a plant. We track the process by the velocity of SynchStep assignments versus the velocity of SynchStep completion. This gives an estimate of package time completion, kind of like launching a rocket, watching its trajectory, and predicting impact point. We can adjust the impact point by lowing the arc (less functionality) or adding rocket fuel (more resources) to hit the time frame committed to management. We monitor progress regularly via demonstrations. Nothing counts with management except delivered code that works. Packages are regularly shipped out as alpha components that people can drop into the current release of Synchronicity. Synchronicity dynamically changes, menus and all, so that people can try out the new functionality and see if they like it. With SCRUM schedules are obsolete (developers love it) and delivery dates never slip (management loves it). If this sounds too good to be true, I suppose it is, but management will agree there is more functionality and less slippage with this process than anything they have ever seen. Our users are asking us to lengthen the product delivery schedule because we are delivering too many new releases with major upgrades too fast. (This still doesn't stop them from complaining about not getting everything on their wish list.) We find that the paridigm shift required for optimum utilization of the SCRUM process is significant. The object-oriented paridigm requires a shift in thinking, but SCRUM requires a shift in the organization and the way people work and relate to one another. Send a note to info@ easel.com if you have trouble locating these papers. Also, since I need to write a White Paper on this process, I am willing to do it dynamically as a thread in response to comments by the newsgroup, if there is sufficient interest. Jeff Sutherland jsutherland@easel.com (via Galahad BIX blinker) From: Marc Davidson Org: State of Oklahoma Reply: marcus@ionet.net Date: Sat, 28 Jan 1995 19:37:51 -0600 (CST) Subj: Re: OO Project Management ____________________________________________________________ >With SCRUM schedules are obsolete (developers love it) and delivery dates >never slip (management loves it). If this sounds too good to be true, I >suppose it is, but management will agree there is more functionality and >less slippage with this process than anything they have ever seen. Our >users are asking us to lengthen the product delivery schedule because we >are delivering too many new releases with major upgrades too fast. (This >still doesn't stop them from complaining about not getting everything on >their wish list.) > >We find that the paridigm shift required for optimum utilization of the >SCRUM process is significant. The object-oriented paridigm requires a >shift in thinking, but SCRUM requires a shift in the organization and the >way people work and relate to one another. > >Send a note to info@ easel.com if you have trouble locating these papers. >Also, since I need to write a White Paper on this process, I am willing to >do it dynamically as a thread in response to comments by the newsgroup, if >there is sufficient interest. > >Jeff Sutherland >jsutherland@easel.com (via Galahad BIX blinker) You sound like a person I would like to share several pots of coffee with. Your views on OO program managment are facinating. I would be very interested in reading your white paper when you finish it. On another subject, I belive I read in an article posted by you that you are useing Visual SmallTalk? If this is correct and if I may impose on you, I would like the, vendors name, address, phone, so on and so forth... I have been aware of SmallTalk for quite some time now but have never had a chance to investigate the language. Visual SmallTalk and several others I've seen are new to me. I am a programmer with the state of Oklahoma and our shop is in the process of a total change in direction. From a main frame environment to a client/server environment. So far the for runner for application development is PowerSofts PowerBuilder and MS Windows. I have been developing in C on the OS/2 platform for a couple of years and see the move to PowerBuilder & the Windows only platform, as a step backwards (no flame on Windows intended. smirk). I am encouraged by all the products available for SmallTalk and the fact that it supports both Windows and OS/2. Any information you could offer to help me show management that SmallTalk is a more productive environment for application development would be greatly appreciated. First I get managment to buy into SmallTalk, then comes OO managment, next nirvana! Or at least I may be able to catch up. Thanks Marc Davidson Group: comp.lang.smalltalk From: goochb@swim5.eng.sematech.org William D. Gooch Org: SEMATECH, Austin Date: Wed, 1 Feb 1995 13:52:39 -0600 Subj: Re: OO Project Management ____________________________________________________________ On Thu, 26 Jan 1995 ron@rschultz.pdial.interpath.net wrote: > I am researching modeling techniques for object-oriented development projects > and was wondering what experiences people have had in using conventional > project management tools (e.g., Primavera Project, Microsoft Project,...) in > modeling OO projects. In particular, how does one depict iteration and reuse > within these project models? How successful have such models been in real > project planning? I have been using MS Project for OO projects for a couple of years with pretty good success. I don't agree with those who say that a conventional tool like MS Project isn't well-suited to OO projects. Time and resource management are the same whether you're doing OO or not. I do agree that MS Project and tools like it are not ideal, but that's true regardless of what type of software you're developing. The main problems are (1) there is no planning component in Project, everything is a schedule with dates and durations, (2) schedules are necessarily based on guesswork about what will happen during projects, (3) software projects are typically ventures into the unknown to some degree (more or less depending on the specifics), which means that schedule estimates are likely to be wrong, and (4) management often doesn't really understand (2) or (3), so they expect schedules to be met. And this doesn't even consider the changes and extraneous problems that get thrown at us in the midst of projects. The trick for handling iteration is simple: decide how many cycles make sense for the specific project you are planning, and put in that many copies of the appropriate task(s). I generally find that each project involves different demands, and the number of iterative cycles varies according to those demands. It doesn't make much sense, for example, to plan for five iterations of prototyping when you only have three months to get the final result completed and delivered. Longer term projects involve more variables in this context, but I think that it's generally good to plan for a specific number of iterative cycles so that everyone knows what to expect. Anything less specific can too easily lead to conflicts. Reuse is a very different issue, but also not that hard to plan around. If you're reusing existing software, you'd better either understand clearly what it is and what it can do for you up front, or include some time in the analysis phase to determine all that. If you're planning for later reuse, then be sure to include extra development time for reusability design and engineering. In one case, I was managing two simultaneous projects with a reusable common core which was designed and implemented as part of both, saving time on both projects overall and reducing the total volume of code. Group: comp.lang.smalltalk From: ron@rschultz.pdial.interpath.net ron Org: Interpath -- Providing Internet access to North Carolina Date: Thu, 02 Feb 95 09:07:56 PDT Subj: Re: OO Project Management ____________________________________________________________ Responses to this thread on OO project management still point out that the project management aspects of object-oriented software development is significantly different than that of other software development approaches, and that available project management tools are not ideal to modeling such efforts (albeit it can be accomplished, sometimes painfully). But back to my original premise that managing OO projects is different than managing other types of system development. Berard, Henderson-Sellers, Booch, and others have noted that the definition of objects and other larger object-oriented entities (i.e., kits and systems of interacting objects) can occur with a significant amount of parallelism. A common theme in articles about object-oriented projects is the realization that development proceeds not along one major path of analyze the system, design the system, implement the system, test the system, then deliver, but along many independent and parallel paths of analyze an object(s), design an object(s), implement an object(s), test an object(s), integrate objects, then deliver. The question then is, how does the project manager estimate, schedule and manage such parallel activity? Most project plans are currently managed using some form of a project management tool. Such tools (on a personal computer) include, but are not limited to: Project Workbench, Primavera Planner, Microsoft Project, and Claris Mac Project. These tools provide support for the creation of PERT charts, GANTT Charts, and other form of network diagrams showing task precedence and succession. Consider for the moment how these tools deal with a PERT chart. A PERT chart consists of a network of nodes representing activities, and directed arcs depicting the required precedence and succession of the tasks. Each node is unique. A node can not be connected to itself, or any other node that was completed prior in time to the current node. PERT charts generally depict time from left to right, and nodes previously completed can not be reopened. Each node may be exploded into a sub-network. The waterfall lifecycle is easily represented using PERT charts. The high level nodes of the PERT chart are identified as Analysis, Design, Implementing, and Testing. Precedence relationships are established that do not allow Design to start until after Analysis is complete, and Implementing to Start before Design is complete, and so on. The project is depicted as four (or some other number) of nodes, with sub-networks further describing the activities taking place within each major node. The recursive and parallel nature of object-oriented development is not nearly as easy to depict. Instead of having a project lifecycle that consists of four large activities, the project itself is the summation of possibly thousand of individual objects with their own separately executing set of activities. Each object is analyzed, designed, implemented, and tested. These objects are then integrated into more complex, or larger object-oriented entities, such as kits and systems of interacting objects. These larger object-oriented entities are similarly analyzed, designed, implemented, and tested. The instances of analyze a little part of the system, design a little part of the system, implement a little part of the system, and test a little part of the system occurs both from the top-down, as well as the bottom-up. An automobile manufacturing analogy (a simple and not necessarily technically accurate one) serves to clarify the situation. When a new automobile is scheduled for development, one of the first tasks is to generally define the architecture of the vehicle. This architecture defines the high level components of the automobile, and how these components will interface. Once established, separate teams are created to start development. The engine teams effort proceeds concurrent to the body design team, whose effort proceeds concurrent to the transmission design team. At points in time the products of each team are brought together and tested to ensure that the architecture is still valid and workable. If changes are needed to the system architecture, each change is identified, the impact assessed, and each team then acts upon each change and continues completing its object(s). When done, each team integrates their assembly with the other team, and an automobile is delivered. Each object, from the automobile itself (the highest-level object, in this case a system of interacting objects) to the engine, to the pistons, down to the camshaft bearings, is analyzed, designed, implemented, and tested. Where certain objects are not well understood, or a high degree of risk is present, the team may create iterations of prototypes to evaluate facets of an objects design. Information garnered from the creation and evaluation of these prototypes is then factored back into the design. Modeling such concurrent activity, as well as such iterations, is not straightforward in currently available project management tools. Individual object life cycles can be input into available tools to deal with concurrent development. The same set of activities can be repeatedly entered to depict iterative development. But the level of complexity becomes overwhelming for many tools. Assume that an object-oriented system is proposed that contains 100 objects. Each object requires 25 kernels to be executed. Assume ten objects are identified as candidates for iterative development, and each require three iterations of prototyping. The project management modeling of such a project will require the inputting of , and establishing of precedence relationships for, 3000 activities ((90 objects * 25 kernels) + (10 objects * 25 kernels * 3 iterations)). This exceeds the capabilities of many tools available today. But the sheer effort to load this amount of information is a significant cost. For a large project, managing this complexity can be overwhelming. Current project management tools can be used, and abused, to meet the immediate need of project planning and management. The project manager must be cautioned not to abuse the project to meet the limitations of the project management tool, rather than abusing the tool to meet the needs of the project. This occurs often if the project manager is not adequately educated in the management of object-oriented development efforts. But in the long term new tools need to be developed that more adequately support the recursive and parallel nature of object-oriented development. The Future of Object-Oriented Project Management Tools An ideal project management tool for object-oriented development would start by including the following features: o A set of predefined object-oriented development roles that can be easily tailored into project position descriptions. o A set of predefined object-oriented development kernels that can be easily tailored into project tasks. o A set of kernel clusters that can be readily assigned to object types. These object types are definable by the project manager. The project manager may, for example, define one object type to be simple objects that requires only design, implementation, and testing. Another object type may include objects that require analysis, design, implementation, and testing, while another object type may be those objects that are available from the In-house Reusability Library. o A cluster assignment facility that allows the project manager to assign an object to an existing kernel cluster, or create a new kernel cluster for the object. o A networking capability that allows the project manager to establish precedence relationships between kernel clusters. o A report generation facility that provides for basic reporting, as well as project manager defined queries. o Graphics output using both GANTT, PERT, and other graphical representations. o Storage of all entered and computed information in a tool repository. o A set of defined interfaces that allow external tools (e.g., word processing packages, spreadsheets, and desktop publishing tools) to directly access the tool repository as well as all tool facilities. The defined interface should allow the same access to third party tools as the user interface(e.g., tool screens, keyboard or mouse input) allows to the tool. o A simulation or modeling facility that allows the identification of potential bottlenecks, as well as computing project duration and cost. This list can be readily expanded with little difficulty. But the above capabilities serve as an adequate starting point. The key to such a tool is that the tool should represent the project in terms of objects. The project manager would, in effect, use the same object-oriented approach to developing and refining the project plan that the project team uses to construct the system itself. An attribute of such an tool would be high conceptual integrity. Project managers of object-oriented software development projects should seek, and over time, demand such facilities be made available by project management tool vendors. Only through communicating these requirements directly with vendors can the project manager hope to see such features become available. Ron Schultz Knowledge Systems Corporation 919-481-4000 Group: comp.lang.smalltalk From: rmartin@rcmcon.com Robert Martin Org: R. C. M. Consulting Inc. 708-918-1004 Date: Fri, 3 Feb 1995 16:05:49 GMT Subj: Re: OO Project Management ____________________________________________________________ The question has been asked: "How do we use our standard project management tools to help manage OO projects?" On the surface of things, this appears to be a significant problem. We have used the normal suite of tools for managing "waterfall" projects, and it is difficult to see how they can be used to manage "iterative" projects. However, the standard suite of project management tools (e.g. PERT and CPM and Ghant) are not incompatible with iterative development. They are designed to model the schedules of projects, and iterative projects still have a schedule. The difficulty is that the items on the schedule are different. In waterfall project management, the items on the schedule are "Analysis", "Design", "Implementation", "Test", etc. However in iterative development it does not normally make sense to use such items. What items should we use? There is a common myth that iterative projects are projects without schedules. They ramble about, hither and yon, until some techie decides that they have done enough work and declare the project complete. This is not the case. An iterative projects has a schedule just like any other project, and that schedule can be modeled with standard project managment tools When an iterative project begins, the application is broken down into many sub-projects, each with a very small number of features. These sub projects are sometimes called vertical slices, or just slices. Each slice represents a small amount of work that needs to be accomplished. It must be possible to array the slices in time, such that the features implemented in earlier slices do not depend upon the features implemented in later slices. Thus the slices can be implemented in a chronological order. Once the slices are allocated, each can be estimated as to the resources that will be required to implement it. Then these slices can be arrayed on a PERT chart, or any other project managment tool to produce a complete project estimate. However, this estimate is extremely unreliable. When the project begins, the time required to implement the initial slices is recorded, and fed back into the schedule. Each time a slice in completed we learn more about how much time the other slices will take. Thus our schedule becomes more and more accurate as time goes on. The end date on the schedule will change (probably recede) as more data on the implementation of the slices is gained. Fred Brooks once said: "Adding manpower to a late project makes it later." This is certainly true when 80% of the schedule has been exhausted and only 40% of the project has been completed. The benefit to iterative scheduling is that feedback concerning the accuracy of the schedule comes back very early. After the first few slices, project managers can begin to measure the error in their initial estimates and plan for resource changes. Thus they can add manpower to an early project so that it does not become late. (Or they can decide to scrap the project altogether). Note, that the items that are placed into the project management tool are not "Analysis", "Design", etc. They are the slices themselves. In projects that are really big, the slices should be broken down into sub-slices, using exactly the same scheme. The schedule for these slices should also be broken down into sub-schedules, and the process repeated in a hierarchical fashion. -- Robert Martin | Design Consulting | Training courses offered: Object Mentor Assoc.| rmartin@rcmcon.com | Object Oriented Analysis 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design Green Oaks IL 60048 | Fax: (708) 918-1023 | C++ Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Fri, 03 Feb 1995 14:39:17 Subj: Re: OO Project Management ____________________________________________________________ >When an iterative project begins, the application is broken down into >many sub-projects, each with a very small number of features. These >sub projects are sometimes called vertical slices, or just slices. >Each slice represents a small amount of work that needs to be >accomplished. It must be possible to array the slices in time, such >that the features implemented in earlier slices do not depend upon the >features implemented in later slices. Thus the slices can be >implemented in a chronological order. > >Once the slices are allocated, each can be estimated as to the >resources that will be required to implement it. Then these slices >can be arrayed on a PERT chart, or any other project managment tool to >produce a complete project estimate. However, this estimate is >extremely unreliable. There are other issues here that make project estimation difficult using a traditional schedule. It is not clear at the beginning of a slice what parts of the system will need to be modified in what order to complete the slice. As development proceeds unexpected opportunities arise that must be capitalized on to gain optimum speed, flexibility, and functionality. So the problem is how to schedule the completion of a project when you do not know specifically the steps or what each step contains, i.e. the steps must be allowed to dynamically change as the project proceeds. The SCRUM process resolves this as follows. Identify areas where change needs to occur to meet the goals of the project piece. Break the next few weeks of work into 2-5 day pieces and schedule these "Synchsteps". Start development and meet daily with the entire team to review and assess progress. In daily meetings some Synchsteps will complete, new ones will be generated, some will be cancelled, and others deferred. Direction can be changed mid-stream to take advantage of unexpected opportunity and direction is driven by the consensus of the team. A chart of cumulative Synchsteps generated is maintained. It rises quickly and then starts to level off. Cumulative Synchsteps completed are plotted on the same graph as cumulative Synchsteps generated. The curve rises more slowly and then starts to asymptotically approach the total Synchsteps curve. The rate of closure of these curves determines the velocity of the project. Distance to project completion = velocity x time. In the SCRUM approach the termination date of a release cycle is fixed. The only thing that changes it the distance (functionality to complete) or the speed by which you get there (the rate of change of (Synchsteps generated minus Synchsteps completed)). You can restrict functionality, alter the approach, or achieve unexpected breakthroughs which limits Synchsteps generated. Or you can add resources or otherwise close Synchsteps which raises the completion rate. This is equivalent to controlling the impact point of a rocket by raising and lowering the trajectory, or adding or taking away thrust. If fact, this is all management can manipulate in this process. To get involved in any finer detail, management must participate directly in the SCRUM as an equal player with developers, QA, doc, and users who are part of the daily SCRUM meetings. The direction of the development moves only by the consensus of the SCRUM. This development process is a growing experience for all who participate, including the management. Control must be released to the SCRUM to enable it to function as a self-empowered team. In return, applications are delivered faster, better, and cheaper. At the same time, the process must be managed, but the manager must be more like the coach of a rugby team. This is a more rough and tumble environment than some managers are comfortable with. Also some developers have problems in really being open about what they are doing and working with a group process. The average project using todays methods is 189% over budget. 31% of them are cancelled before they are complete (see PC Week, 18 Jan). Conventional project management techniques are a failure. SCRUM works. Jeff Sutherland "C++ runs slightly faster than Smalltalk but a lot later!" jsutherland@easel.com (via Galahad BIX blinker) Group: comp.lang.smalltalk From: goochb@swim5.eng.sematech.org William D. Gooch Org: SEMATECH, Austin Date: Mon, 6 Feb 1995 10:58:06 -0600 Subj: Re: OO Project Management ____________________________________________________________ On Fri, 3 Feb 1995, Jeff Sutherland wrote: > .... > The average project using todays methods is 189% over budget. 31% of them > are cancelled before they are complete (see PC Week, 18 Jan). Conventional > project management techniques are a failure. SCRUM works. True or not (certainly I think the second-to-last sentence is an overstatement), this doesn't solve anything. Until such time as the software managers of the world become convinced that SCRUM works *and they start using it* (and allowing contractors to use it), none of this very interesting discussion is relevant to my work. You're addressing the wrong audience. Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Tue, 07 Feb 1995 11:07:47 Subj: Re: OO Project Management ____________________________________________________________ >> .... >> The average project using todays methods is 189% over budget. 31% of >them >> are cancelled before they are complete (see PC Week, 18 Jan). >Conventional >> project management techniques are a failure. SCRUM works. > >True or not (certainly I think the second-to-last sentence is an >overstatement), this doesn't solve anything. Until such time as >the software managers of the world become convinced that SCRUM works >*and they start using it* (and allowing contractors to use it), none >of this very interesting discussion is relevant to my work. You're >addressing the wrong audience. The audience in this newsgroup is the best audience to address when the need for a complete change in development methodology is required. Smalltalkers have already demonstrated that they are flexible and willing to hang in there for the best long term solution, even if it is unpopular. I find that software managers in companies that I think are going to be around after the turn of the century are very interested in SCRUM and trying to implement it on small projects. I'm tremendously impressed at some of the innovation coming out of some of the MIS shops who are moving to Smalltalk. (I am also appalled at the lack of productivity in those MIS shops who are not moving to Smalltalk) Also, the Pittman paper I referenced which is a highly constrained version of SCRUM (and therefore more conservatively acceptable) won the IEEE award for best paper of the year. Software managers who won't read the best paper of the year should be replaced. And you should refuse to work for them. There are better things to do in life that will further your career than work for people who will be shortly obsolete. Jeff Sutherland "C++ runs slightly faster than Smalltalk but a lot later!" jsutherland@easel.com (via Galahad BIX blinker) Group: comp.lang.smalltalk From: goochb@swim5.eng.sematech.org William D. Gooch Org: SEMATECH, Austin Date: Wed, 8 Feb 1995 09:52:16 -0600 Subj: Re: OO Project Management ____________________________________________________________ On Tue, 7 Feb 1995, Jeff Sutherland wrote: [In an earlier post, I said:] > > .... Until such time as > >the software managers of the world become convinced that SCRUM works > >*and they start using it* (and allowing contractors to use it), none > >of this very interesting discussion is relevant to my work. You're > >addressing the wrong audience. > > The audience in this newsgroup is the best audience to address when the > need for a complete change in development methodology is required. Development methodology? I thought we were discussing OO project management tools and techniques. Project management and development methodology are two very different things, and often handled by different people within any given project, in my experience. > Smalltalkers have already demonstrated that they are flexible and willing > to hang in there for the best long term solution, even if it is unpopular. Sure, in the arena of software technology. When it comes to project management, I observe that we often don't have the choice, because the tools and approach to using them are dictated to us by (who else) managers. > I find that software managers in companies that I think are going to be > around after the turn of the century are very interested in SCRUM and > trying to implement it on small projects. I'm tremendously impressed at > some of the innovation coming out of some of the MIS shops who are moving > to Smalltalk. (I am also appalled at the lack of productivity in those MIS > shops who are not moving to Smalltalk) > > Also, the Pittman paper I referenced which is a highly constrained version > of SCRUM (and therefore more conservatively acceptable) won the IEEE award > for best paper of the year. Software managers who won't read the best > paper of the year should be replaced. And you should refuse to work for > them. There are better things to do in life that will further your career > than work for people who will be shortly obsolete. Sorry, but I think you're living in a dream world. Do you know many consultants who will turn down paying work because they don't like the project management tools required by the client? Formal project plans and schedules, etc., are not something I generally need in order to do good work, but managers usually require them as a means of predicting the future, and to some extent as levers to control the future. It's when they do the latter that there are frequently real problems, and if SCRUM methodology prevents that, great. However, if managers perceive that SCRUM takes away from their ability to predict or (try to) control the future, or if they simply don't feel they quite understand it, they aren't likely to accept it. In that case, people like me will have no choice but to continue using MS Project or whatever they will accept, or simply go out of business. BTW, I guess I missed the reference to the paper (I looked back at your previous post on this topic, and didn't find it). Can you please re-post it or email it to me? Thanks. Group: comp.lang.smalltalk From: chandra@lmis.loral.com B. Chandramouli Org: Loral Medical Information Systems Date: Wed, 8 Feb 1995 17:59:04 GMT Subj: Re: OO Project Management ____________________________________________________________ In article <1995Feb3.160549.2349@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) wrote: > The question has been asked: "How do we use our standard project > management tools to help manage OO projects?" On the surface of > > There is a common myth that iterative projects are projects without > schedules. They ramble about, hither and yon, until some techie > decides that they have done enough work and declare the project > complete. This is not the case. An iterative projects has a schedule > just like any other project, and that schedule can be modeled with > standard project managment tools Absolutely true. Any manager of some competence would not let a marketplace driven (in terms of timely delivery of a quality product) software project to be executed as above. Agreed. but.... > When an iterative project begins, the application is broken down into > many sub-projects, each with a very small number of features. These > sub projects are sometimes called vertical slices, or just slices. > Each slice represents a small amount of work that needs to be > accomplished. It must be possible to array the slices in time, such > that the features implemented in earlier slices do not depend upon the > features implemented in later slices. Thus the slices can be > implemented in a chronological order. The more I think about this, it is becoming clear to me that what Booch talks about and what the above discussion alludes to, they do not have much to do with OO Project Management. I have worked on projects involving 100s of engineers, geographically separated, millions of lines of code with a project duration of year and a half. There were vertical slices and each slice had its own schedule (of requirements, architecture, design, coding, etc) and a grand integration plan. This project itself is a (fairly thick) slice of the entire product release cycle which are executed in the Chronological order that you talk about. But no body even pretended that the project used any OO methodologies. So how does OO project management differ from the above style of management? I think most people would agree with the following observations. 1) OO schedules tend to have lot of internal milestones. Demonstrable features early in the product release cycle. 2) Prototyping in encouraged. 3) Good OO engineers and managers in general don't believe in "Full and Complete Analysis" followed by "Full and Complete Design" etc. They do what they can with analysis, then move on to design probably lot sooner than traditionally done. Here are my questions which I am trying to find an answer for myself: 1) So given the above, how can one create a project management philosophy to accomodate points 1, 2 and 3 above? 2) Why are the above points relevant only to OO? Can a project using a methodology of Process Decomposition followed by Functional Decomposition adopt this approach? 3) Along Macro terms, OO, to many seasoned engineers, has a history: a) Really, OO techniques started at the coding level: Data Abstraction led to modular code and better maintainable code. Inheritance and Polymorphism led to better extensible code. People then started looking for an Analysis and Design techniques which will lead to good use of Abstraction, Inheritance Hierarchies that makes good use of Polymorphism. The following general themes emerged. b) Analysis reflects the real world problem domain c) Design is a continuation of analysis with adding computer domain concepts to analysis. Given the above history, it looks to me that Iterative Development, Prototyping etc. that are usually associated with OO are just incidental to the main OO objective. They probably apply to any type of methodology. 4) This lead to my final observation and question: I think the words Analysis and Design have too much ingrained meaning from the days before OO. If Data Abstraction (leading to modular and maintainable design) and Meaningful Inheritance Hierarchies that makes good use of Polymorphism ( leading to extensible systems) are our ultimate objective, should n't we been thinking about how to best to arrive at them starting from requirements and then "invent" a management philosophy to manage those steps? Thanks for putting up with my ramblings. Chandra Group: comp.lang.smalltalk From: chandra@lmis.loral.com B. Chandramouli Org: Loral Medical Information Systems Date: Wed, 8 Feb 1995 17:59:04 GMT Subj: Re: OO Project Management ____________________________________________________________ In article <1995Feb3.160549.2349@rcmcon.com>, rmartin@rcmcon.com (Robert Martin) wrote: > The question has been asked: "How do we use our standard project > management tools to help manage OO projects?" On the surface of > > There is a common myth that iterative projects are projects without > schedules. They ramble about, hither and yon, until some techie > decides that they have done enough work and declare the project > complete. This is not the case. An iterative projects has a schedule > just like any other project, and that schedule can be modeled with > standard project managment tools Absolutely true. Any manager of some competence would not let a marketplace driven (in terms of timely delivery of a quality product) software project to be executed as above. Agreed. but.... > When an iterative project begins, the application is broken down into > many sub-projects, each with a very small number of features. These > sub projects are sometimes called vertical slices, or just slices. > Each slice represents a small amount of work that needs to be > accomplished. It must be possible to array the slices in time, such > that the features implemented in earlier slices do not depend upon the > features implemented in later slices. Thus the slices can be > implemented in a chronological order. The more I think about this, it is becoming clear to me that what Booch talks about and what the above discussion alludes to, they do not have much to do with OO Project Management. I have worked on projects involving 100s of engineers, geographically separated, millions of lines of code with a project duration of year and a half. There were vertical slices and each slice had its own schedule (of requirements, architecture, design, coding, etc) and a grand integration plan. This project itself is a (fairly thick) slice of the entire product release cycle which are executed in the Chronological order that you talk about. But no body even pretended that the project used any OO methodologies. So how does OO project management differ from the above style of management? I think most people would agree with the following observations. 1) OO schedules tend to have lot of internal milestones. Demonstrable features early in the product release cycle. 2) Prototyping in encouraged. 3) Good OO engineers and managers in general don't believe in "Full and Complete Analysis" followed by "Full and Complete Design" etc. They do what they can with analysis, then move on to design probably lot sooner than traditionally done. Here are my questions which I am trying to find an answer for myself: 1) So given the above, how can one create a project management philosophy to accomodate points 1, 2 and 3 above? 2) Why are the above points relevant only to OO? Can a project using a methodology of Process Decomposition followed by Functional Decomposition adopt this approach? 3) Along Macro terms, OO, to many seasoned engineers, has a history: a) Really, OO techniques started at the coding level: Data Abstraction led to modular code and better maintainable code. Inheritance and Polymorphism led to better extensible code. People then started looking for an Analysis and Design techniques which will lead to good use of Abstraction, Inheritance Hierarchies that makes good use of Polymorphism. The following general themes emerged. b) Analysis reflects the real world problem domain c) Design is a continuation of analysis with adding computer domain concepts to analysis. Given the above history, it looks to me that Iterative Development, Prototyping etc. that are usually associated with OO are just incidental to the main OO objective. They probably apply to any type of methodology. 4) This lead to my final observation and question: I think the words Analysis and Design have too much ingrained meaning from the days before OO. If Data Abstraction (leading to modular and maintainable design) and Meaningful Inheritance Hierarchies that makes good use of Polymorphism ( leading to extensible systems) are our ultimate objective, should n't we been thinking about how to best to arrive at them starting from requirements and then "invent" a management philosophy to manage those steps? Thanks for putting up with my ramblings. Chandra Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Wed, 08 Feb 1995 22:16:32 Subj: Re: OO Project Management ____________________________________________________________ >Development methodology? I thought we were discussing OO project >management tools and techniques. Project management and development >methodology are two very different things, and often handled by >different people within any given project, in my experience. >goochb@swin4.eng.sematech.org But this is precisely my point. The reason that the average project is 189% over budget, not to mention late, is that the project management and development process are closely intertwined in reality, and artificially separated in our organizations. On successful projects, I have controlled the architecture, the development process, and the project management, and involved the entire team in synchronizing them. I've brought $50M projects to completion this way. I much prefer a SCRUM of 12 people that needs to deliver a new application within six months using Smalltalk. That's 3 developers, 3 testers, 3 doc people, and 3 users and a lot more fun. When I had COBOL and C programmers it took 3 times the number of people 2-3 years to deliver less functionality. And by that time, the users changed their minds about what they wanted. Another reason these projects are usually late and over budget is that the users must be part of the process to make it work. In a properly run project they participate in the project management and help define the development methodology. In many conventional projects they never show up. They just get fed up, withdraw the funds, and kill over a third of the projects that are started before they come to completion. The record speaks for itself. Current conventional software project management is a failed approach. I mean, how many times does it have to break before we realize we need to do something different! The Pittman paper below is a conservative attempt at change and should be palatable to most organizations. It also won the IEEE award for best paper so everyone should read it as part of ongoing education: Pittman, Matthew (1993) Lessons Learned in Managing Object-Oriented Development. IEEE Software, Jan 1993, pp. 43-53. Usability studies, however, have convinced us that only one paper in the literature describes the rapid application development environment achieved with Object Studio (the combination of Enfin Smalltalk and Synchronicity Business Object Modeling and Persistent Object Mapping). Read this next: Takeuchi, Hirotaka and Nonaka, Ikujiro. The New Product Development Game. Harvard Business Review, Jan/Feb 1986, pp. 137-146. If you don't want to change your conventional development approach, a must read is: Yourdon, Ed. The Decline and Fall of the American Programmer. Yourdon Press, 1993. Jeff Sutherland "C++ runs slightly faster than Smalltalk but a lot later!" jsutherland@easel.com (via Galahad BIX blinker) Group: comp.lang.smalltalk From: goochb@swim5.eng.sematech.org William D. Gooch Org: SEMATECH, Austin Date: Thu, 9 Feb 1995 11:14:44 -0600 Subj: Re: OO Project Management ____________________________________________________________ On Wed, 8 Feb 1995, Jeff Sutherland wrote: > >Development methodology? I thought we were discussing OO project > >management tools and techniques. Project management and development > >methodology are two very different things, and often handled by > >different people within any given project, in my experience. > >goochb@swin4.eng.sematech.org > > But this is precisely my point. The reason that the average project is > 189% over budget, not to mention late, is that the project management and > development process are closely intertwined in reality, and artificially > separated in our organizations. Agreed. That's why I prefer to do both. >.... > The record speaks for itself. Current conventional software project > management is a failed approach. I mean, how many times does it have to > break before we realize we need to do something different! Again, you overstate your case. Conventional project management tools and techniques, when used well, can and do succeed. Basically, I think the reasons for failure are more in the way the tools are used than in the nature of the tools themselves. That doesn't mean there can't be something better - I hope there is (and thanks for the references). It's not that I wouldn't change to a different approach if I thought it was better and had the choice; for now, however, I don't have that choice. From: David Levy Reply: dale@morgan.com Date: Fri, 10 Feb 1995 17:14:18 -0500 Subj: Re: OO Project Management - comp.lang.smalltalk #18941 ____________________________________________________________ On Feb 10, 1:37pm, jsutherland@BIX.com wrote: > Subject: Re: OO Project Management - comp.lang.smalltalk #18941 > >Is there any more info regarding SCRUM that can be forwarded on to me? > > > >thanks, > >dave levy > > > >Morgan Stanley > >attn: David Levy > >1 Pierrepont plaza 5th floor > >Brooklyn, N.Y. 11201 > > > >(718)754-5441 > >fax (718) 754-5205 > > Nope. But I am working on a white paper. What specific questions do you > need answered? > > Jeff Sutherland jsutherland@easel.com > Easel Corp. (via Galahad bix blinker) > 617-221-2424 >-- End of excerpt from jsutherland@BIX.com What's SCRUM stand for? To: dale Reply: dale@morgan.com, jsutherland Date: Sat, 11 Feb 95 15:24:20 EST Subj: Re: OO Project Management - comp.lang.smalltalk #18941 ____________________________________________________________ >What's SCRUM stand for? > SCRUM is a rugby term. I'm not a rugby player myself, but those who are tell me it is when the entire team links arms, surrounds the ball, and as a single unit, drives the ball towards the goal. The Japanese authors of the Harvard Business Review paper I mentioned applied the term SCRUM to the development process. They also mentioned a variant called SUSHIMI where a the project is delivered in slices, just as a Sushi chef slices the sushi. The Japanese tend to use this more controlled variant. Jeff Sutherland jsutherland@easel.com Easel Corp. (via Galahad bix blinker) 617-221-2424 From: Peter Martiniello Reply: peter@lochard.com.au Date: Fri, 17 Feb 1995 13:59:26 +1100 Subj: ____________________________________________________________ Hi, I read your artical on SCRUM programming with great interest. I would like to get hold of the articales that you mentioned in your mail, if possible. I am also interested in find out what type of SW Engineering process you go through in each iterartion. That is do you produce such documents as SW requirements, design and test and if so what has been you experiance in making sure that they kept upto date. Regards Peter Martiniello Lochard Environment Systems 875 Glen Huntly Rd Caulfield Sth Victoria Australia PH: +61 3 532 9040 FAX: +61 3 532 8209 To: Patrick_D_Logan@ccm.jf.intel.com Date: Wed, 22 Feb 1995 23:26:10 Subj: Re: Supporting evidence, Smalltalk and SCRUM ____________________________________________________________ Patrick, you're remarks are well taken. I have some data that might be useful. Comments are below ... > >Text item: Text_1 > >In Comp.client-server I wrote: >>I agree with this too, to a certain extent. A few of Jeff Sutherland's >>posts have some statements that may have some facts to support them in >>his experience, but they come across without the supporting evidence as >>inflammatory and/or sales bunk. > >In Comp.client-server Jeff Sutherland wrote: >>By "sales bunk" I assume you mean making claims that are not true. I'm >>ready to deliver. Show me the project and I'll prove the point. > >No, I meant claims that without evidence to support them *sound* untrue. > >Two examples: > >(1) You made a claim about novice Smalltalk programmers outperforming >COBOL programmers. Without a specific example, preferably several, this >is difficult to evaluate and sounds like any number of claims made for >any number of tools. This morning, I briefed the IS management at Sprint on ENFIN Smalltalk and Synchronicity directions. I was surprised to find out that on their first project in 1993, a Sprint team learned ENFIN for the first time and delivered a production system in 8 weeks. That system is still a key system in production and is saving Sprint significant amounts of money in their business operations. I was not able to determine if the team was made up of COBOL programmers, but they definitely were not Smalltalk programmers. In a recent evaluation, one of our prospects who was committed to Microfocus COBOL brought in ENFIN for one afternoon for evaluation. The COBOL programmers said they were able to do in one afternoon a prototype of their application that could not be done in a week with Microfocus COBOL even though they already new COBOL and had never seen Smalltalk before. >I am a Smalltalk programmer, a former Lisp programmer, and unfortunately >a C++ programmer. I know about productivity. I haven't used COBOL since >I taught it as a TA in college 15 years ago, but I know enough. Even so, >to believe your claim, I'd like to know something about the experience >of the people you call "novice Smalltalk programmers" and something >about the problem they are solving. I think you need to experience the productivity of ENFIN Smalltalk and Synchronicity. It is significantly different than raw Smalltalk. >(2) On another thread you talk about SCRUM you state: >"Management is guaranteed a delivery date that meets product objectives >- conventional project planning gives them a delivery date they cannot >count on" > >This sounds to good to be true. There is more to this statement than >what appears at first. For example, what are they guaranteed to receive? >Is it guaranteed to be useful? Without ever, ever slipping the date? How >early in the development process am I able to give my management a >specific date? How large is the product? > >I am very interested in SCRUM because I like the ideas behind it, and >the way they fit my development techniques as well as what I see happens >in practice anyway. I believe very strongly in management of complexity >and risk using scale, autonomy, and incremental development. But can I >count on SCRUM to guarantee a delivery of very specific and large amount >of functionality on some date very far in the future? I am not sure what >you are claiming. > >BTW I read the Havard Bus. Journal article you cited. It was OK, but had >a fair bit of flowery talk without specific definitions. For example... > >"Under the holistic or rugby approach, the phases overlap considerably, >which enables the group to absorb the vibration or 'noise' generated >throughout the development process. When a bottleneck appears, the level >of noise obviously increases. But the process does not come to a sudden >halt; the team manages to push itself forward." > >OK. I can *infer* what some of this means, but is this really a >*meaningful* paragraph? I'd like to know more about what "the team >manages to push forward" means; what are the "bottlenecks"; what is a >"level of noise"; what is "absorbing the vibration". > >Anyway, thanks for pointing me to the paper. If you have other >references or information about your own work, I'd appreciate knowing >about it. > >Regards, >Patrick Logan > The Japanese paper on SCRUM definitely needs interpretation to apply to the software environment. What the Synchronicity team agrees to deliver is broadly characterized improvements to the tool, for example, they are current adding use cases and interaction diagrams to the tool. They develop a rough plan (as good as any usually done on projects) and commit to the date. The team then uses the process (which I agree needs a lot more concrete definition which is why I need to write a White Paper on it) to drive to the date. The path to get to the result is discovered in real time. They have been successful enough in exceeded expectations of management, that senior management in the company has agreed to the "loose" control specified in the SCRUM paper. Regards, Jeff Sutherland jsutherland@easel.com Easel Corp. (via Galahad bix blinker) 617-221-2424 To: kumamoto@San-Jose.ate.slb.com Date: Thu, 23 Feb 1995 07:33:14 Subj: Re: SCRUM questions ____________________________________________________________ > >I've read the two papers and various posts of yours, and I >have some questions: > >> 4. Developers are guaranteed low administrative overhead > >It wasn't clear how this was to be acheived. What if the delivery date >will slip? What and how things will be tracked to flag this? (E.g., >what if one person gets sick for a week? Or if one cannot get more >resources early enough -- i.e. people with the right skills >background?) The objective of the process which was not met as satisfactorily as we would like during the last development period is for each developer to post via email projected completion dates and actual completion dates of each SyncStep (each small piece of work). We then drew a graph with two curves, cumulative SyncSteps assigned and SyncSteps completed. At the beginning of the project SyncSteps assigned goes way up. Then SyncSteps completed starts to rise to meet the SyncSteps assigned line. The project manager can look at these curves (which should be automatically created from email) and project into the future when the curves will meet (project completion). It the meeting point is beyond the projected date, action must be taken to bring it in. Resources must be reassigned, functionality must be curve, alternative architectural directions must be taken. > >One comment/question: > >I noticed that SCRUM sounds great for a system with "depth" (many >layers of dependent functionalties), but what about a system with >"width" (few layers of dependency, but many (largely) independent >functionalities)? We have 1+ million lines of (almost all) >uncommented C code with about 150 executables (some do have to work >with each other, but mostly they are independent), but they all work >around our chip tester. We cannot wait years for one team to come up >with all the tools, yet I don't think it makes sense to have 10 >different project groups go and prototype on their own and each come >up with one executable every few weeks (but since they have to used on >one chip tester, all tools have to be consistent). > >I would think that an "architecture" team would come up with the >overall plan or guide for the system and then each team would work off >of this "master plan." (The teams would first continue to support the >current system and learn programming language/environment before >starting the new project.) Or was there something I missed about >SCRUM? This is our approach. There needs to be an overall architecture. However, within the overall architecture, there will be components that can be built by small teams of developers. The goal is to specify the larger context so that small groups can work independently. The traditional curve that shows resource requirements increasing exponentially while lines of code increases linearly must be deal with. The exponential increase in resource is due to communications requirements (between people and between code). Object technology allows you to partition the system to minimize these communication requirements. A partition of the system is a component with a clean API that integrates well with the rest of the system. The other parts of the system should only have to know the API (set of methods that form the protocol), the scenarios that the component is guaranteed to support, and the events that the component will support. The internal of the component should be a black box to the rest of the system. A component is normally built with 1-3 people, never more than 6 or the exponential rise in resource requirements will get you. In a Smalltalk environment building a product, there seems to be a need for an equal number of developers, QA people, doc people, and users. So 3 developers are part of a team of 12. The overall architecture needs to be controlled by a SCRUM of SCRUMs. The leaders of teams meet regularly to review the larger picture. >Thanks for your time. > >Danny > >ITS9000 Software Enhancements >Schlumberger Technologies, ATE >1601 Technology Drive, San Jose, CA 95110, U.S.A. >Phone: +1 408-437-5154 FAX: +1 408-437-5246 >Internet: kumamoto@San-Jose.ate.slb.com > Our developers have been successful with delivering product using these concepts, but not in implementing them to their satisfaction. At this moment, they are focused on how to guarantee improved quality in the code delivered in this rapid application development mode. I am convinced that the quality is dependent on continuous automated regression testing and we are working on that. Jeff Sutherland jsutherland@easel.com Easel Corp. (via Galahad bix blinker) 617-221-2424 Group: comp.object From: holder@alsys.com Robert L. Holder Org: Thomson Software Products, San Diego, CA, USA Date: Sat, 10 Jun 1995 07:35:18 GMT Subj: Re: Future of Booch and OMT ____________________________________________________________ In <3r27cc$a4l@news.uni-paderborn.de> Adam Leventis writes: >The details of the notation will be described in the TWO new books availa- >ble mid-end of 1995. Why two books? Well, Booch and Rumbaugh actually >agreed in a common set of symbols, but have a different idea of the OO- >process. So the two books will use the same notation, but describe a different >approach. They think they will agree on a common process in1996. This >ity... Why two books? More pontification and more bucks for the OO preachers. >Booch likes to code. When he developed Rose (the Booch CASE-tool), he >retired to Canada for a couple of month, and haked a first prototype. So Booch "hacks" and does not follow his own methodology? >That is how he thinks a project should start: > * Code for a while a deliver something executable. Like that you get a > feeling for the complexity and technical possibilities. > * Afterwards find the use-cases of the system and expand each use-case > with some scenarios. > * Take a set of scenarios and implement these. > * Check the results, and adjust the architecture. Implement more scenar- > ios. > * and so on... >The shorter the time for a cycle, the better. He said that in his company they >release each week an internal release. You see, the process how he describes >it is somehow fuzzy. The rest of the day he told so called "war-stories". Suc- >cess- and disaster-stories out of projects he worked in as a consultant. I call >his OO-software process method UCS, because a gives no real guidelines. >Have you not heard of this method? Well it is called Use of Common Sense >(thanks for this idea Mike). Well spoken. This is what it all seems to come down to anyway. OO or SA/SD or "hacking" or ... >version of Rose is easy to use, has a good C++ generator, but does not support >the full booch notation and has a lot of bugs. If you would like to use the tool >to generate code, you have to adopt the notation of the tool. This might work >for about 50-100 classes. >It would be great to have a tool that supports the full life-cycle and is easy >to use. I didn't yet find such a tool. Today I would use document generation If Rose has alot of bugs does that mean it was not developed using the Booch method or OO methodology? Do the OO gurus not practice what they preach? Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Fri, 07 Apr 1995 14:45:57 Subj: Re: Analysis, Testing time (was Re: Smalltalk/V latest release?) ____________________________________________________________ >It is my hope that writing small simulations/prototypes *early* in the >analysis process will help to bridge that communication gap. In the >context of something tangible (like a running program), I hope that the >object diagram will "spring to life" for the domain experts, and I expect >that the use-case diagrams will aquire new meaning for the software types. > >Hmmm... This has become a bit of a tangent to the original subject :-) >I'd be interested in hearing others' experiences with using >simulations/prototypes in this way, though (hence the cross-posting). >billf@medicus.com I've noticed, while consulting and working for several companies since 1986 on OO projects, that it is difficult to get the users to write down all the use cases, but they are needed for a complete requirement. They are guaranteed to be there before the analysis is complete for a delivered system, but you may never get all of them out of the users until the end of the project. It has been a lot easier for users to look at static object diagrams of their business model than to work with entity relationship diagrams. Users are essential to building a good business object model. Also, with the SCRUM methodology approach which has been discussed previously in this newsgroup, the project is managed by seeing working code, i.e. no project piece is considered really done until a demo of a working system that incorporates it can be shown. Evolving production prototypes are the system. When the prototype evolves far enough and works well enough it is delivered to the users. In this way, the project team, the users, and the management can clearly see when milestones have been met, and refine (and adjust) delivery dates accordingly. Jeff Sutherland http://www.tiac.net/users/jsuth "If it doesn't work, it's vaporware!" Group: comp.lang.smalltalk From: jsutherland Jeff Sutherland, Winchester, MA Org: Galahad Date: Fri, 07 Apr 1995 15:09:14 Subj: Re: Okay, what is this Synchronicity stuff? ____________________________________________________________ >I don't doubt that this actually happened or that your products are >useful. I find the implicit claims a little misleading though. I >would be very worried about anyone, doing anything when they don't >understand at least some of the underpinnings. 100 class apps are >nothing. Especially when they are "80% auto-gen'd". We've seen the >sort of code gen'd by Synchronicity and it isn't all that "compact". >BTW, if they didn't know anything about ST, who did the 20%? The >folks at Easel in 3 hours? Wasn't a very big app. > >I don't mean to pick on this particular example or anything. I just >find this sort of stuff adds significantly to the hype-factor >surrounding OO and ST. The last thing we want to be encouraging is >for the corporate financial officers to be running out and cutting >teams in half, hiring people who haven't a clue about the environment >in which they will be working and then assuming that Synchronicity >will save the world. When it doesn't work it will be OO and ST that >takes the fall, not the bean counters. > >JEff One of my technical people at a previous company led a $30M project that runs a $10B nuclear reprocessing plant with an application that took 30 people four or five years to build in C++ and it had about a 100 classes. This does not count the classes for the technical underpinnings which were largely class libraries being reused. So 100 classes can be a good sized project and people who know what they are doing work to limit the proliferation of classes. Every system I have every heard of that is over 1000 classes has been a maintenance nightmare. They should be partitioned into systems that intercommunicate, each of less than 100 classes. In the example quoted above, which was a quick prototype, the 20% of code was written by the people who didn't know Smalltalk. I didn't say we recommended this. In fact, we thought they had lost their minds when they did this without learning Smalltalk, but our support team was, fortunately, able to tweak their code in a few hours. This was a rather hair-raising incident for all concerned because the customer was on a short fuse and expected a prototype to work. As far as cutting staff, take a look at the article by Grady Booch in the latest issue of ROAD, the SIGS publication on OOAD. He cites an example where he was brought onto a project that had several hundred people assigned to it. He demanded that they cut the staff to 50 people maximum. When they refused to do so, he walked away from the job and let them self destruct. This was a C++ project. In Smalltalk you should demand that they cut it way down below 50. Jeff Sutherland http://www.tiac.net/users/jsuth "A good size Smalltalk SCRUM is 12 people (3 dev, 3 QA, 3 doc, 3 users). If you need more people then the project (and application) should be partitioned into loosely coupled multiple SCRUMs. This is also about the same size as the C++ team that Coplien called the most productive C/C++ team in recorded history." From: Kent Beck To: Jeff Sutherland Reply: 70761.1216@compuserve.com Date: Mon, 15 May 1995 18:01:15 -0400 (EDT) Subj: HBR paper ____________________________________________________________ Is there a good place to get reprints of the SCRUM paper from HBR? I've written patterns for something very similar and I want to make sure I steal as many ideas as possible. Kent Group: comp.object From: COATES@EUROPA.UMUC.EDU Ell Org: umd uc Date: 12 May 1995 02:58:01 GMT Subj: Re: Where's the paradigms? (was: C++ <> OOP?) ____________________________________________________________ In <3ou3g6$j5i@news1.delphi.com> jsutherland@BIX.com writes: >... > You can't do good object design without OOAD because you > need design reviews by other experts to help refine your design I've had success designing my own programs, but for large, complex projects such a review is either a part of the development process, or it should be. Stroustrup recommends this in the design chapters of C++ Programming Language, even for smaller projects. Peer review. It's a good thing to do. Elliott