“EATING OUR OWN DOG FOOD” TO TRANSFORM RESEARCH INTO PRACTICE

In this paper I have followed the practice I learnt while a consultant at Microsoft: that is “eating your own dog food”. At Microsoft it means running the business on your own software including the latest beta software. I have used Benefits Management as a framework to explore the huge challenges involved in transforming research into practice and to clarify some of the changes required. I have explored how learning from practice can influence the process of research so that research can become more relevant. In particular, I have considered how ‘agile’ principles and practices can be adapted to research projects. This appears to be a valuable line of inquiry with good opportunities for transforming research into practice for individual researchers as well as the wider academic community

Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

The Remote Site Doctrine in Alaska

In recent years, software development has been evolving around an Agile way of working to optimize software development processes. Simultaneously in other industries, the Leanconcept have been adopted and used to make manufacturing and production of services more efficient. Software development companies has now started to realize that in order to become competitive in software delivery they need to optimize the entire end-to-end process and not only improve the development phase. Thus, an increased interest for Lean thinking has appeared in the industry. Applying Lean successfully in a software development context is not an easy task. This since Lean is developed for and by the manufacturing industry its content is also dependent on the characteristics of this context. Thus, it is not applicable to other contexts without being adjusted. Though, literature argues that when the content of Lean is properly adjusted to nature of the relevant context it can contribute with the same benefits as in manufacturing. However, the literature lack in studies on how Lean can be successfully applied in nonmanufacturing contexts. This study aims to contribute to this knowledge gap by adjusting and applying Lean tools in software development context in order to make the end-to-end processmore time- and resource-efficient. This will be made through a case study at a software development department at a Swedish Information and Communications Technology (ICT) Company. This department develops software components that work as building blocks of the product sold to the end customer. More specifically, these components contribute with functionality that enables communications between the nodes in a network. The review of the existing body of knowledge together with an analysis of the company specific problems indicates that the most sufficient tool to apply in this case study Lean implementation is Value Stream Mapping (VSM). Hence, the study focuses on adjusting the Value Stream Mapping framework to this new context in order to visualize the entire value flow and make improvements aligned with Lean. The adjustments of VSM are underpinned by relevant findings from previous research together with an analysis of the differences between manufacturing Lean and software development Lean. The study shows that it is possible to reasonably adapt and benefit from Value Stream Mapping also in the context of an ICT Company. The outcome of the study is an overview of the current value flow at the company and suggestions on how, where and what improvements can be made. Though, all improvement suggestions evolve around the aim of improving the flow efficiency and eliminating waste by improving the communication, standardization, synchronization, resource allocation and developing proper measurements. The conclusion is that Lean is applicable in the particular software development context with some necessary adjustments made to fit the current way of working and value offering. The usage of Lean tools such as Value Stream Mapping is possible, also here adjustments are a must and the VSM shows that the current state is better in providing a base for improvements than the future state map. This since improvements in this context is not always visualized and captured in the future state map, but the future map contribute to a vision for the valuestream to aim towards. Key words: Lean, Agile, Value Stream Map, Software development, Flow, Waste, Managemen

Scrum2Kanban: Integrating Kanban and Scrum in a University Software Engineering Capstone Course

Using university capstone courses to teach agile software development methodologies has become commonplace, as agile methods have gained support in professional software development. This usually means students are introduced to and work with the currently most popular agile methodology: Scrum. However, as the agile methods employed in the industry change and are adapted to different contexts, university courses must follow suit. A prime example of this is the Kanban method, which has recently gathered attention in the industry. In this paper, we describe a capstone course design, which adds the hands-on learning of the lean principles advocated by Kanban into a capstone project run with Scrum. This both ensures that students are aware of recent process frameworks and ideas as well as gain a more thorough overview of how agile methods can be employed in practice. We describe the details of the course and analyze the participating students' perceptions as well as our observations. We analyze the development artifacts, created by students during the course in respect to the two different development methodologies. We further present a summary of the lessons learned as well as recommendations for future similar courses. The survey conducted at the end of the course revealed an overwhelmingly positive attitude of students towards the integration of Kanban into the course

Why and How Your Traceability Should Evolve: Insights from an Automotive Supplier

Traceability is a key enabler of various activities in automotive software and systems engineering and required by several standards. However, most existing traceability management approaches do not consider that traceability is situated in constantly changing development contexts involving multiple stakeholders. Together with an automotive supplier, we analyzed how technology, business, and organizational factors raise the need for flexible traceability. We present how traceability can be evolved in the development lifecycle, from early elicitation of traceability needs to the implementation of mature traceability strategies. Moreover, we shed light on how traceability can be managed flexibly within an agile team and more formally when crossing team borders and organizational borders. Based on these insights, we present requirements for flexible tool solutions, supporting varying levels of data quality, change propagation, versioning, and organizational traceability.Comment: 9 pages, 3 figures, accepted in IEEE Softwar

Bridging the Gap Between Research and Practice: The Agile Research Network

We report an action research-oriented approach to investigating agile project management methods which aims to bridge the gap between academic research and agile practice. We have set up a research network of academics from two universities, through which we run focussed project-based research into agile methods. Organisations are invited to suggest an ‘agile challenge’ and we work closely with them to investigate how challenge affects them. Our approach is both academic and practical. We use appropriate research methods such as interviews, observation and discussion to clarify and explore the nature of the challenge. We then undertake a detailed literature review to identify practical approaches that may be appropriate for adoption, and report our findings. If the organisation introduces new practices or approaches as a result of our work, we conduct an academic evaluation. Alternatively, if we uncover an under-researched area, we propose undertaking some basic research. As befits the topic, we work iteratively and incrementally and produce regular outputs. In this paper we introduce our approach, overview research methods used in the agile research literature, describe our research model, outline a case study, and discuss the advantages and disadvantages of our approach. We discuss the importance of producing outputs that are accessible to practitioners as well as researchers. Findings suggest that by investigating the challenges that organisations propose, we uncover problems that are of real relevance to the agile community and obtain rich insights into the facilitators and barriers that organisations face when using agile methods. Additionally, we find that practitioners are interested in research results as long as publications are relevant to their needs and are written accessibly. We are satisfied with the basic structure of our approach, but we anticipate that the method will evolve as we continue to work with collaborators

The Unfulfilled Potential of Data-Driven Decision Making in Agile Software Development

With the general trend towards data-driven decision making (DDDM), organizations are looking for ways to use DDDM to improve their decisions. However, few studies have looked into the practitioners view of DDDM, in particular for agile organizations. In this paper we investigated the experiences of using DDDM, and how data can improve decision making. An emailed questionnaire was sent out to 124 industry practitioners in agile software developing companies, of which 84 answered. The results show that few practitioners indicated a widespread use of DDDM in their current decision making practices. The practitioners were more positive to its future use for higher-level and more general decision making, fairly positive to its use for requirements elicitation and prioritization decisions, while being less positive to its future use at the team level. The practitioners do see a lot of potential for DDDM in an agile context; however, currently unfulfilled