Simulating the impact of pairing on Agile software development projects: A multi-agent approach : A thesis submitted in partial fulfilment of the requirements for the Degree of Doctor of Philosophy at Lincoln University

Abstract

Scrum is an agile process that incrementally, iteratively and continuously delivers software based on time boxes (sprints). It comprises user stories stored in product backlogs and delivered through sprints by a Scrum teams consisting of team members, a Scrum Master and a Product Owner. The performance of a Scrum team is largely dependent on the team members and the technical practices that they adopt. One such practice, pair programming has been studied in a variety of contexts but not extensively in a Scrum context. Pair programming is a technique where two programmers work side by side at one computer to collaborate on the same design, algorithm, code, or test. The use of pair programming within Scrum has not been widely researched. A multi-agent system is used to simulate the Scrum environment where a team (with varying team members’ capability) work on delivering user stories (which consists of multiple tasks with varying complexities) in multiple sprints. Using this simulated environment, various strategies of compulsory pairing and voluntary pairing are investigated. Impact is measured based on the team’s work efficiency, completion time, effort time and idle time. Experiments were carried out to test these strategies in varying environments and results showed that a hybrid pairing strategy performed the best in fixed environments as it avoided negative pairing. An adaptive strategy performed best in the random setting as it was able to use the best strategy based on the current environment. Experiments were also conducted to investigate what happen when there are potential conflicts in the pair within the team. The result suggests that the proposed hybrid strategy was not heavily affected, as even though the rate of conflict increased from 0% to 20%, the work efficiency only decreased by 0.02%. To reflect how these strategies can be implemented in a real world setting, another experiment was conducted using varying sprint durations of 1 week, 2 weeks, 3 weeks and 4 weeks. The result indicates a strong preference towards a sprint duration of 3 or 4 weeks. Overall, results showed that software development teams using Scrum should use pairing within their set of technical practices for the delivery of software.