Graduate Program in Computer Science
Converge model:
teaching innovation alongside software development
by
Bianca Helena Ximenes de Melo e Menezes
Master’s Thesis
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
RECIFE 2015
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
GRADUATE PROGRAM IN COMPUTER SCIENCE
BIANCA HELENA XIMENES DE MELO E MENEZES
CONVERGE MODEL: TEACHING INNOVATION ALONGSIDE SOFTWARE DEVELOPMENT
RECIFE 2015
THESIS PRESENTED IN THE GRADUATE PROGRAM IN COMPUTER SCIENCE AT THE COMPUTER SCIENCE CENTER FROM UNIVERSIDADE FEDERAL DE PERNAMBUCO AS A PARTIAL REQUIREMENT FOR OBTAINING A MASTER’S DEGREE IN COMPUTER SCIENCE.
Catalogação na fonte
Bibliotecária Jane Souto Maior, CRB4-571
M543c Menezes, Bianca Helena Ximenes de Melo e Converge model: teaching innovation alongside software development / Bianca Helena Ximenes de Melo e Menezes. – Recife: O Autor, 2015.
95 f.: il., fig.
Orientador: Cristiano Coelho de Araújo.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da computação, 2015.
Inclui referências e apêndice.
1. Engenharia de software. 2. Gestão da inovação. 3.
Empreendedorismo. I. Araújo, Cristiano Coelho de (orientador). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2015-71
Dissertação de Mestrado apresentada por Bianca Helena Ximenes de Melo e Menezes à Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco, sob o título “Converge Model: Teaching Innovation Alongside Software
Development”, orientada pelo Prof. Cristiano Coelho de Araújo e aprovada pela Banca
Examinadora formada pelos professores:
______________________________________________ Prof. Kiev Santos da Gama
Centro de Informática/UFPE
______________________________________________
Prof. Pedro Martins Alessio
DepartamentodeExpressão Gráfica / UFPE
_______________________________________________ Prof. Cristiano Coelho de Araújo
Centro de Informática / UFPE
Visto e permitida a impressão. Recife, 20 de março de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Acknowlegments
- Ao Professor Cristiano, por confiar em mim mesmo sem me conhecer, me dando a chance de trilhar um novo caminho na minha vida, onde sou muito mais feliz.
- À Professora Judith, pelo acolhimento, pela generosidade em me ceder tempo pra que eu terminasse o manuscrito e pela disponibilidade em ajudar sempre.
- Aos meus pais, Hélio e Heloiza, por serem meus maiores e mais incansáveis fãs.
- Aos meus irmãos, Eduardo e Adriana, pela parceria top e por me ajudar a escolher as citações de abertura para cada capítulo. Não foi fácil!
- Ao meu namorado, Wellington, pelo amor, carinho e risadas diárias.
- Aos meus amigos, felizmente muitos pra nomear de um por um, por aguentarem minhas choradeiras, me entenderem e apoiarem toda vez que me recusei a sair pra me dedicar à dissertação, e sempre me renderem bons momentos de descanso.
- E, finalmente, aos amigos do BlackBerry Tech Center – Alexandre, Daniel, Délio, Dicksson, Gabriel, Isadora, João Felipe, Ligeiro, Luiz, Newton, Pedro, Roberta, Rodrigo, Gutemberg e Yuri. Vocês me deram o prazer de trabalhar e aprender junto com vocês. Foi lindo ver cada um crescer dia após dia. Vocês me deixam orgulhosa e realizada por fazer o que faço.
E um “obrigada” especial ao amigo Joselito Júnior. Do or do not - there is no try. Obrigada por me poupar de todas as reuniões e e-mails e por entender quando eu deixei nossos projetos em segundo plano. Obrigada por debater comigo e aprimorar minhas idéias, e por acreditar no que construí.
Resumo
A indústria de desenvolvimento de software passou por grandes mudanças na última década. O aumento de fluxo de pessoas para os dispositivos móveis, junto à popularização da internet das coisas e dos dispositivos vestíveis expandiram mercados e mudou a indústria. Todos esses fatores combinados oferecem oportunidades em nichos inovadores de mercado. No entanto, os projetos e startups do setor de tecnologia muitas vezes falham por uma série de razões que raramente são técnicas, relacionadas na realidade ao conhecimento de mercado e do usuário. Uma das possíveis causas para o insucesso é que o ensino superior em desenvolvimento de software na área de Ciência da Computação relega a segundo plano aspectos de mercado, consequentemente fornecendo aos alunos formação insuficiente para lidar com desafios reais dos projetos de software.
A fim de abordar esta situação, um modelo de gestão que objetiva guiar o desenvolvimento de produtos inovadores de software é proposto. Este modelo, denominado Converge, considera que todo projeto de software é baseado em três pilares - capacidade técnica, mercado e usuário. Para acomodar esses três aspectos, o estado da arte dos métodos ligados a cada um dos pilares foi investigado extensivamente, permitindo a combinação dos métodos. Esses métodos são o desenvolvimento Ágil (representado por práticas de Scrum e Extreme Programming), Lean Startup e Design Thinking.
A eficácia do modelo Converge para orientar projetos de software foi avaliada através da implantação do modelo dentro de um laboratório de experimentação mobile na Universidade, composta exclusivamente por alunos de graduação. Após a implantação do modelo, houve uma avaliação do seu impacto em produtos finais, no processo de desenvolvimento e na formação dos alunos, durante 10 meses. Dois estudos de caso foram feitos e são descritos nesta dissertação, explicando o processo e listando resultados qualitativos. Finalmente, para avaliar se os estudantes que participaram do laboratório mudaram sua percepção acerca de desenvolvimento de software e desenvolveram habilidades além da capacidade técnica, um questionário subjetivo foi aplicado e os resultados analisados, descrevendo a influência do modelo Converge no desenvolvimento dos alunos e possíveis aplicações educacionais.
Palavras-chave: Modelo de Gestão. Formação. Inovação. Lean Startup. Design Thinking. Metodologias Ágeis.
Abstract
The software development industry has gone through great changes in the last decade. The shift from computer to mobile devices, alongside the popularization of internet of things and wearables have expanded markets and changed the industry. All these factors combined offer many opportunities in innovative new market niches. However, technology-sector projects and startups often fail for a number of reasons that are rarely technical, related instead to market and customer discovery. One of the possible causes is that higher education in software development in the field of Computer Science overlooks business and market aspects, consequently underpreparing students to deal with real-life challenges in software projects.
In order to address this situation, a management model meant to guide the development of innovative software products is proposed. This model, named Converge, considers every software project is based on three pillars – technical ability, market and user. To accommodate those three aspects, state of the art methods connected to each pillar were studied extensively and combined. Those methods are Agile development (represented by Scrum and Extreme Programming practices), Lean Startup and Design Thinking.
Converge Model’s efficacy in guiding software projects was assessed by implanting the model inside a University mobile experimentation lab that consisted exclusively of undergraduate students. After implantation, there was an assessment of the model’s impact on final products, development process and students’ education, during 10 months. Two case studies were done and are described in this work, explaining the process and listing qualitative results. Finally, to evaluate whether students who took part in the lab changed their perception of software development and developed skills besides technical abilities, a subjective questionnaire was applied and its results examined, depicting Converge Model’s influence on students’ formation and possible educational applications.
Keywords: Management model. Education. Innovation. Lean Startup. Design Thinking. Agile methodologies.
List of figures
Figure number Title Page number
Figure 1-1 Relevance of innovation in the product life cycle 15
Figure 2-1 Graphic responses for group 1 (Undergrads) and group 2
(Specialists) 22
Figure 2-2 Scrum framework highlights 24
Figure 2-3 Build-measure-learn cycle and Lean Startup outline 26
Figure 2-4 Stanford’s d.school Design Thinking spaces 27
Figure 2-5 Comparison of Lean Startup and traditional Agile
deliveries 31
Figure 4-1 Agile’s contribution and structure in the model 51
Figure 4-2 Lean’s contribution and structure in the model 52
Figure 4-3 Design Thinking’s contribution and structure in the model 54
Figure 4-4 The Converge model 56
Figure 4-5 The Converge Model flow after MVP release 57
Figure 5-1 Initial game concept 59
Figure 5-2 First cardboard prototype of version 1.0 62
Figure 5-3 Character sprites for version 1.0 63
Figure 5-4 Cardboard prototype for the game’s second version 66
Figure 5-5 High-fidelity, JavaScript prototype for game’s second
version 68
Figure 5-6 Character sprites for version 2.0 70
Figure 5-7 Comparison of 1.0 and 2.0 versions’ layouts 72
Figure 6-1 Understanding of the methods by students who took part in
the study 76
Figure 6-2 Understanding of the methods by Undergrads and
List of tables
Table number Title Page number
Table 2-1 Manufacturing versus software wastes 26
Table 3-1. Results of lab apps in the market exclusively with Agile 39 Table 3-2 Synthesis of the EasyLaw project, using Agile and Lean
Startup 41
Table 3-3 Synthesis of the Startup Raise project, using Lean
Startup and Design Thinking 42
Table 3-4 Synthesis of the Brasil+9 project, using Design
Thinking and Agile 43
Table 3-5 Synthesis of the Pet Empires project, using Agile, Lean
Startup, and Design Thinking 44
Table 3-6 Synthesis of key characteristics of the three
methodologies 47
Table 4-1 The most desirable traits for this works’ scenario 49
Table 5-1 Pet Empires’ split tests summary 69
Table 5-2. Percentage of positive answers in the final qualitative
validation 71
Table 6-1 Synthesis of lab’s projects through time 75
Table 6-2 New valued aspects in software development 78
Table 6-3 Final considerations on students’ formation 79
Table C-1 Issues identified in Pet Empires Version 1 95
Table C-2 Differences in mechanics and structure in Pet Empires
Abbreviations and acronyms
App Application
DT Design Thinking
HCI Human-Computer Interaction
IAP In-App Purchase
IGDA International Game Developer Association
IT Information Technology
MVP Minimum Viable Product
UX User Experience
UVP Unique Value Proposition
Index
Acknowlegments 5 Resumo 6 Abstract 7 List of figures 8 List of tables 9Abbreviations and acronyms 10
1. Introduction 14
1.1 Context and motivation ... 14
1.1.1 Product and market motivation ... 14
1.1.2 Educational motivation ... 17
1.2 Research objectives ... 18
1.3 Results and application ... 18
1.4 Concepts ... 19
2. Understanding the scenario 20 2.1 Choosing a development model with which to work ... 20
2.2 Digging into Agile, Lean Startup and Design Thinking concepts ... 23
1.1.1 Agile – Scrum and XP ... 23
2.2.1 Lean Startup ... 25
2.2.2 Design Thinking ... 27
2.3 Combining Agile, Lean Startup and Design Thinking ... 28
2.3.1 Agile and Lean Startup ... 29
2.3.2 Lean Startup and Design Thinking ... 31
2.3.3 Design Thinking and Agile ... 33
2.3.4 Agile, Lean Startup and Design Thinking ... 36
3. Experimenting with combinations 39
3.1 Experiments with real projects ... 40
3.2 Discussing the experiments and remaining challenges ... 45
3.3 Summarizing the findings ... 46
4. Building an efficient model 48 4.1 Model conception ... 48
4.2 Model structure ... 50
4.2.1 Agile ... 50
4.2.2 Lean Startup ... 51
4.2.3 Design Thinking ... 53
4.2.4 The final structure ... 56
4.3 Model limitations ... 57
4.4 A widespread search for a model ... 58
5. Case Study – Pet Empires 59 5.1 Version 1.0 – no model to follow ... 59
5.2 Version 1.0 feedback – a total failure ... 62
5.3 Version 2.0 – introducing the Converge Model ... 63
5.3.1 The first-week immersion ... 63
5.3.2 The learning loops ... 65
5.3.3 Testing and using real feedback ... 65
5.4 Version 2.0 feedback – making it a success ... 69
5.5 Why did it work? ... 71
6. The impact of Converge Model 73 6.1 Synthesis of market results ... 73
6.2 Synthesis of educational results ... 74
6.3 Threats to validity ... 80
6.3.1 Threats to external validity ... 80
6.3.2 Threats to internal validity ... 80
6.3.3 Threats to construct validity ... 81
7.1 Thesis overview ... 82 7.2 Contributions ... 84 7.2.1 Applied Contributions ... 84 7.2.2 Scientific Contributions ... 84 7.3 Future developments ... 85 References 87 Annex A 93 Annex B 95
1. Introduction
“I'd take the awe of understanding over the awe of ignorance any day.”
Douglas Adams
This Chapter approaches the problematic dealt with in this thesis. First of all, the motivation and context are discussed, both from a product/market and an educational point of view1.
1.1 Context and motivation
The motivation for this work is twofold. Part of it deals with innovative software products and their importance to the global market; the other part considers the software development educational aspect. Both are explained in details in the following subsections.
1.1.1 Product and market motivation
The software development industry has gone through significant changes in the last decade. The shift from computer to mobile devices, alongside the popularization of ubiquitous computing, internet of things and wearables have expanded markets and changed the industry. Firstly, competition now is greater than it ever was, as Computer Science enrollment numbers grow steadily from year to year, crowding the labor market [63]. Secondly, since software products do not have simply a utilitarian, work application anymore, permeating all aspects in modern life, the importance to provide memorable experiences and facilitate user’s lives is now a focus. All these factors combined offer many opportunities in innovative new market niches.
But how can software development teams lead an innovative process, create a five-star product and still deliver in time? Methodologies such as Agile (using techniques such as Extreme Programming, Scrum, Kanban) have become more common and attempted to change this scenario, preparing teams to be more adaptive and coming to closer contact with clients and customers.
1 This thesis was funded by FACEPE.
However, some issues are still left unresolved or not satisfactorily handled. For instance, lack of contact with product users, being out of touch with the market trends and pursuing unclear project goals still permeate the daily lives of programmers, making them focus almost exclusively on coding, which is not likely to single-handedly provide great experience and market innovation2.
The market know-how of technology teams rarely compares to their technical know-how. This is made evident by the high rate of failures, caused by many projects being released with intrinsic errors in the design, not allowing efficient generation of profit. In fact, according to [62], about 70% of IT (Information Technology) projects fail, and 25% of IT projects never generate revenue.
At the same time, the pull for innovation is an indisputable issue in the global economic system, according to Vernon’s international product life cycle model. It posits that major global competitors, such as China and India, who can copy gadgets and programs in record time and with very low cost, the roadmap for a country to remain ahead economically is to keep the creative process and continuous innovation, preferably creating goods with high technology and added value. Innovation is the engine of economic growth; countries and companies that invest in it are largely responsible for the non-stagnation of the world economy (Figure1-1).
2 According to Geoff Nicholson, “Innovation is transforming knowledge into money” [65]
Figure 1-1 Relevance of innovation in the product life cycle
Figure 1-1 demonstrates that innovative countries introduce new goods and services in the global market and profit from exporting such goods; however, it is a matter of time until other developed and developing countries start copying, and the profit coming from exports decreases, as it is possible to produce at lower costs elsewhere. In the end, the innovative country will import more of the product produced than export. So, to remain ahead, an innovative country, which generates productive impetus, should permanently move the product curve to the right, which means to create and introduce new products in the global market [58]. This situation, depicted as a Macro scenario, also applies to Micro scenarios, in enterprises. Price competition is hard to maintain, for competition drives prices down. Ergo, for a company to remain profitable and attractive, it ought to be innovative.
The IT industry is dynamic and prone to the appropriation of new market niches through innovation, focus on treating problems and solution generation. However, as argued above, good ideas constantly do not have the expected return, not rewarding the disbursement made. The reasons vary, but around 54% of cases are due to poor project management and misinterpretation of stakeholders’ needs [62].
Two recent movements that have become popular in the technology and software industries are Lean Startup and Design Thinking. Lean Startup brings a market focus to project development and was conceived inside a software development company. The Lean Startup movement begun with Eric Ries, who defined a startup as being “a human institution designed to create a new product or service under conditions of extreme uncertainty” [51]. Its philosophy is to transform teams into efficient learning units that do not build products nobody wants to use. Design Thinking, made popular by Tim Brown conveys that the methodology employed by designers when approaching problems can be applied in all areas of knowledge in order to achieve innovation [7]. True innovation lies in working out a creative solution that is desirable for the consumer, economically viable and technically feasible. Thus, Design Thinking is a tool that helps develop new products, services, processes and strategies. These two movements address common problems identified by specialized literature regarding IT project failure, in both the business and the user aspects. Besides, they encourage an environment where it is possible to transform uncertainty into new products, generating innovation.
For all reasons presented above, the idea of combining them in the software development scenario and making a unique model with the state-of-the-art methods for software and startup developments, and user experience design with the aim of fostering innovation appeared to be interesting and worthy of further investigation.
1.1.2 Educational motivation
As explained before, innovative projects and startups are a pulse for the global economy. Despite the exciting new niches and possibilities, technology startups have high failure rates (they span from 55%-90% according to the study). There are many opportunities, but many young companies fail, for several reasons. A research made by Fortune Magazine appoints the most prominent reason as being building something for which there is no market – essentially, products nobody wants [17]. This is most likely due to the fact teams become too focused on technical aspects and entrapped in their own product vision, as seen in [57], which also highlights the products built do not solve real problems. Furthermore, [10] also indicates no go-to market strategy and lack of competitive research as common problems. Finally, [2] explains the major pitfall is the teams’ inability to put themselves in the users’ shoes, truly understanding the way they think and what they need, a concern echoed by all other authors.
These reasons for failure identified by authors and startup owners themselves are the main reasons why IT projects fail as well [11, 13, 33]. It is possible that startups and IT projects fail for the reasons identified above because they usually are software-based companies (at least among the most valuable ones, all are [18]), consisting majorly of Computer Science (CS) graduates and undergraduates. This means that, be it a startup or a more traditional tech company, great part of the workers have the same background, and a similar set (or lack) of skills. Higher education institutions seems to be at fault, for software development skills often come short of market needs. Startups’ pitfalls can be an indicator of common pitfalls of software education itself, in a practical, straightforward way. Hence, the problem of making better, more consistent startups would be the same as providing better, more complete software development education.
Students can learn through internships in established companies and gain some of the skills that University did not provide, by working on real projects; however, it is not possible for all students to get internships, and companies are not usually focused on learning or teaching, but delivering fast and cheaply, instead. For that reason, startups are good for learning and start dealing with real market demands. Besides, in startups it is also easier to stimulate learning, because there are no client or time pressures: the team drives the process. They can benefit from incubators. Fortunately, the trend of creating startup incubators inside Universities, collaborating with well-established companies, is now very common. It makes it possible to create research and development labs that can bridge the gap between the real-world requirements and educational requirements.
This thesis champions that it is possible to improve software development education by teaching students how to be innovative entrepreneurs, while they work on their own projects. This is the hypothesis that was examined throughout this study.
1.2 Research objectives
The main objective of this work is suggesting a methodology that guides students in the systematic development of innovative products that take the form of software.
The specific objectives were:
A. Investigating and comparing state of the art methodologies adopted in the software development scenario which address technical, market, and user aspects, as well as understanding their role in producing innovative products;
B. Training students, developing skills little explored in the mandatory curriculum and beyond technical competence, by encouraging entrepreneurship and user-centric computing; C. Proposing a management model for innovative products grounded theoretically and
validated empirically.
1.3 Results and application
The main result is a management model named Converge. This model is grounded theoretically and applicable to other scenarios with the same specifications as the one where it was conceived and tested. Such scenarios develop projects whose final delivery is an innovative product in the form of software. This model has not been tested outside the software production scope. The products in this context are result of team’s view of results and user input and observation. The developers, in this situation, are also active in the conception of the idea. For that to be possible, teams ideally work dedicatedly on a single project until delivery and are multidisciplinary, but predominantly formed by software developers, be them students of professionals.
The model was applied inside an experimentation lab and used to manage seven mobile app projects developed between August 2013 and May 2014. The main goal was releasing quality software to the market, and six out of the seven projects were successful, meaning they reached
the market and users, and consistently received high ratings in the app store, with mode ratings of 5 stars. The seventh project never got to market as the lab was closed down before it was finished.
1.4 Concepts
In this work, innovative solutions are considered a product that changes the flow users normally undertake to complete a task. According to [7], innovation is result of user observation and team’s insights.
A project is deemed successful if it is qualitatively approved by at least 70% of the final testers, at least 30% of users are willing to pay for the service and it is subsequently released to the market. If the project never reaches a 70% approval rate or 30% willing payers rate, or if it does reach both percentages but is never released, it is considered a failure. The need to define what makes an IT project a success of failure comes from the varied and sometimes controversial methods used across the industry [13]. It also comes from Lean Startup ideology that teams select metrics to monitor in order to assess if their hypotheses are being validated [44].
2. Understanding the scenario
“Give me six hours to chop down a tree and I will spend the first four sharpening the axe”
Abraham Lincoln
One of the specific aims of this work is to explain, comparing and contrasting, the differences among state of the art methodologies employed in the software development scenario which address technical, market, and user aspects.
This chapter is therefore divided into four sessions. The first session concerns the choice of a development method that permeated the local software development scenario and would serve as a cornerstone for the model, making it easier to make developers accept integrating new perspectives. The second session describes the core characteristics of the three methods chosen to address each one of the pillars. The third session presents related work concerning the blending of such methods and their effects on software products, including a table comparing the authors understanding of the core beliefs in each methodology. Finally, the fourth session discusses the challenges evidenced in the theoretical scenario that must be addressed by the model.
Works from other areas or on other topics (creativity, management, uncertainty, project failure rates, education applications) were used in this thesis to provide further data on given topics and support some arguments. They are not introduced as a group in this Chapter because they are not part of the main theoretical body of this thesis.
2.1 Choosing a development model with which to work
The data presented in the Introduction of this thesis concerning project and startup failure suggests that, from a technical point of view, problems that compromise the delivery of software are not common or widespread, being instead fruit of local issues. At the same time, the data also suggests that there is a lack of knowledge concerning market and user development methods.
This work chose to investigate the application of Lean Startup and Design Thinking in software projects especially because it concerns innovation, and both methods are innovation-driven. However, the technical pillar remains unattended. The choice of a development method
that would blend in with Lean Startup and Design Thinking was made having developers and their habits in mind, as the model should disrupt the coding process as little as possible.
In order to propose an effective methodology for innovative projects, it is essential to have the acceptance of the development community. Inserting two other perspectives in the software development context may generate tension and reluctance, because it demands in itself a change in the natural workflow. For that reason, minimizing these changes is a concern. Besides, using a widely accepted development method is a way to gain sympathy and enter the software development scenario more easily, making the industry perceive it as a marginal change instead of a complete overhaul.
This research to identify the most ingrained method in the local development scenario was carried out via an online questionnaire made in Google Forms and sent via e-mail to two groups of people, all of them studying or working in the city of Recife. The questionnaire contained objective questions in which participants had to mark which methods they knew, which they had already used and which they would choose to guide a personal project. More than one option could be marked for methods volunteers knew and had used, but only a single option could be marked for which one they would choose, as a means to define the preferred method. The development methods listed as possible options were Waterfall, Agile, RUP or UP, Spiral, RAD and V. The order in which they appeared to each volunteer was random.
The first group, henceforth referred to as “Undergrads”, consists of undergraduate students from three local Universities (UFPE, UPE, UNICAP) which offer IT-related courses (Computer Science, Computer Engineering, Information Systems and Digital Games), who have also had experience working in software development business, as 40% of them have had the experience of an internship. 105 responses were collected overall. The second group, henceforth referred to as “Specialists”, consists of Computer Science or Engineering graduate students from one University (UFPE), who have also had experience working in local software development businesses - 70% of the respondents, if not currently working, had the experience of an internship. 79 responses were recorded in the second group. Figure 2-1 illustrates the answers.
First of all, for either group, the only truly known methods were Agile, Waterfall, RUP/UP and Spiral, only with a significant shift from knowledge of Spiral to RUP/UP for graduate students. The configuration of answers for the most used methods changed little for both cases. The most utilized was Agile by far, even though Waterfall and RUP/UP also carried a relevant percentage
of practitioners overall. For the Undergrads, “none” was also a significant response, which might be due to their little experience with projects and the industry. Finally, Agile could be the most utilized, but not necessarily the preferred method. It is important to note this difference because the most used methods could show a trend of the industry, which would not necessarily hold when developers chose methods to follow in their own startups and projects. However, the predilection for Agile development became obvious when volunteers were asked which method they would
Figure 2-1 Graphic responses for group 1 (Undergrads) and group 2 (Specialists)
Source: Author’s own elaboration 77% 4% 30% 60% 15% 77% 10% 3% 61% 2% 18% 18% 4% 30% 22% 1% 68% 0% 3% 7% 1% 5% 11% 6% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90%
Agile RAD RUP/UP Spiral V Waterfall None Other
UNDERGRADS
KNOWN USED PREFERRED
92% 6% 78% 59% 10% 85% 1% 0% 85% 1% 41% 20% 4% 39% 1% 1% 84% 0% 6% 1% 0% 1% 5% 0% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Agile RAD RUP/UP Spiral V Waterfall None Other
SPECIALISTS
personally choose to carry out a project. 68% of the Undergrads preferred Agile, second place being no method at all, with 11% of answers. In the Specialists’ case, 84% preferred Agile. Second and third were close, with 6% and 5% for RUP/UP or no method, respectively. Knowing the developers’ preferences and the industry scenario, choosing the Agile development method as the technical cornerstone was a natural consequence.
2.2 Digging into Agile, Lean Startup and Design Thinking concepts
Before comparing the methodologies previously cited, it is important to notice that, even though all of them have applications in the Computer Science field, they do not have the same use and are not necessarily concurrent. This session introduces the core characteristics of the three chosen methodologies – Agile (focusing especially on Scrum and Extreme Programming practices), Lean Startup and Design Thinking – aiming to understand how each of them function and what they could help achieve.
1.1.1 Agile – Scrum and XP
Agile is a name given to different lightweight development methods that share a common ideology: finding better ways to develop software, making it more responsive, adaptable, useful and direct. The ideas are described in the Agile Manifesto [5] since 2001. Two practical methodologies that fit the Agile way of thinking and whose authors helped originate the Agile movement are Scrum (first presented in 1995) and Extreme Programming (first presented in 1999). In this thesis, Agile is used interchangeably with Scrum and XP. Thus, whenever Agile practices are mentioned, they refer to Scrum or XP practices.
Scrum is an iterative and incremental software development framework [22, 38, 54, 56]. Agile attempts to deliver smaller parts of the major software in smaller time intervals (sprints). The feedback is more frequent and rework, when necessary, is minimized.
The greatest difference is that Waterfall relies on extensive initial documentation and the contact with the client is concentrated in the beginning and in the end, when the software is already finished. If there is a misunderstanding or the built software simply does not please the customer, all the effort is thrown away. In Scrum, all features and activities that need to be implemented in the whole project are described, prioritized and kept in the Product Backlog. In the beginning of each sprint (period that usually takes up a few weeks), the most important features according to
the priorities are put in production. One of the pillars of Scrum is abundant communication. For that reason, the team has daily meetings in which the members explain what they have done, what they are doing and what they will do. In the end of the sprint, working code is delivered in the form of features that are ready to be shipped to the client and tested. The feedback defines the priorities for the next sprint. This process is illustrated in Figure 2-2.
Extreme Programming is also a software development methodology [4]. Its name derives from the idea that any beneficial software development practices must be taken to an extreme level,
maximizing software quality. The vision is that the only truly important factor of the system development process is code, for without code, there is no product. The process does not begin with a list of requirements; instead, some requirements are dealt with in very short development cycles, characterizing a strong bias for doing. Smaller cycles grant more checkpoints to talk with the client and elicit new requirements. Code review and code testing is a priority. Code review is, ideally, continuous, hence the common practice of pair programming among Extreme Programmers. Testing has a dual nature. Unit testing assesses if implemented features work as intended. Acceptance testing assesses whether the client is satisfied with the feature delivered. XP also advocates intensive communication among team members and clients. Last but not least,
Figure 2-2 Scrum framework highlights
simplicity is a main characteristic. Core features are delivered first and extra features can be added a posteriori.
Agile methods, besides being the most popular locally, by striving to deliver value to the client and having an iterative and approach open to continuous improvement and constant feedback, is a good fit for the innovation process and likely the best choice for the model.
2.2.1 Lean Startup
Lean Startup in its turn is not concerned with improving the way software production is handled. It was conceived to work for startups – also named “institutions” by Eric Ries – which are not necessarily a company; it might be a team, and the new product or service does not have to come from an all-new institution; it may be from already established ones like Dropbox or Aardvark [50], that are trying to grow in another direction or conquer new markets. Lean Startup is all about sustainable learning. The whole idea is to establish a build – measure – learn loop (see Figure 2-3) that allows for continuous confirmation or rejection of business hypotheses concerning problem, solution, market and clients. The inherent uncertainty comes from the fact that institutions running Lean Startup do not have guaranteed buyers or financing; they also do not build an established product since the beginning – instead, they learn what they need to build during the process of finding a problem, defining a strategy and using the build-measure-learn loops to assemble a product or service incrementally.
The build – measure – learn loop exists to reassess the plans made. Teams might change the product according to what they discover in qualitative tests with early adopters, optimizing it; if the team finds out they are building a product that nobody seems to want, they change strategy, pivoting (as presented in Figure 2-3). Lean Startup, similar to Agile, believes in adapting and changing the process while it is ongoing. Similar to XP, the idea is to build an MVP – Minimum Viable Product, consisting only of core features that solve customer’s main problems. Extra features come later. Unlike XP, though, tests are focused not on the working code, but on the early adopter’s opinion: the problem-solution fit [37].
Lean Startup (focus of this thesis) is not the same as Lean Development. Both share lean ideals from the original Toyota Production System developed between 1948 and 1975 [31], especially regarding the focus on the customer, continual improvement (kaizen) and high quality standards achieved through waste reduction.
The seven wastes of software development and its correspondent manufacturing wastes are in the Table 2.1:
Lean Development is guided by a set of guidelines resulting of the adaptation of original lean concepts to the software industry [49, 61]. Its aim of eliminating waste and is consistent with the Agile Manifesto. However, unlike Scrum or XP, it is not a software development management model, making it very unlikely to organize software production efficiently by itself. It is usually employed to improve Agile environments daily tasks, originating what is known as Leagile software development [14, 60].
Figure 2-3 Build-measure-learn cycle and Lean Startup outline
Source: Ries, 2011 [4]
2.2.2 Design Thinking
Design Thinking was made popular in many domains by Tim Brown [7, 8]. DT (Design Thinking) advocates that creative concepts are a result of heterogeneous teams. It enables better communication among team members from different areas by having everyone contribute and discuss problems and ideas together, instead of separating people by their expertise e.g. developers, designers, sales force, marketing. There are several valid Design Thinking process models in literature [7, 47, 66]. Every DT model relies on at least three phases – an exploratory phase, aiming to understand the user, their problems and reality; an ideation phase, when teams come up with ideas to treat problems previously identified; and a prototyping phase, when ideas come to reality in the physical world, becoming tangible and viable for testing. These phases can be further broken down according to the team’s objectives.
The process model chosen as basis for the management model presented in this thesis is the one proposed by the d.school of Stanford (Figure 2-4). This 5-step model was chosen because it had a strong practical approach and a more direct correspondence with Lean Startup principles. The exploratory phase is further broken down in Empathize and Understand (the problem). This separation clarifies that getting to know the user comes first. Only then it becomes possible to gain insight and understand the problem. This separation of problem and solution (solution only begins to appear in the ideation phase) is similar to the one advocated by Lean Startup (problem-solution fit). The final 5th step, explicitly added in the Stanford model, is important to stress the fact that the process is not finished in the prototype. The test phase allows the team to go back and forth in the process perfecting several aspects.
Figure 2-4 Stanford’s d.school Design Thinking spaces
At this point, the origins, objectives and application of each of the methodologies used as basis for this work’s innovative project management model have been explained. It is now time to contrast and compare them in specific key points. It is worth noticing that until now no challenges or problems of the given methods were approached. They were described and characterized with no judgment of value regarding the way they actually work. The second part of this Chapter will ponder whether these methodologies accomplish what they propose and how they might complement each other in practice.
2.3 Combining Agile, Lean Startup and Design Thinking
This session aims to address how the methods might be combined, what benefits they may bring to innovative projects and software development, and whether any challenges remain or arise when the methods are combined. The body of work approached in this session presents a more practical approach than the former, and it is more concerned about identifying previous experiences of the industry with said methods, paying special attention to practical challenges that have arisen.
The aim of this part is to highlight the benefits achieved with the combination of methods and the challenges that have arisen exclusively in the IT field. Works that discuss the combination of the given methods outside the IT scope are not discussed here.
This section is decomposed into four groups. The idea of uniting Agile, Lean Startup and Design Thinking, the three main methodologies approached in this thesis, is yet little explored in the academia. For that reason, a keen investigation was also extended to papers in which the methodologies were used coupled with a single other, instead of the three of them together. At any rate, it is possible to gain valuable insight on the combination of methods and common challenges with such works as well.
A. Combining Agile and Lean Startup;
B. Combining Lean Startup and Design Thinking; C. Combining Design Thinking and Agile; and finally D. Combining Agile, Lean Startup and Design Thinking.
Finally, in the end of this session, there is a table summarizing visually the main characteristics of each methodology concerning why it is relevant to try and make a project management model using those three methodologies, especially when the final product is a software.
2.3.1 Agile and Lean Startup
Lean Startup is often interpreted as being the same as Lean Development principles. This is in itself part of the challenges of bringing Lean Startup to the development scenario. Lean tends be thought of as an ideology more than practical actions, perhaps because of its roots. [24] highlights both have similarities, such as the close customer collaboration and short feedback cycles, but also stresses that Lean Startup (or a combination of it and Agile methodologies) many times is considered difficult to implement and apply by practitioners.
Scientific papers covering this subject are scarce, but three relevant examples will be discussed. [48] recognizes Lean Startup as a good method to ensure that customers are truly happy with the final product. In spite of the fact that Agile teams allow customers to direct the software development process, this may not always guarantee satisfaction. Involving developers in feature-by-feature validation, mainly in split tests, is a way to measure which solution delivers more value to the customer, which is in accordance with the principles of the Agile Manifesto. This observation allows to emphasize the difference of metrics in both methods. Agile metrics are more concerned with team’s internal productivity and efficiency. It is therefore common to adopt lines of code, number of bugs, and number of tasks concluded per sprint as key metrics [20]. For Lean Startup, key metrics are something altogether different, and sectioned in qualitative and quantitative measurements according to the phase the institution is in. The metrics are variable according to the product or service, but they intend to capture the level of engagement of users. That is the reason split tests (A/B tests) are so common in Lean environments. They provide reference for comparison on different levels of engagement, acceptance, or even willingness to pay for a solution. Uniform metrics in Lean Startup culture are number of people that registered to have more information about a given product on its landpage, frequency and duration of access, percentage of paying users (if there are free and premium options).
Another difference is the involvement of developers on decisions that are not strictly related to coding. Their presence in validations and tests in Lean Startup environments makes them more responsible for the product concept than in Agile environments, where developers rarely interact with users. The majority of places will have a software or requirement engineer translate customers’ demands into requirements and delegate coding to programmers, who hardly take part in deciding about project changes and possibilities.
In [60], Lean Startup is dismissed as a momentous trend that does not much affect Agile practice in the long run. This opinion is mainly owing to the fact that Lean Startup treats issues that are not directly connected to software development. At the same time, the authors recognize
the applicability of Lean principles to software development, albeit reiterating Bosch’s remark that such principles are hard to be applied because are essentially theoretical, not practical.
This perception is derived from The Lean Startup book [51], the principal reference for the topic. Indeed, it does not give much detail on steps to follow to implant the method in an institution. Running Lean, a book published a year later [37], addresses this difficulty, also experienced by the author himself, and compiles practical methods to be Lean, including aids such as the Lean Startup Canvas, a swift and reduced business plan that is constantly updated after every learning loop. The Lean Startup movement is still recent and lacks documentation to guide practitioners.
The combination of Agile and Lean Startup and its effects is a widely discussed topic in specialized magazines and blogs. Some examples are [26, 35, 59], and they offer valuable insight to real experiences, allowing to draw conclusions of the dynamics between both methodologies. For example, the focus on delivering value to client is always stressed as being very alike. Nevertheless, the client’s nature varies considerably. In Agile, the client is usually defined, specific and usually unique. The project revenue is also guaranteed, in the sense that clients will pay for a system that fits their requirements, and rarely any development begins before a contract is signed. Developers will also strive to meet their clients’ needs, making changes and adding features when requested. Lean Startup introduces other characteristics. It was conceived to work for teams that may not (and usually do not) have a fixed client, project or scope. The team will often start their own bootstrapped project from a personal idea, which has to be validated with potential users – the early adopters. Revenue is not guaranteed. It is mandatory to build a rapport with the market and the early adopters, in order to try and find undetected needs and how to make people pay for a product; it is necessary to consider the position of the product in the market. Consequently, liberty and space to create and propose solutions is much greater than that of traditional Agile teams.
Notwithstanding, Lean Startup introduces a hold-up to the Agile workflow. Both Agile and Lean Startup preach a culture where it is possible to pivot because requirements changed. In Agile, that essentially means rebuilding and reusing code according to the client’s vision of the software. In Lean Startup, the product vision belongs to the team, a characteristic of the startup business. In this stance, pivoting means changing the team’s idea, which in its turn demands to abandon not only code, but also a point of view. This does not always come naturally to teams, creating a much greater resistance to pivot (change strategy). Teams may become entrapped in this situation and refuse to modify their perspective, and keep developing something that no one wants, forgetting the learning loops and the constant validation [53]. This is a much higher risk for Lean Startup
teams because, since they usually do not have a client, they do not have any deadlines for product/MVP release except for the ones established internally, which are easily put off.
The difference of perceived deliveries from Agile versus Lean Startup is well represented on Spotify’s product development, illustrated in Figure 2-5.
2.3.2 Lean Startup and Design Thinking
While Design Thinking is not new in essence (for it is a reinterpretation of original Design problem solving techniques, applied to all domains), its introduction in the IT context is a recent attempt, what caused a delay in scientific studies of its interaction with Lean Startup principles. Usually, existent works evaluate Design Thinking interacting with Lean Thinking as a whole, not Lean Startup specifically.
Hildenbrand and Meyer present a case study and offers some insights on how Design Thinking and Lean Startup interact while undertaking a software project for a partner sailing company [21]. According to the authors, in the beginning of the process the team (all of them were software developers) did not “think code”, but instead discovered and observed the users. They
Figure 2-5 Comparison of Lean Startup and traditional Agile deliveries
managed to observe and interview all 15 members of the sailing crew in one week. They created personas with information they gathered and objectively translated the persona needs into a product vision, something innate to Lean Startup. Only then did they lapse into actually building software. Validation with stakeholder took place every week, to whom they had free access. The stakeholders for this project are Lean’s early adopters: they were available to talk and test, but they did not have the final say on the product, as it usually happens with traditional Agile teams. They helped the team establish an efficient feedback loop.
At this point, it is worth it to point out that one of Lean’s characteristics is the need to find early adopters that help the team build the feedback loop. They are the people who are accessible for interviews, who register on landing pages [44], or who can take part in concierge-like validations [29]. Maurya suggests in [37] that if a team is trying to enter an industry in which they do not have any contacts available to chat or test, the first thing that should be done is either taking the time to go to related meetings and build a business network or pivot to another industry where contacts already exist.
The software continued its implementations with new features and hypotheses being tested only with low-fidelity prototypes whenever possible, to reduce wasted time. Afterwards, more mature concepts scaled to high fidelity prototypes and only accepted hypotheses were coded. The whole project was delivered after around three months and users declared the final project surpassed all expectations.
A thorough study of Lean Startup and DT theory interaction is carried out in [42]. The paper uses the going-to book references of each methodology to form a theoretical comparison between both of them, and sums it up by suggesting a workflow combining Lean Startup and Design Thinking. This workflow, however, was never actually tested or practiced, functioning only as reference of a combination possibility.
This work points out many theoretical differences. It identifies that though validation may take place in the same way, DT does not have established metrics for refuting or accepting a hypothesis like Lean Startup does. Lean’s need of establishing a business model and developing customers is a concern not addressed by designers, and in practice this can compromise checking whether a product is viable, undermining the concept. On the other hand, DT offers techniques to capture inputs and empathize with users to generate ideas, something Lean does not clearly explain; ideas are taken for granted. In general, the suggestion is that if the team already has a business idea they want to test, the product vision, they should go with Lean Startup; if the problem is still unclear and team does not have a defined solution yet, it is better to try Design Thinking.
This conclusion from authors comes due to the fact that both methodologies, however, have plenty of similarities, like DT’s iteration and Lean’s pivoting (even though in Lean it is possible to pivot earlier than in DT, before the prototyping phase); the aim to generate innovation; the user-centered approach; the prototype testing and feedback cycles.
Extrapolating the conclusions taken by all authors, it is possible to posit that Lean Startup is concerned with efficiency in learning, constituting a learn-as-you-go process. A consequence of this approach is that concepts are not perfectly polished at times, which is acceptable because what matters is to build something that is simples and good enough to deliver value [9]. The product will not be perfect, but it will tackle a real need. Design Thinking is a learn-as-you-go process as well, but its deliverable is a concept. The DT team does not actually build the product, differently from a Lean Startup team. Hence, all iteration in DT is done to refine a product concept. Even though the teams test imperfect prototypes and have a bias for doing and learning in the process, this all is aimed to create a solution concept as good as it can be and pass it on to builders. A pure DT project has a different deliverable from a Lean Startup (or even an Agile) project. This is a fundamental difference between both methods. Some industries cannot accommodate a Lean Startup flow, because the concept must be perfect before it can be built. Software can be built as you go, as it has already been proved by Agile methodologies. DT can, therefore, cause delays in software projects if one becomes too intent in achieving the perfect concept before actual development.
2.3.3 Design Thinking and Agile
Some relevant works in this group are [48] [46] [12] [1] [23], which are all case studies or theoretical comparisons. There is not a single model proposition suggesting integration possibilities. [48] suggests that DT opens up the possibility of bringing issues of system flow and interaction design into the team, which is positive because since Agile and Design both have iterative approaches, they can evolve to opposite directions when not managed together. Another advantage authors perceive is that currently the main purposes of software is providing engaging experiences, something Agile development by itself only rarely delivers. Authors of [23] have a contrary opinion, and even suggest that UX (User Experience) designers do not have so significant a role in Agile development as they used to have in Waterfall development. Authors conclude that, owing to the frequent Agile iterations and deliveries, it is possible to provide a good final experience for the user based on trial and error. Besides, they argue that designers and developers
tend to consider the communication of the other part suboptimal. Thus, territoriality and defensiveness become problems for the team.
Patton [46] brings a successful case study that defends the need for design practices to be brought inside Agile environments, and explains it is possible when paired with Extreme Programming. Even though this is a 2002 paper and does not use the name Design Thinking, it is exactly what the author advocates. Patton explains that even though Agile software may have amazing interfaces, the process flow is usually a mess for the user. Besides, author argues that, as programmers, he and his team can never truly identify with his user, which makes them prone to make wrong design decisions. He also points out that everyone should take part from the Design process, not only the designers, which is a turning point this work introduces. Sadly, he recognizes that it is unlikely organizations bring DT in-house, so the best to do is try to teach developers to keep the correct mindset – think about who will be using the software, validate features with task cases, look for features that do not serve any role nor facilitate anything and eliminate it.
[32] and [33] bring several case studies and draw conclusions based on the implementation of up-front design, defended by Kent Beck in [43]. Participants of both studies as a whole regarded this initial immersion as positive, considering it eliminates big concept mistakes and allows for better estimation of the product. A lot of the up-front design is the study and observation of users, something developers rarely have access to, and bringing them into this process generates value in itself, through face-to-face communication over specifications. Bringing designers into the team also minimizes the chance that technical constraints are disregarded. Finally, authors in [32] posit that even though most (90-95%) of the design interaction should be done up-front, designers should have the opportunity to make calls along the project. Authors do not explain how that would be achieved. [33] disagrees completely with this assessment; it defends that design practices should be applied only on demand, strictly when needed, to support traditional Agile analysis. Authors consider that, otherwise, design practices would be an unwelcome overload to existing Agile practices. Both papers present completely different conclusions for the same issue.
The paper that best synthesizes the dynamics between Design Thinking and Agile is [34], also a case study, but at this time more robust. Developers were sent to a 2-week course on Design Thinking to reconsider their practices and tune in the design mindset. The majority of works discussed above describe how Design principles are used in Agile environments to improve product rapport with the user through the delivery of products customers really value. This is a somewhat more limited approach than that of investigating DT and Agile interaction as a whole, as this paper points out.
In traditional Agile environments, the discovery phase (empathize and define) is usually left out, mainly because developers do not communicate with clients – a requirement engineer talks to the customer, transforms features clients ask for into requirements and send to the programmers to code. Since customers explain what they want, there is no investigation to find latent needs or problem definition. The prototyping phase is very often overlooked as well. Authors explain that the nature of prototyping of Agile is different from that of DT. Prototypes for Agile tend to be simpler versions of the final product. For DT, prototypes are a way to convey an idea in the real world, with tangible material. Hence, prototypes may be mockups made of paper or devices made of cardboard. Agile aims to validate working code. DT aims to validate a concept.
Another hold-up identified, consequence of the requirements engineering as well, is the fact that the diversity of ideas is not welcome. The main concern is to eliminate possibilities as quickly as possible to start coding. Design preaches that true innovation comes from the generation of many different ideas that are not filtered at first, and only then there is an attempt to converge. For DT, problem and solution are two different spaces. For Agile, the problem space is already solved by customers themselves. Developers participating in the initiative regarded DT as costly and time consuming, and impractical in when team is under time pressure. Even though many of them had personal interest to apply techniques they learned to their daily routines, they found it impossible in the organizational context. Design Thinking, by not defining clear deliverable milestones, are perceived as a risk. Innovation ends up beings discouraged in organizations due to the major uncertainty it naturally brings [41]. The common practice of cutting off divergent thinking due to the requirement engineering process is also hard to circumvent. Moreover, developers are usually involved in more than one project and do not have the time or means to reach the customer and explore one problem. They juggle too many technical activities. Last but not least, the delivery of value, the client satisfaction and the actual innovation are not easily measured, contrary to traditional points such as the number of lines of code produced, of tasks finished and of hours worked.
Examining all the works presented above, it is possible to identify that software companies, even ones that claim to focus on the user, are not friendly to Design Thinking techniques. These companies have structures that do not allow DT to thrive. The natural division of designers, developers, marketers, salespeople do not allow for true interaction of different profiles. Designers are usually responsible for designing screens based on requirements and developers are not allowed time to work on activities other than coding. There is no space for exploration.
2.3.4 Agile, Lean Startup and Design Thinking
Only one work explicitly approaching the combination of the three methods was found in the literature, in the time this research was conducted.
The work of Grossman-Kahn [19], narrates a personal experience of his and some colleagues inside Nordstrom innovation lab. They explain how managers tried to implant Agile development first of all, but it did not work properly because teams in the company were otherwise engaged and could not be derailed from key initiatives; afterwards, they experimented with Lean Startup processes and were somewhat successful, but noticed they wound up making products that were overly concerned with the business side and overlooked customer needs; finally, to aid with the customer needs, they experimented with Design Thinking. An extensive research and empathizing process was carried out with potential users, but the long process made them lose the market timing, launching with delay and losing out on competition.
Finally, authors suggest an ideal model with neat graphical representation that combines Lean Startup, Agile and Design Thinking. DT would provide creative user-centered solutions, as well as the means to discover latent user needs. It would be the major responsible for the production of innovation. Lean Startup would guarantee the right product is being built for the client and establish uninterrupted learning loops, stimulating continuous delivery of features and creating a smooth flow. Agile would guide iterative software development. Programming would be done in pairs and the development process would be optimized in each iteration.
The proposed model is convenient and also based on some practical knowledge on the subject. Notwithstanding, it was never tested nor described how it would work in daily activities. For that reason, it is impossible to tell what the real life challenges could be.
2.4 Lessons from the literature
The past sections discussed challenges and opportunities concerning the combination of the three methodologies: Agile, Lean Startup and Design Thinking. At this point, it is possible to draw some conclusions.
Agile represents the state of the art set of practices to build software. It is iterative, it is fast, it allows to adjust course in ongoing projects and it is now well tested and defined. It is widely practiced in software development companies. It provides guidelines on how to organize teams and tasks, helps establish deadlines and delivers projects in fixed time and budget constraints. On the down side, since its main concern is coding, exploring opportunities that could lead to market
innovation is not common because of the technical focus. Technical innovation in itself is probable. Customer development is not a development issue, left instead to salespeople. Clients hold the product vision. Agile is great to deliver software products which are often and technically brilliant, but not necessarily manages to deliver value and its structure lacks the drive for innovation and for creating great experiences.
Lean Startup is a set of guidelines for not building something on time and on budget that nobody wants. Its main concern is not technical brilliance, but sustainable learning. Lean Startup teams, like other entrepreneurial teams, hold the product vision. Lean aims to deliver code consistently in order to test hypotheses, but code is only built when previous, lower-level hypotheses were already tested and validated. It is extremely focused on efficiency and early customer development, and developers take part in all activities. It deals with uncertainty, and does not guarantee profitability. Teams that follow Lean Startup are subject to all common startup traps, such as loving too much a doomed idea, abandoning projects before they end and not managing to earn money. It is not capable of organizing software production methodically by itself, and it can work well with Agile practices, as long as Agile’s principles coordinate software development and Lean Startup’s principles, product development.
Design Thinking provides the tools for innovation and discovery of latent user needs. It is a collection of practices and techniques that can be applied to overcome obstacles that are common in teams that create products for others, be the product vision theirs or someone else’s. Design Thinking has a bias for experimenting and questioning. User testing is frequent and meant for concept validation and the most user-driven and value-driven method of the three by far. Problem and solution are different matters addressed separately. It aims to make the best product concept possible. Design Thinking teams hardly ever build the actual products themselves; rather, they develop the concept for someone else to build and sell. DT teams usually tackle one challenge at a time; the more diverse and interdisciplinary the teams are, the better. DT does not advocate strict deadlines and does not apply quantitative metrics. Therefore, an external management model can be used to help structure team’s activities.
Some challenges stand out in this scenario. First and foremost, a management model combining the strengths of the three methodologies still does not exist; some efforts have been made, but never have they been used continuously in an organization; rarely have they been tested at all. Such a model would be beneficial for the creation of innovative software and to help identify market opportunities. The presented case studies narrate several experiences, but do not define a model and do not explain how a typical work week following such model would proceed. Many
case studies have extremely short duration, of just a couple weeks. This lack of continuation makes it difficult to generalize results and assess real contribution of methodologies in real-life settings. Experimental models cannot be implanted in established organizations because stakes are too high. Incubators and accelerators, which have the space and means to try such methods, do not register their experiments. Each startup or project is left to choose how to proceed.
Technology-based startups (and software-based startups especially) are now a relevant part of the tech industry, both in number and in market value, in the house on billions of dollars [18]. The success of so many startups is a strong indication that there are many valuable problems that remain undiscovered and that can be solved with software products thanks to technological ubiquity. Not having a model that can guide projects and overcome technical, market and creative challenges is a deficiency. An organized management model that guided the development of innovative products would teach to systematically seize market opportunities that are overlooked and solvable with software products.
