Sampo Suonsyrjä

Ways to Cross the Rubicon: Pivoting in Software Startups

Startup, or a potential company looking for form and repeatable, scalable business model, has become an advocated mechanism for embracing high ambition, innovativeness, and growth. The success of a startup is often related to the time it takes the startupi¾źto develop their business model. When the entire business is based on extreme uncertainty the main business hypothesis of the business model must be continuously tested and improved. This main business hypothesis can be split into smaller business hypotheses and when one of these business hypotheses proves to be false, a change in the direction of the company --- so-called pivot --- must be considered. Readily made approaches exist to accomplish this, including in particular the Lean Startup framework, that aims at iteratively developing, experimenting, and validating business hypotheses. In this paper study how pivots can change business hypotheses shown as a segments in Lean Model Canvas, a strategic management tool for developing nbusiness models. As an empirical contribution, we describe this definition of pivots with three case companies --- all small software startups from Tampere region, Finland --- and map the pivot effects on the business hypotheses. We found out that the pivots can be identified by changes in the Lean Model Canvas, that pivots typically take place in groups, and that comprehensive pivots happen early in the startups life, whereas once the business model is clarified, fine-tuning is more likely to take place.

Understanding the Relations Between Iterative Cycles in Software Engineering

Iterations are one of the most successful mechanisms in software development to ensure that the resulting system is satisfactory. Due to its strengths, various kinds of iterations have been integrated to software development with varying goals. In this paper, we consider different types of iterations related to software development, including prototyping, incremental development, sprints as in e.g. Scrum, and iterations as defined in Lean Startup. The goal is to understand the relations between the types of iterations, and to find out what kind of similarities and differences they have with each other. As a result, we find that while the goals are different, it is possible for the iterations to coexist, so that one form of iteration is used as a tool to complete the goals of another.

The Developers Dilemma: Perfect Product Development or Fast Business Validation?

To find a fast-track to profitability, a startup needs to streamline and speed up two vital processes – developing novel products and finding new markets for their products. These two goals are typically opposed to each other, business development requiring quick iteration and product development requiring focus on quality. This difference in mindsets, where the focus should be on the balance of quality to the business experimentation causes a conflicting environment for the developers to develop products. This problem is aggravated in a startup environment, where the reasons for product failure are not clear, increasing the frustrations felt by the developers. Clear ways to communicate the product goals and even successes between management and developers is needed to create an environment for success. This balancing act between quality and speed to achieve fast product iteration is the developers dilemma.

Designing an Unobtrusive Analytics Framework for Monitoring Java Applications

In software development, attention has recently been placed on understanding users and their interactions with systems. User studies, practices such as A/B testing, and frameworks such as Google Analytics that gather data on production use have become common approaches in particular in the context of the Web, where it is easy to perform frequent updates as new needs emerge. However, when considering installable desktop applications, the situation gets more complex. While analytics facilities are still needed, they should address business logic, not generic traffic as is the case with many web sites. Moreover, analytics should be unobtrusive, and not have a high impact on the evolution of the actual application; thus, analytics should be treated as an add-on, as the target system may already exist. Finally, the instrumentation of features that are observed should be easy and flexible, but the provided mechanisms should be expressive enough for many use cases. In this paper, we examine different alternatives for implementing such monitoring mechanisms, and report results from an experiment with Vaadin, a web framework based on Java and Google Web Toolkit, GWT.

Collecting Usage Data for Software Development: Selection Framework for Technological Approaches

Software development methods are shifting towards faster deployments and closer to the end users. Their ever tighter engagement of end-users also requires new technologies for gathering feedback from those users. At the same time, widespread Internet connectivity of different application envi- ronments is enabling the collection of this post-deployment data also from sources other than traditional web and mobile software. However, the sheer number of different alternatives of collecting technologies makes the selection a complicated process in itself. In this paper, we describe the process of data-driven software development and study the challenges organizations face when they want to start guiding their development towards it. From these challenges, we extract evaluation criteria for technological approaches to usage data collecting. We list such approaches and evaluate them using the extracted criteria. Using a design science approach, we refine the evaluation criteria to a selection framework that can help practitioners in finding a suitable technological approach for automated collecting of usage data. I. INTRODUCTION

Implementing Continuous Customer Care: First-Hand Experiences from an Industrial Setting

With the traditional on-site installation model of enterprise software, end-user characteristics often remain at least partly unknown to the system providers. While users are typically modeled and their personas described during the development, those models and personas are rarely verified or refined based on operative usage of the system after installation. There are several reasons for this, but often the main reason is that it is simply too hard to obtain reliable and comprehensive information on the system usage from an on-site installation. The software as a service (SaaS) model introduces drastic improvement to the situation, as the service provider can now have direct access to the user data and analyze it, if agreed appropriately with the customer. In this paper, we present experiences regarding a companys transition from a provider of installed software systems to a SaaS provider from the viewpoint of customer care and related activities. The paper is based on observations gained with an industrial system that has recently experienced such transition. The results, although partly preliminary, already show that many of our assumptions on the user behavior may not hold true and substantial effort is required to understand various user needs thoroughly. As the studied company is just starting the journey to create customer care processes for the SaaS era, in addition to the descriptions of the current designs and implementations, some plans for future work are presented. These plans aim to better understand the changing role of softer aspects in software engineering when adopting the SaaS paradigm.

Eeny, Meeny, Miny, Mo...

Today, software teams can deploy new software versions to users at an increasing speed – even continuously. Although this has enabled faster responding to changing customer needs than ever before, the speed of automated customer feedback gathering has not yet blossomed out at the same level. For these purposes, the automated collecting of quantitative data about how users interact with systems can provide software teams with an interesting alternative. When starting such a process, however, teams are faced immediately with difficult decision making: What kind of technique should be used for collecting user-interaction data? In this paper, we describe the reasons for choosing specific collecting techniques in three cases and refine a previously designed selection framework based on their data. The study is a part of on-going design science research and was conducted using case study methods. A few distinct criteria which practitioners valued the most arose from the results.

Continuous, Lean, and Wasteless: Minimizing Lead Time from Development Done to Production Use

Modern software organizations invest substantial effort in building and automating their tool chain. The goal is to maximize both the speed of development, and how rapidly new software is deployed. This paper presents results from a descriptive and exploratory single case study from an ongoing project of Finnish company Solita. Based on data from version control and production logs, we investigate the feature flow in the project to study the effect of lean processes and the continuous deployment tool chain to waste produced by the deployment pipeline. We find that flow efficiency can be improved simply by minimizing the idle time the feature waits in the production process after its implementation has been finalized. This reduction of waste benefits both end users and developers - the users get access to new features, and the developers receive timely feedback.

Post-Deployment Data: A Recipe for Satisfying Knowledge Needs in Software Development?

In the field of improving software processes, one of the clear trends has been the ever tighter engagement of end users in the software development process. This is demonstrated by the shift from Agile processes to Continuous Deployment, which requires more rapid ways to validate the developed software and its value than is possible with traditional communication mechanisms and methods, such as face to face conversations with customers. While post-deployment data has been used for years as an extra data source - companies like Microsoft and Intuit have moved a few steps further from that already - we believe that there are numerous uncovered ways of taking advantage of post-deployment data in software development. In this paper, we study how automatically collected post-deployment data could be used for responding to knowledge needs of software development teams. The paper builds on data collected from a number of companies operating in Finland using a questionnaire study. The focus of questionnaire study was to approach post-deployment data - especially usage data - as means of getting information to support understanding of customer and end users.