Mastering programming fundamentals poses a significant challenge for students, especially in demanding higher education environments. This pilot study investigates the effectiveness of a web-based system, SoftwareSkills, designed to enhance programming proficiency among second-year bachelor students. SoftwareSkills leverages, active practice, and self-monitoring to support programming practice. Thirty-six students (n=36) participated in a quasi-experimental design, divided into independent exploration and instructional session groups. User interaction data, exercise performance, and behavioural patterns were analysed. The study revealed four distinct learning strategies: reviewing skill masteries, dedicating sufficient time to each question, striving for mastery, and adapting spaced practice. However, some students exhibited rapid responses and minimal practice, suggesting a need for deeper learning strategies. These findings highlight the suitability of self-regulated learning and deliberate practice in programming education. Future work will involve first and second-year programming students and integrate AI-driven personalised learning features to optimise the learning experience. This research contributes insights into effective practices and the potential of technology-aided learning to support student success in programming education.

Computing platforms in autonomous vehicles record large amounts of data from many sensors, process the data through machine learning models, and make decisions to ensure the vehicle's safe operation. Fast, accurate, and reliable decision-making is critical. Traditional computer processors lack the power and flexibility needed for the perception and machine vision demands of advanced autonomous driving tasks. Hardware accelerators are special-purpose coprocessors that help autonomous vehicles meet performance requirements for higher levels of autonomy. This paper provides an overview of ML accelerators with examples of their use for machine vision in autonomous vehicles. We offer recommendations for researchers and practitioners and highlight a trajectory for ongoing and future research in this emerging field.

Architects always make decisions in some context. That context shifts and changes dynamically. Different decision-making strategies are appropriate in different contexts. Architecture decisions are at times made under conditions of time pressure, high stakes, uncertainty, and with too little information. At other times, decision-makers have sufficient time to reflect on the decision and consider alternatives. Understanding context is critical to choosing appropriate approaches to architecture decision making. Naturalistic Decision Making (NDM) explains how people make decisions under real-world conditions. This paper investigates NDM in software architecture and studies architecture decisions in their environment and decision-making context. The research approach includes a case study of large technology organizations consisting of a survey, multiple focus groups, and participant observation. Previous studies that touch on NDM in software architecture have mainly focused on decision-making processes or tools or developing decision models. This paper provides three contributions. First, we build on previous studies by other researchers to produce an in-depth exploration of NDM in the context of software architecture. We focus on Recognition-Primed Decision (RPD) making as an implementation of NDM. Second, we present an examination of the decisions made by experienced architects under conditions that can be considered naturalistic. Third, we provide examples and recommendations that help software architects determine when an NDM approach is appropriate for their context.

First, we shape our architecture. Then, our architecture shapes us. As architects we bring part of ourselves to the systems we work with. We evolve with our architectures. In this tutorial we consider the metaphor of "terroir" to understand architectures and their sense of place. Terroir comes from the French word used to describe the set of all environmental factors that affect the observable characteristics of an organism, e. g., the unique set of contextual characteristics of place that influence food crops, coffee, tea, or wine. So too in systems, architectures are uniquely shaped by the culture and context of a place. Factors include people, organization, culture, technology, and tenets shared among the architects and makers. Understanding an architecture is a first step towards evaluating it. The set of concepts and practical tools covered in this tutorial are well suited to being used in conducting architecture analyses and reviews and integrate with any other processes an organization might be using.

Agile methods have transformed the way software is developed, emphasizing active end-user involvement, tolerance to change, and evolutionary delivery of products. The first special issue on agile development described the methods as focusing on "feedback and change". These methods have led to major changes in how software is developed. Scrum is now the most common framework for development in most countries, and other methods like extreme programming (XP) and elements of lean software development and Kanban are widely used. What started as a bottom-up movement amongst software practitioners and consultants has been taken up by major international consulting companies who prescribe agile development, particularly for contexts where learning and innovation are key. Agile development methods have attracted interest primarily in software engineering, but also in a number of other disciplines including information systems and project management. The agile software development methods were originally targeted towards small, co-located development teams, but are increasingly applied in other contexts. They were initially used to develop Web systems and internal IT systems, but are now used in a range of domains, including mission-critical systems. Methods that were designed for single teams of 5-9 developers have been adapted for use in projects with tens of teams, hundreds of developers, which can involve integration with hundreds of existing systems and affect hundreds of thousands of users.

Many organizations struggle with efficient architecture decision-making approaches. Often, the decision-making approaches are not articulated or understood. This problem is particularly evident in large, globally distributed organizations with multiple large products and systems. The significant architecture decisions of a system are a critical organization knowledge asset, as well as a determinant of success. However, the environment in which decisions get made, recorded, and followed-up on often confounds rather than helps articulation and execution of architecture decisions. This paper looks at aspects of architecture decision-making, drawing from an industry-based case study. The data represents findings from a qualitative case study involving a survey and three focus groups across multiple organizations in a global technology company. Architects in this organization are responsible for multiple products and systems, where individual products can include up to 50+ teams. The impact is not just on others in the system; architecture decisions also impact other decisions and other architects. The findings suggest recommendations for organizations to improve how they make and manage architecture decisions. In particular, this paper notes the relevance of group decision-making, decision scope, and social factors such as trust in effective architecture decision-making.

For organizations undergoing agile and lean transformation, it can be difficult to get meaningful, actionable insights into progress and impediments. Teams and organizations are best understood as complex adaptive human systems. Understanding what is happening in such systems requires approaches grounded in the complexity sciences and social sciences. This paper describes an approach using complexity science and sensemaking that helps an organization understand its culture, how it is progressing with its strategic initiatives, and the types of impediments that are holding it back. It provides a means of qualitative and quantitative analysis that helps teams and organizations improve. This paper also correlates the experiences of the people in the organization to its goals of being a more agile organization.

The implementation and release of software products has progressed from a lengthy delivery cycle - the methodical sequential path of "big bang" waterfall product delivery - to the rapid iterative release cycle supported by agile practices. Recently, "continuous delivery" has emerged as a strategy to accelerate product availability. However, only a systematic automation of the build, test and deployment processes in concert with superbly coordinated teams of software practitioners and business partners makes make this possible. However, trade-offs in the optimization of process may act to limit the innovativeness of product output. This panel will discuss approaches, challenges, risks, and strategies for using continuous delivery to competitive advantage.

Professionalism evolves as knowledge and skills mature from craft to commercial practice - often as the result of learnings derived from failure and human hazard. Aviation, medicine, engineering, and architecture are examples of disciplines with an established knowledge base and curriculum of learning and mentorship. These disciplines often require regulated practices executed by certified professionals to ensure the safety and economic value of delivered services. This panel will debate whether we are learning effectively from our experiences and what might be done to accelerate increased software professionalism and product value.

Contemporary lean thinking, especially in knowledge work areas like software engineering, begins with understanding flow. Architecture plays a vital role in enabling the flow of value in software engineering teams and organizations. To date there has been little research in understanding impediments to flow in software engineering organizations. A focus on enabling flow through removing impediments is a useful perspective in creating a more agile, lean thinking software engineering organization. Particularly so when supported by appropriate metrics. This paper presents a case study of how architecture-related impediments impact the flow of work in software engineering teams and organizations. The key contributions of this paper are centered on the concept of flow and impediments in modern software engineering, and its relationship with architecture. We develop an understanding of how a focus on flow and removing impediments, supported by appropriate metrics, is helpful in identifying architecture-related challenges. Drawing on research of one company's practices the paper presents an example of a scenario where flow analysis using specific metrics reveals architecture-related impediments and shows how addressing these impediments improves effectiveness and productivity in ways that would not otherwise have been revealed.

The PhD symposium of XP2014, the 15th International Conference on Agile Software Development, was organized as a half-day event prior to the main conference program. Seven PhD candidates came from different research institutes across the globe to present their own research proposals at the symposium. The symposium was run in a lively and interactive manner. The candidates received constructive feedback on their proposals from all the symposium participants. In this report we describe the presented proposals, focusing on the content and feedback. Through them we can take a peek at the trends and emerging areas of agile research in the coming years.

Teams and organizations are complex adaptive systems. Self-organization in complex adaptive systems evolves through a set of Simple Rules. Self-organization is a core tenet of agile teams. Self-organization does not mean everyone gets to do whatever they want to do. Team members create contracts with each other. These contracts create boundaries, or containers, within which self-organization can occur. Teams also create contracts with other teams, the wider organization and other stakeholders. The contracts are both implicit and explicit. Social contracts in complex adaptive systems are more effective if they are based on Simple Rules. Social Contract Theory acts as a lens through which we can better understand these social contracts in agile teams. This paper represents ongoing research that examines the role of Simple Rules and Social Contract Theory in fostering self-organization in agile development teams. The paper discusses four examples of social contracts in agile teams: definition of done, definition of ready, working agreements, and retrospectives.

Achieving a smooth flow of work through the system is a goal for many teams and organizations that embrace agile and lean approaches. However, the flow of work faces many impediments as it flows through teams and organizations. Agile and lean approaches can reveal impediments that impact teams and organizations. Often at the start of their agile transition, but also frequently after the initial transition, teams and organizations can find themselves with a significant quantity of impediments that demand attention. With limited time and capacity, they need techniques to help them understand the impediments and make decisions about where to invest their time. This paper introduces a new technique called Impediment Impact Diagrams that helps people to understand which impediments to address, and who needs to be involved in addressing them. The technique can also be used to understand other attributes of impediments such as the relative cost of removing the impediment, or the relative duration it is likely to take to remove the impediments. The Impediment Impact Diagram can be used on its own or as part of an Impediment Removal Process. Drawing from original research on impediment removal, this paper includes detailed steps to use the technique, presents several examples of Impediment Impact Diagrams from multiple teams and organizations, and describes their experiences with the technique.

The term "agile at scale" is used frequently in relation to agile approaches in large organizations, but the meaning of "scale" is not always clear. Without a proper understanding of meaning and context, inappropriate methods are applied. It is important to understand when "scaling agile" is the solution to the problem at hand, and when its not. There is a difference between agile approaches used by a team in a large organization, agile approaches used on a large development effort, and organization agility. The distinction is important. This paper explores that distinction using Human Systems Dynamics as a lens through which to understand and articulate which of the three contexts an organization is dealing with. By analyzing a system through the HSD lens it becomes possible to predict and influence the impact on the flow of work through the system, and in particular, it is possible to understand what types of impediments might impact the flow of work. This helps organizations to understand appropriate approaches to agility that better suit their context.

Definition of Ready is a set of simple rules adopted by an agile team to help them remember all the things they need to do before a development team starts work on a backlog item. Not having a definition of ready can seriously impede the flow of work through your system. This paper describes where definition of ready fits in a team’s process, and how it can be used as a synchronization point for teams and product owners. This paper presents an example of definition of ready used by agile teams in Cisco. These teams have developed three levels of ready that apply for user stories, sprints and releases. The paper describes how definition of ready provides a focus for backlog grooming, and some consequences of not meeting definition of ready. The paper finishes with perspectives from different roles in the organization and how they are affected by definition of ready.

Eliminating waste is a core principle of lean thinking. Despite the emergence of literature that applies lean in the software domain, an underlying analysis of this literature reveals the fundamental interpretation of waste has remained largely unchanged since its origins in manufacturing. Lean defines waste as any activity that does not directly add value as perceived by the customer. Software development is a creative design activity, not a production activity, and agile teams and organizations are more akin to complex adaptive self-organizing systems than repetitive production lines. Waste has different meaning in such systems. This paper reframes the lean concept of waste as impediments to flow in complex human systems. Drawing from ongoing research, this paper presents an updated categorization to describe the impediments faced by teams and organizations. The categories are extra features, delays, handovers, failure demand, work in progress, context switching, unnecessary motion, extra processes, and unmet human potential. These categories provide a foundation for helping teams and organizations to see, measure and reduce impediments to flow in their systems.

This book contains the refereed proceedings of the 4th International Conference on Lean Enterprise Software and Systems, LESS 2013, held in Galway, Ireland, in December 2013. LESS fosters interactions between practitioners and researchers by joining the lean product development and the agile software development communities in a highly collaborative environment. Each year, the program combines novelties and recent research results that make new ideas thrive during and after the conference. This year, the conference agenda was expanded to incorporate topics such as portfolio management, open innovation and enterprise transformation. The 14 papers selected for this book represent a diverse range of experiences, studies and theoretical achievements. They are organized in four sections on lean software development, quality and performance, case studies and emerging developments.

This book contains the refereed proceedings of the 4th International Conference on Lean Enterprise Software and Systems, LESS 2013, held in Galway, Ireland, in December 2013. LESS fosters interactions

Understanding the impact of technical debt is critical to understanding a team's velocity.For organizations with multiple teams and products, the impact of technical debt combines non-linearly to impact the organization's velocity.We can think of the capacity of a team as a portfolio.Not all of that capacity can be invested in new features or defect fixing, without incurring negative consequences.A portion of the team's capacity needs to be invested in the ongoing management and reduction of technical debt.This paper describes a simple technique for visualizing, quantifying and tracking a team's technical debt as a portion of their overall capacity investment.The knowledge and insights gained through this technique help with better capacity planning, improved forecasting, and helps to justify the business case for investing in managing and reducing technical debt.

The obstacles facing decision making in Agile development are critical yet poorly understood. This research examines decisions made across four stages of the iteration cycle: Iteration Planning, Iteration Execution, Iteration Review and Iteration Retrospective. A mixed method approach was employed, whereby a focus group was initially conducted with 43 Agile developers and managers to determine decisions made at different points of the iteration cycle. Subsequently, six illustrative mini cases were purposefully conducted as examples of the six obstacles identified in these focus groups. This included interviews with 18 individuals in Agile projects from five different organizations: a global consulting organization, a multinational communications company, two multinational software development companies, and a large museum organization. This research contributes to Agile software development literature by analyzing decisions made during the iteration cycle and identifying six key obstacles to these decisions. Results indicate the six decision obstacles are unwillingness to commit to decisions; conflicting priorities; unstable resource availability; and lack of: implementation; ownership; empowerment. These six decision obstacles are mapped to descriptive decision making principles to demonstrate where the obstacles affect the decision process. The effects of these obstacles include a lack of longer-term, strategic focus for decisions, an ever-growing backlog of delayed work from previous iterations, and a lack of team engagement. (C) 2012 Elsevier Inc. All rights reserved.