Agile Product Development: Lessons from Industry - CiteSeerX

Agile Product Development: Lessons from Industry Clifton Kussmaul Muhlenberg College Papers

Abstract This paper describes lessons learned from developing and managing products and projects in the software industry, and how they apply to undergraduate team projects. Significant challenges include changing requirements, distributed teams, and resource limitations. Useful responses to these challenges include agile methodologies, improved communication, issue and risk tracking, and reusable components and product lines. The paper describes these challenges and responses, and how they apply to product teams in industry and in academia.

Introduction Teaching invention and entrepreneurship, or other project-based courses, presents a well-known difficulty: many of the key activities and processes can easily take more effort and calendar time than is available in an academic term. Thus, we must compress and condense such activities and processes, or consider other curricular models (Bagert et al 2002). During the last five years, I have taught team project courses in computer science programs at small liberal arts colleges. I have also worked on a variety of products in industry, generally involving five to fifteen people for six to twelve months. I look for parallels between the two environments, and I try to find ways to learn lessons from industry and teach them in academia. The rest of this paper is organized as follows. First, I describe some challenges commonly faced in product development. Second, I describe some ways of responding to these challenges, both in industry and with student teams. I describe challenges and responses separately, because there are often many too many relationships between them.

Challenges Changing requirements Requirements, business context, and priorities change and evolve, and the pace of these changes seems to be accelerating. With distinct analysis, design, implementation, and testing activities, sequential (or “waterfall”) development models may take too long (or be unable) to complete early activities before starting later ones, and

requirements or business context may change during the project, requiring rework. For example, I worked on one product which consisted of a user interface and database that used a separate processing engine to send and receive messages in an industry standard format. Within a period of six months, the standard went through one major and several minor revisions, we identified significant issues in the processing engine that required fixes or workarounds, and other requirements changed on nearly a weekly basis in response to prospective customers and competitors. (Despite these obstacles, the product was successfully certified and released to customers.) Student projects may not face this degree of volatility in external requirements. However, it is likely that student teams will need to revisit and correct decisions made early in the project, particularly if key decisions are made by the teams, and not by more experienced advisors.

Distributed teams Distributed teams are increasingly common, as a result of mergers and acquisitions, outsourcing, telecommuting, and similar trends. Team members may be in different geographic locations, and even different times zones. Forrester Research estimates that 277 thousand computer jobs and a similar number of management and operations jobs will move offshore by 2010 (Engardio 2003). Such offshore outsourcing can add further complexity; time zone differences of ten to twelve hours are common, and differences in language and culture can be significant.

Education that Works: The NCIIA 8th Annual Meeting, March 18-20, 2004. ©NCIIA 2004

125

Papers

For example, in one project, most of the design was done on the east coast of the US, much of the coding was done in India, and most of the system testing was done on the west coast of the US. The development center in India has significant numbers of Muslim, Hindi, and Christian engineers, so we needed to be aware of three sets of religious holidays, in addition to national holidays.

matched to people, and that everyone can work productively.

Similar factors apply to student teams. Class schedules, employment, and extracurricular activities can make it difficult for student teams to arrange meeting times. This can be even more of a challenge for commuting and non-traditional students, or students attending different institutions. Depending on the institution, team members may also come from varied socio-economic and cultural backgrounds.

•

Resource limitations Significant restrictions on schedule, staff, and budget are normal in industry and academia, although the nature of these restrictions can be quite different. Businesses often need to balance existing products with potential new ones. Staff and budget are limited, particularly given the sluggish economy and conservative business climate of the last few years, and time to market may be an important competitive factor. These issues can be particularly severe in small organizations, where key people may have multiple roles and responsibilities. For example, one person may be responsible both for managing existing products and evaluating new products. In academia, a single student working on a project for a term might complete one person-month of work, and a team of four students might do several times as much work, under the best of conditions. In a one-term project, it can be difficult to effectively engage a larger number of students, unless much of the requirements analysis and design is completed ahead of time. However, these large student projects are quite small in comparison to software projects in industry. For example, benchmark data from over nine thousand projects suggests that over 75% of projects require between around ten and several hundred person-months (Jones 2000). It can also be difficult to obtain specialized hardware, software, or services to support the project, although in some cases this can be addressed by leveraging existing research projects, or through partnerships with businesses. Thus, in both environments it is essential to ensure that the most important tasks are done first, that tasks are

126

Responses Agile methodologies Agile software development describes a group of development methodologies with a shared set of values (Cockburn 2002, Highsmith 2002):

• • •

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Many agile methodologies were developed in response to other methodologies that emphasize detailed documentation and formal processes, and that are often associated with ISO 9000 (described in Patterson 1995) or the Capability Maturity Model (Paulk et al 1993). Typically, agile methodologies have multiple iterations, each of a few weeks, and every iteration contains analysis, design, implementation, and testing. These and other agile principles help a project to react to dynamic conditions. Although agile methodologies often assume that all team members are in one location, they have also been adapted to include distributed teams (Simons 2002). Agile methodologies have multiple benefits for student teams. Perhaps most importantly, the emphasis on individuals and interactions, and the lack of detailed formal processes, give students an incentive to reflect on and adjust the process, rather than blindly following it. Multiple iterations and the emphasis on responding to change give students more opportunities to see the interactions between activities, and encourage students to react to and recover from errors early in the project.

Communication Communication (including documentation) is an essential component of any product development effort, since there are typically numerous stakeholders: managers and executives, analysts, system architects, developers, graphic designers, technical writers, and end users, to name a few. It can be difficult to determine and maintain the appropriate level of communication. Too little communication can lead to misunderstandings, errors, and omissions, but too much communication can take up valuable time and energy.


Asynchronous communication methods, such as email, mailing lists, or newsgroups are useful, because the sender and receiver don’t have to be working at the same time. These methods also provide a persistent record of discussions and decisions. Sites such as Yahoo Groups (http://groups.yahoo.com) make it easy to create public or private groups, or mailing list software can be installed on a local server. Many of these communication methods are inexpensive, and thus quite accessible to students. They also provide a natural way to engage students from multiple disciplines (Mengel and Carter 1999). Written documentation can be a particular challenge; teams or their managers must decide which documents to create, and for how long to maintain them. Brooks defines the documentary hypothesis thus: “A small number of documents become the critical pivots around which every project’s management revolves.” (Brooks 1995, 107). This set of documents may vary from project to project, and even during the course of a project. Bass (2003) distinguishes between “structure,” which is the actual architecture of a system, and “views,” which are particular representations of that structure. Hohmann (2003) further distinguishes between “marketecture” (marketing views for customers) and “tarchitecture” (technical views for developers); the two are related but not necessarily the same, and may need to be managed separately. Teams need to decide which views must be maintained; note that in software projects, it may be possible to generate certain views automatically.

Issue and risk tracking With changing requirements, distributed teams, and limited resources, it can be difficult to remember everything that needs to be done, and it is easy to lose track of requirements, ideas, defects, and requests for enhancements.

This is especially true of risks, which can be defined as “anything that might go wrong.” It is easy for product teams to concentrate on the clearly defined, low-risk aspects of the product, and ignore or postpone the poorly defined, high-risk aspects; thus, risk management has been defined as “project management for adults” (DeMarco and Lister 2003, 15). There are very good resources on risk management (Dorafee 1996, Jones 1994).

Papers

Synchronous communication methods, such as faceto-face meetings, online chats, and teleconferences, are ideal for quick status meetings, brainstorming sessions, and reviews. For example, many teams have a daily meeting to review status and discuss urgent problems. These are called “standing meetings,” because everyone stands for the entire meeting so that it does not run longer than necessary. When I work closely with developers in India, we usually have a brief online chat at the end of their work day and the beginning of mine, to discuss current status and problems. Microsoft’s NetMeeting and services like Webex (http://www.webex.com) are very useful for sharing documents or desktops.

A simple but effective technique is to maintain a spreadsheet listing all identified requirements and tasks for the project. Each item is rated from one to five on effort, priority, and risk. Architects, managers, or team leaders regularly review this list and assign tasks to specific iterations. During each iteration, items are assigned to staff or locations, and the architects track status. Large projects may want to maintain several lists; for example, a lower-level list within an iteration, and a higher-level list for planning across iterations. There are also much more sophisticated issue tracking systems; a popular open source project is Bugzilla (http: //www.bugzilla.org).

Reusable components and product lines A common strategy for quickly building a product is to use existing components where possible; the team focuses on integrating these components, and building only the unique or unusual aspects of the system. This approach is often referred to as “buy and bolt,” but it might better be termed “borrow and bolt,” given the increasing popularity and variety of open source projects. For example, Open For Business (http://www.ofbiz.org) seeks to “create an open source application framework, application components, and suite of enterprise applications,” and utilizes nearly twenty other open source projects. There are also numerous commercial components and several component marketplaces, such as ComponentSource (www.componentsource.com). Components can range from quite large (e.g., databases, Web servers, or language interpreters) to quite small (e.g., graphical controls or specialized software modules), although using many small components can make integration quite difficult. Similarly, a software product line has been defined as “a set of software-intensive systems sharing a common, managed set of features that satisfy the needs of a particular market segment or mission, and that are developed from a common set of core assets in a prescribed way” (Clements and Northrop 2002). A primary benefit of a product line is that new products are built by assembling and extending the core assets, rather than by


127

Papers

creating them from scratch. Designing and building the core assets for a product line is usually more difficult and time-consuming than building a single product. Student teams with limited design experience may find it difficult to design core assets for a product line. However, they should be encouraged to identify parts of their project that might become core assets, and other products that could share these assets. There may also be situations in which multiple student teams can be coordinated so that a set of projects form a product line of sorts, and the teams can share components and experiences. For example, I provide some commonality between the student teams by selecting a theme for the course. The theme may be technology-based (e.g., Windows CE) or domain-based (e.g., assistive technology).

Conclusions The challenges described above have been used as reasons to avoid or limit team project courses. Instead of yielding to the challenges, we should try to identify and acknowledge the parallels between industry and academia, and help students learn ways to respond to these challenges, both as students and as future professionals. Note that very few of the challenges and responses discussed above are primarily technical in nature; rather, they focus on the interactions between people and organizations. This is consistent with the assertion that “the major problems of [software development] are not so much technological as sociological in nature” (DeMarco and Lister 1999, 4). Many of the same factors apply to any sort of product development.

References

DeMarco, T., and T. Lister. 2003. Waltzing with bears: Managing risk on software projects. New York: Dorset House. DeMarco, T., and T. Lister. 1999. Peopleware:

Productive projects and teams, 2nd edition. New York: Dorset House. Dorafee, A., J. Walker, C. Alberts, R. Higuera, and R. Murphy. 1996. Continuous risk management guidebook. Pittsburgh: Carnegie Mellon University. Engardio, P., A. Bernstein, and M. Kripalani. 2003. The new global job shift. Business Week. February 3. Highsmith, J. 2002. Agile software development ecosystems. Addison-Wesley. Hohmann, L. 2003. Beyond software architecture: Creating and sustaining winning solutions. Addison-Wesley. Jones, T. C. 1994. Assessment and control of software risks. Prentice Hall. Jones, T. C. 2000. Software assessments, benchmarks, and best practices. Addison-Wesley. Kussmaul, C. 2000. A team project course emphasizing software entrepreneurship. Journal of Computing in Small Colleges 15(5):308-316.

Bagert, D., J. Gregory, S. Mengel, and L. Heinze. 2002. Engineering education innovation with software engineering projects. ASEE/IEEE Frontiers in Education Conference. Boston, MA.

Mengel, S. and L. Carter. 1999. Multidisciplinary education through software engineering. 29th

Bass, L., P. Clements, and R. Kazman. 2003. Software architecture in practice, 2nd edition. AddisonWesley.

Patterson, J. 1995. ISO 9000: Worldwide quality standard. Menlo Park: Crisp Publications.

Brooks, F. 1995. The mythical man-month: Essays

Paulk, M., B. Curtis, M. Chrissis, and C. Weber. 1993. Capability maturity model, version 1.1. IEEE Software 10(4):18-27.

on software engineering—Anniversary edition. Addison-Wesley. Clements, P., and L. Northrop. 2002. Software product lines: Practices and patterns. Addison-Wesley.

128

Cockburn, A. 2002. Agile software development. Addison-Wesley.

ASEE/IEEE Frontiers in Education Conference. San Juan, Puerto Rico.

Simons, M. 2002. Internationally agile. InformIT March 15. http://www.informit.com.


Wellington, C. 1999. Facilitating student control of group activities using self-directed work groups. NCIIA Annual Meeting.

Papers


129

Papers

130
