Delayed software projects are one of the biggest threats to the integrity of many project portfolios. If portfolio managers were able to foresee delays, they could better manage risks, make adjustments to the planning and reduce delay propagation. In their 2023 paper "Dynamic Prediction of Delays in Software Projects using Delay Patterns and Bayesian Modeling", Kula et al. propose an AI solution for the problem of ineffective delay prediction of software projects. Even though Kula et al. achieved positive results, they are bound to ING’s data, and thus may not be representative of software projects in other companies or industries. This thesis builds on Kula et al.’s work by applying the same methodology to a new dataset - Coca-Cola Hellenic's Project Portfolio. By doing so, it assesses the robustness and generalisability of Kula et al.'s delay prediction model. The results clearly indicate that the model was unsuccessful at Coca-Cola Hellenic, as it proved no better than random guessing.
Differences in dataset size and quality were identified as the primary cause for the lack of performance. Furthermore, contextual factors were likely a major contribution to the difference in results, namely differences in industry, organisational structure and agile maturity. These findings are valuable to anyone attempting to replicate this solution, or to organisations aiming to adopt AI-powered analytics.
Future research directions are suggested, such as a requirement framework for AI solutions and further replication of Kula et al.'s work in different contexts.

This thesis investigates the socio-technical factors influencing the use of Agile methods within project teams in local government organizations in the Netherlands, aiming to develop a practical framework to enhance Agile practices. The primary research question is: How can project teams in local governments stimulate the use of Agile methods? To answer this, the study addresses three sub-questions: (1) What team archetypes represent the typical use of Agile methods in local governments? (2) WWhat barriers and drivers towards the use of Agile methods are experienced by the teams? (3) How do different types of (Agile) team management impact the perceived performance by team members? Data was collected through qualitative methods, including interviews with team representatives of 15 teams across three local government organizations, and surveys with team members from one of these government organizations. The study categorizes teams into archetypes based on their Agile methodologies, reason to change, experience levels, and management support. Key barriers include lack of management support, lack of focus, lack of knowledge, unclear
roles, lack of alignment and organizational resistance to change. Important drivers for Agile adoption include Agile mindset, Agile coaching, dedicated key roles, dedicated management and freedom to experiment and structure. No significant difference in perceived performance was observed between team archetypes, indicating that perceived performance may be influenced by a broader range of factors beyond the scope of this study. The theoretical contribution extends the understanding of Agile adoption in public sector contexts, while the practical framework provides actionable steps for local government teams to navigate barriers and leverage drivers. Future research should broaden the scope to include diverse local government contexts, integrate quantitative data, and explore the long-term impacts of Agile practices and the application of the framework in a government, providing valuable data to inform ongoing Agile transformations in government settings.

Projects in a software engineering (SE) curriculum have many advantages for students. For example, students gain teamwork and project management skills. Involving an external stakeholder can enhance the learning experience further. For instance, students have the opportunity to practice stakeholder management. Moreover, working on a project with a real external stakeholder can help them make informed career choices. This external stakeholder can be a company, a government institution, or an organization from civil society, called ‘client’ from here onwards. In this work, we focus on startups to investigate the collaboration between startups and students in SE projects. Furthermore, we developed and introduced a design thinking workshop.
We did the research in a project course at Delft University of Technology. It is the capstone course near the end of the major in Computer Science & Engineering. In this course, students take on a project for a ‘client’. This external stakeholder brings in the project’s objective. Every student group has a unique project from different clients.
We started by analysing these projects from the client’s perspective. We interviewed several star- tups that previously participated in the course. Additionally, we sent a survey to all clients from the previous two years. We incorporated the findings of the interviews and survey with literature. From this, we concluded that startups potentially suffer from a lack of design upfront. This can lead to the creation of an undesirable product. To address this, we developed and introduced a design thinking workshop to our course. Design Thinking is a method for problem analysis and problem-solving. We evaluated the workshop by interviewing teaching assistants who supervised student groups that had participated in the workshop. Additionally, we surveyed the students who participated in the workshop and teaching assistants who joined a test run of the workshop.
From the results of the interviews with startups and survey of previous clients, we synthesized di- mensions of success for projects with students. We found three dimensions in which startups measure the success of a project. The output of a project can be important to them in terms of the 1) product that is developed or what was 2) learned during the project. Additionally, whether students are successfully 3) recruited after the project can also be a consideration when assessing success. Furthermore, we synthesized dimensions of product success and preconditions to success in these projects. We found five dimensions of product success and five preconditions to success.
The design thinking workshop was given to students in the first week they started their project. It constituted half a day during which the students learned to apply the Design Sprint method, a method for operationalizing design thinking in a structured way.
After the projects ended, we evaluated the impact of the workshop. The students and their teaching assistants were both generally positive about it. The teaching assistants, who also supervised non- workshop groups, noticed an improved early process. Furthermore, they noticed that some of their non-workshop groups fell into traps that could have possibly been prevented if the group had joined the workshop and applied the tools. This leads us to believe that the workshop should be extended to all students in the course.
Implication for startups   Spend time thoroughly understanding the problem before engineering a costly and time-consuming prototype. A design sprint is a low-cost way to discover if the problem is sufficiently understood.
Implications for companies involved in SE project courses   If properly motivated, students can create a useful product or prototype, the project does not have to be just a recruitment exercise.
Implications for teachers (of SE project courses with external stakeholders)   Add a design sprint workshop for all students at the start of the course. This thesis shows that adding such a workshop is feasible and improves students’ early process.
Implications for students  Do a design sprint before formulating requirements; this will deepen the understanding of the problem to solve and improve the process, so that it yields a product that is more aligned with the user’s needs.
i

Agile is a software development approach based on a set of 4 values and 12 principles. Using this set Scrum was developed as a agile framework in the early 1990s, which still remains the most popular framework today. However, Scrum originated to be used by a small number of co-located teams. When the amount of teams and the distance between the teams becomes bigger, issues will start to arise. With the rise of the computer and internet, programming-related work environments have become very large and globally distributed, implying a friction when using agile in these environments. This study aims to explore what challenges occur when using agile in very-large globally distributed environments and explore for practices that can be used to deal with them. To do this, a variety of research methods is used to gain insight, those being a systematic literature review (SLR), interviews and online surveys. We identify 50 challenges that may be encountered and 72 practices that can be used to combat them. Our online survey verified that all found challenges are frequently encountered in practice and the majority have a significant impact when encountered. However we also identified multiple practices that are used often to combat certain high-impact challenges. The most important practices were identified to be training and coaching. Experts were invited to fill in an online survey to generate possible learning goals. These learning goals are used to create an education program prototype for very-large scale globally distributed agile software engineering. As examples, 4 use cases in different environments are provided to show the prototype can be used to construct a matching training program. We provide proposals for further research directions into challenges, practices and the education program based on the steps taken in this study.

Based on the large amounts spent by software companies to develop new and existing software systems, we argue that an evidence-based approach that focuses on a software portfolio as a whole should be in place to support decision-making. We developed EBSPM as an evidence-based, practical model to support software companies to actively steer at optimization of their software delivery portfolio. We evaluated the model in case studies and surveys in industry, to demonstrate its strengths and limitations in practice. This lead to the following results:
• We analyzed - from a portfolio point of view - the characteristics of best performers and worst performers, in a dataset of 352 software projects, resulting in 7 success factors and 9 failure factors.
• We found that a release process that performs above average on cost and duration, satisfies stakeholders through fast response and direct value, even when the reliability and availability of the actual system are weak.
• A statistical, evidence-based pricing approach for software engineering, as a single instrument, can be used in the subject companies to create cost transparency and performance management.
• We found significant differences between the EBSPM-repository and an ISBSG-subset. Practitioners and researchers alike should be cautious when drawing conclusions from a single repository.
• We found that a focus on shortening overall project duration and improving communication and team collaboration on intermediate progress is likely to have a positive impact on stakeholder satisfaction and perceived value.
Based on the findings, we conclude that it is wise for software companies to collect and analyze their own historic software portfolio data because cross-company large differences in performance are found. We obtained a better understanding of the differences and equalities between effort and cost of software deliveries. Additionally, we studied the effects of pricing of software deliveries, giving us a better insight into ways to support decision-making. Based on the results of ongoing research, we expect that automation of the measurement and analysis process, based on statistics to calculate strong relationships, is a direction in which the analysis of software portfolio (software analytics) is the to develop strongly in the coming years.