 |
Thursday |
 Rags to Riches: Product Success @ Net Speed Moderator Panelists As demonstrated by last year's OOPSLA'98 Project Management Game, there are numerous approaches to software product development management. Some work, some don't. Our panelists will share their experience and perspectives with the audience in a dialogue initiated by the following questions:
We have used the term "net speed" - coined in the popular literature - as an exemplar of the increasing speed of interaction on the world wide web (as contrasted to the possibly disappointing "world-wide-wait" experienced by some). Assume that product success is achieved by systematic application of project management principles, methods, and tools by empowered product teams. Product team stakeholders include customers, executive sponsors, marketing, development staff, release staff, and customer care staff. This is a broader set of stakeholders than would be normally considered in a project (contrasted to a product) context. What has changed with respect to software product management in the past 35 years? Have best-practices been effectively absorbed into organizations now that the development community has been exposed to an increasingly broader experience base? Fred Brooks' [1975] The Mythical Man-Month was a landmark collection of essays on the subject of software engineering management. Brooks observed that schedule overruns were the most serious cause of project failure. Schedule overruns resulted from poor project estimation techniques; confusion of progress with effort (staff and time are not necessarily interchangeable commodities); inadequate project monitoring and corrective action; project delays are not adequately communicated to customers; and adding more staff to a late project. Larry Constantine [1993] has proposed four organizational reference paradigms for project man-agement and organization. His paradigms include: closed teams with a traditional authority hierarchy; random teams with innovative individuals; open teams that depend on adaptive collaboration; and synchronous teams with harmonious alignment. More recently, Grady Booch [1996] wrote that software project failure is largely due to: improper risk management; not meeting customer expectations; and/or being blindsided by technology. More precisely - projects fail because of lack of adult supervision … it is not that such projects fail because of poor management; rather they fail because of no management. Steve McConnell [1996] in his book Rapid Development summarizes Classic Mistakes that have contributed to ineffective development practices. Ed Yourdon [1997] has characterized death march projects by: schedule, staff, and budgetary compressions of at least 50%; combined with a doubling of feature requirements. Our panel topic will also be the focus of a OOPSLA'99 Workshop of the same title (Work-shop #1) on Monday, November 1. Interested OOPSLA attendees are invited to participate by contributing a position to the workshop organizers by email to: sdfraser@nortelnetworks.com. If you are reviewing the proceedings, you may wish to cross-reference the post-conference addenda for both the panel and workshop summaries. Booch, Grady. [1996] Object Solutions: Managing the Object-Oriented Project. Addison-Welsley. Steven Fraser (moderator) is an advisor on Tech Transfer and Chair of the Nortel Networks Design Forum at the Nortel Networks facility in Santa Clara, California. Previous to this he was manager of the Software Process Engineering team, responsible for the transitioning of software best practices to design teams. In 1994 he was a Visiting Scientist at the Software Engineering Institute (SEI) in Pittsburgh collaborating with the Appli-cation of Software Models project on the development of team-based domain analysis techniques. Since joining Nortel Networks in 1987, Fraser has contributed to OO casetool development and to software development processes. Fraser completed his doctoral studies at McGill University in Electrical Engineering. He is an avid operatunist and photographer. Kent Beck
Best practices must be adapted by the team as a whole, since the team as a whole will be responsible for applying them. This adaptation must be considered an ordinary part of daily development, so the adaptation process continues as long as the project. And the set of practices chosen by the team must be carefully mapped to their collective (and corporate) personality. There is no sense in even trying to apply a communication-intense process in a team of loners collaborating over the Internet. Kent Beck helped pioneer CRC cards and patterns for software development. He rediscovered test-first programming, and popularized it with his xUnit testing framework, now translated into Java, C++, Visual Basic, and Smalltalk. He is the author of "The Smalltalk Best Practice Patterns", "Kent Beck’s Guide to Better Smalltalk", and a contributing author on Martin Fowler’s book "Refactoring". He is also the author of the forthcoming Addison-Wesley books "Extreme Programming: Embrace Change", and "Extreme Programming: Playing to Win", and stars with Erich Gamma in the forthcoming video "Test Infected". He recommends that you take any faux-third-person biography with a large grain of salt. Martin Fowler So I'm suspicious of methodologies, primarily any software process that is supposed to apply to all kinds of projects. There are marked differences between projects due to size, technology, and culture. One process cannot fit all. One thing that frustrates me in particular is the way that organizations consistently fail to learn from their past experience. I've seen large organi-zations make the same mistake again and again. Making mistakes is human, but you should at least try to learn from them. Because of this I think a strong program of retrospectives is essential to allow an organization to learn its own best practices. Martin Fowler is an independent software consultant who has spent over a decade applying object technology to business information systems. He helps clients with OO analysis and design, UML, patterns, and refactoring. His clients have included Thoughtworks, Chrysler, Andersen Consulting, IBM and Sterling Software. He has written three books: UML Distilled, Analysis Patterns, and Refactoring, none of which are about project management. He never drinks beer and wonders if any third person biography is really true. Norm Kerth I mention the accident because any team building software at net speed will experience problems. Individuals will be assigned work they can’t complete for any one of many reasons. Successful high-performance teams create a culture where discussing difficulties is a natural part of the proc-ess for developing software. The reaction when problems are presented needs to be one of support and help, not condemnation and accusation of in-competence. If you do not work for a high performance team, I urge you to consider the advice of the other panelists – especially the fanatical attention to quality and continuous learning through retrospectives; however, first make sure you install the Four Freedoms. These freedoms are:
These simple freedoms take effort to install in some work environments. Some work environ-ments will never embrace these freedoms. There is one thing I know for sure -- there is no way to build software at net speed without these freedoms available to all members of the team. Norm Kerth is a leading expert and consultant in the areas of specification and design methodologies with emphasis on object-oriented technologies. He has special interest in turning around failed projects. He is active in the Patterns community and is often involved with the "people-side" of technology. His book on leading retrospectives is nearing publication and was heralded as "the definitive work on the subject," by Jerry Weinberg. Norm is co-editor of the book "Pattern Languages of Programs Design Vol. 2." His projects have ranged from the development of a real-time intensive automated factory floor, and robotics to user interface intensive application programs in Smalltalk, C++ and Java. Priya Marsonia As I see it, there are two main types of projects -- small, tightly knit teams where the people deliver the goods, and larger teams where project management rigor delivers the goods. Small projects are usually delivered by small development agencies, and larger projects by larger product development agencies. Small groups may deliver small things fast, with ad-hoc project management practices. Larger groups may deliver larger things, but never as fast as the small team. In the absence of rigorous project management practices, large group performance degrades substantially. This is due to the communication and coordination challenges inherent in the larger team model. Project management serves to narrow the communication gap that exists for large teams in large organizations. As Fortune 500 and Global 500 companies strive for faster cycle times, I have noted that they have seemingly lost the ability to compare apples to apples. Fortune 500 companies are possessed by the belief that they can go faster by reverting to the process and project-management maturity of the average start-up. This seems especially strange given that the goal of most start-ups is to stay in business long enough to "merged" with a blue-chip. Start-ups build products with the assumption that they will neither maintain them forever, nor draw a profits for more than 30 years. Fortune 500 companies are not blessed with this luxury. So clearly, the average Start-up's project management practices will not translate well to the standard Fortune 500 company. The only way achieve improved cycle-times on larger projects in the context of a large organization is to use proper project management practices. These include: executive commitment, involvement and sponsorship; pipeline control and management; clearly delineated, small cross-functional teams delivering the portfolio; schedule, budget and risk management; technology and process control; and resource management. Executing these "boring" practices in a consistent fashion will allow the Fortune 500 companies to keep and grow the riches they have. Surprisingly, these companies do not consistently apply rigorous project management practices. In some ways, the application of consistent, effective project management is a "new" technology. There is no silver bullet, only common sense. We will not go any faster or get any richer by dismissing the obvious practices that require due diligence to execute. Let's stop wasting our energy and money, funding yet another expedition to the base of the mythical rainbow to search for a mythical pot of gold! Priya Marsonia is a program manager in the Nortel Networks' Meridian organization in Santa Clara, California. Prior to joining Nortel, Marsonia owned a software-consulting firm. The firm provided product management, project management, business process re-engineering and improvement, use case modeling, systems analysis and human factors analysis services for large-scale enterprise-wide object-oriented systems development. Marsonia consulted with several multinational corporations including: NEC Electronics, IBM, Nortel Networks, TIBCO, ADA Inc., Ameritech, and Stentor. Dusty Roads |
|
Return To Final Program || Return To Technical Program At A Glance
