Conference PaperPDF Available

What Is Flowing in Lean Software Development?

Authors:

Abstract and Figures

The main concern of the software industry is to deliver more products in shorter time-cycles to customers with an acceptable economic justification. In virtue of these concerns, the software industry and researchers in the field of software engineering have engaged in the process of adopting lean principles. In this paper, we are seeking the knowledge that could help us better understand the nature of flows in software development. We define a generalized concept of the value creation points and an axiomatic system that capture the specifics of software development. Further, a generalized definition of the flow makes it possible to identify super-classes of waste sources. Finally, we define a concept of decision flow, suggesting what a value creation point could be in the software development context. The decision flow is an inseparable part of the software development activities and it carries capabilities of adding or diminishing the value of products.
Content may be subject to copyright.
A preview of the PDF is not available
... Interestingly in the early 2000s, software engineers were more occupied with the concept of value-software attributes that are directly visible to the users-and with approaches to deliver that value to the market more efficiently, e.g. Agile approaches, lean software development, Value-based Software Engineering [10,11,12]. Just in recent years, the concept of TD is gaining more attention from the research community as well as from the industry [4]. ...
... However, this is just one perspective. Software development can be seen as a chain of various decisions (business, design, architecture, etc.), which starts well before coding, and all those decisions impact the creation of a product [11], and consequently the creation of technical debt. One of the conclusions of the Dagstuhl Seminar was that all software development artifacts can carry technical debt [1]. ...
... Ernst et al. [19] in their study, showed that architecture decisions were the main source of TD, while this study adds the finding that several other causes that can be classified as Infrastructure causes can lead to Architecture debt (11). They also found Overly complex code to be a significant cause. ...
Preprint
Full-text available
The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries -- InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadline was the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... Interestingly in the early 2000s, software engineers were more occupied with the concept of value-software attributes that are directly visible to the users-and with approaches to deliver that value to the market more efficiently, e.g. Agile approaches, lean software development, Value-based Software Engineering [10,11,12]. Just in recent years, the concept of TD is gaining more attention from the research community as well as from the industry [4]. ...
... However, this is just one perspective. Software development can be seen as a chain of various decisions (business, design, architecture, etc.), which starts well before coding, and all those decisions impact the creation of a product [11], and consequently the creation of technical debt. One of the conclusions of the Dagstuhl Seminar was that all software development artifacts can carry technical debt [1]. ...
... Ernst et al. [19] in their study, showed that architecture decisions were the main source of TD, while this study adds the finding that several other causes that can be classified as Infrastructure causes can lead to Architecture debt (11). They also found Overly complex code to be a significant cause. ...
Article
Full-text available
Context The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. Objective The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. Method In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries—InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. Results In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadlinewas the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. Conclusion InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... By doing so, team members are able to report progress and suggest changes to be implemented into next iterations. This facilitates learning and enables modifications to the code to be developed through small and manageable increments instead [20]. Sunway University/Lancaster University 2) Improving Workflow: Due to its collaborative nature, it creates unity among team members involved in the project to enhance the team's workflow during the development process. ...
... This also keeps the developers motivated due to the fact that they are granted the flexibility to make important decisions based on the knowledge they receive during the entire project. With shared responsibilities and focused objectives, this results in higher performance within the team due to the fact that everyone is working together towards achieving the best outcome on the project [20]. ...
... According to the figure above, the Lean model works in a series of learning cycles where a software product where each loop is followed by an immediate assessment to make sure that the quality of the product is maintained [20]. Moreover, valuable feedback from its end users are obtained at the end of each iteration which is used as an input that helps the team to come up with the next version of the system. ...
Technical Report
Full-text available
Over the years, a number of processes and SDLC models have been developed to improve the overall quality of a software system, with varying degrees of success. However, the main aim of each SDLC model is to serve as a guideline that assists developers through a chain of various phases while working on a software project. Therefore, this helps to ensure that the developed software not only meets the client’s current expectations, but it will also be capable of scaling to accommodate changes acquired for future requirements as well [2]. As of today, there are two main SDLC methodologies which are utilized by most system developers, namely the traditional and agile (also known as modern) development models [3]. Each one of these methodologies outline a different approach to plan, design, develop, test and manage a software application system. Choosing between traditional or modern development models can be a challenge for most companies when starting a new project. This is because there are multiple factors that need to be considered, such as the client’s business needs, project timeframe and so on, in order to decide on a SDLC model that will be most suitable for the development and release of a new software system. In this paper, a comparison on the differences and similarities of three different traditional and modern development models, along with their characteristics, positives and negatives, will be identified and explained.
... Interestingly in the early 2000s, software engineers were more occupied with the concept of value-software attributes that are directly visible to the users-and with approaches to deliver that value to the market more efficiently, e.g. Agile approaches, lean software development, Value-based Software Engineering [3,4,10]. Just in recent years, the concept of TD is gaining more attention from the research community as well as from the industry [15]. ...
... However, this is just one perspective. Software development can be seen as a chain of various decisions (business, design, architecture, etc.), which starts well before coding, and all those decisions impact the creation of a product [10], and consequently the creation of technical debt. One of the conclusions of the Dagstuhl Seminar was that we need to better understand connections between non-coding activities and TD [2], such a cognition will allow us to balance a delivered value of software with accompanying technical debt. ...
Conference Paper
Background: There is a growing body of knowledge on Technical Debt (TD) in recent years. This knowledge provides various explanations of the term and suggests different remedies for it. However, the knowledge is yet to be validated in software development processes. Aims: The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in Serbian IT industry. Second, to contribute towards precise conceptualization of the TD concept. Method:We conducted a national-wide survey to collect feedback from industry practitioners.The survey is a part of InsighTD–an international initiative to investigate causes and effects of TD. Results: In total, 93 responses were collected, mostly from developers. Results indicate that the concept of TD is not widely accepted for use by the industry, only 35% of practitioners have practical experiences with projects that explicitly considered or managed TD. The most common types of TD are: code, test and design debt that together account for 61% of all reported cases. The archetypal TD case is caused by a tight schedule and resulted with non-optimal solutions that are difficult to evolve and in constant need of rework. Conclusions: Implications are at one hand for academics, who should consider TD as a topic for their curriculums since the results revealed that novice developers are unfamiliar with the concept. At the other hand, industry practitioners have a well aligned understanding of the TD concept, which is consistent with TD literature. However, we perceive that the wider use of the existing tools and techniques for managing TD can significantly help practitioners to deal with the top three occurring TD types.
... Software development is a chain of various decisions (business, design, architecture, etc.), which starts well before coding, and all those decisions impact the creation of a product [7], and consequently the creation of TD. One of the conclusions of the Dagstuhl Seminar on Technical Debt was that we need to better understand connections between noncoding activities and TD [1]. ...
Conference Paper
Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nationwide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.
... In order to solve GSD challenges and gain the competitive edge provided by agile methods, practitioners have started applying agile methods and more recently lean principles based kanban approach in GSD [8,9,10]. Agile methods alleviate some of the challenges of GSD by improving communication, coordination and collaboration [5]. ...
... Remarks Poppendieck and Poppendieck (2006) Discussed the seven wastes in SD. Mandic et al. (2010) Took opposite view of Poppendieck and Poppendieck (2006) by interpreting LT from the software development angle and explained the nature of flows in software development. Kundu et al. (2011) Studied 12 IT support service lines to identify waste/non-value added activities. ...
Article
Implementation of lean thinking (LT) in the service sector has been widely reported. Although few studies describing the application of LT in software development (SD) are available, not many are from an emerging market such as India. Our study addresses this gap by using a single-case study methodology to understand the lean approach adapted by a firm in India to overcome the issues faced in its SD process. Data were collected through direct observation for a period of one year. Difficulty in integrating work from various teams, long release cycles for the developed software products, late shipments, quality issues, customers' dissatisfaction, and high operational costs were the problems faced by the case company. These problems motivated the case company to adopt LT at the team level by following the scrum process. This study identified how the LT approach guided the case company to achieve responsiveness, regular interaction between employees, involvement of customers, and accomplishing targets within the planned timeline. This study helps both academicians and practitioners to understand the approach followed to implement LT in a SD firm in India.
... Remarks Poppendieck and Poppendieck (2006) Discussed the seven wastes in SD. Mandic et al. (2010) Took opposite view of Poppendieck and Poppendieck (2006) by interpreting LT from the software development angle and explained the nature of flows in software development. Kundu et al. (2011) Studied 12 IT support service lines to identify waste/non-value added activities. ...
Article
Full-text available
Different software development approaches (SDAs) are developed with broad portfolios of development processes. Each of the approaches has certain exclusive principles, practices, thinking, and values, which are informally represented, implemented, and improperly institutionalized. Ontologies are developed for the representation, assessment, and adaptation of SDAs separately without having a shared terminology which may lead to terminological conflict and confusion affecting the simultaneous representation and implementation in software development industry and academia. The software engineering approaches does not consider and support sustainability as priority concern. However, the approaches have capabilities of supporting sustainable software development in different sustainability aspects. This research article aims for the designing and development of an integrated ontology of software engineering approaches (i.e., agile, lean, and green) named OntoSuSD (ontology for sustainable software development) to support sustainable software development knowledge, awareness, and implementation. The goal of OntoSuSD is to propose, design and develop a formal, generic, consistent, and shared knowledge base containing semantic terminology and description of concepts and relationships generated around the representation and implementation of lean, agile, and green approaches in software development processes, which will facilitate their simultaneous implementation and assessment for sustainable software development. The OntoSuSD is developed using practical ontology engineering methodology by reusing relevant ontologies and explicit concepts and properties are defined to fulfill knowledge requirements and representations of the domain. The OntoSuSD is evaluated, and results infer OntoSuSD has high ontological design, good domain coverage, potential applications and achieves purpose of the ontology development.
Conference Paper
Rapidly increasing customer demands, competition, continuous changing scenario and accelerating pace of technological developments have put tremendous pressure on the business organization to deliver quality products at lower cost. On the same lines the software development (SD) companies need to deliver quality codes with new features at reduced cost. This can be achieved through Lean to software development projects. As the lean has been considered in different ways and has been implemented to varying extent in different sectors of the economy this paper aims to investigate as to how “lean” is viewed in software development projects and status of implementation in software development projects. First, application of lean in different types of projects viz. construction, healthcare, aerospace, new product development and service is discussed. Secondly, application of lean to SD projects is investigated at three levels: philosophy, principles (value, value stream, flow, pull and perfection) and practices/tools. The effect of lean on performance (inventory, lead time, customer satisfaction, cost, and business value) of SD projects is also analyzed. Further, “Leagile” software development and agile dominance is explored through this paper.
Article
This article introduces the Japanese concept of "Ba" to organizational theory. Ba (equivalent to "place" in English) is a shared space for emerging relationships. It can be a physical, virtual, or mental space. Knowledge, in contrast to information, cannot be separated from the context—it is embedded in ba. To support the process of knowledge creation, a foundation in ba is required. This article develops and explains four specific platforms and their relationships to knowledge creation. Each of the knowledge conversion modes is promoted by a specific ba. A self-transcending process of knowledge creation can be supported by providing ba on different organizational levels. This article presents case studies of three companies that employ ba on the team, division, and corporate level to enhance knowledge creation.