Aug 12, 2004 - company improve its software product development process. ... management team could review how the strategy of the company was realized ...
HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering
KRISTIAN RAUTIAINEN
Cycles of Control: A Temporal Pacing Framework for Software Product Development Management
Licentiate thesis submitted for official examination for the degree of Licentiate in Technology.
Espoo, 8.12.2004
Instructor: Reijo Sulonen Supervisor: Reijo Sulonen
HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering
Author
ABSTRACT OF LICENTIATE THESIS
Date Kristian Rautiainen
8.12.2004 Pages 54
Title of thesis Cycles of Control: A Temporal Pacing Framework for Software Product Development Management Professorship Computer science
Professorship Code T-76
Supervisor Reijo Sulonen Instructor Reijo Sulonen The software product business is a big business and getting bigger all the time. Despite this, the software engineering community has been slow to react to the specific needs of managing software product development. Existing software product development models fail to sufficiently address the specific needs of the software product business, such as flexible and controlled reaction to changes in the marketplace and linking business considerations to product development decision making. Temporal pacing has been proposed as a way of combining flexibility and control in reaction to change. Temporal pacing means dividing time to be expended to achieving a goal into segments of temporal milestones at which progress is evaluated and possible adjustments are made to the plans and goals. These temporal milestones create a pace for the product development process. This research explored how temporal pacing could be utilized to help small companies better manage their software product development. The research consisted of constructing a temporal pacing framework and applying it in a case company to help the company improve its software product development process. Empirical data of the results of applying the framework was collected. The framework consists of four cycles of control spanning different time horizons: strategic release management, release project, iteration, and heartbeat. The cycles help split long-term goals into short-term ones and create a pace for product development and decision making based on development progress. Each cycle begins and ends in a control point, where progress is reviewed and decisions are made by sufficient stakeholder representation. As a result of applying the framework, the case company deployed an improved software product development process that was both used and liked. The framework helped the company envision how product development could be organized and how flexibility and control could be combined in the product development process. It also helped the company choose and combine practices from existing process models into a coherent whole. Flexibility was gained with monthly iterations where partial functionality of the product was developed. After each iteration progress was visible and decisions could be made about the scope of the next iteration. Control was gained by mapping the iteration control points to product release process gates, in which the management team could make informed go/kill decisions based on the progress and priority of all the activities of the company. At the same time the management team could review how the strategy of the company was realized as outputs of the iterations and take corrective action if necessary. An important part of iterations was freezing the development scope and resources, which helped the developers focus on their assigned tasks. This combined with heartbeat-level development practices was instrumental to improved predictability of development work. Communicating the business and customer requirements to the development team was an important part of iteration planning.
Keywords: software product development, software process, temporal pacing
ii
TEKNILLINEN KORKEAKOULU Tietotekniikan osasto
Tekijä
LISENSIAATINTUTKIMUKSEN TIIVISTELMÄ
Päiväys Kristian Rautiainen
8.12.2004 Sivumäärä 54
Työn nimi Cycles of Control (Tuotekehityksen aikajänteet): Ajallisen rytmittämisen viitekehys ohjelmistotuotekehityksen johtamiseen Professuuri Ohjelmistoliiketoiminta ja -tuotanto
Professuurin koodi T-76
Työn valvoja Reijo Sulonen Työn ohjaaja Reijo Sulonen Ohjelmistotuoteliiketoiminta on merkittävä liiketoiminta-alue, joka kasvaa koko ajan. Huolimatta tästä, ohjelmistokehityksen mallit tarjoavat heikosti ratkaisuja ohjelmistotuotekehityksen johtamiseen. Olemassa olevat mallit eivät huomioi tarpeeksi kaikkia ohjelmistotuoteliiketoimintaan liittyviä erityispiirteitä, kuten joustavaa ja hallittua reagointia muutoksiin markkinoilla sekä liiketoimintastrategian huomioimista tuotekehityksen päätöksenteossa. Yhtenä ratkaisuna nopeaan ja hallittuun reagointiin muutoksiin on ehdotettu ajallista rytmittämistä. Ajallisen rytmittämisen avulla luodaan rytmi tuotekehitykselle määrittelemällä ja lyömällä lukkoon aikajänteet, joiden aikana pyritään saavuttamaan tuotekehitykselle asetettuja tavoitteita. Tässä työssä tutkittiin ajallisen rytmittämisen käyttöä pienten ohjelmistotuoteyritysten tuotekehityksen johtamiseen. Tutkimuksen tuloksena luotiin ajallisen rytmittämisen viitekehys, jota sovellettiin oikeassa yrityksessä. Soveltamisesta ja sen tuloksista kerättiin empiiristä dataa. Viitekehys koostuu neljästä tuotekehityksen aikajänteestä: pitkän tähtäimen suunnittelu, tuotejulkaisuprojekti, iteraatio, ja sykäys. Tuotekehityksen aikajänteet auttavat pilkkomaan pitkän tähtäimen tavoitteita käytännön tekemiseksi ja luovat rytmin tuotekehitysprosessille, päätöksenteolle ja edistymisen seurannalle. Jokaisen aikajänteen alussa ja lopussa on ohjauspiste, jossa olennaiset sidosryhmät osallistuvat edistymisen seurantaan ja jatkon suunnitteluun. Viitekehystä sovellettiin pienen ohjelmistotuoteyrityksen tuotekehitysprosessin parantamiseen. Soveltamisen tuloksena yritys otti käyttöön parannetun tuotekehitysprosessin, jota noudatettiin ja josta pidettiin. Viitekehys auttoi yritystä hahmottamaan, miten tuotekehityksen voi organisoida ja miten joustavuuden ja hallittavuuden voi yhdistää tuotekehitysprosessissa. Viitekehyksen avulla yritys pystyi myös helpommin valitsemaan ja yhdistelemään käytäntöjä olemassa olevista prosessimalleista toimivaksi kokonaisuudeksi. Joustavuus saavutettiin kuukauden iteraatioilla, joissa kehitettiin osa tuotteen toiminnallisuudesta. Jokaisen iteraation jälkeen nähtiin miten edistystä on tapahtunut ja voitiin joustavasti päättää mitä jatkossa on järkevää tehdä. Hallittavuus saavutettiin yhdistämällä iteraatioiden ohjauspisteet julkaisuprosessin virstanpylväisiin, joissa johtoryhmä pystyi päättämään resurssien käytöstä kaiken käynnissä olevan toiminnan ja edistymisen perusteella. Samalla johtoryhmä näki, miten yrityksen strategiset tavoitteet toteutuvat iteraatioiden tuotoksina. Erittäin tärkeä osa iteraatioita oli resurssien ja työn laajuuden jäädyttäminen suunnittelun yhteydessä. Näin pystyttiin tarjoamaan työrauha kehittäjille ja yhdistettynä sykäystason käytäntöihin tällä saavutettiin parempi ennustettavuus työn etenemiselle. Iteraatioiden suunnitteluun kuului myös liiketoiminta- ja asikastarpeiden kommunikointi kehitystiimille. Avainsanat: ohjelmistotuotekehitys, ohjelmistoprosessi, ajallinen rytmittäminen
iii
Acknowledgements This research was done in the SEMS project at the Software Business and Engineering Institute (SoberIT) at Helsinki University of Technology. I want to thank all the members of the SEMS project for their input and for the ideas and confidence they have given me. I especially want to thank Casper Lassenius, who has helped me enormously with his insight and encouragement throughout my research. The research would not have been possible without the participation and support of the case company. I extend my warmest thanks to all the participants at the company, especially to the process champion Lauri Vuornos, who has been an inspiration to me throughout the work. I am very grateful to professor Reijo Sulonen, who has urged me on with the work and supported me with valuable ideas and constructive comments along the way. My thanks also go to the Graduate School for Electronic Business and Software Industry (GEBSI), who helped with funding the work and provided a valuable network of peers. Special thanks go to the people in my research group, the Software Process Research Group (SPRG). Without their support and encouragement this work would not have been possible. I especially value the many discussions we have had which have provided me with new ideas and insights. Finally, I thank my mother, who has always believed in me and provided the support and love this kind of endeavour requires. Espoo, 8.12.2004
Kristian Rautiainen
iv
Contents 1.
2.
INTRODUCTION .................................................................................................... 1 1.1
THE BACKGROUND OF THE RESEARCH.................................................................. 1
1.2
THE SEMS RESEARCH PROJECT ........................................................................... 2
1.3
THE OBJECTIVES AND SCOPE OF THE RESEARCH ................................................... 2
1.4
TERMINOLOGY ..................................................................................................... 3
1.5
THE STRUCTURE OF THE THESIS ........................................................................... 4
RESEARCH DESIGN.............................................................................................. 5 2.1
RESEARCH PROBLEM............................................................................................ 5
2.2
RESEARCH APPROACH.......................................................................................... 5
2.2.1
Case study approach and action research ................................................. 5
2.2.2
Limitations of the research approach......................................................... 6
2.3
THE CASE COMPANY ............................................................................................ 6
2.4
RESEARCH METHODS AND EMPIRICAL DATA ........................................................ 8
2.4.1
State-of-the-practice interviews.................................................................. 9
2.4.2
Follow-up interviews .................................................................................. 9
2.4.3
Reviewed documents................................................................................... 9
2.4.4
Reviewed system data ............................................................................... 10
2.5 3.
DATA ANALYSIS................................................................................................. 10
LITERATURE STUDY ......................................................................................... 11 3.1
SOFTWARE PRODUCT DEVELOPMENT ................................................................. 11
3.1.1
The software product business ................................................................. 11
3.1.2
Software development models................................................................... 13
3.2
TEMPORAL PACING ............................................................................................ 16
3.2.1
Temporal pacing in strategic management .............................................. 17
3.2.2
Temporal pacing in software engineering................................................ 18
3.2.3
Strengths and weaknesses of temporal pacing ......................................... 19
APPLICABILITY OF TEMPORAL PACING AND EXISTING IID MODELS FOR THE SOFTWARE PRODUCT BUSINESS ...................................................................................... 20 3.3
v
4.
THE CYCLES OF CONTROL FRAMEWORK ................................................ 23 4.1
4.1.1
Strategic release management.................................................................. 24
4.1.2
Release project.......................................................................................... 25
4.1.3
Iteration .................................................................................................... 25
4.1.4
Heartbeat .................................................................................................. 26
4.2
5.
APPLYING THE CYCLES OF CONTROL FRAMEWORK ........................................... 27
4.2.1
Finding the pace of your own ................................................................... 29
4.2.2
Adopting a practice................................................................................... 30
CASE SMARTNER INFORMATION SYSTEMS ............................................. 32 5.1
THE ROAD TO THE IMPROVED PRODUCT DEVELOPMENT PROCESS ...................... 32
5.2
THE IMPROVED PRODUCT DEVELOPMENT PROCESS ............................................ 34
5.2.1
Strategic release management.................................................................. 35
5.2.2
Release project cycle ................................................................................ 36
5.2.3
Sprint......................................................................................................... 37
5.2.4
Daily rhythm ............................................................................................. 38
5.2.5
Supporting actions .................................................................................... 39
5.3
6.
OVERVIEW AND STRUCTURE OF THE CYCLES OF CONTROL................................ 23
RESULTS ............................................................................................................ 39
5.3.1
The process ............................................................................................... 39
5.3.2
The product............................................................................................... 42
5.3.3
Success factors.......................................................................................... 44
DISCUSSION.......................................................................................................... 46 6.1
SUMMARY AND CONCLUSIONS ........................................................................... 46
6.2
CONTRIBUTION .................................................................................................. 47
6.3
LIMITATIONS ..................................................................................................... 48
6.4
FUTURE WORK ................................................................................................... 49
vi
1. Introduction 1.1 The background of the research The software product business is a big business and getting bigger all the time. In 2002, the world markets for packaged software, i.e. software products that are developed once and sold “as is” to a large number of customers, were estimated by the International Data Corporation (IDC) at 184 billion USD with an expected annual growth of over 10%. In Finland, the software product industry is still relatively small, with revenues of 949 million Euros in 2002, but with an expected growth of 37% until 2006 (IDC 2003). Most companies that operate in the software product business in Finland are young, immature and small, and they are struggling with the challenge of developing highly productized pieces of software for international markets. Despite the economic importance and promising outlook of the software product business, the software engineering community has been slow to react to the specific needs of companies in the software product business as opposed to the software service business. Most existing models and standards seem to share common traits that make them challenging to adopt in Finnish software product companies. Firstly, they have been developed with a large company perspective, which can make them resource intensive to implement and maintain. Secondly, their focus is on customer projects, not on developing software products for specific markets. Specifically concerning the second point, the link between the business considerations that are imperative for the software product business and the software engineering considerations is weak at best. According to Cusumano, most companies actually have a hybrid business model. They sell both products and services. Even those companies that strive to emphasize products and license fees eventually end up selling more services and incremental upgrades to their existing customer base, whether they have planned this or not. The potentially rapid change in the marketplace makes this transition even harder to adapt to, which makes it important for companies to consider and understand these aspects of the software product business, so that they are able to adapt faster. This entails among other things the ability to combine structure and control with flexibility in the software development process.(Cusumano 2004) Temporal pacing has been proposed as a way of combining flexibility and control in turbulent environments. In management science the concept of temporal pacing was introduced by Gersick (Gersick 1994) and further discussed by Eisenhardt and Brown (Brown and Eisenhardt 1997, Brown and Eisenhardt 1998, Eisenhardt and Brown 1998) as time pacing. Time pacing means “creating new products or services, launching new businesses, or entering new markets according to the calendar” (Eisenhardt and Brown 1998). This is opposed to event pacing, which means that change happens as a response to events in the environment, such as competitor moves or the discovery of new technology (Eisenhardt and Brown 1998). In software engineering, the concept of time boxing was introduced by Martin as he described Rapid Application Development (Martin 1991). Time boxing means fixing the end date of development iterations (in an iterative and incremental development model) and the end date of the whole development project.
1
Fixing the end date means that if you cannot finish all requested features by the end date, the scope is reduced so that the developed system is ready at the end date, with lesser features than planned and possibly with lower quality. Time boxing is an essential part of many of the so called agile models of software development, e.g., eXtreme Programming (XP) (Beck 2000), Scrum (Schwaber and Beedle 2002), and Adaptive Software Development (ASD) (Highsmith 2000). The world’s perhaps most successful packaged software product company, Microsoft, uses elements from both temporal pacing aspects (time pacing and time boxing) described above in their ‘Synchronize-and-Stabilize’ software development process (Cusumano and Selby 1995). Although the agile models have been claimed to be suitable for small teams working in turbulent environments, they fail to address the strategic or business aspects of software product development. The Synchronize-and-Stabilize process has only been reported to be used at Netscape and Microsoft (Cusumano and Selby 1995, Cusumano and Yoffie 1998), which both are rather large companies, so the applicability of this process model for small companies is unclear. This research explores how temporal pacing can be used in linking the business and software development aspects in a software development process that combines flexibility and control with the goal of aiding a small software product company better manage its software product development efforts.
1.2 The SEMS research project This research was conducted in the Software Business and Engineering Institute (SoberIT) at Helsinki University of Technology (HUT) as part of the SEMS (Software Engineering Management System) research project. SEMS was financed by Tekes (The Finnish Technology Fund) and the companies participating in the project. The goal of the SEMS research project was to develop an approach for managing software product development in small and medium-sized software product companies, which links the perspectives of business and development and combines flexibility and control in the software product development process. A central part of that approach is using temporal pacing as a mechanism for organizing the software product development efforts of an organization.
1.3 The objectives and scope of the research The objective of this research is to explore and utilize temporal pacing as a means to helping small software product companies better manage their software product development. The research problem is: Can temporal pacing be used to help small software product companies turbulent environments better manage their software product development that business decisions and product development decisions can be linked part of the software product development process cost effectively, and if how?
in so as so
The research problem is further elaborated in Section 2.1. As an answer to the research problem, a framework for temporal pacing is constructed based on existing research on temporal pacing. The framework is applied in a case company to provide a deeper understanding of how a small software product company can use temporal pacing in improving its product development process. This study is limited to one case company,
2
which makes it difficult to generalize any findings, but the findings can be used to increase the understanding of the application of temporal pacing. Also, the results can be compared to existing research to strengthen or overturn previous findings.
1.4 Terminology Temporal pacing means dividing time to be expended to achieving a goal into segments of temporal milestones at which progress is evaluated and possible adjustments are made to the plans. Changes are only made at these milestones, so persistence is accomplished at the same time establishing the flexibility to change plans and adapt to changes in the environment at the specific time intervals (Gersick 1994). These time intervals, or time horizons from a planning perspective, create a pace for the product development process. Time pacing is a term that refers to creating new products or services, entering new markets, or launching new businesses according to a fixed schedule. In contrast, event pacing refers to following a plan until something forces to deviate from that plan, e.g., moves by the competition or weakened performance. Time pacing is proactive in nature, whereas event pacing is reactive (Eisenhardt and Brown 1998). Time boxing has been used in software engineering literature as a term to denote a project or a part of a project (iteration or increment) with a fixed schedule (Highsmith 2000, Martin 1991, McConnell 1996). In this work temporal pacing is used as the generic term as defined above and time boxing is used where appropriate as defined above. Iterative and incremental development (IID) is used in this work as a generic term for any kind of approach to building software in several iterations in which the software is grown in small increments until it is ready. I have chosen to use the term IID for several reasons: 1. To make a distinction between IID and old definitions of iterative development, namely that a system is initially implemented as a whole and then iteratively refined or reorganized (Basili and Turner 1975). 2. To distinguish generic IID from Tom Gilb’s Evolutionary project management and delivery (EVO for short), which is a form of IID, but includes detailed specifications on how to do it, first introduced as a term in (Gilb 1976) and then further defined in subsequent work, e.g., (Gilb 1981, Gilb 1988). 3. To highlight the idea that IID is both iterative and incremental in nature, where iterative means that the already built parts of the software can be revisited for refinement and refactoring, but the software is built in small increments in several subsequent iterations or mini projects instead of a ”big bang” approach. Agile methods are a subset of IID and refer to software development models that emphasize the ability to respond to change in turbulent environments. Many of the agile methods also apply temporal pacing. There are several agile methods, e.g., eXtreme Programming (XP) (Beck 2000), Scrum (Schwaber and Beedle 2002), Adaptive Software Development (ASD) (Highsmith 2000), Feature-Driven Development (FDD) (Palmer and Felsing 2002), and Lean Development (Poppendieck and Poppendieck 2003). All agile methods share common values and principles, stated in the Agile Manifesto (Fowler and Highsmith 2001), but differ in the way in which they apply these values and principles into practice.
3
A software product company is a company whose main income comes from selling software products more or less “as is” for a target market, without customer-specific modifications. This is the opposite of a software service company that sells customerspecific solutions based on orders by customers (Hoch et al. 1999). According to, e.g., Sallinen and Cusumano, most companies are neither “pure” product companies nor service companies, but combine traits from both, one or the other being the dominant business model (Cusumano 2004, Sallinen 2002). In this work the term software product company refers to a company that is mainly selling software products as is, but also selling complementary services, such as installation, integration, and maintenance work. A small company is defined in this work as a company with less than 50 employees. A turbulent environment refers to the environment of a company being an almost constant source of change in the form of, e.g., emerging new technologies, competitors, or markets. A turbulent environment causes a high degree of uncertainty in the beginning of a product development project.
1.5 The structure of the thesis The thesis consists of six chapters: introduction, research design, literature study, the Cycles of Control framework, case Smartner Information Systems, and discussion. Chapter 2 focuses on the research design. First, the research problem is presented. Second, the research approach is described followed by a description of the case company. The chapter ends with a discussion of the research methods, the empirical data, and data analysis. Chapter 3 presents the results of the literature study, concentrating on literature about software product development and temporal pacing. The chapter ends with a discussion on the applicability of temporal pacing and existing iterative and incremental process models for the software product business and the main points these and the constructed framework should address. Chapter 4 presents the constructed framework. First, an overview is given and the structure of the framework is described. Then the application of the framework is discussed. Chapter 5 presents the case study. First, the background of the process improvement initiative at the case company is presented. Second, the improved product development process is described. The chapter ends with a discussion of the results of the process improvement initiative. Chapter 6 concludes the thesis by discussing the results. First, a summary of the results is presented and conclusions are drawn. Then the contribution of the research and its limitations are presented, followed by a comparison to existing research. Finally, directions for future research are discussed.
4
2. Research design In this chapter the research design is presented. First, the research problem is discussed. Second, the research approach is described. Third, the case company is presented and finally the research methods, data collection, and data analysis are discussed.
2.1 Research problem The research problem is: Can temporal pacing be used to help small software product companies turbulent environments better manage their software product development that business decisions and product development decisions can be linked part of the software product development process cost effectively, and if how?
in so as so
The research problem can be divided into the following sub questions: 1. What are the strengths and weaknesses of temporal pacing? 2. What problems is the case company facing in managing their software product development, especially concerning the software development process? 3. Can these problems be alleviated by using temporal pacing, and if so how? 4. Is the use of temporal pacing beneficial and cost effective to the case company? The goal of the research is to construct a temporal pacing framework based on existing literature on temporal pacing. Answering research questions 1-3 helps in constructing the temporal pacing framework. The framework is then applied in a case company to help the company improve its software product development process and the results of the improvement initiative are used to evaluate the applicability of temporal pacing and the constructed framework. Applying the framework answers research questions 2-4, and the results of the improvement initiative help answer questions 3-4.
2.2 Research approach This research is constructive in nature consisting of constructing and validating a temporal pacing framework for managing software product development in small software product companies. The construction is based on a study of existing literature on temporal pacing and software product development. The construction is needed, because existing models fail to address some important aspects of the software product business or have not been used in a small company context. The framework is applied in a case company to help it improve its software product development process. The application of the framework is done as action research with a longitudinal case study research strategy. 2.2.1 Case study approach and action research According to Yin, “a case study is an empirical inquiry that investigates a contemporary phenomenon within its real-life context, especially when the boundaries between
5
phenomenon and context are not clearly evident.” A case study inquiry needs to cope with many more variables of interest than there are data points, relies on multiple sources of evidence and data triangulation, and benefits from a priori development of theoretical propositions to guide data collection and analysis (Yin 1994). Action research can be a special kind of case study. In action research the client organization and the researchers collaborate in solving a practical problem at the same time contributing to research. Action research can be seen as a cyclical process with five phases: 1) identifying or defining a problem, 2) considering alternative courses of action for solving the problem, 3) selecting a course of action, 4) studying the consequences of an action, and 5) identifying general findings from the consequences of an action (Susman and Evered 1978). The purpose of this research was to construct, test and validate a temporal pacing framework in a small software product company to help the company improve its software product development process. A longitudinal case study was chosen because it offers the possibility to get a deeper understanding of the contextual factors influencing the application of the framework. This includes combining different data collection methods, which should provide better validity of results. Action research was chosen because in the beginning of the collaboration with the case company, the framework was still tentative (Rautiainen et al. 2002) and the collaboration provided an opportunity to use the lessons learned during the application of the framework for improving the framework. The specific research methods used are discussed in Section 2.4. 2.2.2 Limitations of the research approach There are inherent limitations in case studies. Case study results are usually tied to specific contexts and the results are thus not generalizable (MacNealy 1997, Yin 1994). Several cases should be used for scientific generalizability. Action research is associated with a great risk of researcher bias. Miles and Huberman mention two kinds of researcher bias: 1) the effects of the researcher on the case and 2) the effects of the case on the researcher (Miles and Huberman 1994). The first one is inevitable and purposeful in action research, since the researcher takes part in the problem solving process in the company. The second one is more serious. When the researcher spends a lot of time in the case company he runs the risk of “going native” or “swallowing the agreed-upon or taken-for-granted version of local events” (Miles and Huberman 1994). This may influence proper analysis of the data and makes triangulation of the data even more important. Another issue of researcher bias is the fact that the framework has been constructed by the same researcher that interprets the results of the application of the framework. This makes it important to record the data carefully, so that other researchers can evaluate and validate the interpretations.
2.3 The case company In this section we present the case company using its real name with permission. Smartner Information Systems Ltd (Smartner for short), founded in 1999, is a software product and professional services company enabling mobile business services. Smartner offers its mobile technology for operators and application service providers who need tools for building mobile services and solutions for enterprises. Customers include Radiolinja, Swisscom Mobile and Vodafone Ireland. In March 2003, Smartner employed about 30
6
people with expertise in mobile solutions, software development and business management. Smartner is based in Helsinki, Finland. Smartner’s main product is a mobile office product, a mass customized enterprise software. Smartner’s organization was in March 2003 divided into five teams: Sales and Marketing (S&M, 4 people), Research and Development (R&D, 11), Product (PT, 3), Professional Services (PS, 8) and Administration (A, 5). Sales is responsible for negotiating and closing deals and managing customer relations. Marketing is responsible for public relations and communicating Smartner’s message to partners and customers. Professional Services is responsible for consultation, product support, and management of delivery and integration projects to the customers. R&D is responsible for developing and maintaining the software products, and the Product team is responsible for planning and envisioning what the products should be. The company’s management team consists of people from the operational teams and is led by the CEO. From the beginning, the people at Smartner understood the importance of a good product development process. The first draft for a development process was written in the beginning of 2000. It resembled the traditional waterfall model (Royce 1970). The uncertainties in the environment made planning in advance very difficult and the process was changed in June 2000 to be iterative and incremental. At the same time a product management view was adopted with productization milestones from kick-off to product launch. This resembled the Stage-Gate™ model for new product development (Cooper 1994) and showed product development as a part of productization and made its link to business clearer. However, the constantly changing product requirements and architecture made product development difficult to control and schedules were overrun. At this time Smartner contacted our research group and joined SEMS, a research project aiming at developing a framework for managing software product development in small software product companies. Smartner was the first company to apply a preliminary version of the framework developed in the research project. Smartner’s first product release was made in mid-July 2000. At the same time development instructions for R&D were made explicit, covering the overall process and details about specifications (requirements; functional and technical), implementation work (unit test scripts and reports, Javadoc documentation, and code review notes), testing (different types of test cases and reports were identified) and the operational product release process (how to make product builds for releases). In an internal R&D team feedback session the developers expressed happiness with the clear roles and responsibilities within R&D. The issues that raised most dissatisfaction were file and document management (information could not be found easily), schedule overruns, and the stakeholders’ inability to freeze the specifications. In November 2000 some problems in product development were identified by the company, namely lacking communication between R&D, Product Management (called Product team in March 2003) and Professional Services, unclear division of roles and responsibilities between these groups, unclear priorities between different products and their features, and unclear real customer/business needs for the products. These issues, together with the objectives to combine flexibility and control in the product development process and make it visible and understandable for all stakeholders, were the main process improvement goals Smartner presented to the researchers.
7
2.4 Research methods and empirical data Figure 1 shows on the left the timeline for the software product development process improvement at Smartner and on the right the involvement of the researchers. This section concentrates on the right side, describing the specific research methods used and the empirical data collected. 1999 Smartner founded 2000 Mar 2000 First development process draft Sep 2000 Join SEMS research project Nov 2000 Challenges with process identified 2001 Sep 2000 – Mar 2002 SEMS researchers involved - consulting role (action research) - provided a high-level framework
Feb 2001 Requirements for development process
Oct 2001 New development process draft Jan 2002 Scrum practices deployed 2002 Mar 2002 Disciplined unit test writing May 2002 New development process described Aug 2002 Sprint planning details defined Oct 2002 Release process details defined
2003 Mar 2003 researchers revisit company to collect data on results
Figure 1 The timeline of the process improvement and research at Smartner In the beginning of the collaboration in the research project, the researchers conducted state-of-the-practice interviews with Smartner’s personnel to get a picture of how Smartner operated. During the collaboration the researchers, mainly I, attended meetings concerning the process improvement initiative in the role of participant-observer. Together with company personnel the researchers solved practical problems concerning the software product development process applying the ideas from the temporal pacing framework the researchers had constructed. The responsibility for implementing the process improvement actions was held by the company at all times. Meetings were held more frequently in the first six months, approximately twice a month. We collected data in the form of process-related documents that the company personnel wrote and notes written at the meetings. The meetings’ agenda was always similar. Company personnel presented how they had implemented or planned to implement process improvements and the researchers gave feedback resulting in a discussion of what had been learned. The meetings ended in discussing further improvement ideas and planning action points to be completed until the next meeting. Between April 2002 and February 2003 Smartner independently continued improving and deploying the software product development process led by the R&D team leader, who
8
was the process owner and process improvement champion. In March 2003 the researchers revisited the company to collect data on the progress and results of the process improvement initiative. At this time data was collected by reviewing relevant documents, reviewing defect tracking and version control system data, conducting interviews with key stakeholders of the process, and having informal discussions with the R&D team leader. The following subsections describe the research methods and empirical data in more detail. 2.4.1 State-of-the-practice interviews In the beginning of the collaboration in the SEMS research project, researchers (including the author) conducted thematic interviews with Smartner’s personnel to get an overview of the company and its operations. We interviewed the head of product management, the head of professional services, the Chief Technology Officer (CTO), the chief architect, the R&D team leader, and a senior software engineer. The thematic areas were the organization, the products, the business models, the processes, and project management of the company. There were always two interviewers present. One of the interviewers asked the questions and the other wrote down notes. The interviews were also tape recorded. 2.4.2 Follow-up interviews In March 2003, I performed semi-structured interviews with key people about their experiences with the new process and the ongoing process improvement efforts in order to get a subjective opinion on how the process has worked. The interviews were tape recorded. The people interviewed were the head of the product team, the head of professional services, the chief architect and a developer. They were all asked to tell about their roles in the process and the process improvement, to evaluate from their perspective how the process works now compared to before, how product quality has been influenced if at all, how the communication works between the different stakeholders, how the process improvement has succeeded from their perspective, what still needs to be improved and the reasons behind all these. 2.4.3 Reviewed documents The R&D team leader, who was responsible for managing the process improvement, provided us with a collection of software product development process-related documents. One of the documents was the R&D team leader’s Master’s Thesis, which detailed the process improvement initiative up to April 2002 (Vuornos 2002). Other documents included, e.g., process descriptions, e-mail correspondence, and minutes from process reflection sessions, which were meetings where the personnel gathered to discuss what had been good and bad about the process and to decide how to further improve it. The documents dated back to the beginning of 2000 to give us the complete overall picture of the process improvement efforts. The fact that the documents were provided by the R&D team leader is a limitation compared to full free access to any documents in the company, but since the R&D team leader had lead the improvement, we trusted his judgment. We were also encouraged to ask for more material during the research, which we did.
9
2.4.4 Reviewed system data The R&D team leader provided us with data from Smartner’s different internal systems. In order to see how the product had evolved we reviewed data from the version control system (CVS). Defect tracking system data showed us how many defects had been reported to the products and their parts and from whom the reports originated. This gave us an indication of how the quality of the products had evolved. Hourly reporting data was reviewed to see how the R&D team’s effort was spent and especially to see how much effort had been used to process improvement. Unfortunately we could only get hourly reporting data for the R&D team, not for the other process stakeholders, and we were also limited to hourly reporting data from 2002, when the new process was deployed for the first time. For earlier effort we had to rely on estimates provided by the R&D team leader, which is a limitation. Product requirements were managed in Excel sheets as so called backlogs in accordance with the Scrum method (Schwaber and Beedle 2002). Backlog Excel sheets from January 2002 onward were provided to us by the R&D team leader. Project progress was monitored with so called burn down graphs managed in the same Excel sheets as the backlogs. Burn down graphs show the estimated effort left of the tasks undertaken in an iteration.
2.5 Data analysis Case write-ups were written based on the state-of-the-practice interviews, which were then submitted to all interviewees for validation of facts. Then the researchers made their own suggestions for process improvement actions, which were presented to company personnel in a planning session. The suggestions were discussed together with ideas presented by the company personnel and an initial plan for process improvement was drafted. This included prioritizing different areas of improvement. After this, process improvement was done according to the cyclic process for action research as described in Sections 2.2.1 and 2.4. The follow-up interviews were transcribed into mind maps for further processing immediately after the interviews based on the recordings of the interviews. The opinions of the four interviewees were compared to each other to find similarities and discrepancies, which were noted and discussed with the R&D team leader or the interviewees for possible further clarification. The opinions were then compared to the provided documents and system data to find supportive evidence or evidence to the contrary of the opinions. Again, these observations were noted and discussed with the R&D team leader for further clarification. Together with the R&D team leader we wrote a research paper to summarize the findings (Rautiainen, Vuornos, and Lassenius 2003).
10
3. Literature study In this chapter we present the results of the literature study on software product development and temporal pacing. The goal of the literature study was to find answers to research questions 1 and 3 presented in Section 2.1, and to provide a basis for the construction of the temporal pacing framework for managing software product development in turbulent environments.
3.1 Software product development In order to understand how temporal pacing can help in managing software product development in turbulent environments, we first need to understand what software product development in turbulent environments means. To do this, we look at literature addressing the software product business and software development models. 3.1.1 The software product business Software companies can be classified according to what kind of business they are in. Typically this has meant that a company is either in the software project business (other terms used are ‘bespoke software’ and ‘software services’) or in the software product business (Carmel and Sawyer 1998, Hoch et al. 1999, Nambisan 2001). The software product business can further be split into two segments, enterprise solutions and packaged mass-market software, as shown in Figure 2.
IT Market
Hardware products
Hardware maintenance services
Embedded software including services
Software products & services
Professional software services
Professional & internet services
Software products
Enterprise solutions
Packaged mass-market software
Figure 2 Segmentation of the IT market (Hoch et al. 1999)
11
The software project business constitutes of companies that sell and develop customized software development services to their customers (usually other companies) and the customers buy the results of the project as well as the related software development services. The software product business is characterized by selling a software product to lots of customers, which can be companies or individuals. The goal is to sell the software product without customer-specific modifications, especially in the case of packaged software. In the case of enterprise solutions, such as ERP systems, the software is based on a product core, which is customized for customers when delivering and installing the system. Table 1 shows some differences in dynamics between the software service and product businesses. The customer relationship in the service business is always intimate, one to one. This simplifies, e.g., requirements engineering in the sense that only one customer is expressing her wishes. In the software product business, the direct contact to customers is usually limited and there can be thousands of customers for the same product. The implication of this is an increased number of stakeholders with potentially conflicting interests that may request changes to the product, and the software product company must be able to analyze and prioritize how this market demand is translated into the product offering. This in turn may require quick reaction to changes in the market. In turbulent markets the signals are coming in almost constantly, so a degree of control in reacting to the change requests is needed. Otherwise you cannot get anything finished but are in a reactive mode all the time. Table 1 Dynamics of software service vs. product business, adopted from (Hoch et al. 1999) Service business
Product business
Customer relationship
One to one
One to few, one to many
Marginal costs
Almost constant
Almost zero
Most important number to watch
Capacity utilization rate
Market share (installed base)
Relevance of management areas
1. Human resources 2. Software development 3. Marketing and Sales 4. Strategy
1. Strategy 2. Marketing and Sales 3. Human resources 4. Software development
The marginal costs in the service business are almost constant, because what you are selling is basically working hours, which implies that human resources is the most important management area in service businesses (Hoch et al. 1999). The way to become more profitable is to make sure that the capacity utilization rate is improved. This means that the software development process needs to be optimized, and software service companies usually have more mature processes than software product companies (Carmel and Sawyer 1998). The way to increased profitability and growth in software product companies is through selling more products and increasing the market share, because the marginal costs for a software product are close to zero. When the product is ready it can be distributed to millions of customers, e.g., over the Internet. This means that time-to-
12
market is of essence to software product companies, and the pressure is on shortening it, especially in turbulent environments (Carmel and Sawyer 1998). This also means that the maturity of the process is only important to the degree it helps in achieving a required time-to-market and hitting the right market window. According to (Hoch et al. 1999), the most relevant management areas in the software product business are strategy, and marketing and sales, which means that there should be an explicit link to these in the software development process. Most software companies offer both software products and complementary services to their customers (Cusumano 2004, Sallinen 2002). According to Cusumano, healthy software product companies need to have a balance of product and service revenues to survive in bad times and to grow in good times. In the case of software product companies this means that they also offer software services in some forms. They can, e.g., customize the product for some customers, provide training for the product, provide integration work when delivering and installing the system at the customer, and sell maintenance work. The more services the company provides, the more people they need, because the more labour intensive the work gets (Cusumano 2004). Hoch et al. suggest organizational separation when combining software service and product business in a company (Hoch et al. 1999). For a small company this can be especially challenging, because of limited resources, which means that resource allocation is a critical issue in successfully managing software product development in a hybrid company, such as the case company in this research. 3.1.2 Software development models There are two basic types of software development life-cycle models: the sequential (or waterfall) model popularized by (Royce 1970), and the iterative and incremental development (IID) model. Other classifications exist that include other approaches, e.g., formal transformation (Sommerville 1996) and object-oriented models (Schach 2002), but in most cases all approaches to software development build on either the sequential model or IID, or combine both. In the sequential model the development of software proceeds sequentially as stages of requirements definition, system and software design, implementation and unit testing, integration and system testing, and operation and maintenance as shown in Figure 3. The emphasis in the sequential model is on fully elaborated documents as completion criteria for the requirements and design phases, which makes it a bad choice for software development in turbulent environments with high degrees of uncertainty in the beginning of a project (Boehm 1988, Schach 2002, Wong 1984). Therefore we concentrate here on IID, which through the years has been advocated by many researchers and practitioners (Larman and Basili 2003), and today seems to be the dominant model (Cusumano et al. 2003).
13
Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
Figure 3 The sequential software development model, adapted from (Sommerville 1996) In IID software is developed in small increments in several subsequent iterations or sub projects in contrast to the ‘big bang’ approach in the sequential model. However, within iterations the sequential model may be used for developing the increment of functionality, so the two approaches are not mutually exclusive. The iterations may also overlap, as shown in Figure 4. Concurrency increases the risk that the pieces from the different iterations do not match perfectly when integrated. Iteration 1 Specification
Design
Implementation
Testing
Design
Implementation
Testing
Design
Implementation
Iteration 2 Specification
Iteration 3 Specification
Testing
Figure 4 Concurrent iterations, adapted from (Schach 2002) There are several potential advantages of using IID: Early risk mitigation and discovery. You can tackle the hardest perceived problems in the first iterations and learn about the implementation of the system and the skills of the team members. For example, you can start with developing the baseline architecture of the system (Kroll and Kruchten 2003). If you stumble onto problems, you at least know the project may take longer than expected to finish, or that you have to cut down the scope of the project. Early greater investments in architectural design have also been associated with better performing projects regarding customer perceived quality (MacCormack, Verganti, and Iansiti 2001). Other risky areas could be, e.g., experimenting with new technology to see how it works.
14
Lower risk of total project failure. After each iteration you should have a product that could be at least shown to customers or delivered, as in evolutionary development (Gilb 1981) or agile methods. In this way you can collect feedback on the product and use it to control what to do next, thus lowering the risk of total project failure. In the sequential model you cannot get this feedback before all the code is written and integrated. Royce proposed a correction to the classic sequential model by recommending to “do it twice” (Royce 1970). First you should use about one third of the allocated time for the project to quickly develop a first full version of the product, because otherwise you would not know what you were doing. Final product better matches customer’s wishes. An issue closely related to the previous point is that in IID the final product should better match the customer’s needs, because he has been able to give feedback and steer the development to the right direction. In the sequential model the customer may get what he required in the requirements document, but that may not be what he really wanted. In the product business, the direct contact to users or customers can be very limited, but for the product business this point translates to being better able to adapt to changes in the markets. Accommodation of early change. The previous points have already partly discussed that IID accommodates early change. In turbulent environments the requirements of the software may be unclear to all stakeholders in the beginning of the project. Unclear requirements have been cited as one of the main reasons for failed or runaway projects, e.g. (Glass 2003, The Standish Group 1995). Demonstrating working software at the end of iterations helps in eliciting new requirements and clarifying the existing ones. It also helps in having the product closer to release readiness after each iteration. Manageable complexity. Basili and Turner demonstrated that with an iterative process they could develop a system based on simple and well-understood extensions in each iteration step (Basili and Turner 1975). Using IID forces you to plan and split the development into smaller chunks that in themselves are less complex and easier to understand than trying to do the whole system at once, as in the sequential model. However, problems might arise, if the architecture does not support the extensions in the later iterations. For this, early investments in architecture (Kroll and Kruchten 2003, MacCormack, Verganti, and Iansiti 2001) or simplest possible solutions and refactoring are suggested (Beck 2000, Fowler 2000). Visible progress. In IID you have working software to show after the iterations, making progress visible. This should reveal problems early, as discussed in many of the previous points. Successful iteration can also boost the confidence of the team (Cockburn 2002). Potential for better quality. A prerequisite for having working software at the end of iterations is that quality assurance has been properly done. Assuming that the functionality has been developed in some kind of priority order, the most important parts of the final product are tested many times over in the iterations and should thus be of good quality. Early and regular process improvement. After each iteration, the team has the possibility to reflect on the process and identify weaknesses for improvement. This is one of the principles of the agile manifesto (Fowler and Highsmith 2001) and thus practiced in the agile methods. Besides advantages, there are also potential risks and disadvantages of using IID:
15
Planning overhead. In IID you need to plan each iteration. This could mean a lot of planning overhead compared to a sequential model of development, where you plan everything in the beginning. However, in a turbulent environment you do not know all the requirements in the beginning of a project and need to accommodate to change as the project proceeds, making IID with suitable length iterations a preferable choice. More experienced personnel required. As mentioned above in the advantages of IID, an architecture that accommodates flexibility and change is needed. In a turbulent environment the team may need to learn about new technical solutions and their potential application (MacCormack, Verganti, and Iansiti 2001). This calls for experience in the team to the degree that it facilitates framing and directing an effective experimentation strategy to resolving the uncertainties of the new technology (Thomke, Hippel, and Franke 1998). Integrating the new technological solutions as part of the product and maintaining a coherent system-level architecture also requires experience from the team (MacCormack, Verganti, and Iansiti 2001). Cockburn suggests that more experienced people are needed simply because they can get more done (Cockburn 2002). Constant changes in the architecture. The different IID methods differ in their emphasis on early investments in architecture. The RUP is architecture centric and advocates beginning with developing a baseline architecture, whereas XP advocates constant refactoring of the software. Too many changes in the architecture during a project may hinder flexibility (MacCormack, Verganti, and Iansiti 2001) and slow the project down concerning developing new features. As mentioned in the previous point, an experienced team may be needed to solve the architectural issues during development. Also, too many changes late in the project are discouraged (Kroll and Kruchten 2003). Solving the easy stuff first. One of the advantages of IID is early risk mitigation by tackling the hardest perceived problems first to help learn about the implementation and find out more potential problems as early in the development as possible. There is a risk that a team chooses to solve some easier issues first, because they want time to think about the harder issues. When it is time to take on the difficult problems, a new architecture might be needed making all the previous work obsolete and derailing the project (Kroll and Kruchten 2003). Another manifestation of doing the easy stuff first is leaving proper system testing to the last iteration, because it is difficult to do when the system is not ready. In this way big surprises, e.g., in system performance might surface and delay the project. Software project contracts require early commitment. Software project contracts are not always a big concern in the software product business, but in the software service business the subcontractor may have to complete detailed up-front planning to base the contract upon. This takes away most of the advantages of IID (Kroll and Kruchten 2003).
3.2 Temporal pacing In this section we discuss temporal pacing as reported in two research areas: strategic management and software engineering. We also discuss the strengths and weaknesses of temporal pacing.
16
3.2.1 Temporal pacing in strategic management Gersick studied a venture capital-backed start-up company in the medical products field (Gersick 1994). In her previous studies she had noticed connections between groups’ pacing efforts and their creative work progress, specifically that the former can catalyze the latter (Gersick 1988, Gersick 1989). When faced with fixed temporal milestones, the groups more effectively moved from one task to another and got better results than groups that did not pace their efforts. Gersick wanted to examine whether such time-linked patterns occur at the organizational level and how managers use them. Gersick characterised the venture capital-backed start-up company the following way (Gersick 1994): “Challenged to create novel products and build their organisation in new markets, they must mediate between perseverance, which is needed to overcome obstacles to innovation, and flexibility (needed to change unworkable plans) in settings fraught with uncertainty.” This characterisation could well be used to describe the case company in this research, and therefore Gersick’s findings are interesting to us. Gersick’s study shows how managers use two mechanisms to control the alternation between persistence and flexibility: temporal pacing and event pacing. Temporal pacing was used by the CEO as he divided time to be expended to achieve a goal into segments of temporal milestones at which progress was evaluated and possible adjustments were made to the plans. Changes were only made at these milestones, so persistence was accomplished at the same time keeping the flexibility to change plans and adapt to changes in the environment at specific time intervals. This is similar or equal to time boxing in software development, a concept that was introduced in (Martin 1991) and is presented in more detail in the following section. Event pacing was used by the venture capitalist as his actions were triggered by particular events signalling when actions could or should be taken. The venture capitalist used financial measures to assess the readiness of the company to take next steps, for example to go public. Gersick also reports that the CEO’s pacing efforts involved simultaneous awareness of several time horizons. The short-term projects of the company were harnessed to serve the long-term goals. Temporal pacing allowed the company to pursue each strategy fully until its viability was evaluated. This helped maintain focus instead of dribbling with too many alternatives. According to Gersick, the biological concept of entrainment helps understand the foundations of temporal pacing. Human activity is rhythmic by nature, as in the example of circadian rhythms causing jet lag, because different metabolic and glandular functions adapt to a certain daily rhythm that is disrupted when people move to distant time zones. Temporal pacing, as Gersick observed it in the case company, could be explained in a similar manner. The CEO established work rhythms in the company to help synchronize it to its strategic environment. This brings forth the question on an organisation’s ability to match its internal pacing to the pacing of the environment, which can be a key to good performance. Mintzberg and Waters concluded in (Mintzberg and Waters 1982) that yearly strategic planning is too frequent in slow moving industries, possibly desensitizing top management to strategic issues causing the need for substantial change pass them unnoticed when it arises. As a contrast, Eisenhardt noticed that good performers in highvelocity environments use weekly strategic planning meetings to keep up the pace (Eisenhardt 1989).
17
Gersick summarises that temporal pacing is a prominent mechanism for keeping organisations adaptive in the face of uncertainty. It seems to work well in situations where change is continuous, as opposed to the punctuated equilibrium model of change, where long periods of small change are interrupted by brief, discontinuous radical change, see e.g. (Tushman and Anderson 1986). Temporal pacing is not to be confused with the practice of scheduling regular meetings or milestones. The key to temporal pacing is in the adaptive behaviour, which, if lacking reduces the meetings to mechanical cyclical events that can blind the managers from the need of change. Gersick uses the term “temporal maintenance” to describe these kinds of cyclical activities, as she sees their function as preserving the status quo instead of changing it. Brown and Eisenhardt’s findings support Gersick’s findings and bring forth three key properties of successful, continuously changing organisations: (1) semi structures with clear responsibilities and priorities coupled with extensive communication, (2) links in time that direct attention simultaneously to different time horizons, and (3) sequenced, well-organised steps of transition from present to future projects. Semi structures refer to organisations in which some details are prescribed and others are not. Among the prescribed details can be, e.g., project priorities, different roles and responsibilities, and time intervals between product releases. Brown and Eisenhardt argue that some structure is needed to facilitate coordinating change, but too much structure makes it hard to react when needed. Links in time refer to organisational practices that handle past, present and future time horizons and the transitions between them. The successful companies Brown and Eisenhardt studied realized these links as they focused on managing current projects at the same time developing probes to test different future scenarios.(Brown and Eisenhardt 1997) 3.2.2 Temporal pacing in software engineering Time boxing is used as a term in software engineering referring to doing temporal pacing on a project and iteration time horizon. Time boxing means that the end date of each iteration is fixed and the end date of the project is also fixed. Fixing the end date means that if you cannot finish all requested features by that date, the scope is reduced so that the system is ready at the fixed date. The requirements must be prioritized so that the team can make scope adjustments by themselves. This is important, because otherwise you could inappropriately force the team to work overtime in order to meet both the deadline and the scope. The term ’ready’ implies that the system is in a stable and tested state. An important part of time boxing is freezing the requirements for the duration of an iteration. New features cannot be introduced in the middle of an iteration, except if an existing feature needs to be redefined because of, e.g., unexpected technical problems. In software engineering time boxing was first reported being used at DuPont as a variant of Rapid Application Development (RAD) (Martin 1991). The time boxes for building an application were 90 days (later 120 days). In larger applications consecutive 60-day time boxes were used for developing partial functionality of the final application. Later RAD was refined into the Dynamic Systems Development Method (DSDM) (Stapleton 1997), which is one of the agile methods. In DSDM, as in many other agile methods (Beck 2000, Highsmith 2000, Schwaber and Beedle 2002), the recommended length of an iteration time box is 2-6 weeks, the shorter the better. On a shorter time horizon than an iteration, Scrum and eXtreme Programming (XP) both advocate daily meetings for coordinating
18
and monitoring the team’s work as well as for early problem identification (Beck 2000, Schwaber and Beedle 2002). It seems that the only software product development model reported in literature that employs temporal pacing also on a strategic management level is the Synchronize-andStabilize as described in (Cusumano and Selby 1995). Or more correctly, the Synchronize-and-Stabilize is a way of harnessing product development projects to the strategy of the company. Cusumano and Selby argue that Microsoft follows a strategy of pioneering and orchestrating evolving mass markets, which is where temporal pacing of introducing new products to the markets comes in, as described in the previous section. In the Synchronize-and-Stabilize a time boxed project is done in 3-4 iterations or sub projects that last 2-4 months each. In each of the iterations there is a stabilizing period, where no new functionality is developed. Instead the existing features are stabilized, that is, tested and debugged. Also, a stabilizing phase is used at the end of the project, where release preparations are done, including testing and debugging the product. The work of the team members is synchronized in daily builds of the software that are smoke tested1. The Synchronize-and-Stabilize has been packaged and improved from 1995 onward as the Microsoft Solutions Framework (MSF), the latest version of which can be found at http://www.microsoft.com/msf/. 3.2.3 Strengths and weaknesses of temporal pacing As temporal pacing is one way of doing IID, the same strengths and weaknesses apply. In addition to these, there are some strengths and weaknesses specific to temporal pacing. The strengths of temporal pacing include: 1. Time boxes force hard business and technology trade-off decisions from all parties of a project (managers, customers and developers) to frequently re-scope the project as new information arises. Without the pressure to make these decisions, human nature delays them towards the end of the project, when there is very little manoeuvrability (Highsmith 2000). Without time boxing the project you can just add iterations until you get everything done, as described in (Kroll and Kruchten 2003). This introduces a big risk of feature creeping and gold plating. 2. Short time boxed deliveries force convergence and learning. People tend to want to do quality work, so when the deadline of the time box is fixed, it helps overcome the tendency to gold plate a deliverable, before it is shown to others. Instead, when you are forced to deliver your work at the end of the time box, you can learn from any problems encountered during the time box and hopefully use this to your advantage in the following time boxes. Especially for young companies in turbulent environments this kind of trial-and-error type of learning is important, since they cannot base plans on prior experience. A trial period to pursue a strategy must be long enough to protect against abandoning it prematurely as unsuccessful, but short enough to protect from chasing a lost cause for too long.(Gersick 1994, Highsmith 2000) 1
Smoke tests refer to tests that exercise the entire system from end to end. They do not have to be exhaustive, but they should be capable of exposing major problems. The smoke tests should be thorough enough so that if the build passes the tests, you can assume that it is stable enough to be tested more thoroughly.
19
3. Time boxing helps keep the team focused. A specific due date provides a focal point. When you have to deliver and present the product to outsiders of the development team (customers or other stakeholders), it forces the team to concentrate on the most important activities. At the same time the requirements freeze for the iterations helps prevent unnecessary distractions from the work at hand.(Gersick 1994, Highsmith 2000) All the points above can easily be misinterpreted and badly implemented. The first point can be turned into doing anything for the sake of keeping the project moving, not because it is the most important thing to do next. Also, if decisions are made ”mechanically” at each time box, the need to change the direction and scope of the project or even kill the project due to changed market conditions may be missed. The second and third point can lead to stress and disappointment in your employees. As Highsmith says, people like to take pride in their work and thus it may feel awful to reduce the scope of the time box or to be forced to turn in deliverables that are not ”perfect”. Both could be seen as reflecting poor performance, even when it is not true. A strength and weakness of temporal pacing is that it forces good quality assurance practices. If you do not get the quality right in the first place, the time box leaves you no room to get it in later and you may be forced to delay the release of your product, which means that you are not really employing temporal pacing, just ordinary IID with iterations of the same length. On the other hand, if you insist on holding on to the time box, you may be forced to release a product of inferior quality, which can have negative consequences for your business.
3.3 Applicability of temporal pacing and existing IID models for the software product business In Section 3.1.1 we discussed the software product business. The following list summarizes the main points in the software product business that need to be addressed in the product development process and thus in our framework: 1. There are multiple stakeholders to the product with possibly conflicting interests. The process should include analysis and prioritization of these. 2. In a turbulent market quick reaction to change is needed, but there has to be a degree of control, so that the reactions go through the same prioritization as in the previous point. This requires a combination of flexibility and control in the process. 3. Hitting the right market window with the right product is of essence, which requires having the product ready for launch even at short notice. This also helps in quick reaction to change. 4. Strategy and Sales & Marketing are the most important management areas, which means that the strategic dimension of product development should be accounted for in the product development process. There should be a link between strategic decisions and product development decisions in the process, so that the developers understand the strategic implications of what they are doing. Development progress should also be visible, so that Sales & Marketing and strategic decision makers can make decisions based on real progress.
20
5. Most software product companies also offer services. Therefore there are many activities that may demand product development resources. Since resources are very scarce in a small company, the process should place special emphasis on resource allocation management. Making resource allocation decisions is a way of concretely prioritizing what gets done (Christensen and Raynor 2003), so it is closely linked to all the previous points. As discussed in Section 3.2, temporal pacing seems promising in providing a structure within which to deal with the points above. For example, setting the pace of product releases to the market and splitting the long-term goals into short term goals realized in time boxed projects and iterations deal with points 2-4. From the existing IID models the ones employing temporal pacing seem more relevant than the others, especially concerning point 3. Without temporal pacing, you can just add iterations until the software is ready, which could drag the project on for a long time and introduce risks of feature creep and gold plating. Even the RUP recommends adding iterations and prolonging a project in order to reduce technical risk (Kroll and Kruchten 2003). Concerning the fifth point, resource allocation management, most IID models adequately address how to use resources within a project, but they do not address the viewpoint of multi-project management. In a small company in the software product business there can be many ongoing activities that demand the attention of the developers, which makes the situation very much like that of multi-project management. This means you have to consider which activities to “fund”, that is, how much resourcing each activity gets. You may not be able to dedicate only one activity per person, which introduces risks that one activity takes longer than anticipated and the other allocated activity to that person is delayed. However, you should at least try to consider this when managing your resources and this is something the existing process models for IID do not cover sufficiently. The first point is close to the fifth point, because the multiple stakeholder interests are the ones providing the requirements for the activities that demand resourcing. Especially the agile methods seem weak in this respect, because they tend to emphasize that there should be only one customer. This leads to thinking that the agile methods are better suited for the service business, where there is only one customer in each project. Highsmith proposes using a customer proxy to circumvent this, e.g., a product manager (Highsmith 2002), but this introduces the risk of bias towards the opinions of the product manager. Most IID models seem weak regarding the fourth point, because the strategic aspects of a project are left out of scope of the models. The only IID model that emphasizes the strategic aspects of temporal pacing seems to be Microsoft’s Synchronize-and-Stabilize, as discussed in the previous section. However, some practices in other models offer a forum to resolve these issues, e.g., the planning game practice in XP, where representatives for Business and Development gather together to plan what to do in a project and each iteration respectively. The planning game could be used to convey the strategic implications of the development work to the development team. Based on the literature study it seems that no existing process model can as such be used for software product development in a small software product company operating in a turbulent environment. Microsoft’s Synchronize-and-Stabilize comes very close, but it has not been tried in a small company, and as such it has features that do not translate directly to the small-company context, e.g., the practice that each developer has a buddy
21
tester. In the next chapter we present the temporal pacing framework we have constructed. The framework draws features and inspiration from the foundations of temporal pacing and from existing process models, mainly from Microsoft’s Synchronizeand-Stabilize (Cusumano and Selby 1995), Scrum (Schwaber and Beedle 2002), and XP (Beck 2000).
22
4. The Cycles of Control framework In this chapter the constructed framework, called Cycles of Control (CoC), is presented. The first section provides an overview of the framework and the second section discusses the application of the framework. The construction of the framework has been iterative and incremental, but for clarity’s sake we present only the latest version in the following sections. For snapshots of earlier versions, please refer to (Rautiainen et al. 2002, Rautiainen, Lassenius, and Sulonen 2002).
4.1 Overview and structure of the Cycles of Control Figure 5 shows an overview of the basic building blocks of the Cycles of Control framework (CoC). Each cycle represents a specific time horizon and starts and ends in a control point where decisions are made. The cycles and time horizons are hierarchical so that the longer time horizons set the direction and constraints for the shorter ones. Control points
Strategic Release Management
Release Project
Iteration
Heartbeat
Software development process
Figure 5 Cycles of Control building blocks The leftmost cycle in Figure 5, strategic release management, deals with the long-term plans for the product and project portfolios of the company and provides an interface between strategic decision making and product development. Strategic release management decides what release projects are launched. Each individual product release is managed as a time-boxed project and dealt with in the release project cycle. Each project is split into time-boxed iterations where partial functionality of the final product release is developed. Daily work is managed and synchronized in heartbeats. The three rightmost cycles constitute the software development process, which is temporally paced, iterative and incremental. In order to better understand how the cycles relate to each other
23
and show the hierarchy of the time horizons, the cycles can be drawn on a timeline as depicted in Figure 6. In the example in Figure 6 we can see how the strategic release management time horizon spans two release projects, the releases are built in three iterations, and the work is coordinated and synchronized with daily heartbeats.
Strategic Release Management
Release Project
Iteration Heartbeats Time
Figure 6 Cycles of Control on a timeline
4.1.1 Strategic release management The strategic release management cycle sets the direction for product development by aligning the product development efforts with the business and technology strategy of the company. This means considering the overall strategic ambitions of the company together with the competences and availability of people that do the actual work in conjunction with planning future releases of products. In a way, strategic release management means constantly monitoring what happens inside and outside of the company making necessary adjustments to the release plans and resource allocation, so there is no definite starting or ending control point to strategic release management. But considering the planning horizon you can say that the starting and ending control point is planning future product releases and checking whether the set direction for the company is still valid or needs adjustment in the release plans. The roles that participate in strategic release management should include at least the most important stakeholders or stakeholder viewpoints of the products and other activities demanding product development resources. These could be, e.g., the CEO, sales & marketing, customer services, product development, product management, and key customers and partners. The time horizon for strategic release management in a turbulent environment is 6-12 months, or 2-3 product releases ahead. The time horizon should be synchronized both with the marketplace and the internal capabilities of the company. Within the time horizon the upcoming product releases and the needed release projects are planned on a high level of abstraction (e.g., product vision, major new features and technology, quality goals, release schedule, coarse resource allocation) and documented, e.g., in the form of an aggregated release plan or a product and technology roadmap. In this way there is a baseline against which to make trade-off decisions, e.g., when customers request
24
something that has not been planned for the near future. Also, if a customer makes a request for something that is already in the roadmap, you can ask if the customer can wait until the planned release in 4 months, instead of immediately altering existing plans and disrupting work in progress. Christensen and Raynor pointed out the crucial role of the resource allocation process in putting a company’s strategic intention into action: “...a company’s strategy is what comes out of the resource allocation process, not what goes into it.” (Christensen and Raynor 2003) This means that besides being temporally paced with, e.g., major roadmap revisions every 6-12 months, strategic release management should be represented in resource allocation decisions at least on the time horizon of an iteration, since the outcome of iterations is what the company actually does. Since there are other activities possibly demanding product development resources, such as maintenance work and assisting in customer deliveries and integration, resource allocation decisions can be difficult trade-offs. In small companies the resource allocation decisions are especially important, since there is a very limited possibility to dedicate resources for longer periods of time. This is where temporal pacing can add stability and control. After each iteration you have a chance to redirect resource spending if needed. 4.1.2 Release project The release project cycle develops a release of a product. A steady release pace helps to keep the development focussed and provides opportunities to control the development. The starting control point of a release cycle is release planning and the closing control point is the release decision, i.e., deciding whether the product version developed can be released or not. Depending on whether the release is internal or external, the quality goals and release criteria can differ. The roles that participate in a release project are the project team and strategic release management representation for the control points, as discussed above. The time horizon for a release project is 3-4 months, during which a release candidate of the product is developed. In the beginning of the release cycle the release is planned and specified based on the goals and priorities set in the roadmap or long-term release plan. This includes deciding on the schedule and content of the iterations in the project and appointing the project team. Also, you need to plan when and how you are going to test the product, so that you can make sure that the quality of the released version is sufficient to make releasing the product possible. This includes allocating necessary rework time in the end of the project cycle to fix the defects that need to be fixed. Since the project is time boxed it means that the schedule cannot slip. The requirements need to be prioritized so you can make decisions on altering the scope of the project, if everything cannot be finished within schedule. Based on the release goal(s) set by strategic release management, decisions about decreasing the scope can be made, as long as the release goal is not compromised. 4.1.3 Iteration The purpose of iteration cycles is to develop the product as a series of reasonably stable, working intermediate versions having part of the functionality of the final release. This is done to get feedback of the product during development. The starting control point of an iteration cycle is the planning of the work to be done. The closing control point of an
25
iteration cycle is demonstrating the developed functionality. The roles that participate in an iteration cycle are the development team and strategic release management representation in the control points, as discussed above. In a turbulent environment the time horizon of an iteration cycle should not exceed 1 month, during which a stable increment is developed and integrated into the product. During an iteration cycle the requirements and resources should be frozen. Therefore, if it is possible to split work into shorter iterations without excessive overhead, it is advisable to do so to guarantee the availability of the allocated resources. The shorter the iteration cycle the fewer the possible interruptions are. The developers should be allowed to concentrate on the work planned for the iteration. The key lies in including all known commitments that need attention from the developers into the resource allocation plan in the beginning of the iteration. For example, if Jack needs to help in integrating the system at a customer’s site, the time needed for this should be subtracted from Jack’s product development time, and so on. Even for a month-long iteration cycle there should not be any big surprises, except for bugs found by the customers, and for this you might consider dedicating one person. By the end of the iteration cycle the new features developed are integrated into the product and the product is stabilized, meaning that testing and possible bug fixing need to be planned and executed. This needs to be considered when planning the iteration, and the requirements need to be prioritized so that scope adjustments can be made. Also, part of the planning is converting the requirements into tasks to be done that can be estimated for effort. After that the selection of requirements to be done during the iteration cycle can be based on the available product development time and the estimated effort for the tasks. The iteration cycle ends with a demonstration of the product to all interested stakeholders, where comments and feedback are gathered and can be used when planning the following iteration(s). 4.1.4 Heartbeat To gain more control of the development effort, it is paced into heartbeats. A heartbeat is the shortest time horizon within which the progress of development is synchronized and reflected against plans. The starting and closing control points of a heartbeat can be combined into a status check that creates links in time from past to present to future in the form of three questions: What have you done? What problems are you facing? What are you doing next? The participant in heartbeats is the development team. The time horizon of a heartbeat can range from a day to a week. During this time development proceeds and at the end of the heartbeat the status is checked. In this way there is up-to-date information at regular, short intervals about project progress. This helps in identifying early warning signs of things that might compromise development goals. For example, if Joe has not been able to use his time as planned to developing the product, this is revealed in time for corrective actions to be taken, instead of being revealed at the end of the iteration cycle when it is too late to react. Another example is that Joe cannot finish his task within the estimated effort, which could affect the work of others. Therefore, a part of the heartbeat cycle is updating the estimated effort left for tasks. A part of synchronising the work might be making daily builds and running automated smoke tests against them. This gives an indication of system status from a technical perspective.
26
4.2 Applying the Cycles of Control framework In this section we explain the general idea of how the CoC can be applied. Figure 6 above shows the different cycles and their time horizons on a timeline and gives you an overview of how the product development process works. The time horizons show the pace of product development and can be used as a starting point to planning and mapping different practices and activities to that pace. For a practice or activity belonging to a certain time horizon means that it is planned and tracked with that pace. If necessary, a practice or activity can be split into parts to be tracked on a faster pace, and so on. To give you an example, let us consider how functional requirements can be managed using so called backlogs, an idea presented in the Scrum process model (Schwaber and Beedle 2002). A bunch of product stakeholders and stakeholder representatives participate in the April roadmapping session to plan future releases of the products. Jeff (the CEO) represents the company strategy and wants to secure that the products reflect this strategy. John (the Visionary) provides some “out there” visions about the future development of the markets and technology, supported on the technology front by Jenny (the Chief Architect), who also is responsible for more “down to earth” assessments of the viability of using new technologies. Jermaine and Joanna (the Sales Directors) represent the customer viewpoint and bring the latest information from the markets. Jeremy and Jay (the Product Managers) are responsible for one product each and also represent the viewpoint of customer support (Help Desk and Product Delivery). Jericho (the Marketing Director) wants to secure sexy features to future product releases, so he can market them successfully. The meeting starts with Jeremy presenting the up-to-date product backlog of Widget, the older of the two products of the company. A product backlog is a prioritized list of product requirements and features of differing scope. All the ideas for the product have been gathered into the product backlog and Jeremy is responsible for keeping it up-to-date. Jeremy presents his preliminary suggestion for the release backlogs of the two following releases of Widget. A release backlog contains the requirements and features to be included in a product release and is a prioritized list, like the product backlog, only a bit more detailed. At the end of August a minor release of widget is scheduled, containing some bug fixes and new features. The next major release for Widget is scheduled just before Christmas and contains support for new databases that are needed to penetrate new markets and a bunch of other new features. Jeff is pleased with the release backlogs, especially since the strategic intent of the company is to move to new markets to generate new cash flow. Jenny expresses concern for the tight schedule, because Jack (the Senior Developer) has been very busy with rewriting Gadget (the second product of the company) for .NET, and the progress has not been as good as expected, as everybody could see in the last iteration demo of Gadget. Since Jack is the database expert of the company, a decision must be made on which is more important, getting .NET Gadget out in time or extending database support for Widget. Jermaine (Sales Director of Widget) and Joanna (Sales Director of Gadget) argue that both are very important for their customers and Jericho shows that market research results support an aggressive strategy to move into the new markets now. Before the meeting breaks into on open fight, Jay (the Product Manager of Gadget) proposes that he shows the release plans for Gadget, so that the possible trade offs are clear to everybody. When Jay has shown his suggestions for release backlogs for Gadget, the lively debate continues until lunch. Everything is important and no trade offs can be made. After lunch, when things have cooled down a little bit, Jenny suggests that Jack continues working on .NET Gadget. But instead of doing it alone, he pair programs with Jo (the Junior Developer). Pair programming has been used earlier with some positive results in different tasks, so Jack and Jo already have some experience in doing it. In this way Jo would learn from Jack and in a couple of iterations Jo would be able to continue on her own, if necessary,
27
leaving Jack free to start with the new database support for Widget. The drawback is that some of the features in the release backlog need to be reprioritized to lower priority, since Jo cannot be working on them, meaning that they probably cannot be finished in time for the release. But at least the most important goals for the releases of both products have a greater chance of being met. The meeting participants discuss Jenny’s suggestion for a while and agree that this is the best course of action. The meeting then continues with more discussion and reprioritisation of the release backlogs. A week later Joanna, Jay and Jenny meet with Jill (the Development Team Leader), Jack, Jo, Joe (another Junior Developer), and Jake (the Quality Engineer) to plan the next iteration of Gadget. At the coffee table they have already discussed some of the ideas from the roadmapping session, so there are no big surprises for anyone. Joanna, Jay, Jenny and Jill have prepared for the planning session by discussing the most important release backlog items and what they mean in more detail, both from a business perspective and from a technical perspective. The results from these discussions are presented to the development team and questions about unclear things are asked and answered. Then the team is left alone to plan how these release backlog items can be broken down into tasks for the iteration and effort is estimated for the tasks. When the planning is ready the development team presents the results to the others and also discuss the budget of available development effort for the iteration. It is apparent that not all tasks can be done within the available budget, so Joanna, Jay, Jenny and Jill discuss and prioritize the scope of the iteration. They also create the iteration backlog, which contains the iteration goal(s) and the features to be done including the planned breakdown to tasks for developing those features. When the iteration backlog is ready the development team joins the others and the backlog is shown and discussed. After that the team accepts responsibility for realizing the iteration backlog, at least to the extent that the iteration goal is met. A month later the same iteration planning process is repeated using what was left in the release backlog as a starting point. At this time new, emerged requirements can be traded off with those in the release backlog to reflect changed prioritisations. These should not, however, be in contradiction with the release goals. Changing the release goals every month would probably result in over reacting to changes in the market. Of course, if the initial analysis of the markets was totally wrong, even the release goals should be changed.
The example above shows the nature of software product development management. To recap the main issue in the example, functional requirements can be managed using backlogs of different scopes as depicted in Figure 7. As we move downward in Figure 7 the backlogs get more detailed. Managing the requirements on a monthly pace gives us flexibility to change plans if we have missed something earlier. Each month we also see how much has been accomplished, giving us a measure of progress we can compare to the plans and goals. This gives us control to make corrective actions based on real progress, if our plans have been too optimistic or pessimistic.
28
Product Backlog planned scope for release allocated into
Release Backlog
Release Backlog parts chosen and allocated into Iteration Backlog
Iteration Backlog
Iteration Backlog
Figure 7 Managing functional requirements with backlogs
4.2.1 Finding the pace of your own Finding a suitable pace entails understanding the pace of the markets and the internal capabilities of the company. Releasing products to the markets should be done at an appropriate pace. For example, if a magazine publishes a product review at a certain time of the year, you need to release your product in time for that review. Or if a fair is organized at a certain time, you need to have a product release ready by that time. Another example could be seasonality, e.g., you need to release a product for the Christmas market. Your product’s maintenance agreement may also contain promises of maintenance releases with a defined pace. All releases of the product do not need to be external or commercial releases. You can also make internal releases that can be used in demonstrations for potential customers or just used as intermediate versions for, e.g., thorough testing. In this way you can get a better understanding of the product and improve it before you make it widely available. While the pace of the markets tells you when you would want to release your product(s), the internal capabilities of the company constrain what is possible. With the internal capabilities we mean, e.g., how effective your processes are, how skilled your employees are, how easy it is to develop and test your product(s) incrementally, and how much development effort different people can contribute considering all the other tasks at hand. One way to find out the internal capabilities is to define and try some pace and see how it works. For example, if you decide to make a commercial release of a product once a year, you could make two additional internal releases per year, which defines the release pace as 4 months. Then you could define 1-month iterations for developing the product and use a daily heartbeat pace to monitor progress. If the tasks planned on a heartbeat time horizon start taking almost an iteration to complete (instead of a maximum of a couple of days) you have not been able to plan and split the tasks into small enough items. This could mean that you have selected too difficult and large features to be done in the iteration or that the iteration as well as the heartbeat is too short. If you think the iteration and heartbeat pace is appropriate, you need to develop your skills in planning the iteration and the tasks to be done in it. One of the problems may also be that you do not yet understand what you are supposed to get done or how it can be done using some new technology. In that case you might need to reconsider the release goals and iteration contents to reflect that you are learning a new technology. The pace helps you show
29
progress or lack thereof, which in turn helps you make informed decisions about continuing or discontinuing pursuing the goals or turning to an alternative course of action in order to be able to make the commercial release. A more structured way of planning and defining the development pace based on the internal capabilities is considering what needs to be accomplished by the end of each time horizon and how long that will take. For example, when a product is released to the market, much more is involved than just coding and testing the product, which in themselves are already challenging. You may need product documentation, such as installation instructions and a user’s manual. You may need marketing material well in advance before the product release containing, e.g., screen shots of the product. You may need sales material for the sales people, such as brochures and prepared demonstrations of the functionality of the product. Preparing all these have lead times, which need to be considered when planning the iterations of the release. A good idea is to dedicate at least the last iteration before a commercial product release to stabilizing the product and preparing all the necessary accessories. For the screen shots for the marketing material you may need to make a visual freeze even earlier than in the last iteration. Stabilizing the product means that instead of developing new features we rather make sure that the existing ones work properly. For this we need to do some testing and bug fixing, the amount of which depends on, e.g., how much and what kind of testing we have been able to do in the previous iterations. If we need to do extensive testing that could take 2-4 weeks to complete, a 1-month iteration is not long enough. 4.2.2 Adopting a practice To give you an example on using pace and the different time horizons in planning how to adopt a software engineering practice, we will use refactoring. Refactoring means changing the internal structure of the code without changing the external behaviour of the software (Fowler 2000). Refactoring has been used successfully as a practice in eXtreme Programming (XP) and you might be interested in trying it out. You could directly try the XP way as described in (Beck 2000) or you might want to consider other approaches. Figure 8 shows three different approaches to refactoring: 1) refactoring heartbeat, 2) refactoring iteration, and 3) refactoring release.
Refactoring release
Refactoring iteration Refactoring heartbeat Figure 8 Different approaches to refactoring
30
1. Refactoring on a heartbeat time horizon could mean dedicating one day of the week to refactoring the code, as shown in Figure 8. It could also mean that refactoring is a part of every work day, as explained in XP. Each developer is responsible for refactoring code when it seems appropriate. 2. Refactoring on an iteration time horizon could mean that the first iteration of a release project is dedicated to refactoring the code, which is shown in Figure 8. Another option would be dedicating the beginning of each iteration or some iterations to refactoring the code. 3. Refactoring on a release project time horizon means dedicating a whole release to refactoring the code. This option is probably the least likely to be used, because if the code is already so bad that a whole release project is needed to fix it, you might as well rewrite the whole software and include some new features. The approaches above are by no means mutually exclusive. Rather you could combine them, e.g., by doing major refactoring in the first iteration of a release project and then in the rest of the iterations you do refactoring on a case-to-case basis, i.e., decide in heartbeat control points if and when refactoring is needed.
31
5. Case Smartner Information Systems In this chapter the results of the process improvement initiative at Smartner are presented. Figure 9 shows process improvement milestones on the left and major product releases on the right. Here we concentrate on the process improvement efforts from February 2001 onward, when the temporal pacing framework and its ideas were first applied. The earlier background has been shortly summarized in Section 2.3. We need to clarify the two main concepts used, the product release process and the product development process. The product release process is the productization process, in which all stakeholders contribute to making a product release. The product development process is part of the product release process and comprises the software engineering efforts done by the R&D team. Here we focus on the product development process and its most important connections to the product release process. Process improvement milestones
Product releases 2000
Mar 2000 First development process draft Sep 2000 Join SEMS research project Nov 2000 Challenges with process identified 2001 Feb 2001 Requirements for development process
Oct 2001 New development process draft
Oct 2001 Office Extender 1.2
Jan 2002 Scrum practices deployed (M1) 2002 Mar 2002 Disciplined unit test writing (M2) May 2002 New development process described Aug 2002 Sprint planning details defined (M3) Oct 2002 Release process details defined (M4)
Jan 2001 E-mail and Calendar Extender 1.0 Mar 2001 E-mail and Calendar Extender 1.1 Jun 2001 Database Extender 1.0
Feb 2002 Office Extender 2.0 Jun 2002 Office Extender 2.0.1 Jul 2002 Office Extender 2.0.2 Oct 2002 Office Extender 2.5
2003
Figure 9 The timeline of the process improvement and product releases at Smartner The rest of this chapter is structured in the following way. First, we present the road to the temporally paced product development process (February 2001 – December 2001). Second, we present the temporally paced development process. This is followed with a presentation of the results of the process improvement and lessons learned from applying the temporal pacing framework.
5.1 The road to the improved product development process Figure 9 shows a timeline with process improvement milestones and major product releases at Smartner. The major process improvement milestones are marked M1-M4, and
32
are referenced from this point on in the text. The requirements for the product development process were gathered by the R&D team leader by interviewing key people and arranging a workshop in February 2001 to discuss the factors that define the company’s operational environment and the requirements those factors pose to the product development process. Also, the state-of-the-practice of the product development process and its practices were discussed to understand why they had been chosen, what worked and what did not. The main requirements identified for the product development process are summarized in Table 2. Table 2 The environment and needs of the company and the requirements they pose for the product development process The environment and needs of the company
Requirement for process
Customizable and easily managed product Product works without customer-specific modifications Responsibility divided among developers Design for security Use standards and 3rd party components for security Focus on interfaces Deploy new technologies
Architecture centric
Fixed deadlines and a right pace Fast release cycles Short projects to minimize risks
Temporally paced
Uncertain and dynamic environment Continuously changing requirements Task prioritization Transition management
Fast reactions to change
Feature requests from customers Feature prioritization according to customers Fast reaction to customer feedback Providing early access to new product visions
Customer oriented
Demo capability Visibility of development progress Binary quality gates at the ‘inch-pebble’ level1
Visible progress
Peer reviewing Defect tracking Extensive testing
Quality focus
1
This means that automated unit tests must pass at 100 % after each build.
33
Due to the nature of the requirements for the process, four software process models were chosen for closer evaluation: the Rational Unified Process (RUP) (Kruchten 2000), eXtreme Programming (XP) (Beck 2000), Scrum (Schwaber and Beedle 2002), and Microsoft’s Synchronize-and-Stabilize (Cusumano and Selby 1995). RUP was chosen as a more traditional iterative and incremental process model, which is architecture-centric but not temporally paced. XP was chosen because of its emphasis on the development work and temporal pacing. Scrum was chosen as a temporally paced process model with a project management perspective. Microsoft’s process was chosen because it seems to have worked well for developing software products in an uncertain and dynamic environment. The goal of the evaluation was to find a process model described in literature that could satisfy the requirements, because we had noticed that the temporal pacing framework on its own did not provide specific practices for the software development process. None of the process models could satisfy all the requirements perfectly on their own, although Microsoft’s Synchronize-and-Stabilize came close with some concerns about resource allocation and iteration length. Using the strengths of each model the requirements could be covered well. This led to combining practices and ideas from all the evaluated process models in Smartner’s improved product development process, which is described in the next section.
5.2 The improved product development process Figure 10 shows an overview of the implemented cycles of control at Smartner. The two rightmost cycles have different names from those in the CoC framework presented in the previous chapter, which goes to show that applying the framework can also entail renaming the concepts to better suit the organization’s needs.
6 months
Strategic Release Management
3-4 months
Release Project Cycle
1 month
Sprint
1 day
Daily Rhythm
Supporting Actions
Figure 10 Overview of the cycles and their time horizons Table 3 summarizes details for each of the cycles and the supporting actions in Figure 10. These are all discussed in more detail in the following subsections.
34
Table 3 Summary of the improved development process Strategic Release Management Set product vision
Goals
Define the main content for product releases Schedule product releases Resource R&D projects
Release Project Cycle Update product vision and refine release backlog
Sprint Define the sprint backlog and goals
Schedule sprints
Produce a stable product increment
Produce a tested product
Show sprint results to all stakeholders Get feedback for further development of the product
Activities
Collect feature ideas and feedback on products Update product roadmap Decide on resource allocation for the release projects in the roadmap
Participants
Set dates for sprint reviews Select and prioritize features for the release
Daily Rhythm
Supporting Actions
Steer the development towards the sprint goal
Help development team to concentrate on achieving the sprint goal
Produce high-quality code
Form a common basis for working with tools and other infrastructure
Synchronize and communicate work of development team members
Sprint planning
Design
Configuration mgmt
Sprint management
Code
Requirements mgmt
Sprint review
Test
Defect tracking
Demonstrate working software
Daily builds
Define testing strategy for the release
Scrum meeting
Automated testing Maintaining test and development environments
Management team
Sprint board
Sprint board
Scrum master
System administrator
Sprint board
Customers and partners
Scrum master
Development team
Product manager
Customers and partners
Development team
Development team
Scrum master
Any stakeholders in reviews
Development team
5.2.1 Strategic release management Strategic release management aims at setting the direction for product development by aligning the product development efforts with the business and technology strategy of the company. This is accomplished by setting a vision for the products (one-year planning horizon), scheduling upcoming product releases into a product roadmap, and prioritizing features to be implemented in those releases. Strategy updates are done biannually and the product roadmap is updated after each product release. The concept of product vision is applied from Synchronize-and-Stabilize and RUP combined with Scrum’s concept of backlogs. All ideas for features in a product are collected in a product backlog. The product vision crystallizes the main scope of the upcoming releases and explicates the main product features from the product backlog to be developed in each product release. Rough effort estimation is done to these features, which are then grouped into preliminary release backlogs. The releases are scheduled into the product roadmap. Based on the roadmap, high-level resource allocation can be planned. Even if resource allocation in a small company is sometimes done on a daily basis, making high-level resource allocation between different projects such as new product development, product delivery, product customization and support is necessary to avoid or at least detect overcommitment of people.
35
Strategic release management is done by the management team of the company and the sprint board. The sprint board consists of the most important stakeholders of the product: the head of the product team, the product manager, the R&D team leader and the head of professional services. The sprint board prepares the issues for the management team, which makes the final decisions. Customers and partners participate by providing and evaluating ideas for future product releases. Smartner used simple roadmapping on a six-month planning horizon before the process improvement initiative, but there were problems in making the plans visible and understandable to all stakeholders. Making a product vision explicit and defining preliminary release backlogs one year ahead were thought to remedy at least some of these problems. The product backlog provides a systematic way to collect feature suggestions continuously from all stakeholders, compared to doing that only before each release project earlier. This was thought to help in considering user feedback and needs in long-term product planning. 5.2.2 Release project cycle The main purpose of the release project cycle is to produce a product release. The length of the release project cycle is 3 months, after which a beta release of a product is ready. To complete all the work needed for a market launch, an additional commercialization sprint is needed, in which the product is thoroughly tested and the accompanying product documentation is finalized. The sprint board is responsible for managing the release project cycle. The activities in the release project cycle can be divided into three parts: project planning (scheduling the sprints and refining the projects’ scope), decision-making at release process gates, and product release. The most important sprint scheduling issue is to plan the dates and times for the sprint demonstrations. These dates are published to the whole company so that people can include them into their personal schedules. Another important use of sprint scheduling that can also influence the content of the product release is giving selected customers a possibility for early access to the new product version, e.g., for trying the product or joint testing. As described in Synchronize-and-Stabilize, this early external testing is an important source of feedback about the product and can be used in refining the scope of later sprints. Improvement suggestions are included in the product backlog and planned into future product releases. The main task in refining the projects’ scope is reprioritizing the features in the preliminary release backlog defined in the product roadmap. New features can be added to the release backlog, meaning possibly that other features must be excluded. The reprioritization of the features is the responsibility of the product team. It is done in different sessions with internal experts and selected customers and partners. The internal sessions are 1) a technical planning session where architectural issues are discussed and considered in the feature prioritizations, and 2) a session for defining the testing strategy for the release, which covers planning testing tasks that need to be included in the release backlog, such as performance testing, usability testing and testing on different platforms (e.g. operating systems).
36
In October 2002 (M4) a release process with gates in which the management team makes decisions about the release projects were defined in detail by the head of the product team. The definition included a description of all different stakeholders of the product and their responsibilities and deliverables in making a product release. This resembles the Stage-Gate™ model for new product development (Cooper 1994). After each sprint, the management team gets a status report (including an update of effort estimates) from all the projects, and go/kill decisions can be made considering the whole project portfolio. The biggest difference to the earlier release project practices was the introduction of Scrum terminology and practices in project planning and inclusion of the responsibilities and deliverables of all product stakeholders to the release process description. At the same time the release process control points (gates) have been mapped to the development process control points (sprint reviews). These modifications were thought to help in increasing the visibility of the process and avoiding lacking communication between stakeholders. Also, adding a stabilizing commercialization sprint after the beta release of the product was thought to help in achieving release-quality software and preventing schedule overruns. Figure 11 shows an overview of the development and release processes. Product backlog
Strategic Release Management
Allocated into roadmap as
Release backlogs
Release Project Cycle
Parts allocated into
Sprint backlog
Development
Sprint
3 months
1 month
Commercialization sprint (1 month)
Business
Release process with go/kill gates
Figure 11 Overview of the product development and release processes
5.2.3 Sprint The purpose of sprints is to develop stable increments to the product. The concept of sprint is adopted from Scrum. The length of a sprint is one month. A scrum master—also a concept adopted from Scrum—is responsible for the sprint. The sprint starts with sprint planning and ends with a sprint review and a demonstration of what has been achieved in the sprint. Sprint planning has two goals: defining the sprint goals and creating a sprint backlog. This is done in 5 steps taking up to 1½ days to go through (2-5 hours for the development team and 4-8 hours for the sprint board, according to the R&D team leader). This was made explicit by defining the sprint planning procedure in August 2002 (M3).
37
1. Defining the issue backlog is done in a sprint board meeting. Inputs are customer and other commitments, the product roadmap and unfinished tasks from previous sprints. The output is a list of issues to be tackled in the following sprint. 2. Designing tasks for the sprint backlog from the issue list is done as group work by the development team, where the developers define the tasks that need to be done to complete the issues in the issue list. If any issue is unclear, it is immediately discussed with the sprint board for clarification. 3. Estimating efforts of the tasks and checking availability of resources is done as group work by the development team. 4. Selecting issues to complete and postpone is done by the sprint board. The list of issues is typically longer than can be accomplished in a sprint, so choices must be made, what to include in the sprint backlog and sprint goals, and what to leave to future sprints. 5. Committing to the sprint goals is done by the development team. It reviews the choices made by the sprint board and decides on accepting the tasks or continuing the discussion if something seems unacceptable. A sprint is managed using a project burn down graph and daily scrums, as suggested in Scrum. Work estimates for tasks are updated and new tasks are added by the developers during the sprint, if necessary, and the estimate of remaining work is shown in the burn down graph. An indicator of problems in development is that the estimate of remaining work goes up instead of down, which often happens when the work is better understood or something unexpected occurs. At that point the scrum master can decide to contact the sprint board to agree on adjustments to the sprint tasks and goals. The sprint ends with a sprint review session, where anyone from the company can participate. The scrum master is responsible for coordinating the session. It is an informal meeting including a sprint overview, where the highlights of the sprint are presented. The sprint goal and sprint backlog are compared with the actual results and reasons for deviations are discussed. An architectural overview is given to describe the main technical points and their relation to product functionality. The product increment is demonstrated feature by feature in a simulated production environment to concretely show what has been accomplished. Questions, suggestions and discussion are encouraged throughout the sprint review. All these practices were new. Previously iterations were planned in an almost ad-hoc manner, contributing to too much flexibility and lack of control. The whole development team was not directly involved in the planning, so the business goals and requirements were not communicated to them. Task effort estimations were only done sporadically, if at all, which contributed to unrealistic plans and goals. No sprint review sessions were held, so the visibility of project progress was very limited. 5.2.4 Daily rhythm The purpose of daily rhythm is to coordinate day-to-day activities in product development towards the sprint goal. The main activities are design, code, test, synchronize, demonstrate, and adjust.
38
Design has two main principles: keep it simple and keep the end-user in mind. Refactoring is an essential element of coding, as well as collective code ownership and a common coding standard. Pair programming is not used extensively, only when developers deem it useful for solving a problem or sharing information. In daily rhythm the focus in testing is on unit testing and doing it in parallel with coding using JUnit as a tool to help automate the tests. Having unit tests in place for the components encourages developers to refactor the code, because errors introduced should be picked up by the tests. These ideas and practices are adopted from XP. Synchronizing the effort of development team members is done in two ways: a daily scrum (from Scrum) and a daily build-test cycle (discussed in both XP and Synchronizeand-Stabilize). The daily scrum works as a status meeting, lasting a maximum of 10 minutes. A build is done automatically every night, taking the latest code versions from the version control system. The unit tests are run automatically against the new build and a report is generated and available the next morning. Short weekly demonstrations are made by the developers to show what they have accomplished during the week in terms of running software. Adjusting the project is done frequently in minor ways, such as switching tasks between developers, changing the implementation order of tasks or refining tasks when unforeseen dependencies emerge, and updating the effort estimations. Although some of the practices above were used earlier, the definition of the daily rhythm practices is more specific and considered to improve teamwork capabilities. 5.2.5 Supporting actions Supporting actions include tools and infrastructure for helping product development achieve its goals and form a common basis for working. These include tools for configuration management, requirements management, defect tracking, daily builds, and automated testing. Maintaining test and development environments is also part of supporting actions. The following section discusses the results of the process improvement.
5.3 Results In this section we present the results of the process improvement. The results are grouped into three subsections. First, we discuss how the improved process has worked during the first year. Then we discuss how the product has evolved, especially concerning product quality. Finally, we discuss the success factors of the process improvement initiative. We conclude this section with discussing the lessons learned in applying the temporal pacing framework. 5.3.1 The process A pragmatic measure of software process improvement success is implementation success, i.e., the extent to which initiatives lead to actual changes in software engineering practices (Börjesson and Mathiassen 2004). On the basis of the interviews and the reviewed material, it is easy to conclude that the improved product development process
39
and its practices are in use at Smartner, which in itself can be considered a success. However, not all of the improvements worked as planned when first implemented. One of the practices that did not win early acceptance among all developers was the daily scrum meeting. In an internal survey in March 2002 the developers were asked how they liked the new Scrum practices. Most developers thought both the monthly sprint and the daily scrum were good improvements and helped them see the project status better. But some developers complained that they had to report the same thing over and over in the scrum meetings, when they were working on something bigger and more complex. This could be an indication that the developers and chief architect were not yet capable of planning and splitting work into small enough items to fit the new process. Another suggested explanation was that the developers in question had run into problems they could not solve by themselves and should have asked for help, which is one of the strengths of the daily scrum meeting. Both explanations could be attributed to not yet having learned the new process. In the follow-up interviews in March 2003 both the developer and the chief architect were very pleased with the daily scrum meetings and they were confident that all other developers were pleased too. One specific point mentioned was how part time employees benefited from the daily scrum. They could rely on being quickly updated on project progress in the daily scrum meeting, even when they had been away the two previous days. This saved them and all the others the bother of going around and asking what had happened. All interviewees reported that the main purposes of sprints, i.e., freezing the requirements the development team works on as well as giving the development team a month without external interruptions, were not fulfilled when sprints were first deployed bottom-up by the R&D team. Customer projects took precedence over product development, causing sprint goals to be missed, because only part of the time allocated to development in the sprints could be used. This happened partly because the new process was not yet understood by all, partly because management was not fully committed to the new process, and partly because the customers were prioritized ahead of product development at that stage of Smartner’s life cycle. All interviewees reported independently of each other that the major breakthrough in process improvement happened when a top-down approach was taken and the management processes for roadmapping, product releases and sprint planning were detailed and deployed in M3 and M4. When asked about the increased formalism and bureaucracy this improvement entailed, the chief architect and developer told that they were very happy with the changes and that the changes made the process “more sturdy”, but at the same time “more relaxed”. Now they have the opportunity to work with their assigned tasks for the duration of sprints, which they claim has helped them get the work done in sprints from M4 and on. They also claim that they have learned to estimate task efforts better from M3 onward, which has helped in setting more realistic goals for the sprints. The head of the product team expressed it from a different viewpoint: “We still get very busy at the end of release projects, but now we can see it coming two months in advance.” When looking at the estimate of effort left undone at the end of sprints (Figure 12), we can see that the numbers to some degree corroborate the above claims. However, the numbers are neither representative nor conclusive, since we could not compare realized hours with the original planned hours, and how many tasks had been dropped during the sprints as corrective action. Also, the estimated work left undone cannot be trusted, since
40
estimation was made less systematically before M3 and has improved since. The missing data in Figure 12 relates to the time when two major customer projects were done. The R&D team leader estimates that during this time the work left undone was much higher. 350
Work left undone (hours)
300 250 200 150
No data available
100 50 0 Time
M3
M4
Figure 12 The estimated effort of work left undone at the end of sprints One concern identified by the head of the product team is being able to manage simultaneously with limited resources customer projects and product development according to the roadmap. One improvement that has helped show the need for extra resources is considering all commitments that require development resources in the sprint planning since M3. Outsourcing has been tried in product development earlier, with some bad experiences, mainly concerning the quality of work and knowledge transfer between Smartner and the independent subcontractor. Recently, outsourcing has been tried in customer delivery projects and that has worked better. One reason mentioned is that it was easier to control, because it was done as body shopping. Outsourcing should, however, be better considered in the process according to the head of the product team. According to the chief architect and developer, a benefit of the sprint planning session is that the dialog between the development team and the sprint board has clarified the business objectives of the product to the development team. Also, since customer inputs and commitments are now considered during sprint planning, there have been fewer surprises that take away product development resources during the sprints, which has contributed to better success in reaching the sprint goals. The release process gates and the estimation and specification corresponding to the gates together with monthly sprint demonstrations has helped the management team follow the progress of development and make more informed decisions, according to the head of the product team. He told that before the gates were taken into use, the management team could not understand all the implications of their decisions and had to rely more on the expertise of the sprint board. Also, now the plans are more detailed in the product roadmap and development more predictable, so when customers ask for something, answers about schedules of future releases and their content can be given with high
41
confidence, which has satisfied the customers. The head of the product team and the head of professional services both reported that everybody now realizes that there is no need to make adjustments to the product within less time than a sprint and that the possibility to make changes to the release content each month in sprint planning is flexible enough. To give an indication of the workload needed for process improvement—notwithstanding ineffectiveness due to a learning curve—the R&D team leader recorded 120 hours to process improvement during 2002, and the rest of the R&D team recorded all in all 49 hours. Data on the hours recorded by management was not available. In 2001 the R&D team leader estimated that he used approximately 1-2 months of effort in planning and preparing for the improvements. One contributing factor to the seemingly small effort needed is the light process documentation. The process is documented mostly as PowerPoint slides, both as pictures and explaining text, which seemed to work well. The same light documentation approach is also used in some of the process practices, with varying success. The developer reported that dependencies between the tasks in the sprint backlog and the order in which to perform the tasks were not written down anywhere, but just discussed and agreed upon within the development team. In the last sprint there had been some problems with this and considering that some of the people work part time, this could be an issue for further improvement. 5.3.2 The product The product has evolved and improved since January 2002. Looking at incident reports from customer delivery projects, the head of professional services says that problems attributed to the product have decreased significantly. This can be partly explained with a maturing product, but both the head of professional services and the chief architect claim that the improved testing practices with, e.g., automated unit testing have also made a difference. Other data does not fully support this. Although the amount of automated unit test code has grown, the amount of source code has grown even more as the ratio shows in Figure 13. This can partly be explained by the fact that user interface components are not tested with automated unit tests and their share of the code has grown. The big jump in the amount of code in Figure 13 is explained by moving a large code base from a subbranch to the main branch in CVS. Only the main branch is shown in the figure.
42
16 % 14 %
Number of methods
12 %
Number of methods in source code
10 % 8%
Number of methods in test code
6% 4% 2%
M2
M3
M4
Methods in test code / methods in source code (%)
0%
Time
Figure 13 The evolution of the main code base and unit test code base When comparing product components that have been developed after M2 with components developed earlier, only a fraction of defect reports from customers have been attributed to the newer components as can be seen in Figure 14. In this period 4 major customer deliveries have been done. Looking at the amount of serious and critical defects reported by customers (Figure 15), the trend has been steadily going down during 2002, even after two major customer-specific product releases were delivered. The data does not show what the exact reason for this is. The Chief Architect estimates that the new product that is ready in April 2003 will have even less defects. He speculates that this is because there has been more time for testing after M4, and that better testing tools are available. Another reason he gives is that the product architecture has improved to entail more and better defined components, which can easily be tested separately. One aspect of product quality is customer satisfaction. The head of professional services reported that based on the latest customer installations customer satisfaction has been high.
43
40
Number of reports
35
Product components developed before M2
30 25 20
Product components developed after M2
15 10 5 0
Critical
Serious
Normal
Minor
Severity
Figure 14 Defects reported by customers before and after M2 9 8
Number of reports
7 6 5
2 major customer releases
4 3 2 1 0
M2
Time
M3
M4
Figure 15 Serious and critical defects reported by customers per month (the ellipse denotes a period of time when two major customer releases were delivered)
5.3.3 Success factors The R&D team leader’s opinion was that the temporal pacing framework had helped him envision how product development could be organized in the company. It gave him an
44
idea of how to combine flexibility and control and made choosing and combining practices from existing process models easier. The pictures used to describe the framework also communicated the process intuitively, according to the R&D team leader, who told that a preliminary version of the process—consisting of one page with the picture and some explanatory text—had been shown to customers in October 2001. With the help of the picture the customers had been informed of how the process works at Smartner and how and when the customers have the opportunity to influence product development decisions. According to the R&D team leader this had helped convince customers of the capabilities of Smartner and had raised the internal confidence in the new process. The developers have been in a key role in the process improvement initiative. It started bottom-up with picking ways of working that felt natural to the developers, which have then further evolved. Many of these were inspired by the practices of XP and adapted to suit Smartner’s developers. But the process did not work as expected, until management committed to the process. As agreed by all interviewees, this happened when the management processes for roadmapping, product releases and sprint planning were defined and deployed in M3 and M4, integrating long-term product planning into product development. Only then was management fully committed to the new process. All interviewees thought the incremental approach to process improvement was a success factor. As the chief architect put it: “We learned something new in every sprint and made small adjustments to the process in feedback sessions. I don’t think we could have done it any better or faster.” Of course, the process improvement initiative needed a driving force or champion, who was the R&D team leader. He reported that without extra “pushing”, the process improvement initiative might have stalled completely at several points in time. For example, the early problems with the daily scrum meetings which were mentioned in Section 5.3.1 could have caused the daily scrum practice to be abandoned prematurely, since it later was reported as a success. The effort needed for process improvement might vary significantly from company to company depending on the organizational culture and attitudes towards process improvement, and how familiar the personnel already is with different practices and process models. At Smartner process improvement has been considered important since the company was established, which was mentioned as a success factor by the R&D team leader and contributed to the seemingly small effort used for process improvement, reported in Section 5.3.1.
45
6. Discussion In this chapter we present a summary of the research and draw conclusions based on the results. Then we discuss the contribution and limitations of the research and suggest directions for future work.
6.1 Summary and conclusions This research consisted of constructing a temporal pacing framework for managing software product development based on existing literature on temporal pacing and software product development. The framework was applied in a case company to help the company improve its software product development process. Results on using the improved process were gathered and analyzed. The research problem was: Can temporal pacing be used to help small software product companies turbulent environments better manage their software product development that business decisions and product development decisions can be linked part of the software product development process cost effectively, and if how?
in so as so
Based on the results of the research we can answer the research problem. Temporal pacing could be used to help the case company better manage their software product development. The improved product development process included practices that linked business decision making with product development decision making. The process improvement could also be done with seemingly small effort. The limitations of the research and the framework are discussed in Section 6.3. The constructed temporal pacing framework helped in providing a structure within which to deal with the issues identified in the research problem. Applying the framework included selecting and combining suitable practices for the product development process. The framework consists of four cycles of control spanning different time horizons: strategic release management, release project, iteration, and heartbeat. The cycles help split long-term goals into short-term ones and create a steady pace for product development and decision making based on development progress. Each cycle begins and ends in a control point, where progress is reviewed and decisions are made by sufficient stakeholder representation. Strategic release management deals with the long-term plans for the product and project portfolios of the company and provides an interface between strategic decision making and product development. Strategic release management decides what release projects are launched and how projects and iterations are resourced. Each individual product release is managed as a time-boxed project and dealt with in the release project cycle. Each project is split into time-boxed iterations where partial functionality of the final product release is developed. Daily work is managed and synchronized in heartbeats. The literature study provided a list of main points concerning the software product business that needed to be addressed in the product development process and the constructed framework: 1) analysis and prioritization of multiple stakeholder interests, 2) combining flexibility and control, 3) short time-to-market, 4) linking strategic decision
46
making and product development, and 5) resource allocation management for multiple activities. Based on the literature study, no existing process model could as such be used to cover all the above points, which indicated that the framework was needed. However, the existing models provided examples of practices that can be used for addressing the above points when applying the framework. In Chapter 5 we reported how Smartner—a small software product company in a very turbulent environment—applied the Cycles of Control framework for improving their product development process. The R&D team leader reported that the temporal pacing framework helped him envision how product development could be organized in the company. It also gave him an idea of how to combine flexibility and control and made choosing and combining practices from existing process models easier. Smartner succeeded in combining flexibility and control (point 2 above) in their improved product development process. Flexibility was gained with the monthly sprints, after which new decisions about project scope can be made in planning the following sprint. Control was achieved by mapping the sprints to product release process gates, in which the management team makes informed go/kill decisions based on all the activities of the company (points 4 and 5). A product release process with gates is a long-known best practice reported in new product development literature (Cooper 1994). Smartner also successfully communicated the customer needs of the product and the strategic implications of the development work to the development team through the sprint planning process (points 1, 4 and 5), in which the whole development team and other stakeholders of the product participate. This combined with high-level product roadmapping and sprint demonstrations has given visibility of development plans and progress to the whole organization and facilitated communication between the different organizational units (point 4). Freezing the development scope and the resource allocation (point 5) for a month at a time helped in giving the development team a chance to work on their assigned tasks and created a more relaxed atmosphere. This combined with development practices that give a daily rhythm were the key to more predictable development during sprints. Short time-to-market (point 3) was achieved at Smartner with 3-month release projects, after which a 1-month commercialisation sprint was needed for commercial release. It was also possible to provide a beta version of the product to key partners after a sprint as long as that was considered when planning the release project. The effort required for planning and preparing for the process improvement was 1-2 months by the R&D team leader. The effort used for process improvement during 2002 was 120 hours by the R&D team leader and 49 hours in total by the rest of the development team. These numbers suggest that the process improvement has been cost effective, especially considering that the improved process is used and liked in the company.
6.2 Contribution The theoretical contribution of this research is the constructed temporal pacing framework that combines knowledge from two areas of temporal pacing research, namely strategic management and software engineering. The framework also captures issues that have been deemed important for software product business in a turbulent environment. No
47
existing model as such covers all the identified issues for the context of a small software product company. The practical contribution of this research is the case study and its findings. There is not a lot of empirical evidence of the practical functionality of process models. The case study shows that practices from different process models can be combined to make a coherent whole that works. When Smartner made a list of requirements for its development process and evaluated existing process models against these requirements, none of the evaluated models fulfilled all the requirements. Applying the temporal pacing framework helped in choosing and combining practices from existing process models. The chosen combination of processes and practices got the job done and suited the organization’s culture. This goes to show that one size really does not fit all and is a lesson to all practitioners creating or improving their development process. They should take time to consider the requirements for the process, both from a business and a technical viewpoint, as well as consider cultural issues, in order to be able to adopt and combine processes and practices for their own needs. A risk-based approach to balancing agile and plan-driven methods when tailoring a development strategy has been suggested in, e.g., (Boehm and Turner 2003, Boehm and Port 2001). An approach to integrating business and software development models has been suggested in (Wallin, Ekdahl, and Larsson 2002). Combining process models is not a new idea (see e.g. www.controlchaos.com on combining engineering practices from RUP and XP into Scrum), but our findings contribute to the empirical body of knowledge on the subject. The identified success factors of the process improvement initiative, namely using small improvement steps, getting management commitment, having a champion as the driving force, and involving all the stakeholders are also not a novel finding, see e.g. (Baddoo and Hall 2002). However, the importance of these factors should not be forgotten. We believe the findings of our case study contribute to encouraging practitioners in small software product companies to start improving their software product development process by combining and adopting different processes and practices to suit their own needs. This research can be used as inspiration of how one small company in a turbulent environment has succeeded in their process improvement. The process description could be used by other companies in a similar environment as a good starting point for tailoring their own process and applying the Cycles of Control framework.
6.3 Limitations The limitations of the research approach are discussed in Section 2.2.2. We believe the risk of author bias is reduced with triangulation of data from multiple sources. But at the same time we must acknowledge that the data is incomplete and cannot explain all findings. Therefore we must assume that there are alternative explanations to the results than the ones we have presented. Researcher bias is reduced by the fact that most of the work was conducted by the company on its own without researcher involvement. However, researcher involvement was significant in the planning stages of the improvement initiative, which influenced the implementation. The reported usefulness of the Cycles of Control framework is based on only one case study, which makes generalization of the findings impossible. What we can say is that
48
applying the framework worked in the case company, which is supporting evidence of the practical utility of the framework. However, since we cannot compare applying the framework with applying some other approach that uses temporal pacing, we can only speculate about the usefulness of the framework. We can also speculate that temporal pacing could be used to help improve software product development management in other companies operating in similar environments as the case company. More case studies are needed to further validate these speculations. There are also limitations to the framework and to applying it. The framework as such only provides the user with a pattern of thought that needs to be applied to the user’s context. Applying the Cycles of Control requires knowledge on existing processes and practices that are used to create the software product development process. The personnel in the case company in this research were already familiar with many existing process models and practices, which contributed to the seemingly small effort used for planning and implementing the process improvement initiative. In another organization, the required effort might be significantly higher. However, we believe that one strength of the framework is that is forces the user to consider the context of application. For example, Highsmith speculates that the stage the product is in its life cycle influences choices for the development process (Highsmith 2002). This should and could be considered when applying the CoC, e.g., for setting the pace of development. There are four cycles in the framework, as we have presented it in Chapter 4. Based on our research, we believe that these represent the four time horizons that are at a minimum needed for managing software product development in an organization. This does not mean that another combination of cycles is not possible. For example, Cockburn reported that he has noticed seven cycles in play in most projects: the project, the delivery, the iteration, the work week, the integration period, the work day, and the development episode (Cockburn 2004).
6.4 Future work In the future we intend to gather more case evidence of applying the CoC. From 2002 to 2004 we have worked with three companies, which have all applied the CoC for improving their software product development processes. Data on experiences and results from these companies are gathered and analyzed within the next few months. Through this we hope to learn more about how the CoC can be applied, so we can improve the framework and the instructions for applying it. We have also been working on the SEMS approach, of which the CoC is a central part. An initial version of the approach is summarized in (Rautiainen and Lassenius 2004). Based on our research so far, temporally paced quality assurance can be very challenging, and therefore quality assurance is an area of software engineering we are focusing on in applying the CoC in the future. Another focus area is what we call development portfolio management. We consider managing product development activities as an explicit portfolio crucial to the long-term success of product-oriented software companies. Our tentative approach for this can be found in (Vähäniitty and Rautiainen 2005).
49
References BADDOO, N. and HALL, T., 2002. Motivators of Software Process Improvement: An Analysis of Practitioners' Views. Journal of Systems and Software, 62(2), pp. 85-96. BASILI, V.R. and TURNER, A.J., 1975. Iterative Enhancement: A Practical Technique for Software Development. IEEE Transactions on Software Engineering, 1(4), pp. 390396. BECK, K., 2000. eXtreme Programming eXplained. Addison-Wesley. BOEHM, B. and TURNER, R., 2003. Using Risk to Balance Agile and Plan-Driven Methods. Computer, 36(6), pp. 57-66. BOEHM, B.W., 1988. A Spiral Model of Software Development and Enhancement. IEEE Transactions on Software Engineering, 21(5), pp. 61-72. BOEHM, B. and PORT, D., 2001. Balancing Discipline and Flexibility With the Spiral Model and MBASE. Crosstalk, 14(12), pp. 23-28. BÖRJESSON, A. and MATHIASSEN, L., 2004. Successful Process Implementation. IEEE Software, 21(4), pp. 36-44. BROWN, S.L. and EISENHARDT, K.M., 1998. Competing on the Edge: Strategy as Structured Chaos. Boston: Harvard Business School Press. BROWN, S.L. and EISENHARDT, K.M., 1997. The Art of Continuous Change: Linking Complexity Theory and Time-Paced Evolution in Relentlessly Shifting Organizations. Administrative Science Quarterly, 42(1), pp. 1-34. CARMEL, E. and SAWYER, S., 1998. Packaged Software Development Teams: What Makes Them Different? Information Technology & People, 11(1), pp. 7-19. CHRISTENSEN, C.M. and RAYNOR, M.E., 2003. The Innovator's Solution: Creating and Sustaining Successful Growth. Boston: Harvard Business School Press. COCKBURN, A., 2004. Crystal Clear: A Human-Powered Methodology for Small Teams. Boston: Addison-Wesley. COCKBURN, A., 2002. Agile Software Development. Boston: Addison-Wesley.
50
COOPER, R.G., 1994. Perspective: Third-Generation New Product Processes. Journal of Product Innovation Management, 11(1), pp. 3-14. CUSUMANO, M.A., 2004. The Business of Software. New York: Free Press. CUSUMANO, M.A. and SELBY, R.W., 1995. Microsoft Secrets: How the World's Most Powerful Software Company Creates Technology, Shapes Markets and Manages People. New York: The Free Press. CUSUMANO, M.A. and YOFFIE, D., 1998. Competing on Internet Time: Lessons from Netscape and its Battle with Microsoft. The Free Press. CUSUMANO, M., MACCORMACK, A., KEMERER, C.F. and CRANDALL, B., 2003. Software Development Worldwide: The State of the Practice. IEEE Software, 20(6), pp. 28-34. EISENHARDT, K.M., 1989. Making Fast Strategic Decisions in High-Velocity Environments. Academy of Management Journal, 32(3), pp. 543-576. EISENHARDT, K.M. and BROWN, S.L., 1998. Time Pacing: Competing in Markets that Won't Stand Still. Harvard Business Review, 76(3), pp. 59-69. FOWLER, M. and HIGHSMITH, J., 2001. The Agile Manifesto. Software Development, 9(8), pp. 28-32. FOWLER, M., 2000. Refactoring: Improving the Design of Existing Code. Upper Saddle River: Addison-Wesley. GERSICK, C.J.G., 1994. Pacing Strategic Change: The Case of a New Venture. Academy of Management Journal, 37(1), pp. 9-45. GERSICK, C.J.G., 1989. Marking Time: Predictable Transitions in Task Groups. Academy of Management Journal, 32(2), pp. 274-309. GERSICK, C.J.G., 1988. Time and Transition in Work Teams: Toward a New Model of Group Development. Academy of Management Journal, 31(1), pp. 9-41. GILB, T., 1988. Principles of Software Engineering Management. Wokingham: AddisonWesley. GILB, T., 1981. Evolutionary Development. ACM SIGSOFT Software Engineering Notes, 6(2), p. 17.
51
GILB, T., 1976. Software Metrics. Lund: Studentlitteratur. GLASS, R.L., 2003. Facts and Fallacies of Software Engineering. Boston: AddisonWesley. HIGHSMITH, J.A.,III, 2000. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House Publishing. HIGHSMITH, J., 2002. Agile Software Development Ecosystems. Boston: AddisonWesley. HOCH, D., ROEDING, C., PURKERT, G., LINDNER, S. and MÜLLER, R., 1999. Secrets of Software Success: Management Insights from 100 Software Firms Around the World. Boston: Harvard Business School Press. IDC, 31 March, 2003-last update, Finland's IT sector is poised for a new round of growth [Homepage of Business Software Alliance], [Online]. Available: http://www.bsa.org/idcstudy/pdfs/Finland.pdf [10/14, 2004]. KROLL, P. and KRUCHTEN, P., 2003. The Rational Unified Process Made Easy: A Practitioner's Guide to the RUP. Boston: Addison-Wesley. KRUCHTEN, P., 2000. The Rational Unified Process: An Introduction. Second edn. Boston: Addison-Wesley. LARMAN, G. and BASILI, V.R., 2003. Iterative and Incremental Development: A Brief History. Computer, 36(6), pp. 47-56. MACCORMACK, A., VERGANTI, R. and IANSITI, M., 2001. Developing Products on Internet Time: The Anatomy of a Flexible Development Process. Engineering Management Review, 29(2), pp. 90-104. MACNEALY, M.S., 1997. Toward Better Case Study Research. IEEE Transactions on Professional Communication, 40(3), pp. 182-196. MARTIN, J., 1991. Rapid Application Development. New York: Macmillan Publishing Company. MCCONNELL, S., 1996. Rapid Development: Taming Wild Software Schedules. Redmond: Microsoft Press. MILES, M.B. and HUBERMAN, M.A., 1994. Qualitative Data Analysis: An Expanded Sourcebook. 2nd edn. Thousand Oaks: SAGE Publications.
52
MINTZBERG, H. and WATERS, J.A., 1982. Tracking Strategy in an Entrepreneurial Firm. Academy of Management Journal, 25(3), pp. 465-499. NAMBISAN, S., 2001. Why Service Businesses are Not Product Businesses. MIT Sloan Management Review, 43(4), pp. 72-80. PALMER, S.R. and FELSING, J.M., 2002. A Practical Guide to Feature-Driven Development. Prentice Hall PTR. POPPENDIECK, M. and POPPENDIECK, T., 2003. Lean Software Development: An Agile Toolkit. Boston: Addison-Wesley. RAUTIAINEN, K. and LASSENIUS, C. (eds), 2004. Pacing Software Product Development: A Framework and Practical Implementation Guidelines. Technical Report 3. Espoo: Helsinki University of Technology, Software Business and Engineering Institute. RAUTIAINEN, K., LASSENIUS, C. and SULONEN, R., 2002. 4CC: A Framework for Managing Software Product Development. Engineering Management Journal, 14(2), pp. 27-32. RAUTIAINEN, K., LASSENIUS, C., VÄHÄNIITTY, J., VANHANEN, J. and PYHÄJÄRVI, M., 2002. A Tentative Framework for Managing Software Product Development in Small Companies, Proceedings of the Thirty-Third Annual Hawaii International Conference on System Sciences, January 4-7 2002, pp. 251-260. RAUTIAINEN, K., VUORNOS, L. and LASSENIUS, C., 2003. An Experience in Integrating Strategic Product Planning and Agile Software Development Practices, Proceedings of 2003 International Symposium on Empirical Software Engineering, 30.9.1.10. 2003, pp. 28-37. ROYCE, W.W., 1970. Managing the Development of Large Software Systems: Concepts and Techniques, Proceedings of Wescon, August 1970, pp. 1-9. SALLINEN, S., 2002. Development of Industrial Software Supplier Firms in the ICT Cluster: An Analysis of Firm Types, Technological Change and Capability Development, University of Oulu. SCHACH, S.R., 2002. Object-Oriented and Classical Software Engineering. Fifth edn. Boston: McGraw-Hill. SCHWABER, K. and BEEDLE, M., 2002. Agile software development with Scrum. Upper Saddle River: Prentice Hall.
53
SOMMERVILLE, I., 1996. Software Engineering. Fifth edn. Wokingham: AddisonWesley. STAPLETON, J., 1997. Dynamic Systems Development Method. Harlow: AddisonWesley. SUSMAN, G.I. and EVERED, R.D., 1978. An Assessment of the Scientific Merits of Action Research. Administrative Science Quarterly, 23(4), pp. 582-603. THE STANDISH GROUP, 1995. The CHAOS Report. Published Report. The Standish Group International, Inc. THOMKE, S., HIPPEL, E.V. and FRANKE, R., 1998. Modes of Experimentation: An Innovation Process--and Competitive--Variable. Research Policy, 27(3), pp. 315-332. TUSHMAN, M.L. and ANDERSON, P., 1986. Technological Discontinuities and Organizational Environments. Administrative Science Quarterly, 31(3), pp. 439-465. VÄHÄNIITTY, J. and RAUTIAINEN, K., 2005. Towards an Approach for Managing the Development Portfolio in Small Product-Oriented Software Companies, Proceedings of the 38th Hawaii International Conference on System Sciences, January 3-6 2005, forthcoming. VUORNOS, L., 2002. Software Process Improvement in a Small High-Tech Company: Case Smartner Information Systems Ltd, Helsinki University of Technology. WALLIN, C., EKDAHL, F. and LARSSON, S., 2002. Integrating Business and Software Development Models. IEEE Software, 19(6), pp. 28-33. WONG, C., 1984. A Successful Software Development. IEEE Transactions on Software Engineering, 10(6), pp. 714-727. YIN, R.K., 1994. Case Study Research: Design and Methods. Second edn. London: SAGE Publications.
54
