Pekka Abrahamsson

Towards Understanding Startup Product Development as Effectual Entrepreneurial Behaviors

Software startups face with multiple technical and business challenges, which could make the startup journey longer, or even become a failure. Little is known about entrepreneurial decision making as a direct force to startup development outcome. In this study, we attempted to apply a behaviour theory of entrepreneurial firms to understand the root-cause of some software startup s challenges. Six common challenges related to prototyping and product development in twenty software startups were identified. We found the behaviour theory as a useful theoretical lens to explain the technical challenges. Software startups search for local optimal solutions, emphasise on short-run feedback rather than long-run strategies, which results in vague prototype planning, paradox of demonstration and evolving throw-away prototypes. The finding implies that effectual entrepreneurial processes might require a more suitable product development approach than the current state-of-practice.

Building an entrepreneurship data warehouse

The main principle of the Lean Startup movement is that static business planning should be replaced by a dynamic development, where products, services, business model elements, business objectives and activities are frequently changed based on constant customer feedback. Our ambition is to empirically measure if such changes of the business idea, the business model elements, the project management and close interaction with customers really increases the success rate of entrepreneurs, and in what way. Our first paper; “Does Lean Startup really work? Foundation for an empirical study” presented the first attempt to model the relations we want to measure. This paper will focus on how to build and set up a test harness (from now on called the Entrepreneurship Platform or EP) to gather empirical data from Companies and how to store these data together with demographical and financial data from the PROFF-portal in the Entrepreneurial Data Warehouse (from now called the EDW). We will end the paper by discussing the potential methodological problems with our method, before we document a test run of our set-up to verify that we are actually able to populate the Data Warehouse with time series data.

Consequences of Unhappiness while Developing Software

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding the positive side of happiness – positive emotions and moods – is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that also studying the negative side – unhappiness – could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, and is mainly expressed in terms of development productivity and software quality. In this paper, we attempt to uncover the experienced consequences of unhappiness among software developers. Using qualitative data analysis of the responses given by 181 questionnaire participants, we identified 49 consequences of unhappiness while doing software development. We found detrimental consequences on developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data, will spawn new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

What happens when software developers are (un)happy

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavor. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and unhappy while developing software. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artifacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.

Unhappy Developers: Bad for Themselves, Bad for Process, and Bad for Software Product

Recent research in software engineering supports the "happy-productive" thesis, and the desire of flourishing happiness among programmers is often expressed by industry practitioners. Recent literature has suggested that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness of developers due to its negative impact. However, possible negative effects of unhappiness are still largely unknown in the software development context. In this paper, we present the first results from a study exploring the consequences of the unhappy developers. Using qualitative data analysis of the survey responses given by 181 participants, we identified 49 potential consequences of unhappiness while developing software. These results have several implications. While raising the awareness of the role of moods, emotions and feelings in software development, we foresee that our classification scheme will spawn new happiness studies linking causes and effects, and it can act as a guideline for developers and managers to foster happiness at work.

Achieving CMMI Level 2 with Enhanced Extreme Programming Approach

The relationship between agile methods and Software Engineering Institute's CMM approach is often debated. Some authors argue that the approaches are compatible, while others have criticized the application of agile methods from the CMM perspective. Only few CMM based assessments have been performed on projects using agile approaches. This paper explores an empirical case where a project using Extreme Programming (XP) based approach was assessed using the CMMI framework. The results provide empirical evidence pointing out that it is possible to achieve maturity level 2 with approach based on XP. Yet, the results confirm that XP, as it is defined, is not sufficient. This study demonstrates that it is possible to use the CMMI for assessing and improving agile processes. However, the analysis reveals that assessing an agile organization requires more interpretations than normally would be the case. It is further concluded that the CMMI model does not always support interpretations in an agile context.

Future directions in Agile research: Alignment and divergence between research and practice

Innovation initiatives in large software companies: a systematic mapping study

This extended abstract summarises an article, which has been published in the Information and Software Technology (IST) Journal and was selected for the Journal-First presentations at the International Conference on Software and System Process (ICSSP 2018). Full Article Reference. Henry Edison, Xiaofeng Wang, Ronald Jabangwe, and Pekka Abrahamsson. 2018. Innovation Initiatives in Large Software Companies: A Systematic Mapping Study. Information and Software Technology, 95:1--14, (March 2018) DOI:10.1016/j.infsof.2017.12.007.

Are Software Startups Applying Agile Practices? The State of the Practice from a Large Survey

Software startups operate under various uncertainties and the demand on their ability to deal with change is high. Agile methods are considered a suitable and viable development approach for them. However, the competing needs for speed and quality may render certain agile practices less suitable than others in the startup context. The adoption of agile practices can be further complicated in software startups that adopt the Lean Startup approach. To make the best of agile practices, it is necessary to first understand whether and how they are used in software startups. This study targets at a better understanding of the use of agile practices in software startups, with a particular focus on lean startups. Based on a large survey of 1526 software startups, we examined the use of five agile practices, including quality related (regular refactoring and test first), speed related (frequent release and agile planning) and communication practice (daily standup meeting). The findings show that speed related agile practices are used to a greater extent in comparison to quality practices. Daily standup meeting is least used. Software startups who adopt the Lean Startup approach do not sacrifice quality for speed more than other startups do.

Female Leadership in Software Projects: A Preliminary Result on Leadership Style and Project Context Factors

Women have been shown to be effective leaders in many team-based situations. However, it is also well-recognized that women are underrepresented in engineering and technology areas, which leads to wasted efforts and a lack of diversity in professional organizations. Although studies about gender and leadership are rich, research focusing on engineering-specific activities, are scarce. To react on this gap, we explored the experience of female leaders of software development projects and possible context factors that influence leadership effectiveness. The study was conducted as a longitudinal multiple case study. Data was collected from survey, interviews, observation and project reports. In this work, we reported some preliminary findings related to leadership style, team perception on leadership and team-task context factors. We found a strong correlation between perceived team leadership and task management. We also observed a potential association between human-oriented leading approach in low customer involvement scenarios and task-oriented leading approach in high customer involvement situations.

What Influences the Speed of Prototyping? An Empirical Investigation of Twenty Software Startups

It is essential for startups to quickly experiment business ideas by building tangible prototypes and collecting user feedback on them. As prototyping is an inevitable part of learning for early stage software startups, how fast startups can learn depends on how fast they can prototype. Despite of the importance, there is a lack of research about prototyping in software startups. In this study, we aimed at understanding what are factors influencing different types of prototyping activities. We conducted a multiple case study on twenty European software startups. The results are two folds; firstly we propose a prototype-centric learning model in early stage software startups. Secondly, we identify factors occur as barriers but also facilitators for prototyping in early stage software startups. The factors are grouped into (1) artifacts, (2) team competence, (3) collaboration, (4) customer and (5) process dimensions. To speed up a startup’s progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototyping.

Coopetition of Software Firms in Open Source Software Ecosystems

Software firms participate in an ecosystem as a part of their innovation strategy to extend value creation beyond the firm’s boundary. Participation in an open and independent environment also implies the competition among firms with similar business models and targeted markets. Hence, firms need to consider potential opportunities and challenges upfront. This study explores how software firms interact with others in OSS ecosystems from a coopetition perspective. We performed a quantitative and qualitative analysis of three OSS projects. Finding shows that software firms emphasize the co-creation of common value and partly react to the potential competitiveness on OSS ecosystems. Six themes about coopetition were identified, including spanning gatekeepers, securing communication, open-core sourcing and filtering shared code. Our work contributes to software engineering research with a rich description of coopetition in OSS ecosystems. Moreover, we also come up with several implications for software firms in pursing a harmony participation in OSS ecosystems.