{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

the white water process software product development in small it

The white water process software product development in small it

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: THE WHITEWATER PROCESS: SOFTWARE PRODUCT DEVELOPMENT IN SMALL IT BUSINESSES Small software development companies need it to ensure they stay on course and are able to respond to the market’s ebbs and flows. B y Mi c hael Harris , K r i s Ae b i s c he r , a nd Ti m K l aus AT THE CORE OF THE ENGINE THAT DRIVES HISTORICAL ECONOMIC GROWTH ARE THE SMALL businesses that employ 50% of all workers in the U.S. [6]. According to the U.S. Department of Labor, 80% of IT workers are in small companies, and the economy’s IT sector is expected to grow 68% in the period 2002–2012 [5]. These companies use nontraditional development methods, yet few scholars have sought to examine or even identify their characteristic operations. Here, we examine the software development process and methodologies used at three small IT businesses (SITBs) in Florida. It would be convenient to view a small business simply as a large business with fewer people, but a business’s size directly affects its structure [3]. A shortage of slack resources (such as software engineers) is a common SITB problem. Just one unexpected new customer can require doubling the development staff, and just one delayed sale can leave the same staff idle. A small portfolio of active projects can lead to volatile staff requirements and uncertain revenue streams. One way to level demand on the staff is to develop software prod- ucts, instead of relying solely on custom development contracts. Small businesses can leverage limited development staff by building a product, then deploying it repeatedly for multiple customers. Embracing a product-oriented development strategy also brings new challenges to a development organization. The most notable is the difficulty in determining product requirements. Products must be designed for the needs of an amorphous market, but it is more difficult to define the needs of a market than it is to gather require- COMMUNICATIONS OF THE ACM May 2007/Vol. 50, No. 5 89 Design Implementation ments for a particular customer. Furthermore, a prod- development. While these techniques do not necesuct must not only fulfill the market’s needs, it must also sarily represent universal answers for every business, H be favorable compared to competitive products. arris fig 1 (5/07) they do include insights that may be useful for other Many techniques used by large businesses to probe small businesses. the market are resourceintensive. For example, DEVELOPMENT PROCESSES Planning current users may be IT researchers have studenticed to provide feedied many development Analysis back via user-group meetprocesses designed to ings held at attractive manage the tension Design resort destinations. between control and flexProspective users may be ibility. Examples include reached via elaborate the waterfall developImplementation trade show presentations ment process, the spiral where key prospects are development methodolFigure 1. Traditional waterfall ogy, and rapid prototyping [1, 2, 4]. The most invited to confidential briefings. Large compa- software development process. widely used is the waterfall development process (see nies may employ resident Figure 1). The waterfall name refers to the stair-step experts who track the competition, as well as those depiction of the process through distinct stages. Howwho follow technology trends and forecast changing ever, a more evocative description might be called the market requirements. “canal” approach in which the project transitions SITBs lack the economies of scale to support these from one stage to the next in controlled steps, like a market-probe techniques. In large companies the cost of a tradeshow booth can be amortized I Platform M n across many customers. Small icr s oDe companies may be unable to p O re liv Su ngo i lea er afford the market-planning activipp in y r se or g ties used by their larger counters a t Flexible and t parts. Similarly, economies of scale Iterative i Evaluation Development in large companies help justify o n staffing full-time marketing and technology specialists. In contrast, small companies have fewer peoCustomer Feedback ple to cover the same range of activities. Small-company employees find themselves stretched to handle a broader range of issues Figure 2. Whitewater ship transiting the locks of a canal. This stately proand lack time to develop in-depth software development cession is the antithesis of the loosely structured chaos process. expertise in individual issue areas. in many small businesses. While the spiral developThe implications of these factors ment methodology 2 (5/07) prototyping represent Harris fig and rapid can be far reaching. With only a small marketing staff, more flexible processes, neither captures the freethe development and operations team receives less wheeling nature of small business development. Small guidance on product requirements. With fewer special- businesses proceed in a more chaotic fashion, like a ists, the SITB loses a source of standards and guidelines lone whitewater kayaker shooting the rapids of a river. that would help developers manage unfamiliar issues. The image of a heroic kayaker dodging obstacles As a result, many SITBs have relatively streamlined through instinct and quick reflexes is intriguing, but structures compared to large companies [3]. the history of IT shows that chaotic processes lead to Our study examined three small software busi- system disasters. The goal of our study was to help us nesses operating in loosely structured, seemingly understand the underlying structure behind the seemchaotic, markets (see the sidebar “How the Study Was ingly freewheeling development approaches used by Done” for business descriptions). We found that, SITBs. That’s why we focused our search for the despite their differences, each had independently underlying “whitewater” process that gives form to developed similar techniques for managing software apparent chaos. 90 May 2007/Vol. 50, No. 5 COMMUNICATIONS OF THE ACM HOW THE STUDY WAS DONE We used an exploratory approach to identify common trends in product development at three companies. We built up our own basic understanding of the companies by having a researcher work as a consultant with each of them for several months. This experience guided our loosely structured interview process with company executives. The interviews were transcribed and categorized independently by two researchers who compared and reconciled the emergent categories that became the basis for an emergent software model. Each company employed fewer than 20 software developers and had been in existence for more than four years. Each originally developed a custom solution for internal users and later transformed it into a product offered to the marketplace in the form of business software. In order to preserve the confidentiality of the interviewed companies, we conceal their identities, using pseudonyms to refer to them in the study. However, in order to provide context for the study, we describe them in the following paragraphs: LegalSoft, software for law firms. Originally an internal IT division of a law firm, this company was spun off as an independent entity to develop software for the legal industry. We conducted interviews with its director of information technology. iManager, solutions for Internet content management. Venture capital funding led to the formation of an independent company based on an Internet company’s operational software. It offered Web-portal software for managing content, collaboration, and e-commerce. We interviewed the company’s CEO. InsureCo, software support for sales and servicing insurance policies. This embedded software product is an integral part of the company’s insurance policy business, used by independent agents to quote policy prices, terms, and conditions. The software is indeed the embodiment of an intangible insurance product. The software team functions as an independent entity that creates and manages its software for the agent market. We interviewed the company’s CTO. c Although the executives we interviewed were in three different companies, the companies themselves shared several characteristics. In order to provide a context for our study, the following outlines the environment in which the interviewed companies operate: Product complexity. Each company offers full-featured products, though these products are less complex than comparable enterprise-class systems offered by large companies; Modular architecture. The products use a modular approach, allowing for extensibility; Small teams. The interviewed companies had software teams of fewer than 10 members, so coordi- nation among them was relatively easy. The coordination costs are a special issue during software integration and release. As a result, smaller teams may find it easier to justify more frequent releases; Internet delivery. The products and their documentation can be compressed and downloaded over the Internet; new releases incur no packaging or printing costs; Limited customer base. The three companies had no more than a few hundred customers for each product in their portfolios; when problems or opportunities arose it was relatively easy for each of them to reach its entire customer base; Single product path. Each release is a linear progression along a single product upgrade path; SITBs lack the resources to support special versions and parallel product directions; and Customer characteristics. The target customer is a small entity lacking IT experts; hands-on support is critical; in fact, the willingness of an SITB to provide personalized installation, training, and follow-up is often a key selling point. A lthough support needs are demanding, small business customers can be more tolerant in terms of feature requirements than their larger counterparts. These customers compromise on specific features, as long as overall functionality is acceptable. Moreover, infrequent bugs are not a problem, as long as they are resolved quickly. PRODUCT DEVELOPMENT ANALYSIS At first glance, the companies in the study appeared to be using unstructured development processes. However, comparing the three companies revealed common structures that build on small business strengths to provide an experientially based development process. We identified five components of that process—inspiration and evaluation; micro-releases; delivery and high-touch support; feedback and control; and technology platform (see Figure 2)—discussed in the following sections, which include representative quotes from the interviews: Inspiration and evaluation. The process begins with inspiration, usually from customers, employees, and marketplace scanning. In evaluating new ideas, the customer is the primary focus; however, the company does not automatically accede to customer demands. “[we] also develop software from ideas originated [here]...but we will still attempt feedback from...a potential customer...”—LegalSoft IT director. Resources are inadequate to support multiple product variations. When resources are assigned to COMMUNICATIONS OF THE ACM May 2007/Vol. 50, No. 5 91 Design Implementation ments for a particular customer. Furthermore, a prod- development. While these techniques do not necesuct must not only fulfill the market’s needs, it must also sarily represent universal answers for every business, H be favorable compared to competitive products. arris fig 1 (5/07) they do include insights that may be useful for other Many techniques used by large businesses to probe small businesses. the market are resourceintensive. For example, DEVELOPMENT PROCESSES Planning current users may be IT researchers have studenticed to provide feedied many development Analysis back via user-group meetprocesses designed to ings held at attractive manage the tension Design resort destinations. between control and flexProspective users may be ibility. Examples include reached via elaborate the waterfall developImplementation trade show presentations ment process, the spiral where key prospects are development methodolFigure 1. Traditional waterfall ogy, and rapid prototyping [1, 2, 4]. The most invited to confidential briefings. Large compa- software development process. widely used is the waterfall development process (see nies may employ resident Figure 1). The waterfall name refers to the stair-step experts who track the competition, as well as those depiction of the process through distinct stages. Howwho follow technology trends and forecast changing ever, a more evocative description might be called the market requirements. “canal” approach in which the project transitions SITBs lack the economies of scale to support these from one stage to the next in controlled steps, like a market-probe techniques. In large companies the cost of a tradeshow booth can be amortized I Platform M n across many customers. Small icr s oDe companies may be unable to p O re liv Su ngo i lea er afford the market-planning activipp in y r se or g ties used by their larger counters a t Flexible and t parts. Similarly, economies of scale Iterative i Evaluation Development in large companies help justify o n staffing full-time marketing and technology specialists. In contrast, small companies have fewer peoCustomer Feedback ple to cover the same range of activities. Small-company employees find themselves stretched to handle a broader range of issues Figure 2. Whitewater ship transiting the locks of a canal. This stately proand lack time to develop in-depth software development cession is the antithesis of the loosely structured chaos process. expertise in individual issue areas. in many small businesses. While the spiral developThe implications of these factors ment methodology 2 (5/07) prototyping represent Harris fig and rapid can be far reaching. With only a small marketing staff, more flexible processes, neither captures the freethe development and operations team receives less wheeling nature of small business development. Small guidance on product requirements. With fewer special- businesses proceed in a more chaotic fashion, like a ists, the SITB loses a source of standards and guidelines lone whitewater kayaker shooting the rapids of a river. that would help developers manage unfamiliar issues. The image of a heroic kayaker dodging obstacles As a result, many SITBs have relatively streamlined through instinct and quick reflexes is intriguing, but structures compared to large companies [3]. the history of IT shows that chaotic processes lead to Our study examined three small software busi- system disasters. The goal of our study was to help us nesses operating in loosely structured, seemingly understand the underlying structure behind the seemchaotic, markets (see the sidebar “How the Study Was ingly freewheeling development approaches used by Done” for business descriptions). We found that, SITBs. That’s why we focused our search for the despite their differences, each had independently underlying “whitewater” process that gives form to developed similar techniques for managing software apparent chaos. 90 May 2007/Vol. 50, No. 5 COMMUNICATIONS OF THE ACM HOW THE STUDY WAS DONE We used an exploratory approach to identify common trends in product development at three companies. We built up our own basic understanding of the companies by having a researcher work as a consultant with each of them for several months. This experience guided our loosely structured interview process with company executives. The interviews were transcribed and categorized independently by two researchers who compared and reconciled the emergent categories that became the basis for an emergent software model. Each company employed fewer than 20 software developers and had been in existence for more than four years. Each originally developed a custom solution for internal users and later transformed it into a product offered to the marketplace in the form of business software. In order to preserve the confidentiality of the interviewed companies, we conceal their identities, using pseudonyms to refer to them in the study. However, in order to provide context for the study, we describe them in the following paragraphs: LegalSoft, software for law firms. Originally an internal IT division of a law firm, this company was spun off as an independent entity to develop software for the legal industry. We conducted interviews with its director of information technology. iManager, solutions for Internet content management. Venture capital funding led to the formation of an independent company based on an Internet company’s operational software. It offered Web-portal software for managing content, collaboration, and e-commerce. We interviewed the company’s CEO. InsureCo, software support for sales and servicing insurance policies. This embedded software product is an integral part of the company’s insurance policy business, used by independent agents to quote policy prices, terms, and conditions. The software is indeed the embodiment of an intangible insurance product. The software team functions as an independent entity that creates and manages its software for the agent market. We interviewed the company’s CTO. c Although the executives we interviewed were in three different companies, the companies themselves shared several characteristics. In order to provide a context for our study, the following outlines the environment in which the interviewed companies operate: Product complexity. Each company offers full-featured products, though these products are less complex than comparable enterprise-class systems offered by large companies; Modular architecture. The products use a modular approach, allowing for extensibility; Small teams. The interviewed companies had software teams of fewer than 10 members, so coordi- nation among them was relatively easy. The coordination costs are a special issue during software integration and release. As a result, smaller teams may find it easier to justify more frequent releases; Internet delivery. The products and their documentation can be compressed and downloaded over the Internet; new releases incur no packaging or printing costs; Limited customer base. The three companies had no more than a few hundred customers for each product in their portfolios; when problems or opportunities arose it was relatively easy for each of them to reach its entire customer base; Single product path. Each release is a linear progression along a single product upgrade path; SITBs lack the resources to support special versions and parallel product directions; and Customer characteristics. The target customer is a small entity lacking IT experts; hands-on support is critical; in fact, the willingness of an SITB to provide personalized installation, training, and follow-up is often a key selling point. A lthough support needs are demanding, small business customers can be more tolerant in terms of feature requirements than their larger counterparts. These customers compromise on specific features, as long as overall functionality is acceptable. Moreover, infrequent bugs are not a problem, as long as they are resolved quickly. PRODUCT DEVELOPMENT ANALYSIS At first glance, the companies in the study appeared to be using unstructured development processes. However, comparing the three companies revealed common structures that build on small business strengths to provide an experientially based development process. We identified five components of that process—inspiration and evaluation; micro-releases; delivery and high-touch support; feedback and control; and technology platform (see Figure 2)—discussed in the following sections, which include representative quotes from the interviews: Inspiration and evaluation. The process begins with inspiration, usually from customers, employees, and marketplace scanning. In evaluating new ideas, the customer is the primary focus; however, the company...
View Full Document

{[ snackBarMessage ]}