Marko Leppänen

Improving the delivery cycle

Context: Software companies seek to gain benefit from agile development approaches in order to meet evolving market needs without losing their innovative edge. Agile practices emphasize frequent releases with the help of an automated toolchain from code to delivery.Objective: We investigate, which tools are used in software delivery, what are the reasons omitting certain parts of the toolchain and what implications toolchains have on how rapidly software gets delivered to customers.Method: We present a multiple-case study of the toolchains currently in use in Finnish software-intensive organizations interested in improving their delivery frequency. We conducted qualitative semi-structured interviews in 18 case organizations from various software domains. The interviewees were key representatives of their organization, considering delivery activities.Results: Commodity tools, such as version control and continuous integration, were used in almost every organization. Modestly used tools, such as UI testing and performance testing, were more distinctly missing from some organizations. Uncommon tools, such as artifact repository and acceptance testing, were used only in a minority of the organizations. Tool usage is affected by the state of current workflows, manual work and relevancy of tools. Organizations whose toolchains were more automated and contained fewer manual steps were able to deploy software more rapidly.Conclusions: There is variety in the need for tool support in different development steps as there are domain-specific differences in the goals of the case organizations. Still, a well-founded toolchain supports speedy delivery of new software.

Three patterns for user involvement in startups

Creating products in software startups consists of a great deal of uncertainty combined with little resources. Rapid validation of created solutions with the potential customers is essential to startups. However, often startups lack people with skills needed for the validation. We present three patterns that help in involving users to gain meaningful feedback and learning. First, the feedback has to be gotten from the right people and the right questions have to be asked. Furthermore, if the feedback is collected with a prototype, often called a Minimum Viable Product, users should be able to give feedback of the actual idea, not to any roughness caused by the immaturity and the prototypishness of the product.

Four patterns for internal startups

In this paper, we describe patterns that are meant for founding internal startups in a larger company. The patterns are part of a larger pattern language for software startup companies. The patterns presented here cover four main parts of an internal startups life cycle starting from idea creation by enabling innovation with 20% Rule. The second pattern introduces an incubator phase, where the idea is validated to have a sensible problem and solution. This optimally leads to the creation of an internal startup, where resources are allocated to concretize the idea. With restricted resources such as a limited time, the internal startup may find a new Product-Market fit and offer a validated business opportunity for the parent company. This is concluded by the Exit decision by the parent company and ends the internal startups life cycle.

Visualizations as a Basis for Agile Software Process Improvement

Software projects have usually a lot of software engineering data available in different kinds of repositories. This data can be mined and used for software process improvement purposes. In general, agile methodologies emphasize reflection, making problems visible, and learning from the past. As the human mind is powerful in interpreting visual representations, visualizations could help in recognizing problems and areas of improvement in an agile software development process. In this paper an action research approach was taken to carry out software process improvement in an industry project. The research resulted in a visualization of the issue management systems data. The visualizations were a tool to identify problems in the development process and to make them visible for all stakeholders. The results show that this kind of visual approach can be used successfully to point out problems in the process. The visualizations form a basis for communication on possible software process improvement.

The social developer: now, then, and tomorrow

The practice of software engineering needs both individual commitment as well as social interaction. It has long been widely recognized that communication problems are a major factor in the delay and failure of software projects. However, the patterns of communication that can be associated with the different development paradigms have gained less attention. In this paper, we present some views to the evolution of social dimensions in the light of software engineering methodologies and associated tools. To study this, we have surveyed a number of software developers working in industry to reflect our views into the state-of-practice in software development companies and shed light to the impact of distributed and agile development has had on developer communication. Towards the end of the paper, we provide some ideas for future research and draw some final conclusions.

Decision-making framework for refactoring

Refactoring has been defined as improving code quality without affecting its functionality. When refactoring is overlooked in daily development, the likelihood of larger refactorings increases with time. Disadvantages of larger refactorings include that they disrupt the daily work, require additional planning effort, and often they need to be justified to stakeholders. In this paper, we investigate with interviews how professionals make refactoring decisions. As a result, we present a framework for decision making for larger refactoring operations describing the key stages in a refactoring workflow. Furthermore, one actual industry case of refactoring decision making is presented in detail.

Patterns for starting up a software startup company

Nowadays, startups have been of growing significance in software business. After the publication of the seminal work of Eric Ries, the Lean Startup concept has been a popular trend. Startup companies have especially been popping up in the volatile fields of web applications and games. Startups have even been dubbed to be the saviors of declining western economies. In this paper, we describe patterns that are a part of a larger pattern language for software start-up companies. The patterns were collected during autumn 2013. These particular patterns help start-up companies to focus on the hardships of the starting up a start-up; knowing that your idea is worth of our effort and how to finance your vision.

Hammer and Nails - Crucial Practices and Tools in Ad Hoc Student Teams

We have observed students teams on a software engineering project course to understand what software engineering practices they end up using and how do they experience the usefulness of the selected practices and tools. In our context, the most often applied practices and tools were planning meeting, commitment to using tasks, self-selected communication tools, a revision control, and project management systems. We found out that student valued various face-to-face activities the most - even more than they were able to practice them. Finally, the wide variety of communication tools students take even from their leisure time and apply in the course setting surprised us.

Patterns for distributed machine control systems

Control systems are getting more and more complex and include growing number of features. The control systems are nowadays software controlled to high degree. All features of the machine, however, are not useful for all customers and customers do not want to pay for the features they do not need. The product, the work machine, needs to be tailored to fit the customers needs. However, tailoring the product for each customer is not an option as there would be too many control system software versions and configurations of the control system and for example updating the control system software would became impossible. In this paper, we will present three patterns for control systems to help in addressing the aforementioned problems. These patterns generate software architecture that supports varying the control system for different customer needs.

Two Patterns for Minimizing Human Resources in a Startup

In this paper, we describe two patterns that are part of a larger pattern language for software startup companies. These two particular patterns help startup companies to focus on the essential; the product itself and keeping their team intact and productive. In this way, the startup may operate with a sustainable team size.