Today, the competition and speed in software development has increased. Companies are forced to produce more value to the customer at an accelerating pace. This has led to the phenomena where companies, who can leverage existing code, ecosystems and services to rapidly produce value to the customer can scale their operation faster. This has led to many companies becoming a part of a selected ecosystem, locking themselves into it, but reaping the benefits. Here we investigated what kind of ecosystems software companies use to grow and in what role do they want to participate in these ecosystems to leverage them for their growth. Two main types were identified, software ecosystems which provide ready made technologies to focus on providing added value to the customer, not in infrastructure development, and mutualistic software ecosystems where the value provided to the client is a sum of services provided by multiple companies in the ecosystem.

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.

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 environments 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.

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.

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 startup 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 startup's life, whereas once the business model is clarified, fine-tuning is more likely to take place.

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.

. Typical management strategies proven to work in already established businesses do not work as expected in startups. Startups do not yet have a business model and product that they could focus on, but are still looking for a working business model. Lean Startup is a method for startup management that focuses on quick iteration and on fast learning to find an iterable business model. As a method, Lean Startup is still quite novel. It does not have much scientific literature written about it, but it is used by startups. The two case study companies were both positive about Lean Startup and felt that the method had given them a helpful approach.

Software process data is available in several tools such as version control systems, issue trackers and test and build systems to name a few. Using the data gathered in these software engineering tools would be ideal for collecting different kinds of software processes and product metrics as the data is already automatically gathered by the tools. However, the tools present and store the data in various formats. The data collection methods and interfaces also vary between the tools. This closes the software engineering data into silos and makes it hard to build reusable analysis and visualizations for the data. In this position paper we present a unified model for software engineering data and a framework for data collection, conversion and storing that utilizes our model. The aim of the model is to define a common format for software engineering data which is not dependent on specific software engineering tools or the software engineering process and thus can be used as a basis for building reusable visualization and analysis components. To demonstrate that we can build reusable visualization plugins on top of the framework, we created a timeline visualization plugin. The visualization plugin is used to visualize two data sets from industrial software projects that have different contexts and semantics.

Modern software development approaches rely extensively on tools. Motivated by practices such as continuous integration, deployment and delivery, these tools are used in a fashion where data are automatically accumulated in different databases as a side-effect of everyday development activities. In this paper we introduce an approach for software engineering data visualization as a mashup that combines data from issue management, software development and production use. The visualization can show to all stake holders how well continuous delivery is realized in the project. The visualization clearly shows the time spent to specify and develop the features as well the length of the delivery cycle. Further more the visualization shows how much work is unfinished and waiting for delivery. This can help the development team to decrease the amount of unfinished work and by that help them to keep up in continuous delivery mind set. In addition to development data usage of the features is also visualized.