XP customer practices: A grounded theory

The Customer is a critical role in XP, but almost all XP practices are presented for developers by developers. While XP calls for Real Customer Involvement, it does not explain what XP Customers should do, nor how they should do it. Using Grounded Theory, we discovered eight customer practices used by successful XP teams: Customer Boot Camp, Customer’s Apprentice, Customer Pairing, and Programmer’s Holiday support the well-being and effectiveness of customers; Programmer On-site and Road shows support team and organization interactions; and Big Picture Up Front and Re-calibration support Customers steering the whole project. By adopting these processes, XP Customers and teams can work faster and more sustainably

Adopting Agile Practices When Developing Software for Use in the Medical Domain

Non-safety critical software developers have been reaping the benefits of adopting agile practices for a number of years. However, developers of safety critical software often have concerns about adopting agile practices. Through performing a literature review, this research has identified the perceived barriers to following agile practices when developing medical device software. A questionnaire based survey was also conducted with medical device software developers in Ireland to determine the barriers to adopting agile practices. The survey revealed that half of the respondents develop software in accordance with a plan driven software development lifecycle and that they believe that there are a number of perceived barriers to adopting agile practices when developing regulatory compliant software such as: being contradictory to regulatory requirements; insufficient coverage of risk management activities and the lack of up-front planning. In addition, a comparison is performed between the perceived and actual barriers. Based upon the findings of the literature review and survey, it emerged that no external barriers exist to adopting agile practices when developing medical device software and the barriers that do exists are internal barriers such as getting stakeholder buy in

The Impact of Regulatory Changes on the Development of Mobile Medical Apps

Mobile applications are being used to perform a wide variety of tasks in day-to-day life ranging from checking email, to controlling your home heating. Application developers have recognized the potential to transform a smart device into a medical device, by using a mobile medical application i.e. a mobile phone or a tablet. When initially conceived these mobile medical applications performed basic functions e.g. BMI calculator, accessing reference material etc.; however, increasing complexity offers clinicians and patients a range of functionality. As this complexity and functionality increases, so too does the potential risk associated with using such an application. Examples include any applications that provide the ability to inflate and deflate blood pressure cuffs, as well as applications that use patient-specific parameters and calculate dosage or create a dosage, plan for radiation therapy. If an unapproved mobile medical application is marketed by a medical device organization, then they face significant penalties such as receiving an FDA warning letter to cease the prohibited activity, fines and possibly face criminal conviction. Regulatory bodies have finalized guidance intended for mobile application developers to establish if their applications are subject to regulatory scrutiny. However, regulatory controls appear contradictory with the approaches taken by mobile application developers who generally work with short development cycles and very little documentation and as such, there is the potential to stifle further improvements due to these regulations. The research presented as part of this paper details how by adopting development techniques such as agile software development, mobile medical application developers can meet regulatory requirements whilst still fostering innovation

Adopting Agile Practices when Developing Medical Device Software

Agile methods are gaining momentum amongst the developers of non-safety critical software. They offer the ability to improve development time, increase quality and reduce development costs. Despite this, the rate of adoption of agile methods within safety critical domains remains low. On face value agile methods appear to be contradictory to regulatory requirements. However while they may appear contradictory, they align on key values such as the development of the highest quality software. To demonstrate that agile methods could in fact be adopted when developing regulatory compliant software they were implemented on a medical device software development project. This implementation showed that not only can agile methods be successfully followed, but it also revealed that benefits were acquired. For example, the medical device software development project was completed 7% faster when following agile methods, when compared to if it had been completed in accordance with a plan-driven approach. While this implementation is confined to a single project, within a single organization it does strengthen the belief that adopting agile methods within regulated domains can reap the same benefits as those acquired in non-safety critical domains

Enhancing the Auditability of the Agile XP Software Development Process in the Context of EU Medical Device Regulations

Nowadays, there is increasing reliance on software in the healthcare industry, such as software used for diagnostic or therapeutic purposes and software embedded in a medical device, often known as medical device software. Regulatory compliance has become increasingly visible in healthcare industries. Software development companies that develop medical devices software in Europe must comply with EU Medical Device Regulation (EU MDR) regulations in order to get the CE marking. Agile development practices are increasingly adopted by generic software development companies. For example, agile extreme programming (XP) is now considered a common model of choice for many business-critical projects. The reason behind that is that Agile XP has several benefits, such as developing high-quality software with a low cost and in a short period of time, with the capability to embrace any changing requirements during the development process. However, healthcare industries still have a low rate of agile adoption. This is due to the challenges that software developers face when using Agile XP within the stringent requirements of healthcare regulations. These challenges are the lack of fixed up-front planning, lack of documentation, traceability issues, and formality issues. Agile software companies must provide evidence of EU MDR conformity, and they need to develop their own procedures, tools, and methodologies to do so. As yet, there is no consensus on how to audit the Agile XP software companies to ensure that their software processes have been designed and implemented in conformity with EU MDR requirements. The motivation of this research is to assist the companies developing medical device software that wish to adopt Agile XP practices in their effort to meet the EU MDR certification requirements (CE marking). In addition, this research aims to help the information system auditors to extract auditing evidence that demonstrates conformity to the EU MDR requirements that must be met by Agile XP software organisations. This research will try to answer three main questions: Do Agile XP practices support the EU MDR requirements? Is it possible to adopt Agile XP practices when developing medical devices software? Is it possible to submit conformity evidence to EU MDR auditors? The main aim of this research is to enhance the auditability of the Agile XP software development process in the context of EU MDRs. This aim can be achieved by two main objectives: first, proposing an extension to the Agile XP user story to enhance the early planning activities of Agile XP according to EU MDR requirements. Second, designing an auditing model that covers the requirements of EU MDR. This auditing model should provide the EU MDR auditors with auditing evidence that the medical device software developed with an Agile XP process has fulfilled the requirements of EU MDR. The main contribution of this research study is the auditing model for EU MDR requirements that is aligned with the principles of Agile XP. The proposed auditing model would help auditors to audit the Agile XP development process of the medical device with regard to the EU MDR requirements in way of obtaining evidence in conformity to EU MDR requirements. And also, this auditing model can be considered as a guideline that would guide the Agile XP developers to follow the EU MDR requirements. The proposed auditing model has been assessed based on relevant case studies. As result, the evidence gathered shows at least partial support for the requirements in each case study. However, no case study has been demonstrated as supporting fully the auditing yardsticks of the proposed auditing model

The Role of Customers in Extreme Programming Projects

eXtreme programming (XP) is one of a new breed of methods, collectively known as the agile methods, that are challenging conventional wisdom regarding systems development processes and practices. Practitioners specifically designed the agile methods to meet the business problems and challenges we face building software today. As such, these methods are receiving significant attention in practitioner literature. In order to operate effectively in the world of vague and changing requirements, XP moves the emphasis away from document-centric processes into practices that enable people. The Customer is the primary organisational facing role in eXtreme Programming (XP). The Customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. This thesis presents a grounded theory of XP software development requirements elicitation, communication, and acceptance, which was guided by three major research questions. What is the experience of being an XP Customer? We found that teams agree that the on-site customer practice is a drastic improvement to the traditional document-centric approaches. Our results indicate, however, that the customers are consistently under pressure and commit long hours to the project in order to fulfil the customer role. So while this approach to requirements is achieving excellent results, it also appears to be unsustainable and thus constitutes a great risk to XP projects. Who is the XP Customer? The initial definition of XP resulted in many people interpreting the onsite customer to be a single person. This research has highlighted that a customer team always exists, and goes further to outline the ten different roles that were covered on the team, which range from the recognised "Acceptance Tester" role to the less recognised roles of "Political Advisor" and "Super-Secretary". What are the practices that support an XP Customer to perform their role effectively on a software development project? An additional eight customer-focused practices have been uncovered to supplement the existing XP practices. These customer-focused practices together enable customers to sustainably drive XP projects to successful completion. The practices range from those that specifically focus on interaction (both with the programmer team and the larger organisation) e.g. "Programmer On-site" and "Roadshows" to those that specifically look to the well-being and effectiveness of the customer (e.g. "Pair Customering") to those that highlight the key steps or activities that need to occur along the way (e.g. "Big Picture Up-Front" and "Recalibration")

The Role of Customers in Extreme Programming Projects

eXtreme programming (XP) is one of a new breed of methods, collectively known as the agile methods, that are challenging conventional wisdom regarding systems development processes and practices. Practitioners specifically designed the agile methods to meet the business problems and challenges we face building software today. As such, these methods are receiving significant attention in practitioner literature. In order to operate effectively in the world of vague and changing requirements, XP moves the emphasis away from document-centric processes into practices that enable people. The Customer is the primary organisational facing role in eXtreme Programming (XP). The Customer's explicit responsibilities are to drive the project, providing project requirements (user stories) and quality control (acceptance testing). Unfortunately the customer must also shoulder a number of implicit responsibilities including liaison with external project stakeholders, especially project funders, clients, and end users, while maintaining the trust of both the development team and the wider business. This thesis presents a grounded theory of XP software development requirements elicitation, communication, and acceptance, which was guided by three major research questions. What is the experience of being an XP Customer? We found that teams agree that the on-site customer practice is a drastic improvement to the traditional document-centric approaches. Our results indicate, however, that the customers are consistently under pressure and commit long hours to the project in order to fulfil the customer role. So while this approach to requirements is achieving excellent results, it also appears to be unsustainable and thus constitutes a great risk to XP projects. Who is the XP Customer? The initial definition of XP resulted in many people interpreting the onsite customer to be a single person. This research has highlighted that a customer team always exists, and goes further to outline the ten different roles that were covered on the team, which range from the recognised "Acceptance Tester" role to the less recognised roles of "Political Advisor" and "Super-Secretary". What are the practices that support an XP Customer to perform their role effectively on a software development project? An additional eight customer-focused practices have been uncovered to supplement the existing XP practices. These customer-focused practices together enable customers to sustainably drive XP projects to successful completion. The practices range from those that specifically focus on interaction (both with the programmer team and the larger organisation) e.g. "Programmer On-site" and "Roadshows" to those that specifically look to the well-being and effectiveness of the customer (e.g. "Pair Customering") to those that highlight the key steps or activities that need to occur along the way (e.g. "Big Picture Up-Front" and "Recalibration")

Reconciling agility and architecture: a theory of agile architecture

The purpose of agile software development is to enable the software development team to respond to change and learn from change so that it can better deliver value to its customer. If an agile software development team spends too much time planning and designing architecture up-front then the delivery of value to the customer is delayed or otherwise compromised, and responding to change can become extremely difficult. Not doing enough architecture design increases exposure to risk and increases the chance of failure. The balance between architecture and agility is not well understood by agile practitioners or researchers. This thesis is based on grounded theory research involving 44 participants from 36 organisations, all working in agile software development and who are either experienced in architecture design or are closely involved with architecture. The thesis presents a theory that describes how agile software teams design an agile architecture with reduced up-front design and which is able to respond to change, helping teams find a balance between architecture and agility. The theory describes six forces that affect the agility of the architecture and up-front design, and five strategies that teams use in response to those forces to determine how much effort they put into up-front design. Understanding these forces and strategies helps agile teams to determine how much up-front design is appropriate in their contexts

“AgiLean PM” – A UNIFIYING STRATEGIC FRAMEWORK TO MANAGE CONSTRUCTION PROJECTS

A challenge in Lean Construction is how to make it applicable when there is a high degree of complexity and uncertainty. In many construction projects there are changing project requirements, unique products and a need for actions that are highly focused on meeting customer/client expectations. Such scenarios require management methods that are characterised by being flexible and able to react to change. The aim of this thesis is to introduce a method that has such characteristics. Project Management, Lean and Agile paradigms are merged through the application of the fission and fusion approach of nuclear physics. This research is facilitated through a sequential explorative method. In the first instance, interviews with 22 practitioners in the fields of construction project management, Lean and Agile have been conducted. Then a quantitative self-administered questionnaire with 213 useful responses has been utilised to validate the transferability of the interview findings. It is concluded that Lean is not ideally suited to dealing with the dynamic nature of construction projects. Agile methods, which were developed to cope with the high levels of uncertainty inherent to IT projects, are more flexible and able to react to change. Hence utilising Agile-based methods might be the key to the successful utilization of Lean in construction. Therefore a management method based on combining Lean and Agile approaches has potential. Such an approach needs creative thinking to develop a solution that is different to that of “Leagile”. Leagile uses Lean and Agile methods in the execution phase sequentially, through using a decoupling point model to separate the two. This thesis introduces a new paradigm in which such a decoupling or separation does not take place. Rather, project management, Lean and Agile have been merged together to develop a new holistic and strategic framework. The paradigm presented in this thesis is termed “AgiLean Project Management”