also known as the creator of the Ruby on Rails web application development ..... The system-level design phase includes the definition of the product architecture and the ...... software in the data centers that provide those services (Armbrust et al., 2010). ... the audience on purpose, as a kind of affordable marketing strategy.
A Scientific Review of the “Getting Real” Software Development Approach
University of Oulu Department of Information Processing Science Master‟s Thesis Jari Sarja August 31, 2011
2
Abstract The small American bootstrapped software developing company called 37signals is a significant phenomenon in many ways. The company has launched many successful commercial web applications, for instance Basecamp and Campfire. The company is also known as the creator of the Ruby on Rails web application development framework. The company has its own unique way of business thinking, and the people of the company do not have any growth target. The people of the company also have their own way of thinking about the software developing process. They have named it Getting Real. Getting Real is not described as a developing method; rather, it is a philosophy or approach behind the development activities. It has confluence with agile methods, but unlike agile methods, in Getting Real the nature of the final product is also strongly emphasized. The success of the company has proven that there is some effectiveness in the Getting Real approach. Therefore, the aim of this research is to find out whether the Getting Real approach can be supported by previous scientific research. What is noteworthy is that according to the people of the company, the Getting Real approach is based on their practical experience and does not have any academic background. Nevertheless, the key men of the company have been cited a few dozen times in academic researches and articles. We think it is important to know more about the company itself in order to get a better understanding of the Getting Real approach. This research is divided into two parts: the purpose of the first part is to study the company behind the researched approach, and the second part is aimed at finding an answer to the research question: Can the Getting Real approach be supported scientifically by previous research? The research method in this study is conceptual analysis. It is done by comparing empirical source material with scientific literature, the purpose being to analyze common issues. The conclusion of this research is that the unique business thinking models and the Getting Real principles already existed to some extent, and that they are supported by previous research. However, the researched company has arrived at similar conclusions in their practical work and collected in a successful way the most important models, which seem to work well with small software developing companies. Keywords Software development, agile methods, small business, the Getting Real approach
3
Foreword The researched company has developed its successful tools and applications originally for its own use. Equally, this thesis came into being from my own private research, which was started months before the idea of a thesis was born. Unlike in many cases, writing this thesis has not been a mandatory task for me, and I have not experienced much pain while writing it. Instead, I have experienced nice moments refreshing my way of thinking. I want to thank the people of the researched company, even though we do not know each other. I gratefully acknowledge my supervisor, Professor Samuli Saukkonen, who has given me great support and instructions during the entire process. I have also greatly enjoyed our friendly discussions. I also want to thank Adjunct Professor Raija Halonen for the quick responses to my questions and all the support and ass-kicking she has given me. I also want to thank M.Sc. Jani Sassali for updating my poor information retrieval skills to this millennium.
Jari Sarja Oulu, August 10, 2011
4
Contents Abstract ............................................................................................................................. 2 Foreword ........................................................................................................................... 3 Contents ............................................................................................................................ 4 1. Introduction .................................................................................................................. 5 2. Agile Software Development Methods ........................................................................ 8 2.1 Traditional Software Development Processes ..................................................... 8 2.1.1 The Waterfall Model ................................................................................ 9 2.1.2 The Stage-Gate Model ............................................................................ 10 2.1.3 Criticism ................................................................................................. 11 2.2 Agile Methods .................................................................................................... 12 2.2.1 Extreme Programming............................................................................ 14 2.2.2 Scrum .................................................................................................... 15 2.2.3 Crystal Methods ...................................................................................... 17 2.2.4 Feature Driven Development .................................................................... 18 3. Research Methods ...................................................................................................... 20 3.1 Systematic Review ............................................................................................. 22 3.2 Deconstruction ................................................................................................... 22 3.3 Transcription ...................................................................................................... 23 4. 37signals – the Company behind the Getting Real Approach .................................... 25 4.1 The Audience of the Company .......................................................................... 26 4.2 The 37signals Products ...................................................................................... 27 4.2.1 Ruby on Rails ......................................................................................... 28 4.3 A Unique Way of Business Thinking ................................................................ 29 4.3.1 Funding and Pricing ............................................................................... 29 4.3.2 Software Characteristics ......................................................................... 32 4.3.3 Everyday Working Methods ................................................................... 34 5. The Getting Real Approach ........................................................................................ 37 5.1 Getting Real – Principle 1 .................................................................................. 39 5.2 Getting Real – Principle 2 .................................................................................. 40 5.2.1 Less Software ......................................................................................... 40 5.2.2 Less Features .......................................................................................... 41 5.3 Getting Real – Principle 3 .................................................................................. 42 5.4 Getting Real – Principle 4 .................................................................................. 44 5.5 Getting Real – Principle 5 .................................................................................. 47 5.6 Getting Real – Principle 6 .................................................................................. 49 6. Conclusions ................................................................................................................ 51 6.1 37signals – the Researched Company................................................................ 51 6.2 The Getting Real Software Development Approach ......................................... 52 6.3 Discussion .......................................................................................................... 54 References ....................................................................................................................... 56
5
1.
Introduction
This research identifies the scientific evidence for the software development philosophy or approach called Getting Real. The Getting Real approach was created by an American company called 37signals. The key men1 of the 37signals have created the Getting Real approach based on their own experience about developing software applications and commercializing them successfully. The key men of the 37signals have written two books about their way of thinking about software development (Getting Real)2 and creating a profitable business in the Internet environment (Rework). These two books, Getting Real (2006) and Rework (2010), are important sources in this research. In Rework, the authors write the following about the book: “This book isn‟t based on academic theories. It‟s based on our experience. We‟ve been in business for more than ten years. Along the way, we‟ve seen two recessions, one burst bubble, business-model shifts, and doom-and-gloom predictions come and go – and we‟ve remained profitable through it all.” (Fried & Heinemeier Hansson, 2010, p. 3.) The same principle applies to the Getting Real book. Consequently, these two issues make the Getting Real approach an interesting research subject: the non-academic starting point and the proven results of successful proceedings in practical cases. I call Getting Real an approach rather than a method, technique or procedure. Getting Real is not a described or documented development method. It is a range of principles based on the good practices of the 37signals company. The authors have also called Getting Real a movement (Getting Real, 2011). The Getting Real approach has confluence with agile methods. What is noteworthy is that that 37signals is a small bootstrapped company without any expanding purpose. Regardless of that, they have gathered an active audience that follows the company. Widespread newspapers and magazines, such as The New York Times, Time, and The Wall Street Journal, have written stories about the key men of the company, and they have been crowd-pleasing speakers in different events. It can be said that the outcome of the company is much wider than just the products they have developed; it consist of a different way of processing development, business thinking, and by-products. The company seems to enjoy a strong charisma of lonely riders, or even a little bit rebellious pioneers. Still two more issues exist, which make Getting Real an interesting research subject: according to prominent databases, the key men of the company and their books have been cited a few dozen times in academic researches and articles, although they do not
The definition “key men” refers to Mr. Jason Fried and/or Mr. David Heinemeier Hansson, who are the partners of 37signals and co-writers of the books Getting Real and Rework. The definition is used when it is not known which partner/co-writer to cite, or when citing both. 1
2
The Internet version of the book Getting Real does not have page numbering. Citations to this book are in the form “(Fried & Heinemeier Hansson, 2006)”.
6
have an academic background. Moreover, the Getting Real approach has not been the subject of a research before in a comprehensive way. From a practical point of view, this research may establish if the studied development and business models – or part of them – are useful benchmarking targets to other business owners. From a theoretical point of view, the purpose of this research is to find out if there exists any scientific evidence for the Getting Real software development approach and, secondarily, for the business models. The main contribution is to connect the proven successful small business (or small organization) development and business ways to a scientific context. Since the Getting Real approach has not been researched before in a comprehensive way and it has confluence with agile methods, the studied previous research material mainly concerns agile methodologies. Abrahamsson, Salo, Ronkainen, and Warsta (2002) have observed that agile methodologies have evoked a substantial amount of literature. The Agile Manifesto (2011) is an important source in this research because it has been the starting point for agile definitions, rules, principles, and it is cited in most literature concerning agile methodologies. The influential persons behind the Agile Manifesto are also notable book and article writers. The other previous research materials mainly handle software development processes, small business research, and supportive case researches. It can be concluded that agile methodologies, software development and business models have been widely researched, but the specific research target, the Getting Real approach, might need more research. The aim of this research is to find out if there exists scientific evidence for the principles of the Getting Real approach. The key men of the researched company have explained that the Getting Real approach is based on their experience of best practices. They have created a provenly successful business following an approach based on their best practices. Therefore, the interesting research question is: Can the Getting Real approach be supported scientifically by previous research? The research method in this study is conceptual analysis. Järvinen (2004) describes the nature of conceptual analysis by setting the question: “What is a part of reality according to a certain theory, model, or framework?” This research applies conceptual analysis in the contrary manner; it asks what is a part of theory according to certain practical activities? The data has been collected from many different sources: books, magazines, the Internet, scientific papers, and video clips. The collected data has been analyzed using the systematic review, deconstruction, and transcription methods. Systematic review can be undertaken to examine the extent to which empirical evidence supports theoretical hypotheses, or even to assists the generation of new hypotheses (Kitchenham, 2004). This is a very important aspect in this study, since the main research activity is to compare the empirical material to previous researches. Deconstruction is a means for interpreting different texts, and it is based on semiotics. Transcription means converting the source text to another format, for instance from spoken language to a written form. The first section (Chapter 2) presents the previous studies on agile methodologies. An important part of this section is the description of the Agile Manifesto. The Agile Manifesto has been defined by the influential persons behind the separate agile methodologies, and it is cited in most literature concerning agile methodologies. Since there exist numerous agile methods (Abrahamsson et al., 2002; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003), we have chosen four of them for general review and
7
introduction: Extreme Programming, Scrum, Crystal Methods, and Feature-Driven Development. The research and data collection methods are introduced in the second section (Chapter 3). The section includes short descriptions of the principles of conceptual analysis, systematic review, deconstruction, and transcription. The third section (Chapter 4) presents the company itself. The background information of the company helps to deepen understanding of the Getting Real approach, which is the research target. Without knowing the company behind the approach, it would be difficult to gain an understanding of the approach. The presented issues are those that appear time and again when the company is spoken about. These issues are the big audience, the nature of the products and the unique business models of the company. The main purpose of the section is to present the company, but some support evidence from the previous researches is used as well. In the fourth section (Chapter 5), we describe six separate Getting Real software development principles. Following each description, explanatory comments and case justifications by the 37signals people will be included. We also present previous research results that support the principle – if there are any. A conclusion is drawn on the separate principle and its possible scientific support at the end of each sub-chapter. The conclusions of this research are summarized in the fifth section (Chapter 6). The answer to the research question – Can the Getting Real approach be supported scientifically by previous research? – is analyzed thoroughly in this section.
8
2.
Agile Software Development Methods
Different kinds of software development methods are introduced in this literature review. Since the development methods and models have been thoroughly researched, described and documented – unlike the research target of this study – the review provides a good possibility to view the similarities and differences between the documented methods and the research target. The manufacturing business is much older than the software business. Therefore it is clear that manufacturing development processes were developed much earlier. The first chapter shortly presents a manufacturing development model called the Generic Development Process and two traditional software development processes based on it. The second chapter concentrates on agile software development processes, which have many points of comparison with the research target. Nevertheless, the traditional methods and agile methods are not alternatives to one another, and both method types are indispensable. Software projects are different in size and complexity point of views, which is why both process-oriented and agile methods are needed (McCayley, 2001).
2.1 Traditional Software Development Processes Traditional software development processes are based on the Generic Development Process, which is widely used in various manufacturing business lines. “A [generic] product development process is the sequence of steps or activities which an enterprise employs to conceive, design, and commercialize a product. Many of these steps and activities are intellectual and organizational rather than physical.” (Ulrich & Eppinger, 2008, p. 12.) Ulrich and Eppinger (2008, pp. 13-15) describe the Generic Development Process as a six-step process, which consists of the planning, concept development, system-level design, detail design, testing and refinement and production ramp-up phases. The Generic Development Process is illustrated in Figure 1.
Phase 0 Planning
Phase 1 Concept development
Phase 2 System level design
Phase 3 Detail design
Phase 4 Testing and refirement
Phase 5 Production Ramp-Up
Figure 1. Generic Development Process (Ulrich & Eppinger, 2008, p. 9)
According to Ulrich and Eppinger (2008, pp.13-15), the key actions and outputs of the phases are the following:
9
The planning activity is often referred to as „phase zero‟ since it precedes the project approval and launch of the actual product development process. The output of the planning phase is the project mission statement, which specifies the target market for the product, business goals, key assumptions, and constraints. In the concept development phase, alternative product concepts are generated and evaluated, and one or more concepts are selected for further development and testing. A concept is a description of the form, function, and features of a product and is usually accompanied by a set of specifications, an analysis of competitive products, and an economic justification of the project. The system-level design phase includes the definition of the product architecture and the decomposition of the product into subsystems and components. The outputs of the phase are a geometric layout, functional specifications, and a flow chart for the final assembly process. The detail design phase includes the complete specification of the geometry, materials, and tolerances. The output of this phase is the control documentation for the product. Two critical issues in the detail design phase are product cost and robust performance. The testing and refinement phase includes the construction and evaluation of preproduction versions (prototypes) of the product. In the production ramp-up phase the product is made using the intended production system. The output of the phase is to transit the product to mass production and product launch. Software business is a much newer business line compared to manufacturing business lines. That is why traditional software development methods are based on the Generic Development Process. There are both similarities and differences between the processes and viewpoints. According Nambisan and Wilemon (2000), the new product development (NPD)3 process research shows how processes can be better managed by influencing people, process, and technology dimensions. The software development process research has focused on development methodologies and techniques (e.g. object-oriented programming) and the use of technology to support the development process.
2.1.1 The Waterfall Model The waterfall model was originally conceived by Winston Royce in 1970. It has become the industrial standard for software development (ISO/IEC 12207 Software Life Cycle Processes). The waterfall model is illustrated in Figure 2. “The successive processes of the waterfall model are: planning, requirements analysis, software design, coding, integration and testing, and installation. After these comes the actual use of the system – operation and maintenance” (Molin-Juustila, 2001.)
3
The new product development process (NPD) here means the same thing as the [generic] product development process created by Ulrich & Eppinger (2008).
10
Planning
Requirements analysis
Software design
Coding
Integration and testing
Installation
Figure 2. The waterfall model (Molin-Juustila, 2001)
“These stages together are frequently referred to simply as „conventional systems analysis‟, „traditional system analysis‟, „the systems development life-cycle‟ or the „waterfall model‟. The term „life-cycle‟ is well chosen as the process was iterative and, by the time the review stage came, the system was frequently found to be inadequate and the process started again with a new feasibility study” (Avison & Fitzgerald, 1991, p. 13.) Fuggetta (2000) explains the transition from one phase to another: “The waterfall model suggests that a specific phase should be started only when the deliverables (outputs) of the previous one have been completed.”
2.1.2 The Stage-Gate Model The Stage-Gate model was conceived by Dr. Cooper and Dr. Scott (Stage-Gate, 2011). The idea of the Stage-Gate process comes from the manufacturing business. Cooper (1990) compares the Stage-Gate model to the production process and describes it from a quality-related point of view. He points out that to improve the quality of output from the process the focus has to be laid on the process itself by removing the variances of the process. “A process is sub-divided into a number of stages or work stations. Between each work station or stage, there is a quality checkpoint or gate. A set of deliverables is specified for each gate, as is a set of quality criteria that the product must pass before moving to the next work station. The stages are where the work is done; the gates ensure that the quality is sufficient. The entrance to each stage is a gate; these gates control the process, much like quality control checkpoints control the production process.” (Cooper, 1990.) The Stage-Gate model is illustrated in Figure 3.
Idea
Gate 1
Stage 1
Gate 2
Stage 2
Gate 3
Stage 3
Figure 3. The Stage-Gate model (Cooper, 1990)
The more flexible model of product development has made it possible to make the project development time shorter, to get earlier feedback from the market, and to make changes to the product and its features later in the process. The more flexible development models are characterized by overlapping development stages. They create the possibility to generate and respond to new information for as long as possible during development (MacCormack, Verganti, & Iansiti, 2001).
11
The more flexible model of product development is illustrated in Figure 4.
First Concept New information integration frozen
Concept development
Detailed design
System-level test
Feedback on performance
Figure 4. A more flexible model of product development (MacCormack et al., 2001)
2.1.3 Criticism The most important reason for criticism of traditional software development processes is the inflexibility for changes. According to Cooper (1990), the structure should minimize the changes, since MacCormack – the initiator of the flexible development process – argues that traditional development processes are not working in dynamic environment: “Effective projects are characterized by a structure that minimizes changes to the product design once the execution stage has begun (Cooper, 1990). It has been argued that traditional development processes are effective only in stable environments, but their value has been questioned in uncertain and dynamic environments.” (MacCormack et al., 2001). Nerur, Mahapatra, and Mangalaraj (2005) share the idea that traditional development processes are rigid: “Organizations need information systems that constantly evolve to meet their changing requirements – but the traditional, plan-driven software development methodologies lack the flexibility to dynamically adjust the development process.” Avison and Fitzgerald (1991, p. 21.) list the reasons for criticisms of the systems development approach: -
Failure to meet the needs of management Unambitious system design Instability Inflexibility User satisfaction Problems with documentation Incomplete systems Application backlog Maintenance workload.
Abrahamsson et al. (2002) share the claims of previous researchers (e.g. Parnas and Clements, 1986; Nandhagumar and Avison, 1999; Truex et al., 2000) that traditional development methods are control-oriented, too mechanistic to use in detail, too ideal
12
and hypothetical, and this provides a background for the emergence of agile software development methods. McCayley (2001) does not totally reject the traditional software development processes, but she emphasizes that both [traditional and agile] methods are needed. The philosophy behind the traditional development methods is that all requirements of the project are locked and specifications frozen before the implementation starts. Because this approach is not always possible and late specification changes can be possible, developers need flexible, adaptable, and agile methods.
2.2 Agile Methods The major idea behind agile methods is to speed up the development time and to allow later changes to requirements. The agile methods present an attempt to offer an answer to the eager business community that is asking faster and nimbler software development processes. This takes place especially in the Internet software industry and mobile application environment (Abrahamsson et al., 2002.) Abrahamsson et al. (2003) have noticed that the number of different agile methods has exploded in the past years and is not showing any signs of ceasing. Therefore it is difficult to find a common definition for an agile method. Diana Strode (2006) has carried out a comparative analysis in order to answer her research question: “What is an agile method?” She has analyzed seven separate agile methods chosen from the paper written by Abrahamsson et al. (2003) by splitting her research question into six subquestions. Based on her research, she has defined an agile method in this way: “An agile method is a software development methodology designed for the management and support of iterative and incremental development of business systems in environments where change is constant. Agile methods use software development techniques that enhance teamwork in small empowered teams and support active customer involvement. An agile method is designed to produce working software early, using communication, feedback, learning and frequent meetings in preference to than modelling and documentation. Agile methods adapt existing software development techniques to achieve these goals” (Strode 2006.) The Agile Manifesto includes general rules and principles for agile methods. It was signed by seventeen persons influential in the agile field at the Snowbird ski resort in Utah, US, in 2001. (Agile Manifesto, 2011; Cockburn, 2002, p. 213; Lindstrom & Jeffries, 2004). The people behind the Agile Manifesto were individuals who had published separate software development methods with similar characteristics. All these methods are based on best practice experiences and evolutionary development practices focusing on early delivery and quality of software. (Strode, 2006.)
13
The common rules in the Agile Manifesto are: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
The Agile Manifesto further includes twelve explicit principles. These twelve principles of agile software are: -
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
-
Welcome changing requirements, even late in development. Agile processes harness change for the customer‟s competitive advantage.
-
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
-
Business people and developers must work together daily throughout the project.
-
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
-
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
-
Working software is the primary measure of progress.
-
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
-
Continuous attention to technical excellence and good design enhances agility.
-
Simplicity – the art of maximizing the amount of work not done – is essential.
-
The best architectures, requirements, and designs emerge from self-organizing teams.
-
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
(Agile Manifesto, 2011.) The Agile Manifesto (2011) is an important source in this research because it has been a starting point for agile definitions, and it is cited in most literature concerning agile
14
methodologies. For example, searching with the words “agile manifesto” in the Google search engine gave 139 000 results and in Google Scholar 2450 results on May 6, 2011. As mentioned, there exists numerous different agile methods. As explanatory examples, we have selected four agile methods for a short introduction, mainly according to Abrahamsson et al. (2002; 2003) and Schwaber and Sutherland (2010). These four methods are Extreme Programming, Scrum, Crystal Methods, and Feature Driven Development.
2.2.1 Extreme Programming Lindstrom and Jeffries (2004) argue that Extreme Programming (XP) is the most widely used agile methodology. According to them, XP shares the values of the Agile Manifesto, but it goes further than some other agile methods that specify a simple set of practices. This is noteworthy, since many other agile methodologies resemble approaches and do not describe the practical processes. Extreme Programming is a software development method based on the values of simplicity, communication, feedback, and courage. “It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and tune the practices to their unique situation” (Lindstrom & Jeffries, 2004.) “XP is a lightweight software development process for small teams dealing with vague or rapidly changing requirements. XP breaks with a number of traditional software engineering practices.” The need for documentation is minimized; the only documentation is the source code. There is no specification at all, only the executable test cases, which are written before the code development and serve as a substitute. The design, implementation, and test phases are not separated but done together in small increments. There is an explicit prohibition against design for change, and there are no normal reviews or inspections in the process (Müller & Tichy, 2001.) XP is a set of known software development practises. Depending on the source, the amounts of the practices vary a little. According to Beck (1999) and Abrahamsson et al. (2003), the main characteristics are short iterations with small releases and rapid feedback, close customer participation, constant communication and coordination, continuous refactoring, continuous integration and testing, collective code ownership, and pair programming. Also some organizational practices are mentioned, such as a maximum 40-hour working week and open work space. Lindstrom and Jeffries (2004) even present a layout of work stations which enable maximized communication and pair programming. There are different roles in the XP process for different tasks and purposes. These roles are the following: Programmer: Programmers write tests and keep the program code as simple and definite as possible. The first issue making XP successful is to communicate and coordinate with other programmers and team members. Customer: The customer writes the stories and functional tests, and decides when each requirement is satisfied. The customer sets the implementation priority for the requirements.
15
Tester: Testers help the customer write functional tests. They run functional tests regularly, broadcast test results and maintain testing tools. Tracker: Tracker gives feedback in XP. He traces the estimates made by the team and gives feedback on how accurate they are in order to improve future estimations. He also traces the progress of each iteration and evaluates whether the goal is reachable within the given resource and time constraints or if any changes are needed for the process. Coach: Coach is the person responsible for the process as a whole. A sound understanding of XP is important in this role, enabling the coach to guide the other team members in following the process. Consultant: Consultant is an external member possessing the specific technical knowledge needed. The consultant guides the team in solving their specific problems. Manager: Manager makes the decisions. In order to be able to do this, he communicates with the project team to determine the current situation, and to distinguish any difficulties or deficiencies in the process. (Beck, 1999; Abrahamsson et al., 2002, pp. 21-22.) “XP promises to reduce project risk, improve responsiveness to business changes, improve productivity, throughout the life of a system, and add fun to building software in teams.” (Beck, 1999).
2.2.2 Scrum The initiators of the Scrum framework, Schwaber and Sutherland (2010), have explained that Scrum already has a long history in the software development, and it has been used to develop complex products already in the early 1990s. “Scrum is based on industry-accepted best practices, used and proven for decades.” Schwaber and Sutherland (2010) point out that Scrum is not a process or product building technique, rather a framework which makes it possible to employ various processes and techniques. “The role of Scrum is to surface the relative efficacy of your development practices so that you can improve upon them while providing a framework within which complex products can be developed.” Abrahamsson et al. (2002) have noted that Scrum does not define any specific software development techniques for the implementation phase, instead it focuses on how the team members should function in order to develop the system in a dynamic and constantly changing environment. Schwaber and Sutherland (2010) emphasize that the Scrum approach has been developed for managing the system development process: “It is an empirical approach applying the ideas of industrial process control theory to systems development resulting in an approach that reintroduces the ideas of flexibility, adaptability and productivity.” Scrum is based on empirical process control theory and it employs an iterativeincremental approach to optimize predictability and control risk. The implementation of empirical process control has three legs, namely transparency, inspection, and adaption. Schwaber and Sutherland (2010) define the three fulcrum of the Scrum process control as the follows: “Transparency ensures that aspects of the process that affect the outcome must be visible to those managing the outcomes. Not only must these aspects be transparent, but
16
also what is being seen must be known. That is, when someone inspecting a process believes that something is done; it must be equivalent to their definition of done.” “The various aspects of the process must be inspected frequently enough so that unacceptable variances in the process can be detected. The frequency of inspection has to take into consideration that all processes are changed by the act of inspection.” “There are three points for inspection and adaptation in Scrum. The Daily Scrum meeting is used to inspect progress toward the Sprint goal, and to make adaptations that optimize the value of the next work day. In addition, the Sprint Review and Planning meetings are used to inspect progress toward the Release Goal and to make adaptations that optimize the value of the next Sprint. Finally, the Sprint Retrospective is used to review the past Sprint and determine what adaptations will make the next Sprint more productive, fulfilling, and enjoyable.” The Scrum approach includes three phases; pre-game phase, development phase, and post-game phase. The pre-game phase is divided into two sub-phases: planning and architecture/high level design. In the planning phase, a product backlog list is created containing all the requirements that are known at that time. The requirements are prioritized and their implementation is estimated. In the planning phase, the definition of project resources and needs is also approved by the management. In the architecture phase, the high level design of the system and the architecture are planned based on the current items in the product backlog. In the development phase, different environmental and technical variables (e.g. time frame, requirements, resources, and development methods) are identified in Scrum; they may change during the process and are observed and controlled through the practices during the sprints. “Each Sprint includes the traditional phases of software development: requirements, analysis, design, evolution, and delivery.” The time frame for one sprint can be from one week to one month, and there can be for example three to eight sprints in one system development process before the system is ready for distribution. In the post-game phase, all requirements are completed and all tasks including integration, system testing, and documentation will be finalized. (Schwaber & Beedle, 2002; Abrahamsson et al., 2002.) There are three different roles in the Scrum team; the Scrum Master, the Product Owner, and the Team. The Scrum Master is responsible for ensuring that the Scrum team follows the Scrum values, practices, and rules. The Scrum Master is also a kind of supporting person for the team by helping, teaching, coaching, and leading it. The Product Owner is the only person responsible for the product backlog and the working performance of the team. He/She is also responsible for the task priorities. The team consists of members with cross-functional skills. The skill the team members share is the skill of addressing a requirement and turning it into a usable product (Schwaber & Sutherland, 2010.) Abrahamsson et al. (2002) also introduce two more roles to the Scrum team; the Customer and the Management. “The Customer participates in the tasks related to Product backlog items for the system being developed or enhanced. The Management is in charge of final decision making, along with the charters, standards and conventions to be followed in the project. Management also participates in the setting of goals and requirements. For example, the management is involved in selecting the Product Owner, gauging the progress and reducing the Product backlog with Scrum Master” (Abrahamsson et al., 2002.)
17
2.2.3 Crystal Methods According to the definition by Abrahamsson et al. (2002), Crystal methodologies include several different methodologies for selecting the best methodology for each individual project. They also include principles for tailoring them to fit varying circumstances of different project environments. The different Crystal methodologies are also called family members. The Crystal family members have some common values and principles, as well as some dissimilarities. Cockburn (2002, p. 197) describes the Crystal family members as follows: “Crystal is the family name for the methodologies. As with geological crystals, each has a different color and hardness, corresponding to the project size and criticality: Clear, Yellow, Orange, Orange Web, Red, Magenta, Blue, and so on.” The purpose in Crystal methodologies is to choose an appropriate color based on project size and criticality; the darker the color, the heavier the methodology. Abrahamsson et al. (2002) explain that larger projects need more coordination and heavier methodologies than smaller ones. That means that the development of more critical systems needs heavier control than smaller systems. Each methodology is people- and communication-centered, is adjusted to fit in a particular setting, and works from the project tolerance level and the bottleneck activities towards an answer that matches the project ecosystem (Cockburn, 2002, p. 197). The people- and communication-centered approach means that tools, work products, and processes are there only for supporting the human component (Cockburn, 2002, p. 201). Figure 5 presents a simplified model of Cockburn‟s Crystal family methodologies corresponding to project size and criticality. Criticality of the system
Clear
Figure 5.
Yellow
Orange
Red
Size of the project
Dimensions of Crystal methodologies (Cockburn, 2002, p. 200).
“The core Crystal philosophy is that software development is usefully viewed as a cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game. Two consequences of that philosophy are that different projects need to be run differently, and the amount of modeling and communication that people need to do is just the amount they need to jointly move the game forward.” (Cockburn, 2002, p. 201.)
18
According to Cockburn (2002, p. 201), the two common rules in the Crystal methods are: -
The project must use incremental development, with increments of four months or less (and a strong preference for one-to-three-month increments).
-
The team must hold pre- and post-increment reflection workshops (with a strong preference for holding mid-increment reflection workshops as well).
The two basic techniques are: -
The methodology-tuning technique: using project interviews and a team workshop to convert a basic methodology to a starter methodology for the project.
-
The technique used to hold the reflection workshop.
Crystal methods are open and can be integrated with other agile methodologies, for instance with Scrum and Extreme Programming (Cockburn, 2002, p. 206; Abrahamsson et al 2003).
2.2.4 Feature Driven Development Like many agile methods, Feature Driven Development (FDD) is an agile and adaptive approach for developing systems, which embodies iterative development with best practices in the industry. FDD is also called an approach rather than a process, and it emphasizes quality aspects throughout the process and includes frequent and actual deliveries. (Abrahamsson et al., 2002.) “FDD is a straightforward approach to producing systems that uses simple, easy-tounderstand and easy-to-implement methods; problem-solving techniques and reporting guidelines providing every stakeholder of a project with the information they need to make sound, timely decisions.” (Palmer & Felsing, 2002, xix.) According to Palmer and Felsing (2002), the FDD approach is: -
Highly iterative
-
Emphasizing quality at each step
-
Delivering frequent, tangible, working results
-
Providing accurate and meaningful progress and status information with the minimum of overhead and disruption for the developers
-
(Is liked by clients, managers, and developers).
FDD is a product development process, which consists of five sequential processes from planning to delivery. The Design and Build are the iterative part of the process, and it supports the agile development principle of late changes in requirements and business needs. The typical feature iteration period lasts one to three weeks (Abrahamsson et al. 2002.)
19
The five processes of FDD are Develop an Overall Model, Build a Features Lists, Plan by Feature, Design by Feature, and Build by Feature (Palmer & Felsing, 2002, p. 57). The main outputs of the five processes according to Palmer and Felsing (2002) and Abrahamsson et al. (2002;) are: -
Develop an Overall Model: documented requirements (e.g. use cases) and functional specifications
-
Build a Features Lists: The major feature sets defined according to client-valued functions. The feature lists under each major feature set.
-
Plan by Feature: A high-level plan with feature priorities. A schedule and milestones for major feature sets.
-
Design by Feature and Build by Feature: The design by feature and build by feature processes are iterative procedures, during which the selected features are produced. These procedures include e.g. design inspection, coding, unit testing, integration, and code inspection. After a successful iteration, the features are completed.
According to Abrahamsson et al. (2002), there are no reliable success stories or failure reports on using FDD. Palmer and Felsing (2002, p. xxi) explain that FDD was derived from a large baking software development project in Singapore. They also refer to the development of complex software systems (2002, p. 3), and therefore it can be said that the FDD method is valuable for large and complex software development projects.
20
3.
Research Methods
The selected research method in this study is conceptual analysis. Conceptual analysis is a non-empiric research method, which can be used as a basis for empirical research or as an independent research approach (Puusa, 2008). The roots of conceptual analysis are in the science of philosophy. The objective of conceptual analysis is to gain knowledge from previous researches. However, this research also includes an empirical side, the source material of the researched company, which is compared with scientific researches. According to Sloman (1978, p. 69), recent analysts as well as previous philosophers define the main function of the conceptual analysis to be to help clarify or resolve philosophical problems, and occasionally also to provide a basis for criticizing some uses of language. Additionally, Sloman points out that conceptual analysis also has another important purpose – to find out things about people and the world. Järvinen (2004) demonstrates the nature of conceptual analysis by setting the question: What is a part of reality according to a certain theory, model, or framework? In this approach, a disciplined and systematic approach to the analysis of concepts is required. Sloman (1978, pp. 70–77) suggests that there are sixteen different strategies in conceptual analysis (a–p). The first (a) describes perfectly the strategy used in this study: it proposes to collect descriptions of non-instances that are similar in some way to instances, and to compare them with each other in order to find convergences (or divergences). Conceptual analysis is a widely used research method in computing science. According to Glass, Vessey and Ramesh (2002), as well as Ivarson and Gorschek (2009), conceptual analysis has been the most used research method in the field of software engineering/requirements. Since the research problem is to find out whether there is any scientific evidence for the Getting Real principles, the research has been carried out by becoming familiar with the materials of the 37signals company (non-instances) and comparing them with scientific materials (instances), mainly articles. The materials of the company mean two books written by the key men, and the company‟s web site, which includes the weblog and video clips of seminar lectures given by the 37signals people.4 The company‟s product websites have also been studied. The scientific material has been collected by utilizing prominent databases used in information processing science and licensed for use in the University of Oulu, Finland. The databases utilized in this study are mainly Google Scholar, Scopus, and IEEE Xplore. The scientific material has been collected by searching keywords from the non-instances, and using them as a search words. Because the data has been collected from different kinds of sources, the data analysis has been done by using different methods. The literature – mainly the scientific part – The term „37signals people‟ is used when referring to the whole personnel of the company or an individual employee who cannot be identified. 4
21
has been studied by following the principle of the systematic review method. The study of the literature related to the research target has also been influenced by the deconstruction method. The audiovisual material – mainly the seminar lectures given by the company people – has been analyzed by using the transcription method. The mentioned methods are introduced in Chapters 3.1, 3.2, and 3.3. The context of this research is presented in Figure 6. The research follows somewhat the IMRD format5, but in order to acquire a better idea of the research target, the Getting Real principles, it has been important to also vet the company itself. Therefore the results part of the study has been divided into two sections. The first part introduces the researched company, its products and business thinking. It gives a better idea of why the philosophy behind the Getting Real approach is such as it is. The second part consists of the research target itself, the Getting Real approach. The primary sources in the first part are the above-mentioned literature and Internet sources created by the company, and the secondary and supporting sources consist of scientific literature. The sources in the second part are contrary to the first; the primary source is scientific literature, and the secondary and supporting sources are materials relating to the company. The primary sources in each part are illustrated by the solid arrow in Figure 6, and the secondary ones by the dash line arrows.
Introduction
Empirical ref erences
Books * Getting Real •Rework •Magazines
Scientif ic ref erences
37signals – the company behind Getting Real approach 1. 2. 3.
The audience of the company The 37signals products The unique way of business thnking
Web sources
Scientific papers
* 37signals * Product pages * Webblog
Getting Real principles 1. 2. 3. 4. 5. 6.
Principle Principle Principle Principle Principle Principle
Research target
Findings
Figure 6. The context of the researc
5
The IMRD (Introduction-Methods-Results-Discussion) format is the structure of a scientific paper as formalized by Louis Pasteur (Blackstone 2007, p. 5).
22
3.1 Systematic Review Systematic review is a trustworthy, rigorous, and auditable methodology of evaluating and interpreting all available research relevant to a particular research question, topic area, or phenomenon of interest. Systematic review has been used in medical research, but it can be used in software engineering research as well (Kitchenham, 2004; Ivarson & Gorschek, 2009.) The biggest difference between medical research and software engineering research is that the latter includes relatively little empirical research compared to the former. As a result, the research methods used by software engineering researchers are not as rigorous as those used by medical researchers (Kitchenham, 2004.) Systematic review can be undertaken to examine the extent to which empirical evidence supports theoretical hypotheses, or even to assists the generation of new hypotheses (Kitchenham, 2004). This is a very important aspect in this study, since the main research activity is to compare the empirical literature with previous researches. Systematic review differs from ordinary literature review in that it is planned and done using a specific form. The phases of systematic review are planning, conducting, and reporting. “A systematic review synthesizes existing work in manner that is fair and seen to be fair. For example, systematic reviews must allow the completeness of the search to be assessed. In particular, researchers performing a systematic review must make every effort to identify and report research that does not support their preferred research hypothesis as well as identifying and reporting research that supports it.” (Kitchenham, 2004.) In case systematic review research is carried out by a single researcher, Kitchenham (2004) emphasizes to undertake the following, most important steps: -
Developing a protocol Defining the research question Specifying what will be done to address the problem of a single researcher applying inclusion/exclusion criteria and undertaking all the data extraction Defining the search strategy Defining the data to be extracted from each primary study including quality data Maintaining lists of included and excluded studies Using the data synthesis guidelines Using the reporting guidelines
The systematic review method is used in this research in order to find an answer to the research question: Can the Getting Real approach be supported scientifically by previous research?
3.2 Deconstruction This research is not done by using the deconstruction research method as such. However, the deconstruction method has to some extent influenced the analysis of the literature and audiovisual material, both the empirical and scientific ones.
23
Deconstruction is a way of interpreting different texts, and it is based on semiotics. Semiotics is broadly defined as it is concerned with anything that can be taken as a sign (Eco, 1976, p. 7). In a semiotic sense, signs take the form of words, images, sounds, gestures, and objects (Chandler, 2001, p. 2). The semiotic approach has been utilized in this research for interpreting not only texts, but also audiovisual material (see Chapter 2.3). The word deconstruction was first used by the French philosopher Jacques Derrida. In general, in deconstruction the text is not thought of as a discrete whole, but as composed of many contradictory and irreconcilable meanings. Derrida argued that any text contains not only one content, but many more (Chandler, 2001, pp. 7, 115; Ni & Wu, 2009.) Deconstructive reading must be done by carefully concentrating on words and the context of words. The purpose of deconstructive reading is to discover conflicts in texts (Kilduff, 1993, p.16.) The scientific material has been collected by searching keywords from the researched materials (non-instances), and using them as search words. The chosen keywords are bolded in Chapter 5, in which the Getting Real principles are introduced and researched. The keywords have been used and connected in different modes and ways.
3.3 Transcription The definitions of transcription seem to vary slightly in different sources. It can also be mixed up with the related term „transliteration‟. Both methods are used to convert the source text to another format, and are widely used in linguistics. Al-Sulaiti and Knowles (2002) have found several definitions and separate the terms as follows: “A quite distinct problem is that there are also different approaches to the representation of the word, including transcription and transliteration. Transcription uses a phonetic alphabet to represent the actual pronunciation of [Arabic forms], while transliteration uses Roman letters to represent [Arabic] written forms.” They also point out that when comparing the methods, transliteration is linked to reading skills and transcription more to listening skills. Huitfeldt and Sperberg-McQueen (2008) have also noted the different definitions of the transcription term: “It may be useful to observe that in other fields, the term transcription is used with sometimes widely different meanings. In linguistics, for example, it may denote the conversion of spoken words into written language.”
24
Figure 7. Transcription text in the research diary
A total of 4 hours and 15 minutes of video material has been studied in this research. The video material was transcribed to written format using the transcription method. The notes were written in the research diary, of which an example page is presented in Figure 7. The presented issues, as well as useful citations, were written down. All issues and citations were marked with playing time, so it was easy to return to an important issue if necessary.
25
4.
37signals – the Company behind the Getting Real Approach
37signals is an American company based in Chicago, Illinois. It started as a web design consulting company in 1999, but has later designed its own web-based products. The first application, Basecamp, was launched in 2004 (37signals, 2011). The reason for the change from tailored products (web pages) to products created by the company itself (packaged web applications for small business use) derived from its own need to have better solutions. “We weren‟t happy with the project-management software used by the rest of the industry, so we created our own: Basecamp. When we showed the online tool to clients and colleagues, they all said the same thing: they needed this for their business too” (Fried & Heinemeier Hansson, 2010, p. 3.) The evolution of 37signals‟ products and business seems to follow Ronstadt‟s Corridor Principle concept. The Corridor Principle describes “how many entrepreneurs create multiple ventures, and thereby apparently lengthen the duration of their entrepreneurial careers. A new concept, called the Corridor principle, is proposed as a possible explanation of the multiple venture phenomenons. The Corridor principle states that the mere act of starting a venture enables entrepreneurs to see other venture opportunities they could neither see nor take advantage of until they had started their initial venture” (Ronstadt, 1988.) Basecamp was a successful application. Five years after its launch, Basecamp generated millions of dollars a year in profits (Fried & Heinemeier Hansson, 2010, p. 3). After releasing Basecamp, 37signals has created, released and commercialized more successful web applications. What is remarkable is that 37signals is a small company considering its products, profit and reputation. The head count of the company is only 25 people (Signal vs. Noise, 2011). The common factor of 37signals‟ products is that they are all web-based applications. As the founders have started in web design consulting and developed web-based tools for their own needs, it is well-founded to say that web-based applications are the core know-how and business of the company. The people of 37signals see web-based applications as the best way to distribute software products. “Web-based software is software you use over the internet with a web browser. You don‟t have to install any CDs, download any software, or worry about upgrades. When you use our web-based software, your data is stored on secure, always-updated, backed-up daily enterpriseclass servers in a state-of-the-art, highly-secure data center. Our software works on any platform with a web browser and internet connection. Mac, Windows, Linux are all supported. When you use web-based software your office is everywhere. At work, at home, a hotel, at a client‟s office, even on your mobile phone. Your data is accessible anywhere with internet access.” (Getting Real, 2011.) Web applications actualize the cloud computing definitions. Cloud computing refers to both applications delivered as services over the Internet and the hardware and systems software in the data centers that provide those services (Armbrust et al., 2010). The
26
products of 37signals are often connected with the concept of Web 2.0. “Web 2.0 is the network as platform, spanning all connected devices; Web 2.0 applications are those that make the most of the intrinsic advantages of that platform: delivering software as a continually-updated service that gets better the more people use it, consuming and remixing data from multiple sources, including individual users, while providing their own data and services in a form that allows remixing by others, creating network effects through an „architecture of participation,‟ and going beyond the page metaphor of Web 1.0 to deliver rich user experiences.” (O‟Reilly, 2005a.) The Web 2.0 concept is introduced in Figure 8. As the key men of the company have created successful products and the Getting Real approach based on their own experience about developing software applications, they have also created a unique way of running a software business.
Figure 8. Web 2.0 “meme map” (O’Reilly, 2005b)
4.1 The Audience of the Company 37signals is followed increasingly, and it has a loyal audience. The company has built the audience on purpose, as a kind of affordable marketing strategy. The key men have said: “Big companies can afford a Super Bowl ad: you can‟t. But you can afford to teach, and that‟s something they never do, because big companies are obsessed with secrecy. Everything at those places has to get filtered through a lawyer and go through layers red tape. Teaching is your chance to outmaneuver them.” (Fried & Heinemeier Hansson, 2010, p. 174.) It has been a successful approach. The company launched a weblog titled Signal vs. Noise in 1999. In 2007 it had more than 90 000 daily readers, and in 2010 already over 100 000 (Signal vs. Noise, 2011; Fried & Heinemeier Hansson, 2010, p. 170). Hence, a large number of people follow the company of only 25 employees. The popular Signal
27
vs. Noise weblog is about design, business, experience, simplicity, the web, culture, and more (Signal vs. Noise, 2011). The key men of the company explain the audience issue as follows: “All companies have customers. Lucky companies have fans. But the most fortunate companies have audiences” (Fried, 2008a; Fried & Heinemeier Hansson, 2010, p. 170.) The key men of the company argue for the importance of the audience by explaining that it is more affordable to be followed than to pay when one has something to tell about. “A lot of businesses still spend big bucks to reach people. Every time they want to say something, they dip into their budgets, pull out a huge wad of cash, and place some ads. This approach is both expensive and unreliable. Today‟s smartest companies know better. Instead of going out to reach people, you want to people come to you. An audience returns often – on its own – to see what you have to say. This is the most receptive group of customers and potential customers you‟ll ever have. If they like what we have to say, they‟ll probably also like what we have to sell.” (Fried & Heinemeier Hansson, 2010, p. 170.) The key men compare the traditional way of reaching customers with their weblog followers: “How much would it cost to us to reach those hundred thousand people every day the old-fashioned way? Hundreds of thousands? Millions? And how would we have done it? Running ads? Buying radio spots? Sending direct mails?” (Fried & Heinemeier Hansson, 2010, p. 171.) Even though the key men do not mention the idea of brand, the meaning of the audience can be connected with the following argument of Abimbola and Vallaster (2007): “While big companies often spend considerable amounts of money to research brand reputation and take corrective actions, entrepreneurs and SME‟s (small and mediumsized enterprises) face significant budgetary limitations. Often, personal contacts with the company‟s audience are the most relevant information sources. Such short information cycles enable a quick reaction to ensure customers have positive experiences with the brand.” The key men of the company also emphasize the personal communication between the company and its audience: “The smaller companies are closer to the customers by default. That means they can use familiar language instead of jargon. Your site and your product can have a human voice instead of sounding like corporate drone. Being small means you can talk with your customers, not down to them.” (Fried & Heinemeier Hansson, 2006.) The fans and audience mean a lot to the company. Having an audience means an affordable way to reach a great number of people and potential customers, and to get direct feedback without any information barriers. Building an audience has been a planned and successful marketing strategy to the company. The big group of followers of the small company, the audience, makes the company even more interesting from a research point of view.
4.2 The 37signals Products The products of 37signals can be divided into three groups: the commercial products which have to be bought (Basecamp, Highrise, Backpack and Campfire), the free products (Ta-da List and Writeboard), and the open source products (Ruby on Rails).
28
Furthermore, the books Getting Real and Rework can be mentioned as by-products, since they are included in the product list in the company‟s website, and according to the key men, Getting Real has given a million dollar turnover. (Fried & Heinemeier Hansson, 2010, p. 90; Fried, 2009a). Rework is on the bestseller lists of The Wall Street Journal and The New York Times (37signals, 2011; The New York Times, 2011). The company also has focused services called The Job Board and The Sortfolio (37signals, 2011). Here is a short description of the products and by-products: -
Basecamp: a project management tool including message boards, to-do lists, simple scheduling, collaborative writing and file sharing (Fried & Heinemeier Hansson, 2006).
-
Highrise: a contact management system (37signals, 2011).
-
Backpack: an organizing and information sharing tool (Fried & Heinemeier Hansson, 2010, p. 278).
-
Campfire: team collaboration with real time chat (Campfire, 2011).
-
Ta-da List: the web‟s easiest to-do list tool (37signals, 2011).
-
Writeboard: a collaborative writing tool (Fried & Heinemeier Hansson, 2010, p. 278).
-
Ruby on Rails: a powerful and simple open-source web application framework (Fried & Heinemeier Hansson, 2006; 37signals, 2011).
-
Getting Real: a book published by 37signals about discovering smarter, faster and easier ways to build a successful web-based application (Getting Real, 2011).
-
Rework: a fresh approach to running a business (37signals, 2011).
4.2.1 Ruby on Rails There are two reasons for taking a closer look at the Ruby on Rails web application framework. Firstly, it is a typical tool-to-product case in the company‟s history, and secondly it is at least one of the most well-known products of 37signals. „Rails‟, „Ruby on Rails‟, and the Rails logo are registered trademarks of David Heinemeier Hansson, a partner of 37signals (Rails, 2011a). “Rails is a web application development framework written in the Ruby language. It is designed to make programming web applications easier by making assumptions about what every developer needs to get started. It allows you to write less code while accomplishing more than many other languages and frameworks” (Rails, 2011b.) Rails is a full-stack, open-source web framework in Ruby for writing real-world applications quickly and easily. Rails takes care of the busy work so you can focus on your idea. (Fried & Heinemeier Hansson, 2006.) Rails was released to the world in July 2004 by the Danish programmer David Heinemeier Hansson (often referred to simply as “DHH”). The framework was
29
extracted from a web-based management and collaboration application project called Basecamp (Rails, 2011c, p. 8.) The benefit of the Ruby on Rails framework is the easiness and clearness of code. This has been a target of the creator, and it has been noticed by the users as well. Obie Fernandez (2008) writes about it in his 900-page-book The Rails Way as follows: “Ruby is a beautiful, dynamic, high-level language. Ruby code is easier to read and write because it more closely maps to the problem domains we tackle, in a style that is closer to human language. My experience has shown me that programs written in Ruby have fewer lines of code than comparable programs in Java and C#. Smaller codebases are easier to maintain and long-term maintenance is widely cited as the biggest cost of successful software projects.” Tim O‟Reilly, the founder and CEO of O‟Reilly Media has said: “Ruby on Rails is a breakthrough in lowering the barriers of entry to programming. Powerful Web-applications that formerly might have taken weeks or months to develop can be produced in a matter of days.” (Rails, 2011a.) The Rails is often connected with Web 2.0. It has quickly become the tool of choice for most of the Web 2.0 start-ups, and is today widely adopted by some of the largest sites on the web (e.g. Twitter) (Rails, 2011c). Ruby on Rails is a novel Web 2.0 application development framework that attempts to combine PHP‟s simple immediacy with Java‟s architecture, purity, and quality (Bächle & Kirchberg, 2007). The Ruby on Rails web framework is used widely. It was released in 2004 and has compiled statistics since 2009. It has been downloaded more than 130 million times since the year 2009 (Rails Statistics, 2011).
4.3 A Unique Way of Business Thinking 37signals has a unique way of thinking about the running of a business. The company people‟s ideas about product development and product simplicity will be handled in Chapter 4.3.2. Furthermore, they have ideas based on their best practises about starting a business, successful products, promotion issues, growing or not growing the business, daily working methods etc. A few of 37signals‟ best practises concerning running a business are introduced in this chapter.
4.3.1 Funding and Pricing 37signals highlights in many sources the significance of independent funding. Their message is clear: external money is not good for business. The funding should consist of bootstrap financing and the selling of the developed products. Bootstrap financing means highly creative ways of acquiring the use of resources without borrowing money or raising equity financing from traditional sources (Freear, Sohl, & Wetzel 1995). Fried and Heinemeier Hansson (2010, p. 50) emphasize that big investments are not needed especially in the service business (e.g. consultants, software companies, graphic designers etc.). Bootstrap Finance The key men of the company throw doubt on the need for investments using a list of questions in a chapter titled “You need less than you think” in Rework and give an example based on their own experience: “There‟s nothing wrong with being frugal.
30
When we launched our first product, we did it on the cheap. We didn‟t get our own office; we shared space with another company. We didn‟t get a bank of servers; we had only one. We didn‟t advertise; we promoted by sharing our experience online. We didn‟t hire someone to answer customer e-mails; the company founder answered them himself. And everything worked out just fine. Great companies start in garage all the time” (Fried & Heinemeier Hansson 2010, p. 54.) The key men of the company argue why it is advisable to avoid venture capital from outside the company. They list for example the following reasons: giving up the control, possible product quality problems because of short payback time, dependence on outside money, bad deals because of a lack of leverage, investors‟ opinions can rise above customers‟ opinions, and enormous work load (Heinemeier Hansson, 2008a; Fried & Heinemeier Hansson, 2010, pp. 50–51). Heinemeier Hansson (2008b) spoke in his lecture at a start-up school seminar at Stanford University about the unwillingness of venture capital investors to finance smaller businesses with realistic expectations. “There used to be once upon a time when million was a lot of money. I still think million dollars is a lot of money. But all these VCs (venture capitals) are talking about is billion dollars companies, or 300 million dollars companies. I think you can be pretty happy just a million dollars, most people would be.” This describes investors‟ sometimes unrealistic expectations, and unwillingness to invest in companies that aim to be profitable but are not necessarily growth-oriented. He claims that there is a lot of room between a life style business and billion dollar companies and continues: “I encourage a lot more people to take a better odds at the smaller reward, and then perhaps worry about the billion dollars next time.” A bootstrapped company is not responsible to outsiders for the size of the business (or for any other issues). “Bootstrappers need a different mind-set and approach. Bootstrappers don‟t mind starting with a copy-cat idea targeted to a small market. Often that approach works well. Imitation saves the cost of market research, and the start up entering a small market is unlikely to face competition from large, established companies. Once they are in the flow of business, opportunities often turn up that they would not seen had they waited for the big idea.” (Bhide, 1992.) 37signals‟ bootstrapping principles seem to be in line with researches on bootstrapping. For example, they advise to do all possible tasks by yourself and hire an employee only when it is a real necessity. (Fried & Heinemeier Hansson, 2010, pp. 201–204). Accordingly, chapters of the Rework book are named incisively “Do it yourself first” and “Hire when it hurts”. It is not unusual for investor-backed start-ups to hire CFO or marketing managers at $100,000 a year. Bootstrappers cannot afford this investment (Bhide, 1992.) The key men of the company strongly recommend bootstrap financing. They have spoken about it in their books and lectures. They have also started a weblog discussion to raise forward companies with a similar background and business models. The discussion is titled “Bootstrapped, profitable and proud”, and it has continued for about two years (Signal vs. Noise, 2011.) Pricing Pricing strategies are one of the most important challenges and decisions for today‟s IT service providers. No tool in the marketing tool box can increase sales or destroy demand more quickly than the pricing strategy. Harmon, Raffo, and Faulk (2004); and
31
Harmon, Demirkan, Hefley, and Auseklis (2009) argue that the pricing decision is one of the most critical decisions that a firm can make when launching a product. Besides the bootstrap funding, the finance should consists of the income earned from the developed products. The key men of 37signals do not believe in free products. They think the company‟s core products should always have a price. It is justified to say they mean core products because on the one hand they speak about products that have to be bought, but on the other hand 37signals also offer free products, such as Ta-da List, Writeboard, and Ruby on Rails. It is also possible to read the Getting Real book free of charge in the Internet. The business that makes the most money for a company and is considered its most important and central one, is called core business. The key men of the company specify the meaning of free products (outside the core products) in the following way: “Drug dealers are astute business people. They know their product is so good they‟re willing to give a little away for free upfront. They know you‟ll be back for more – with money.” (Fried & Heinemeier Hansson, 2010, p. 191.) They explain that Writeboard and Ta-da List are free for the same reason; they are used to get people on the path of using their other products (Fried & Heinemeier Hansson, 2006). Mr. Fried has said in his lecture: “I think free is the wrong direction for this industry . . . I don‟t think free is the future of business.” He compares the software business to several traditional product businesses where the products naturally have a price. He mentions the meaning of invoicing for smaller companies: ”The Google, the company of billions of dollars has decided something is given for free, I‟m not sure how smaller companies are familiar with that” (Fried, 2009b.) 37signals‟ way of pricing is very simple and traditional. If customers like the product, they pay for it, and the company receives a profit. (Heinemeier Hansson, 2008b). Additionally, they apply a fixed price system: “We believe everyone who pays us for our products should pay the same price. We‟ve worked hard to keep our prices reasonable. We haven‟t increased our prices in years. From the small guy just getting started in his spare time on the weekends, to an established small business, to organizations assembled for a cause, to small groups inside some of the world‟s largest corporations, our published prices are the same no matter who you are or what you do. We think that‟s the only fair way.” (Signal vs. Noise, 2011.) The fixed price system has been recognized as a preferred one also in other cases. Ghayur (2003) defines fixed price as follows: “There will be one price for every customer. There will be no room for negotiations. All the contracts would be drawn based on advertised prices, hence creating a level playing field for all buyers, big or small. This will ultimately result in better commercial ethics and benefits to the customer in cheaper and fixed price goods.” Using a fixed price is also called „flat pricing‟. It means that users pay a fixed price for an unlimited use of software. This approach enables the customers to predict more easily what they will pay for the use of a software (Harmon et al., 2004; 2009.) By-Products The key men of 37signals have mentioned in many sources the possibility of making profit with by-products. Mr. Fried has explained: “When you make something, you always make something else. You can‟t make just one thing. Everything has a byproduct. Observant and creative business minds spot these by-products and see opportunities. Our last book, Getting Real, was a by-product. We wrote a book without
32
even knowing it. The experience that came from building a company and building software was the waste of actually doing a work. We swept up that knowledge first into blog posts, then into a workshop series, then into a .pdf, and then into a paperback. That by-product has made 37signals more than $1 million directly and probably more than another $1 million indirectly.” (Fried, 2009a; Fried & Heinemeier Hansson, 2010, p. 90.) The company has clearly recognized the business opportunity of selling by-products and implemented that successfully.
4.3.2 Software Characteristics The 37signals people think that a good starting point for developing new products is solving a problem faced by oneself (Fried & Heinemeier Hansson, 2006; Fried and Heinemeier Hansson, 2010, p. 34). They explain the reason for it as follows: “When you build a product or service, you make the call on hundreds of tiny decisions each day. If you‟re solving someone else‟s problem, you‟re constantly stabbing in the dark. When you solve your own problem, the light comes on. You know exactly what the right answer is” (Fried and Heinemeier Hansson, 2010, p. 34.) It can be said that the company has successfully turned around the customer-driven product decision thinking by developing products for its own needs. They give an example: “At 37signals, we build products we need to run our own business. For example, we wanted a way to keep track to whom we talked to, what we said, and when we need to follow up next. So, we created Highrise, our contact-management software. There was no need for focus groups, market studies, or middlemen” (Fried and Heinemeier Hansson, 2010, p. 34.) Product Features The common factor of 37signals‟ products is that they have all been planned to be easy to use, opinionated, and relatively light and simple overall. Considering how successful these products have been, it can be said that customers like simple products that do not require a lot of training before they can be used. After decades‟ evolution with increasing features and complexity, simplicity and minimalism might be the forthcoming trend in the software business, perhaps in other business lines as well. Dr. Jakob Nielsen, who has been called for example the world‟s leading expert on web usability (Useit.com, 2011), is a co-inventor of the heuristic evaluation method (Nielsen & Mack, 1994, p. v). Aesthetic and minimalist design has been selected one of the ten Nielsen‟s usability heuristics. Aesthetic and minimalist design means that dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. (Nielsen & Mack, 1994, p. 30.) Minimalism can also be an aesthetic value itself, as used for example in industrial design, architecture, music, and other art forms (Ronkainen, Häkkilä, & Pasanen, 2005).
33
The 37signals people summarize the idea of simplicity as the modus operandi of the company as follows: Our modus operandi6 “We believe software is too complex. Too many features, too many buttons, too much to learn. Our products do less than the competition – intentionally. We build products that work smarter, feel better, allow you to do things your way, and are easier to use.” (Fried & Heinemeier Hansson, 2006.)
Mr. Ryan Singer, who is the user interface expert at 37signals, highlights the easiness and clarity of a product, especially the user interface. He points out that usability is not a compliment, it is a meaningful thing. He argues that for customers the interface is a product. The design of a user interface must be focused on three main things: screens, flow and language. He separates the idea of usability from the company‟s way of thinking when designing software and user interfaces. He explains they are not talking about usability, interaction or user experience, but rather about clarity, making things easy, fastness, fun and feeling good when one uses something (Singer, 2008.) The company summarizes the easiness and opinionated character of their products in their website: “Our products are intuitive. You‟ll pick them up in seconds or minutes, not hours, days or weeks. We don‟t sell you training because you don‟t need it” (37signals, 2011.) The thing that helps to develop simple products is that there are not too many features. 37signals has turned this into a competitive advantage. “Conventional wisdom says that to beat your competitors you need to one-up them. If they have four features, you need five (or 15, or 25). If they are spending x, you need to spend xx. If they are spending $20,000, you need to spend $30,000. If they have fifty employees, you need a hundred. This sort of one-upping cold war mentality is a dead-end. It‟s an expensive, defensive, and paranoid way of building products. Defensive, paranoid companies can‟t think ahead, they can only think back. They don‟t lead, they follow. So, what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of one-upping, try to one-downing. Instead of outdoing, try underdoing.” (Fried, 2008b; Fried & Heinemeier Hansson, 2006; Fried & Heinemeier Hansson, 2010, p. 144.) As mentioned before, minimalism might be a forthcoming trend, not only in the software business, but perhaps in other business lines too. The 37signals people have followed other business lines for benchmarking purposes, and they often compare software business to other businesses. In many sources, they have drawn examples from the restaurant world, oil business and so on. In Rework they give examples of the success of „underdoing‟ by referring to the popularity of one-gear bicycles and an ultra simple camcorder called Flip (Fried & Heinemeier Hansson 2010, p. 145).
Modus operandi is a Latin phrase, which approximately translates as „mode of operating‟ (Wikipedia, 2011). 6
34
The way to maintain the characteristics of clarity, easiness and minimalism in products is to ignore unnecessary or unimportant features. The key men of the company encourage developers to think about the feature set already in the idea phase. “Stick to what‟s truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it half. Pare features down until you‟re left with only the most essential ones. Then do it again” (Fried & Heinemeier Hansson, 2006.) In many sources, they encourage developers to say no to outside feature requests by default and to concentrate on the features that really matter. The extra features also generate developing costs. “Each time you say yes to a feature you‟re adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature‟s out there, you‟re stuck with it.” (Fried & Heinemeier Hansson, 2006.) To illustrate the feature selection procedure, the key men of the company present a list of what should be done with every new feature: 1) Say no 2) Force the feature to prove its value 3) If “no” again, end here. If “yes”, continue 4) Sketch the screen(s)/UI 5) Design the screen(s)/UI 6) Code it 7– 15) Test, tweak, test, tweak, test, tweak, test, tweak 16) Check to see if help text needs to be modified 17) Update the product tour (if necessary) 18) Update the marketing copy (if necessary) 19) Update the terms of service (if necessary) 20) Check to see if any promises were broken 21) Check to see if pricing structure is affected 22) Launch 23) Hold breath. (Fried & Heinemeier Hansson, 2006.) It is easy to see from the list that every new feature causes extra work and costs. Steve Jobs, the co-founder and long-time CEO of Apple thinks in the same way about selecting the right features: “It comes from saying no to 1,000 things to make sure we don‟t get on the wrong track or try to do too much. We‟re always thinking about new markets we could enter, but it‟s only by saying no that you can concentrate on the things that are really important” (Burrows, 2004.)
4.3.3 Everyday Working Methods The 37signals company is an inventive organisation. Besides the individual and simplified products, the company has also created unconventional working methods. Three themes appear constantly in the books and lectures of the key men of the company: avoidance of interruptions, meetings, and documentation. Interruptions
35
People need uninterrupted time to get things done. The key men of the company claim that most people are most productive early in the morning and at night time. It is possible mostly because there are no other people around and no interruptions. The company has simulated the situation and propose to set a rule such as “alone zone” or “no-speak-Thursday”. The main principle is that no one speaks with each other during an agreed time period (Fried, 2008b; Fried, 2009a; Fried & Heinemeier Hansson, 2006; Fried & Heinemeier Hansson, 2010, p. 104.) The reverse of maximizing human creativity during working hours is to let people rest and do something else in their free time. “If you want something done, ask the busiest person you know. People who have a life outside of work. People who care about more than one thing” (Fried & Heinemeier Hansson, 2010, p. 258.) “Workaholics aren‟t heroes. They don‟t save the day, they just use it up. The real hero is already home because she figured out a faster way to get things done” (Fried & Heinemeier Hansson, 2010, p. 26.) Researchers are of the same opinion about interruptions and personal productivity. O‟Conaill and Frohlich define an interruption as a synchronous interaction that was not initiated by the subject, was unscheduled and resulted in the recipient discontinuing their current activity. Perlow has found in a field experiment that by implementing a „quiet-time‟ – an agreement among co-workers not to interrupt one another during designated hours – three mornings a week, software developers were more efficient (Perlow, 1999; Rennecker & Godwin, 2003). Meetings The key men of the company claim that meetings are the worst interruption to productivity. They argue that meetings are about words and abstract concepts, not real things. According to them, the meetings are needed when the concept is not clear enough. They also argue that meetings take time and interrupt the natural work flow; besides the lost time, moving to the meeting place and back also takes time (Fried & Heinemeier Hansson, 2006; Fried & Heinemeier Hansson, 2010, p. 108–109.) “Let‟s say you‟re going to schedule a meeting that lasts one hour, and you invite ten people to attend. That‟s actually a ten-hour meeting, not a one-hour meeting. You‟re trading the hours productivity for one hour of meeting time. And it‟s probably more like fifteen hours, because there are mental switching costs that come with stopping what you‟re doing, going somewhere else to meet, and then resuming what you were doing beforehand” (Fried & Heinemeier Hansson, 2010, p. 109.) If a meeting must still be held, the key men of the company advise the following: set a timer (when it rings the meeting is over), invite as few people as possible, always have a clear agenda, and begin with a specific problem (Fried & Heinemeier Hansson, 2006; Fried & Heinemeier Hansson, 2010, p. 109.) Documentation The key men of the company question in many sources the benefits of written plans and documents, even specifications. “The business world is littered with dead documents that do nothing but waste people‟s time. Reports no one reads, diagrams no one looks at, and specs that never resemble the finished product. These things take forever to make but only seconds to forget” (Fried & Heinemeier Hansson, 2010, p. 97) The 37signals people prefer to record issues in real things like mock-ups, prototypes, drawings, and interface design instead of documents. “Documents that live separately from your application are worthless. They don‟t get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it‟s dead”
36
(Fried & Heinemeier Hansson, 2006.) They do not make road maps, specifications, or projections at all (Fried, 2008b). The reason for not to draw up documentation is that most documents are estimations and most probably do not come true. “We‟re all terrible estimators. We think we can guess how long something will take, when we really have no idea. We see everything going according to a best case scenario, without the delays that inevitably pop up. Reality never sticks to best case scenarios” (Fried & Heinemeier Hansson, 2010, p. 124.) The key men continue with what they think will happen if plans that do not come true are documented: “When you turn your guesses into plans, you enter a danger zone. Writing a plan makes you feel in control of things you can‟t actually control” (Fried & Heinemeier Hansson, 2010, p. 19.) The key men of the company explain in many sources that they do not make long-term plans but rather concentrate on what is most valuable to do in the next hour or day. They say the maximum planning period is two weeks. (Fried, 2008b). However, they do not recommend not thinking about the future, only not using time to write it down because no one reads it afterwards (Fried & Heinemeier Hansson, 2010, p. 20).
37
5.
The Getting Real Approach
Getting Real is, besides the name of the first book published by the key men of 37signals, a kind of way of lateral business thinking. It is a set of principles that lead the activities of a company. It is relatively difficult to define Getting Real, nor is it clearly defined by the company. It is not a software development method since the development process is not determined in it, and it also involves working and business methods. Getting Real is based on the company‟s experience about developing software applications and commercializing them successfully. There are only two single-word definitions for Getting Real used by the company people in the source material. They are movement (Getting Real, 2011) and approach (Fried & Heinemeier Hansson, 2006). The key men of the company define Getting Real as “an approach ideally suited to web-based software” (Fried & Heinemeier Hansson, 2006). After deconstructing the source material, Getting Real is defined in this research as an approach that has an existence identical with the philosophies behind software development methods. It is presumable that the company people use ultra-light agile methods without any formal documentation as their development method. Getting Real is a range of principles based on good practices according to 37signals. There are six separate general principles in total:
1) Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing. 2) Getting real is less. Less mass, less software, less features, less paperwork, less of everything that‟s not essential (and most of what you think is essential actually isn‟t). 3) Getting Real is staying small and being agile. 4) Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong. 5) Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software. 6) Getting Real delivers just what customers need and eliminates anything they don’t.
38
(Fried & Heinemeier Hansson, 2006.) The key men of the company define the benefits of the Getting Real approach as follows: “Getting Real delivers better results because it forces you to deal with the actual problems you‟re trying to solve instead of your ideas about those problems. It forces you to deal with reality. Getting Real foregoes functional specs and other transitory documentation in favour of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That‟s what your customers are going to see and use. That‟s what matters. Getting Real gets you there faster. And that means you‟re making software decisions based on the real thing instead of abstract notions” (Fried & Heinemeier Hansson, 2006.) In order to clarify the analysis of the Getting Real theme, the principles are numbered (1–6). Each principle is introduced in detail below and compared with scientific findings. Research Question The research question guiding this study is: “Can the Getting Real approach be supported scientifically by previous research?” The results provide an analysis of the Getting Real principles, the supportive references for the company, and scientific literature. Analysis We provide supportive references using systematic review (see Chapter 3.1). The first step was to find keywords from the research target (each Getting Real principle). The keywords are bolded in the beginning of each chapter (5.1–5.6). The second step, by using the keywords, was to find supportive references from the empirical material – books, magazine interviews, web pages, and video clips. The last step was then to search scientific support from previous researches by searching with the keywords in prominent databases, e.g. Google Scholar and Scopus. As an example, the keyword “less software” gave 1490 results in Google Scholar (on August 10, 2011). We limited the large number of results by adding general keyword(s) concerning the topic(s) to the search inquiry. The search inquiry “less software” AND “software development” limited the results to 460. Additionally, the search inquiry “less software” AND “software development” AND “agile” limited the results to 60, and so on. The relevant literature for more detailed study was chosen by interpreting titles and abstracts of the search results. Depending on the discovered material, it was studied with the help of deconstruction (a way of interpreting different written material, see Chapter 3.2), or transcription (converting audiovisual material into written language, see Chapter 3.3). The transcription was done by watching audiovisual material bit by bit, and making notes in the research diary, for instance supportive subjects and citations (see Figure 7, p. 24). Finally, the studied materials, both empirical material and previous researches, were compared and possible common issues were noted.
39
5.1 Getting Real – Principle 1 “Getting Real is about skipping all the stuff that represents real (charts, graphs, boxes, arrows, schematics, wireframes, etc.) and actually building the real thing.” (Fried & Heinemeier Hansson, 2006). The first Getting Real principle is very similar to the common agile definitions regarding documentation. Already the set of common general rules for all agile methods – the Agile Manifesto (2011) – recommends focusing on well-functioning software instead of documentation: “Working software over comprehensive documentation”. The Agile Manifesto further includes twelve explicit principles. One of them is to focus on the development of process measurement: “Working software is the primary measure of progress”. In her research, Ms. Strode (2006) introduces common properties of agile methods and also mentions working software as the main product of development, together with minimizing documentation. She answers her research question “What is an agile method?” by comparing twelve agile methods investigated by Abrahamsson et al. (2002; 2003). According to her, the definition of agile method includes the preference for working software instead of documentation: “. . .An agile method is designed to produce working software early, using communication, feedback, learning and frequent meetings in preference to than modelling and documentation. . .” (see p. 12 for the entire definition). Abrahamsson et al. found out already in 2002 that agile methods had evoked a substantial amount of literature and debates. The Agile Manifesto (2011) was chosen as a reference because it was a starting point for agile definitions and cited in most literature. Strode‟s comparative analysis research was chosen as a reference because it includes a fundamental definition of agile methods. These two references are useful also because they cover the rules and properties of all agile methodologies. The key men of the company criticize the need for comprehensive operational documentation – not only documentation related to software developing (see p. 32). “Getting Real foregoes functional specs and other transitory documentation in favour of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That‟s what your customers are going to see and use. That‟s what matters. Getting Real gets you there faster. And that means you‟re making software decisions based on the real thing instead of abstract notions” (Fried & Heinemeier Hansson, 2006.) In Getting Real, the key men of the company cite the creator of Linux, Mr. Linus Torwalds, who share the thinking: “A spec is close to useless. I have never seen a spec that was both big enough to be useful and accurate. And I have seen lots of total crap work that was based on specs. It‟s the single worst way to write software, because it by definition means that the software was written to match theory, not reality” (Torvalds, 2005.) Besides specifications, the key men of the company call into question the need for roadmaps, projections (Fried, 2008b), business plans, five-year plans (Heinemeier Hansson, 2009), financial plans, and strategies (Fried & Heinemeier Hansson, 2010, p. 19). Palmer and Felsing (2002, pp. 100–101) state that it is a painful process to generate documents of source code, and it increases the chances for updating. Cockburn (2002, p. 177) suggests to dispense with design documentation beyond whiteboard sketches. This
40
is in line with what the key men argue; they recommend using paper sketches and real HTML screens in the planning phase instead of documents (Fried & Heinemeier Hansson, 2006). “Documents that live separately from your application are worthless. They don‟t get you anywhere. Everything you do should evolve into the real thing. If a document stops before it turns real, it‟s dead” (Fried & Heinemeier Hansson, 2006.) Conclusion The first Getting real principle closely resembles one of the four common rules for agile methods (Agile Manifesto, 2011), it is only defined in a somewhat more detailed and extensive way. There exists an enormous amount of scientific literature on the agile methods, most of which cite the Agile Manifesto and share its rules. We can conclude that the first Getting Real principle is supported by previous scientific research.
5.2 Getting Real – Principle 2 “Getting real is less. Less mass, less software, less features, less paperwork, less of everything that’s not essential (and most of what you think is essential actually isn’t).” (Fried & Heinemeier Hansson, 2006.) “If you keep your mass low, you can quickly change anything: your entire business model, product, feature set, and/or marketing message. You can make mistakes and fix them quickly. You can change your priorities, product mix, or focus” (Fried & Heinemeier Hansson, 2006; Fried & Heinemeier Hansson, 2010, p. 62.) It has been proved that agile methods are effective tools for creating simple products and for small teams (e.g. Abrahamsson et al., 2002; Strode, 2006). This is mentioned here because not all agile rules and principles are necessarily useful when reviewing more complex software or data systems or bigger organizations. One of the principles in the Agile Manifesto can be compared to this second principle of Getting Real: “Simplicity – the art of maximizing the amount of work not done – is essential” (Agile Manifesto, 2011.) The key men of the company emphasize to do less at every level; the code level, feature level, daily routine level as well as company strategy level. Since the paperwork, daily working methods, and strategy-level planning has been discussed above in chapters 4.3.3. and 5.1, this chapter is concentrated on the issues of reducing software and its features.
5.2.1 Less Software All characteristics of the agile methods, as well as those of the Getting Real approach, aim at flexible changes during the developing process. Mr. Appleton (2005) has summarized this idea as follows: “There is no code that is more flexible than no code!” He explains his phrase: “The secret to good software design wasn‟t in knowing what to put into code; it was in knowing what to leave out. It was recognizing where the hard-
41
spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.” The key men of the company have cited Appleton and claimed that every time the amount of code increases, the complexity of the software grows exponentially. “Each minor addition, each change, each interdependency, and each preference has a cascading effect.” They summarize the „less software thinking‟ as follows: “The way you fight this complexity is with less software. Less software means less features, less code, and less waste” (Fried & Heinemeier Hansson, 2006.) The key men of the company see many different advantages in reducing codes. Less software is easier to manage, it reduces the codebase, which means less maintenance work, it lowers and speeds up the cost of change, and it causes fewer bugs and reduces the need of support. “For every feature that makes it into your app, ask yourself: Is there a way this can be added that won‟t require as much software? Write just the code you need and no more. Your app will be leaner and healthier as a result” (Fried & Heinemeier Hansson, 2006.) Wild (2008) recommends writing less code by justifying every feature and minimizing useful feature sets. “Limit the features and the functions that make it into the codebase. Every feature should proof that if will create more economic value than its lifecycle costs. Divide software into minimum useful features and deploy these one set at a time, highest priority first. These allow using the software much faster” (Wild, 2008.) It is a received principle that software design should be kept as simple as possible. For instance Müller and Tichy (2001), Lindstrom and Jeffries (2004), Nielsen and Mack (1994), Appleton (2005), Wild (2008), and Fernandez (2008) share this principle with the 37signals people.
5.2.2 Less Features The „less mass‟ philosophy seems to present even a competitive edge to the company. “It‟s all part of how we differentiate ourselves from competitors; instead of trying to build products that do more, we build products that do less” (Fried & Heinemeier Hansson, 2006). Building simple software to accomplish narrow tasks is so significant a point that it is presented in its own chapter (4.3.2) in this study. The key men of the company highlight the minimalist character in every source when they speak about the products (e.g. Fried & Heinemeier Hansson, 2006; 2010; Fried, 2008a; Heinemeier Hansson, 2009; Park, 2008, etc). According to the key men, feature evaluation should always be done by thinking what is really needed, and leaving out the rest. They recommend saying no by default to internal and external feature requests in the first phase, but if a feature keeps recurring, it is worth of taking a deeper look. A practical way to reduce features is also to study what people do not want in a product, instead what they want (Fried & Heinemeier Hansson, 2006; 2010, pp. 153–154.) “The best designers and best programmers aren‟t the ones with the best (programming) skills, or nimblest fingers . . . they are the ones that can determine what just doesn‟t matter” (Fried & Heinemeier Hansson, 2006). It is difficult to prove scientifically whether there is any correlation between the number of features and the success of the product since there is not very much previous research available on this subject. There are also many variables, e.g. different researched
42
customer segments (the customer segments according to G.A. Moore (1991): innovators, visionaries, pragmatists, conservatives, sceptics). But it can be concluded that the fewer features a product contains, the simpler it is to use. Simple-to-use products always have loyal users. The company has proved it with more than three million users (Fried & Heinemeier Hansson, 2010, p. 3). As mentioned, minimalism might be a growing trend also in other business lines, such as consumer electronics or catering business. The key men refer to Gordon Ramsey – a three-Michelin-star chef – as an example of downgrading the number of features: “Ramsey‟s first step (in the Kitchen Nighmare TV program) is nearly always to trim the menu, usually from thirtyplus dishes to around ten. Then he polished what‟s left” (Fried & Heinemeier Hansson, 2010, p. 83.) Conclusion The second Getting Real principle is very general and extensive. It recommends doing things in a simple and light way at various levels. The phrase „less mass‟ covers practically all functions of a software company, including the daily-level job, planning, documentation, and product design activities (Fried & Heinemeier Hansson, 2006). The phrases „less software‟, „less features‟, and „less paperwork‟ are more descriptive and belong under the „less mass‟ umbrella. The general less mass thinking – including all sub-thoughts – is in line with the Agile Manifesto (2011) principle: “Simplicity – the art of maximizing the amount of work not done – is essential.” The idea of „less software‟ and keeping the code as simple as possible is clearly in accordance with the agile approaches and is shared for instance by Müller and Tichy (2001), Lindstrom and Jeffries (2004), Nielsen and Mack (1994), Appleton (2005), Wild (2008), and Fernandez (2008). The „less feature‟ thinking is very close to the „less software‟ thinking since in most cases less software is the result of reducing the number of features. It is not possible to reach a conclusion concerning the correlation between the number of features and the success of the product because there are so many different kinds of customer segments. It is certain that innovators and visionaries want more features than mainstream customers. On the other hand, it can be seen that many customers want products that are easy to use, which in many cases means fewer features. The „less paperwork‟ thinking is clearly in line with the agile methodologies and is defined in the Agile Manifesto (2011) as one of the four common rules: “Working software over comprehensive documentation”. We can conclude that the second Getting Real principle is supported by previous scientific research.
5.3 Getting Real – Principle 3 “Getting Real is staying small and being agile.” (Fried & Heinemeier Hansson, 2006). This is the first instance in which the key men mention the concept of agility. However, they do not seem to refer directly to agile methodologies; rather, agility is a consequence of the small size of the company. “All the cash, all the marketing, all the people in the world can‟t buy the agility you get from being small” (Fried & Heinemeier Hansson, 2006).
43
This is also the first Getting Real principle which does not have a straightforward connection with the Agile Manifesto rules or principles; in the Agile Manifesto (2011) itself, agile methodologies are not linked only with small teams. However, some key men behind the Agile Manifesto (e.g. Beck, 1999; Lindstrom & Jeffries, 2004) argue that particular agile methods are meant for small teams. Many researchers (e.g. Rising & Janoff 2000; Müller & Tichy, 2001; Abrahamsson et al., 2002; Strode, 2006) also share the idea of the small team size. The key men of the company do not speak about the size of the developing team but the size of the whole company. They point out that a small business can be profitable and that growth itself should not be a main target of a company (Fried & Heinemeier Hansson, 2010, pp. 22–23). They emphasize four main reasons why it is favourable to keep a company small. The first reason is the possibility of cheap and fast changes. “The ability to change on a dime is one thing small teams have by default that big teams can never have. This is where the big guys envy the little guys. What might take a big team in a huge organization weeks to change may only take a day in a small, lean organization. That advantage is priceless. Cheap and fast changes are small‟s secret weapon” (Fried & Heinemeier Hansson, 2006.) The Agile Manifesto (2011) does not commit itself to the team size, but the readiness for changes. The second reason is that resource limitations force one to do things faster and cheaper. “There‟s never enough to go around. Not enough time. Not enough money. Not enough people. That’s a good thing.” (Fried & Heinemeier Hansson, 2006.) The key men of the company have told about the limitations they faced when they were building their first commercial application called Basecamp. They had to take care of their customer projects, managing with a 7-hour time difference (Mr. Heinemeier Hansson was working in Denmark at that time), a small team and no outside funding. They came up with creative solutions, and even with the limitations, they were able to build a successful application. “Constraints are often advantages in disguise. Forget about venture capital, long release cycles, and quick hires. Instead, work with what you have.” (Fried & Heinemeier Hansson, 2006.) The third reason to keep the company size small is that such a company can enjoy fewer formalities, less bureaucracy, and have more freedom. The key men of the company have also observed that both internal and external communication is more effective in small companies. Regarding external communication they have said: “Smaller companies are closer to the customer by default. That means they can communicate in a more direct and personal way with customers. If you‟re small, you can use familiar language instead of jargon. Your site and your product can have a human voice instead of sounding like a corporate drone. Being small means you can talk with your customers, not down to them.” About internal communication they have argued: “There are also advantages to internal communications at small companies too. You can ditch formalities. There‟s no need for arduous processes and multiple sign-offs on everything. Everyone in the process can speak openly and honestly. This unfettered flow of ideas is one of the big advantages of staying small.” (Fried & Heinemeier Hansson, 2006.) The fourth reason Mr. Fried mentions is obvious; a smaller organization is nimbler than a bigger one: “He [Mr. Fried] insists that the bigger a staff gets, the slower it moves. A lot of teams have problems with over collaboration. Too much teamwork, too many cooks in the kitchen, too many people making decisions.” (Caplan, 2007.)
44
Power and Reid (2005) have researched the flexibility and performance of small firms, and they have identified the main factors that influence the performance of long-lived small businesses positively. Two out of the four factors support this principle. A small firm must be aware of the drivers of change, and it must be ready for quick changes. Conclusion The Agile Manifesto does not commit itself to the size of a company, but one of its main ideas is to react fast to requirement changes even in a late phase of the developing process. The fourth common rule of the Agile Manifesto is “Responding to change over following a plan”, and one of the twelve explicit principles is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer‟s competitive advantage.” (Agile Manifesto, 2011.) Agile behavior and the possibility of reacting fast are a consequence of the small size of a team or company. In most literature, agile methodologies are considered effective if the group size is small. It is an established fact that small companies are more agile and faster than bigger ones (e.g. Power & Reid, 2005). We can conclude that the third Getting Real principle is supported by previous scientific research.
5.4 Getting Real – Principle 4 “Getting Real starts with the interface, the real screens that people are going to use. It begins with what the customer actually experiences and builds backwards from there. This lets you get the interface right before you get the software wrong.” (Fried & Heinemeier Hansson, 2006.) The order of building software is not addressed in the Agile Manifesto. One rule is loosely similar and closest to this fourth principle; it is the one that was already introduced in Chapter 5.1 – “Working software over comprehensive documentation.” The key men of the company emphasize in many sources that it is important to start the building of software directly with real things without formal planning and documentation (e.g. Fried & Heinemeier Hansson, 2006; Fried 2008b). The fourth principle states that the starting point should be the user interface. The key men have argued: “. . . an actual web page is reality. That‟s what your customers are going to see and use. That‟s what matters. Getting Real gets you there faster. And that means you‟re making software decisions based on the real things instead of abstract notions” (Fried & Heinemeier Hansson, 2006.) The key men also equate the user interface to a product: “[Another] reason to design first is that the interface is your product. What people see is what you‟re selling. If you just slap an interface on at the end, the gaps will show” (Fried & Heinemeier Hansson, 2006; Singer, 2008.) Constantine and Lockwood (2002) note that the web page itself is an user interface. They also claim that the success of the user interface design determines the success of web applications. Nielsen and Mack (1994) have estimated that billions of dollars have been lost in Internet sales because of usability problems. It is hard to find support for starting the design from the user interface, or for the opposite viewpoint. In all likelihood, the issue has not been researched extensively. However, Parnas (1969) notes
45
in his paper that the user interface should be designed first, and thus share the viewpoint of the key men. The key men of the company argue for starting the interface design first because it is relatively light and easy to change before the programming has started. “Programming is the heaviest component of building an app, meaning it‟s the most expensive and hardest to change. Instead, start by designing first. Design is relatively light. A paper sketch is cheap and easy to change. Html designs are still relatively simple to modify (or throw out). That‟s not true of programming. Designing first keeps you flexible. Programming first fences you in and sets you up for additional costs” (Fried & Heinemeier Hansson, 2006.) The key men of the company present a few reasons for starting the user interface design first. First, the user interface gives an impression of the application. They explain they can see how the product looks and feels already at the beginning. “It‟s [the user interface] constantly being revised throughout the process. Does it make sense? Is it easy to use? Does it solve the problem at hand? These are the questions you can truly answer when you‟re dealing with the real screens. Designing first keeps you flexible and gets you to those answers sooner in the process rather than later” (Fried & Heinemeier Hansson, 2006.) The 37signals people have focused strongly on user interface design, also at the more detailed level. They mention the same principles as with whole products; the user interface must be easy to use, opinionated and aesthetic. They emphasize the meaning of blank slate design, and the form of context and language. Blank slate design is an important part of the user interface design process because it gives the first impression of the application to the user. “The problem is that when designing an UI, it‟s usually flush with data. Designers always fill templates with data. Every list, every post, every field, every nook and cranny has stuff in it. And that means the screen looks and works great. However, the natural state of the app is one that‟s devoid of data. When someone signs up, they start with a blank slate . . . Unfortunately, the customer decides if an application is worthy at this blank slate stage” (Fried & Heinemeier Hansson, 2006.) The 37signals people emphasize the significance of the form of context when designing the user interface. They try to think of the most clear and natural way for a user to proceed. In Getting Real, there is a paragraph titled “Context Over Consistency – What makes sense here may not make sense there”. They give clear examples: “Should actions be buttons or links? It depends on action. Should a calendar view be in list-form or grid-form? It depends where it‟s being shown and how long the time period is. Does every global navigation link need to be on every page? Do you need a global search bar everywhere?…The answer: It depends.” They continue: “That‟s why context is more important than consistency. It‟s ok to be inconsistent if your design makes more sense that way. Give people just what matters. Give them what they need when they need it and get rid of what they don‟t. It‟s better to be right than to be consistent.” (Fried & Heinemeier Hansson, 2006.) The language also has a very important role in interface design. According to the 37signals people, 90% of the information in a web page is text (Singer, 2008). “Copywriting is interface design. Great interfaces are written. If you think every pixel, every icon, every typeface matters, then you also need to believe every letter matters. When you‟re writing your interface, always put you in the shoes of the person who‟s
46
reading your interface . . . Do you label a button Submit or Save or New or Create?” (Fried & Heinemeier Hansson, 2006; see also Nielsen & Mack, 1994, pp. 279–293.) The 37signals people also advise to use the same language as the user. “Just because you‟re writing a web app doesn‟t mean you can get away with technical jargon” (Fried & Heinemeier Hansson, 2006; Singer, 2008.) User interfaces have been researched already before the Internet became a common phenomenon. Grudin (1989) had already concluded that context is more important than consistency, against previous studies: “A close examination suggests that consistency is an unreliable guide and that designers would often do better to focus on users‟ work environments.” Grudin made the same conclusion as the 37signals people: to design a good user interface, the user must be studied: “[This article argues for a shift in perspective], suggesting that when user interface consistency becomes our primary concern, our attention is directed away from its proper focus: users and their work.” Grudin and Gentner (1990) have also drawn attention to another point that may lead to a bad user interface design – the differences between engineering and the user point of view: “From the engineer‟s perspective, the ideal interface reflects the underlying mechanism and affords direct access to the control points of the mechanism . . . The user, however, wants to complete a task, and an interface that is based on the task is often more appropriate than one based on the system mechanism.” The language of the user interface has also been studied before. De Souza (1993) presents the semiotic engineering approach for user interface designers, which has similarities with the 37signals people‟s principles. Since the 37signals people point out the importance of the user interface due to its role as a product from the user point of view, Grudin (1989) shares the thinking: “The way to stay at the forefront of this evolution is to know your users and their tasks a little better than anyone else.” Conclusion The fourth Getting Real principle is ambiguous. The first point suggests to start the design of an application from the user interface and to design the real screens first. This seems to be based on the best practices of the company, and it is certainly a good observation. It is maybe stating the obvious for software designers, or it has not been researched a lot. In any case, it is hard to find support from previous research for this point. The second point – the user experience - is loosely connected with the fourth principle. However, the company has focused on and described user interface design from the user‟s point of view, in other words the user‟s experience, so deeply that it is valuable to summarize the point. All aspects the 37signals people present, the form of context and design including the language of user interface, are supported to some extent by previous research. A noteworthy matter is that most of the relevant studies are relatively old, from the time before the Internet became common. The newer user interface research mostly focuses on more complicated user interfaces. However, it can be concluded that the same principles are valid with simple and minimalist web applications – such as the products of the researched company. We can conclude that the fourth Getting Real principle is partly supported by previous scientific research.
47
5.5 Getting Real – Principle 5 “Getting Real is about iterations and lowering the cost of change. Getting Real is all about launching, tweaking, and constantly improving which makes it a perfect approach for web-based software.” (Fried & Heinemeier Hansson, 2006.) The fifth Getting Real principle is not directly supported by the Agile Manifesto rules or principles. The Agile Manifesto addresses the possibility of change, but from a different point of view. The Agile Manifesto rule and principle that were introduced in connection with the third Getting Real principle (see Chapter 5.3), “Responding to change over following a plan” and “Welcome changing requirements, even late in development”, refer to one of the main characteristics of agile methods – flexibility for changes. This rule and principle do not handle the cost of change, only flexibility. However, it is self-evident that lowering the cost of change is one important motive behind the establishment of agile methodologies. Lowering the cost of change has been mentioned many times when separate agile methods have been introduced (e.g. Abrahamsson et al., 2002; Highsmith & Cockburn, 2001). The key men of the company emphasize the change possibility from the cost point of view. The cost thinking is in line with their experience of limited development resources and the minimalist design principle. “When it comes to web technology, change must be easy and cheap. If you can‟t change on the fly, you‟ll lose ground to someone who can. That‟s why you need to shoot for less mass” (Fried & Heinemeier Hansson, 2006).
Cost of Change
Kunz, Dumke, and Schmietendorf (2008) summarize the relationship between the cost of change and agile methodologies as follows: “Agile software development methods [like Extreme programming] try to decrease the cost of change and therewith reduce the overall development costs.” The different cost of change in agile software development in comparison with traditional software development according to the project progress as suggested by Beck (1999) is shown in Figure 9.
Traditional
Agile
Time
Figure 9.
The cost of change compared to the development method (Beck, 1999)
In a way, the fifth Getting Real principle is the first instance of dealing with the developing process itself and mentioning iterations. There is a strong connection between iterations and agile methodologies. Miller (2001) has defined nine characteristics which make a software development process agile. One of those
48
characteristics is iteration: “Agile software processes acknowledge that we get things wrong before we get them right. Therefore, they focus on short cycles. Within each cycle, a certain set of activities is completed. These cycles will be started and completed in a matter of weeks. However, a single cycle (called an iteration) will probably not be enough to get the element 100% correct. Therefore, the short cycle is repeated many times to refine the deliverables.” (The other characteristics are modularity, timeboundedness, parsimony, adaptivity, incrementality, convergence, people-orientedness, and collaborativity). Kunz et al. (2008) have found that Extreme Programming (XP) is a common and widespread agile software development method and use it as an example: “The major element of the XP life cycle is „iteration‟. The iteration is a recurring event in which an actual version is edited for example by adding additional functionality, correcting errors or removing unnecessary functionality.” The fifth Getting Real principle addresses the same aspect (iterations) with the model phrase “launching, tweaking, and constantly improving . . .” The key men of the company have described the iterative process as follows: “Instead of banking on getting everything right upfront, the iterative process lets you continue to make informed decisions as you go along. Plus, you‟ll get an active app up and running quicker since you‟re not striving for perfection right out the gate. The result is real feedback and real guidance on what requires your attention” (Fried & Heinemeier Hansson, 2006.) They do not mention agile methodologies but speak about the exactly same iteration characteristic as the researchers and co-founders of agile methodologies. According to the researched company, lowering the cost of change activities is a consequence of many already introduced activities, such as aesthetic and minimalist design (Chapter 4.3.2), avoiding extra features (Chapters 4.3.2 and 5.2.2), programming less code (Chapter 5.2.1), underdoing the competition (Chapter 4.3.2), and keeping the company size small (Chapters 4 and 5.3). Therefore these activities have not been discussed again in this chapter. Conclusion The Agile Manifesto strongly supports flexibility for changes. It does not mention the cost of change viewpoint. However, lowering the cost of change has been recognized as one important motive behind the establishment of agile methodologies, and it is an important characteristic of agile methodologies in general. Thus it has been discussed when agile methodologies have been – commonly or separately – introduced or researched. In the fifth Getting Real principle, iteration is regarded as a method of implementing the lowering of the cost of change. It is totally in line with the characteristics of agile methodologies (see eg. Miller, 2001; Strode, 2006). A noteworthy matter is that also the second Getting Real principle introduces many other methods of implementing the lowering of the cost of change. It can be said that to lower the cost of change is a consequence of iteration, but also of other methods of implementation introduced in Chapter 5.2 “Getting Real – Principle 2”. We can conclude that the fifth Getting Real principle is supported by previous scientific research.
49
5.6 Getting Real – Principle 6 “Getting Real delivers just what customers need and eliminates anything they don’t.” (Fried & Heinemeier Hansson, 2006). The 37signals people have emphasized the importance of eliminating extra features in many sources, as has been discussed above (in Chapters 4 and 5). They have turned it into a competitive advantage, calling it „underdoing the competition‟ (see Chapter 4.3.2.). The content of the sixth Getting Real principle resembles the previously introduced „less software-thinking‟ of the 37signals people (see Chapter 5.2.1): “The way you fight this complexity is with less software. Less software means less features, less code, and less waste.” All these methods and mindsets have been introduced previously in this study, most recently in the previous chapter concerning the cost of change issue (see Chapter 5.5). Therefore, we examine one small new viewpoint in this chapter, the waste eliminating. Wild (2008) has defined principles of lean thinking. One of the seven principles is “eliminate waste” (the others are create knowledge, defer commitment, deliver fast, build quality in, respect people and optimize the whole). Wild (2008) defines waste as follows: -
Anything that does not create value for the customer The customer would be equally happy with the software without it
He explains the prime directive of lean thinking: -
Create value for the customer Improve the value stream by removing non-value-adding activities
Cost
The cost of complexity as suggested by Wild (2008) is illustrated in Figure 10. The curve titled complexity simply means that more features cause more waste. According to Wild (2008), complexity is the biggest source of waste.
Complexity
Essential features
Time
Figure 10.
The cost of complexity (Wild, 2008)
Wild (2008) has found that only 7% of features and functions are always used in typical systems. 13% of them are used often, 16% sometimes, 19% rarely, and 45% never. The
50
percentages are illustrated in Figure 11. It means that only 20% of features and functions are used always or at least often. This means that, roughly speaking, 80% of features and functions are against lean thinking and are waste. Avoiding these 80% could make a lot of savings in the development and maintaining phases. This theory is totally in line with the sixth Getting Real principle and supports it.
Figure 11.
The features and functions used in a typical system (Wild, 2008)
Conclusion It can be concluded that the sixth Getting Real principle is relatively universal by nature. It is a higher-level principle compared to the other Getting Real principles, and it summarizes many other principles and mindsets of the researched company. The sixth Getting Real principle is also in line with the Agile Manifesto (2011) principle: “Simplicity – the art of maximizing the amount of work not done – is essential.” It is also supported by Nielsen‟s (1994) usability heuristics (aesthetic and minimalist design), as well as by Wild‟s (2008) principles of lean thinking (eliminate waste). We can conclude that the sixth Getting Real principle is supported by previous scientific research.
51
6.
Conclusions
This research has identified the scientific support for the Getting Real software development approach. The Getting Real approach was created by a small and bootstrapped American company called 37signals. The key men of 37signals have created the Getting Real approach based on their own experience about developing software applications and commercializing them successfully. The success of the researched company proves they have done at least some things right. Therefore it has been important and interesting to research if the mindset of the company and the development approach is supported by previous researches. Considering the size of the researched company, the company and the Getting Real approach are relatively well known, especially in its home country and by special interest groups. The key men of the company and their books have been cited a few dozen times in academic researches and articles even though they do not have an academic background. The Getting Real approach has not been a research subject before in a comprehensive way, so it has been interesting to connect the provenly successful small business (or small organization) development and business ways to a scientific context. The research method in this study was conceptual analysis. Conceptual analysis was a natural choice because we tried to find out what was the part of theory compared with certain practical activities; in practice, whether the Getting Real principles (based on best practices) are supported by scientific theories. Conceptual analysis was a natural choice also because of the written and audiovisual source material used.
6.1 37signals – the Researched Company There are issues which appear time and again when the company is spoken about. These issues are the large audience, the nature of the products and the unique way of business thinking. The large audience is a fact which is only a consequence of success, lonely rider thinking, and the charisma of the key men of the company. It is hard to find any connection between the followers, fans, or audience and previous research. Nevertheless, Abimbola and Vallaster (2007) have noted that personal contacts between a company and its audience have a positive influence on the company brand. The common factor of 37signals‟ products is that they are all planned to be easy to use, opinionated, and relatively light and simple overall. The simplicity is a consequence of including fewer features in the products. The key men of the company call it „underdoing the competition‟. This is strongly supported by previous research, for instance by the Agile Manifesto (“Simplicity - the art of maximizing the amount of work not done - is essential”) and Nielsen‟s (1994) usability heuristics (aesthetic and minimalist design). The Getting Real principles are strongly linked with software characteristics and have been presented in more detail in the related sections.
52
The researched company has a unique way of business thinking concerning the running of a business. In addition to the successful products, they have ideas based on their best practises about starting a business, running a business, and at the operational level about daily working methods. The company uses fixed pricing for their products, which is supported by Ghayur (2003), who found out that in some cases fixed prices will better commercial ethics from the customer point of view. The key men of the company strongly recommend bootstrapping finance and avoiding venture capital. In the case of small companies, Bhide (1992) argues that bootstrap funding may work well. The 37signals people have paid much attention to personal productivity issues, and one resort is to set a „quiet-time‟ – an agreement among co-workers not to interrupt one another during designated hours – three mornings a week, which made software developers more efficient. This resort is supported by previous research by O‟Conaill and Frohlich (1995), Perlow (1999), and Rennecker and Godwin (2003). The 37 signals people have argued in many sources (e.g. Fried & Heinemeier Hansson 2006; Fried 2008b, Fried & Heinemeier Hansson 2010, pp. 19–20, 97, 109, 124) against meetings and documentation as daily working methods. It is difficult to find any support from previous researches for avoiding meetings. For avoiding documentation (and for concentrating on the real application) is supported by the Agile Manifesto rule (“Working software over comprehensive documentation”). It is also supported by previous researches, for instance by Cockburn (2002), Palmer and Felsing (2002), and Strode (2006).
6.2 The Getting Real Software Development Approach Following the investigation of the Getting Real principles, it can be concluded that many principles include a similar message. Perhaps the authors have meant a somewhat different viewpoint between the principles. However, the main message of the principles could be summarized as follows: The application should have as few features as possible, and the whole development process should focus on building the real things directly instead of deep planning and documentation. That, and being small, make late changes possible, and also keep the cost of changes reasonable. For instance, the messages of the first and fourth principles are very similar to one another, as well as the messages of the second and sixth principles. The Getting Real principles resemble the Agile Manifesto rules and principles, but the viewpoint is somewhat different. The Getting Real principles deal with the nature of an application, which limits its use only to light products, such as web applications. The rules and principles of agile methodologies also address other viewpoints, such as individuals, teams, customers, collaboration, and reviews. However, the agile rules and principles do not commit to the nature of the final product. It would be interesting to know if the 37signals people have thought about the agile rules when defining the Getting Real principles. We tried to find that out with a short personal email interview, but Mr. J. Fried‟s answer was a polite refusal explained by the lack of time (personal email, 24.5.2011). The support from previous research for the Getting Real principles is introduced in Table 1. It shows that the Getting Real principles, which reportedly are based on the best practices of the researched company, are mostly supported by previous researches.
53
Getting Real principle 1 2 3 4 5 6 Table 1.
support from Agile manifesto/ Other scientific Agile methodologies researchs x x x x partly x partly partly x x x x
Scientific support for the Getting Real principles
The first Getting real principle closely resembles one of the four common rules for agile methods (Agile Manifesto, 2011), it is only defined in a more detailed and extensive way. There exists an enormous amount of scientific literature on the agile methods, and most of it cites the Agile Manifesto and shares its rules. The first Getting Real principle is also supported by previous researches, for instance by Cockburn (2002), Palmer and Felsing (2002), and Strode (2006), as well as by other developers, for instance by Torvalds (2005). It can be concluded that the first Getting Real principle is supported by previous scientific research. The second Getting Real principle is very general and extensive. It recommends doing things in a simple and light way at many levels. The general less mass thinking – including all sub-thoughts (less software, less features, less paperwork) – is in line with the Agile Manifesto (2011) principle “Simplicity – the art of maximizing the amount of work not done – is essential.” The second Getting Real principle is also supported by for instance Müller and Tichy (2001), Lindstrom and Jeffries (2004), Nielsen and Mack (1994), Appleton (2005), Wild (2008), and Fernandez (2008). It can be concluded that the second Getting Real principle is supported by previous scientific research. The third Getting Real principle is partly supported by the Agile Manifesto. The Agile Manifesto is not focused on the size of a company, but one of its main ideas is to react fast to requirement changes even in a late phase of the developing process. The agile behavior and possibility for fast reactions are a consequence of a small team or company size. However, some key men behind the Agile Manifesto (e.g. Beck, 1999; Lindstrom & Jeffries, 2004) argue that particular agile methods are meant for small teams. Also many researchers (e.g. Rising & Janoff, 2000; Müller & Tichy, 2001; Abrahamsson et al., 2002; Strode, 2006) share the idea about the small team size. It can be concluded that the third Getting Real principle is supported by previous scientific research. The fourth Getting Real principle is ambiguous. The first point suggests to start the design of an application from the user interface and to design real screens first. It is hard to find support from previous research for this point. The second point – the user experience – is loosely connected with the fourth principle. All aspects the 37signals people present, the form of context and design including the language of the user interface, are supported by previous research to some extent. Parnas (1969), De Souza (1993), and Grudin (1989) present similar ideas about the user interface design. It can be concluded that the fourth Getting Real principle is partly supported by previous scientific research.
54
The fifth Getting Real principle explains the iteration as a method of implementing the lowering of the cost of change. It is totally in line with the characteristics of agile methodologies (see e.g. Miller, 2001; Strode, 2006). A noteworthy matter is that the second Getting Real principle introduces many other methods of implementing the lowering of the cost of change. It can be said that lowering the cost of change is a consequence of iteration, but also of other methods of implementation introduced in Chapter 5.2 “Getting Real – Principle 2”. It can be concluded that the fifth Getting Real principle is supported by previous scientific research. It can be concluded that the sixth Getting Real principle is relatively universal by nature. It is a higher-level principle compared to the other Getting Real principles, and it summarizes many other principles and mindsets of the researched company. The sixth Getting Real principle is also in line with the Agile Manifesto (2011) principle “Simplicity – the art of maximizing the amount of work not done – is essential.” It is also supported by Nielsen‟s (1994) usability heuristics (aesthetic and minimalist design), as well as by Wild‟s (2008) principles of lean thinking (eliminate waste). It can be concluded that the sixth Getting Real principle is supported by previous scientific research. It seems all conclusions support the principle that has occurred time and again; the researched company emphasizes the importance of simple-to-use, opinionated, and light applications that have only those features that the customers need without any extra ones. Considering the success of the company, it seems that at least a part of the customer segment appreciates those kinds of products.
6.3 Discussion As a summary, we can conclude that four out of the six Getting Real principles are supported by the Agile Manifesto, which is, as mentioned, cited in most literature concerning agile methodologies. These four principles are clearly supported by other previous researches as well. One of the six Getting Real principles is not directly supported by the Agile Manifesto, but there are other previous researches which support it. Finally, one the six Getting Real principles is only partly supported by the Agile Manifesto and other previous researches. Consequently, we can conclude that there are not so many new aspects in the Getting Real approach. The ideas included in the principles have existed already before in some form. How is it possible that the media and followers have given so much attention to the Getting Real approach? We think there are many reasons. The company has proved in practice the effectiveness of the Getting Real approach by developing and commercializing successful products. The success of the small company has provided the people of the company with a strong charisma. The charismatic entrepreneurs have been very open and shared their knowledge with their growing audience. The books written by the key men of the company (Getting Real (2006) and Rework (2010)) resemble the company‟s products; they are very light and easy to read and use ordinary language instead of jargon. We think the manner of representation has helped people to appreciate the thoughts of the 37signals people. Even though there are not so many new aspects in the Getting Real principles, it can be said that the small company has picked up the right principles from all possible business and development rules and tenets for strengthening their activities. From a practical point of view, we can conclude that the researched company might be a good
55
benchmarking case for other small business owners as well. From a theoretical point of view, we can conclude that there are no conflicts between previous research and the Getting Real approach. It might also be a good direction for the authorities to start benchmarking these kinds of successful small company stories. In Finland, for instance, the whole public business supporting network aims at finding “a new Nokia”, and the prerequisite for public support is a business plan with unrealistic growth numbers. The Internet has made the world smaller, and internationalization is easier than ever before for small companies too. As a matter of fact, the “old Nokia” is not growing in its home country any more, and the kind of small company studied in this research could be a nice direction for creating new places of employment – without fictitious growing plans. The aim of this research was to find out if there is scientific evidence for the principles of the Getting Real approach. We think we have met this target. The limitations of the research were the empirical references since it was not possible to conduct a personal interview with the company people. It might have given more detailed information than just the written and audiovisual material. This research is relatively universal and it includes wide viewpoints. After this research, there might be two directions to continue in this field. From a software business point of view, it could be useful to examine the success factors of this kind of small software company at a more detailed level. From a software developing point of view, it could be useful to go deeper into the developing philosophy and processes of this kind of successful small company.
56
References 37signals. (2011). The 37signals home page. Retrieved from http://37signals.com/ (Accessed 31.1.2011). Abimbola, T., & Vallaster, C. (2007). Brand, organizational identity and reputation in SMEs: an overview. Qualitative Market Research: An International Journal, 10 (4), 341–348. Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Development Methods. Review And Analysis. VTT Publications 478. Espoo: Otamedia Oy. Abrahamsson, P., Warsta, J., Siponen, M., & Ronkainen, J. (2003). New directions on agile methods: A comparative analysis, Proceedings of the International Conference on Software Engineering, May 3–5, Portland, 244–254. Agile Manifesto. (2011). Manifesto for agile software development. Retrieved from http://agilemanifesto.org/ (Accessed 13.4.2011). Al-Sulaiti, L., & Knowles, G. (2002). A multimedia Arabic course, Proceedings of the International Symposium on the Processing of Arabic, 94–105. Appleton, B. (2005). Brad Appleton’s ACME blog. Retrieved from http://bradapp.blogspot.com/2005/02/there-is-no-code-that-is-more-flexible.html (Accessed 11.5.2011). Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I., & Zaharia, M. (2010). A view of cloud computing. Communications of the ACM, 53 (4), 50–58. Avison, D.E., & Fitzgerald, G. (1991). Information Systems Development. Oxford: Blackwell Scientific Publications. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Reading, MA: Addison-Wesley. Bhide, A. (1992). Bootstrap finance: the art of start-ups. Harvard Business Review, 70 (6), 109–117.
57
Blackstone, E.H. (2007). Planning the research. Clinical Research Methods for Surgeons, I, (3–29). Burrows, P. (2004). The seed of Apple‟s innovation. Retrieved from http://www.businessweek.com/bwdaily/dnflash/oct2004/nf20041012_4018_db083.htm. Business Week, 12.10.2004 (Accessed 7.3.2011). Bächle, M., & Kirchberg, P. (2007). Ruby on Rails. IEEE Software, 24 (6), 105–108. Campfire. (2011). The Campfire home page. Retrieved from http://campfirenow.com/ (Accessed 31.1.2011). Caplan, J. (2007). Small is essential. Retrieved from http://www.time.com/time/magazine/article/0,9171,1622565,00.html. Time Magazine, 17.5.2007 (Accessed 30.5.2011). Chandler, D. (2001). Semiotics: The Basics. London: Routledge. Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley. Constantine, L.L., & Lockwood, L. A. D. (2002). Usage-centered engineering for web applications. IEEE Distributed Systems Online, 19 (2), 42–50. Cooper, R.G. (1990, May–June). Stage-Gate systems: A new tool for managing new products. Business Horizons. De Souza, C. S. (1993). The semiotic engineering of user interface languages. International Journal of Man Machine Studies, 39, 753–773. Eco, U. (1976). A Theory of Semiotics. Bloomington: Indiana University Press. Fernandez, O. (2008). The Rails Way. Upper Saddle River, NJ: Addison-Wesley. Freear, J., Sohl, J., & Wetzel, W. (1995). Angels: Personal investors in the venture capital market. Entrepreneurship and Regional Development, 7, 85–94. Fried, J., & Heinemeier Hansson, D. (2006). Getting Real. [book]. Retrieved from http://gettingreal.37signals.com/toc.php (Accessed 10.1.2011). Chicago. Fried, J., & Heinemeier Hansson, D. (2010). Rework. London: Vermillion.
58
Fried, J. (2009a). Jason Fried of 37signals at BIG Omaha 2009. A presentation at the BIG Omaha event. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 1.2.2011). Fried, J. (2009b). Jason Fried of 37signals at FOWA Miami 2009. A presentation at the FOWA Miami event. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 25.2.2011). Fried, J. (2008a). Jason Fried of 37signals at Business Innovation Factory 4. A presentation at the Business Innovation Factory event. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 15.2.2011). Fried, J. (2008b). Jason Fried of 37signals at Business of Software 2008. A presentation at the Business of Software event. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 17.3.2011). Fuggetta, A. (2000). Software process: A roadmap, Proceedings of the Conference on The Future of Software Engineering, 25–34. Getting Real. (2011). Getting Real. Introduction page. Retrieved from http://gettingreal.37signals.com/ (Accessed 26.1.2011). Ghayur, A. (2003). Utilising the surging potential of e-commerce: A case of hour glass supply chain. The Pakistan Development Review, 42 (4), 607–625. Glass, R.L., Vessey, I., & Ramesh, V. (2002). Research in software engineering: An analysis of the literature. Information and Software Technology, 44 (8), 491–506. Grudin, J. (1989). The case against user interface consistency. Communications of the ACM, 32 (10), 1164–1173. Grudin, J., & Gentner, D. R. (1990). Why good engineers (sometimes) create bad interfaces, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems: Empowering People, 277–282. Harmon, R., Demirkan, H., Hefley, B., & Auseklis, N. (2009). Pricing strategies for information technology services: A value-based approach, Proceedings of the 42nd Hawaii International Conference on System Sciences – 2009, 1–10. Harmon, R., Raffo, D., & Faulk, S. (2004). Value-based pricing for new software products: strategy insights for developers, Proceedings of the Portland International Conference on the Management of Engineering and Technology, 1–24.
59
Heinemeier Hansson, D. (2009). David Heinemeier Hansson of 37signals at FOWA Dublin 2009. A presentation at the FOWA Dublin event, Ireland. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 5.5.2011). Heinemeier Hansson, D. (2008a). David Heinemeier Hansson of 37signals interview with O‟Reilly. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 27.5.2011). Heinemeier Hansson, D. (2008b). David Heinemeier Hansson of 37signals at Startup School 2008. A presentation at the Startup school, Stanford University. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 7.2.2011). Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34 (9), 120–122. Huitfeldt, C., & Sperberg-McQueen, C.M. (2008). What is transcription? Literary and Linguistic Computing, 23 (3), 295–310. Ivarson, M., & Gorschek, T. (2009). Technology transfer decision support in requirements engineering research: a systematic review of REj. Requirements Engineering, 14 (3), 155–175. Järvinen, P. (2004). On Research Methods. Tampere: Opinpajan kirja. Kilduff, M. (1993). Deconstructing organizations. Academy of Management Review, 18 (1), 13–31. Kunz, M., Dumke, R., & Schmietendorf, A. (2008). How to measure agile software development. Lecture Notes in Computer Science, 4895, 95–101. Lindstrom, L., & Jeffries, R. (2004). Extreme Programming and agile software development methodologies. Information Systems Management, 21 (3), 41–52. MacCormack, A., Verganti, R., & Iansiti, M. (2001). Developing products on “Internet time”: The anatomy of a flexible development process. Management Science, 47 (1), 133–150. McCayley, R. (2001). Agile development methods poised to upset status quo. ACM SIGCSE Bulletin, 33 (4), 14–15. Miller, G. G. (2001). The characteristics of agile software processes, Proceedings of the 39th International Conference and Exhibition on Technology of Object-Oriented Languages and Systems, 385–387.
60
Molin-Juustila, T. (2001). Market Centered Model of the Early Phases of SW Product Development, Proceedings of the 24th Information Systems Research Seminar in Scandinavia, 1–14. Moore, G.A. (1991). Crossing the Chasm. New York: HarperCollins Publishers. Müller, M., & Tichy, W. (2001). Case Study: Extreme programming in a university environment, Proceedings of the 23rd International Conference on Software Engineering, 537–544. Nambisan, S., & Wilemon, D. (2000). Software development and new product development: Potentials for cross-domain knowledge sharing. IEEE Transactions on Engineering Management, 47 (2), 211–220. Nerur, S., Mahapatra, R., & Mangalaraj, G. (2005). Challenges of migrating to agile methodologies. Communications of the ACM, 48 (5), 73–78. The New York Times (2011). Hardcover business best sellers. Retrieved from http://www.nytimes.com/2011/01/02/books/bestseller/besthardbusiness.html. The New York Times January 2, 2011 (Accessed 8.2.2011). Ni, H., & Wu, X. (2009). The impact of semantics on the product design research. Proceedings of the IEEE 10th International Conference, 273–276. Nielsen, J. & Mack, R. L. (1994). Usability Inspection Methods. New York: John Wiley & Sons. O‟Conaill, B., & Frohlich, D. (1995). Timespace in the workplace: Dealing with interruptions. Proceedings of the CHI ’95 Conference Companion on Human Factors in Computing Systems, 262–263. O‟Reilly, T. (2005a). Web 2.0: Compact Definition?. O'Reilly radar blog. Retrieved from http://radar.oreilly.com/archives/2005/10/web_20_compact_definition.html (Accessed 17.2.2011). O‟Reilly, T. (2005b). What is Web 2.0: Design patterns and business models for the next generation of software. Retrieved from http://oreilly.com/web2/archive/what-isweb-20.html (Accessed 17.2.2011). Palmer, S. R., & Felsing, J. M. (2002). A Practical Guide to Feature-Driven Development. Upper Saddle River: Prentice-Hall.
61
Park, A. (2008). The Brash Boys at 37signals will tell you: keep it simple, stupid. Retrieved from http://www.wired.com/techbiz/media/magazine/1603/mf_signals?currentPage=1. Wired Magazine March 16, 2008 (Accessed 23.5.2011). Parnas, D. L. (1969). On the use of transition diagrams in the design of a user interface for an interactive computer system. Proceedings of the 1969 24th national conference, 1969, 379–385. Perlow, L. (1999). The time famine: Toward a sociology of work time. Administrative Science Quarterly, 44 (1), 57–81. Power, B., & Reid, G. C. (2005). Flexibility, Firm-Specific Turbulence and the Performance of the Long-Lived Small Firm. Review of Industrial Organization, 26 (4), 415–443. Puusa, A. (2008). Käsiteanalyysi tutkimusmenetelmänä, Premissi, 4, 36–43. (In Finnish) Rails. (2011a). Ruby on Rails homepage. Retrieved from http://rubyonrails.org/ (Accessed 16.2.2011). Rails. (2011b). Ruby on Rails Guides. Retrieved from http://guides.rubyonrails.org/getting_started.html (Accessed 16.2.2011). Rails. (2011c). Getting started with Rails. Retrieved from http://www.scribd.com/doc/17673862/04703749502 (Accessed 16.2.2011). Rails Statistics. (2011). Stats since 2009. Retrieved from http://rubygems.org/stats (Accessed 17.2.2011). Rennecker, J., & Godwin, L. (2003). Theorizing the unintended consequences of instant messaging for worker productivity. Working Papers on Information Environments, Systems and Organizations, 3 (3), 137–168. Rising, L., & Janoff, N. S. (2000). The Scrum software development process for small teams. IEEE Software, 17 (4), 26–32. Ronkainen, S., & Häkkilä, J., & Pasanen, L. (2005). Effect of Aesthetics on Audioenhanced Graphical Buttons. Proceedings of the ICAD 05 – Eleventh Meeting of the International Conference on Auditory Display, 121–126. Ronstadt, R. (1988). The Corridor Principle. Journal of Business Venturing, 3 (1), 31– 40.
62
Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum. Upper Saddle River: Prentice-Hall. Schwaber, K., & Sutherland, J. (2010). The Scrum Guide. Retrieved from http://www.scrum.org/scrumguides/ (Accessed 20.4.2011). Signal vs. Noise. (2011). Signal vs. Noise, a weblog by 37signals about design, business, experience, simplicity, the web, culture, and more. Retrieved from http://37signals.com/svn (Accessed 21.2.2011). Singer, R. (2008). Ryan Singer of 37signals at FOWD New York 2008. A presentation at the FOWD (Future of web design) event. [video clip]. Retrieved from http://37signals.com/speaks (Accessed 6.3.2011). Sloman, A. (1978). The Computer Revolution in Philosophy: Philosophy Science and Models of Mind. Sussex: The Harvester Press Limited. Retrieved from http://www.cs.bham.ac.uk/research/projects/cogaff/crp/crp.pdf (Accessed 26.3.2011). Stage-Gate. (2011). Stage-Gate International. Retrieved from http://www.stagegate.com (Accessed 7.4.2011). Strode, D. (2006). Agile methods: A comparative analysis, Proceedings of the 19th Annual Conference of the National Advisory Committee on Computing Qualifications, 257–264. Torvalds, L. (2005). Linux: Linus On Specifications. Retrieved from http://kerneltrap.org/node/5725 (Accessed 5.5.2011). Ulrich, T., & Eppinger, S.D. (2008). Product Design and Development. Singapore: The McGraw-Hill Companies. Useit.com. (2011). About Jakob Nielsen. Retrieved from http://www.useit.com/jakob/ (Accessed 4.3.2011). Wikipedia. (2011). Modus Operandi. Retrieved from http://en.wikipedia.org/wiki/Modus_operandi (Accessed 7.3.2011). Wild, W. (2008). Agile Software-Development & Tools. Retrieved from http://www.softnet2008.info/download/Wild.pdf (Accessed 12.5.2011).
