(C) Lisamarie Babik
An essay I wrote for my software measurement and quality assurance module discussing how eXtreme programming can be implemented in a business and in such a way that it can satisfy the capability maturity model.
How can extreme programming be implemented successfully in an organisation? Can it be incorporated into a defined software process?
Extreme Programming (XP) has become a popular agile process. This essay will discuss how XP principles and core practices can be implemented in an organisation, and extended into mature and defined software process that satisfies the various Capability Maturity Model (CMM) levels.
XP promotes, from the perspective of traditional approaches, a radical orientation to change that Mateos-Garcia and Sapsed (Adopting Agile and Scrum Practices as Organizational Becoming, 2008) believe can “give rise to new structures for project management” (pp. 2-3)
XP is based on iterative process models and includes the familiar stages of planning, design, coding, and testing, within each stage there are tools and practices. For example, user stories during planning, class responsibility-collaborator (CRC) cards and prototypes during design, developing unit tests prior to coding and pair programming during coding to improve quality, and acceptance tests based on user stories. (Pressman, 2005)
What makes XP so radical is how it “turns conventional software process sideways” (Beck, 1999), which in practice means that the distinct planning, design, coding, and testing phases of the iterative processes, from which XP evolved, merge and are conducted simultaneously.
Beck’s article (Embracing Change with Extreme Programming, 1999), though old, explains XPs core practices and how they can be implemented. The organisation implementing XP should focus on releasing working increments through short iterations.
The features to be included in an iteration are determined by the “planning game” (Beck, 1999) where clients rate the priority and developers estimate the time required for each feature, and the client selects the most important features until all the developer time is used up. Honest and clear communication with the client is essential throughout the project, but particularly during the planning game.
Features are broken down into tasks that are allocated to developers, who then write tests based on client input to determine when a feature is working satisfactorily and then implement the feature to satisfy the tests. This test-driven development helps the organisation rapidly produce working code, and if automated can be used to continuously integrate new code ensuring the latest build of the product is always working.
Coding is done in pairs so that code is reviewed as it is written and refactoring existing code is encouraged. Refactoring is supported by the notion of collective ownership: the idea that each developer is responsible for code across the project and should take opportunities to improve it if such an opportunity arises.
Beck’s “sideways” process is evident in the way that testing, design, and coding are merged as tests are written and executed throughout the development and design by refactoring is conducted during coding.
However, extreme programming (XP) may seem at odds with large scale software development and the planning and control such development entails, but the truth is that XP methods can successfully be integrated into organisations using defined software processes.
Implementation of agile principles and XP is largely dependent, as with a project, on the circumstances. There is no silver bullet for development processes; any implementation must be tailored to the context of the project. Mateos-Garcia et al acknowledge this when they conclude “[t]he emphasis on change, flexibility and structural emergence… needs to be balanced with an acceptance of the fact that stability can in some cases be a goal that organisations should strive to”. Studio B provides an example of implementing a balanced approach (Mateos-Garcia & Sapsed, 2008, pp. 11-12) as they have implemented agile practices in a particular area of the product where agility is beneficial (experimental AI) while maintaining stability across the project as a whole. They achieve this by organising the agile element as unit operating within a traditional structure, thus externally the organisation is able to maintain stability, while internally react agilely to changes.
Martinsson (Maturing XP through the CMM, 2003) argues that eXtreme Programming (XP) and the Capability Maturity Model (CMM) are complementary models of software development and can be used together to ensure high quality software products. He believes that the CMM indicates what to do, while XP can suggest how to do it. In spite of this apparent synergy, the CMM already makes suggestions about how to implement its key performance areas (KPAs) (citation needed?), however Martinsson notes it only “suggest[s] possible routes” and “is not mandating how to achieve the associated goals”.
However, when implemented alone, XP’s core practices don’t even meet all the criteria for CMM level 2. The organisation relying purely on XP will not progress beyond the ad-hoc process of CMM level 1. Despite this, core XP practice does fulfil 22 of the 53 CMM goals across 11 of the 18 KPAs. A further 10 goals across 6 KPAs can be fulfilled “either through XP’s values or by using additional common [XP] practices”. (Martinsson, Maturing XP through the CMM, 2003)
To fully integrate XP into a defined software process, driven by the CMM, additional measures are needed to fully address the following KPAs:
- Software Quality Assurance (SQA)
- Organisation Process Focus (OPF)
- Training Program (TP)
- Integrated Software Management (ISM)
- Quantitative Process Management (QPM)
- Software Quality Management (SQM)
- Technology Change Management (TCM)
- Process Change Management (PCM)
Software quality assurance (CMM L2) can be integrated into XP by applying “objective scrutiny” (Martinsson, Maturing XP through the CMM, 2003) and selecting metrics that allow such scrutiny to be applied. In the context of XP, such metrics could be:
- Percentage of successful test cases
- Number of successful acceptance tests
- Individual velocity
- Team velocity
- Actual velocity against estimated velocity
(Martinsson, Maturing XP through the CMM, 2003)
These metrics all support the core XP practices and build on what XP already does to provide suitable data to measure quality. Objectivity should be maintained by ensuring the person responsible for the measurements is not involved in developing for that project. That person is also responsible for communicating the metrics to affected parties and the daily stand up meetings or team notice board are ideal means of doing so in an XP driven project. (Martinsson, Maturing XP through the CMM, 2003)
CMM level 3 is reached by formally establishing the XP process in an organisation process definition and identifying strengths and weaknesses in order to improve, and customising the organisation process definition to the circumstances of each project. Doing so satisfies the Organisation Process Focus (OPF) and Integrated Software Management (ISM) KPAs. To achieve OPF, the CMM suggests a software engineering process group to oversee the management of the process and improvements to it based on regular assessment. ISM is achieved by tailoring the organisation’s standard process to suit individual projects based on feedback from other projects. Process modifications may include altering the iteration length, the frequency of releases, or using different units of estimation for user stories and tasks. (Martinsson, Maturing XP through the CMM, 2003)
Quantitative Process Management (QPM) and Software Quality Management (SQM) are required for CMM level 4. QPM involves using data from past projects to improve the execution of future projects and establish what is possible using that process. For XP to achieve this data from past projects will need to be captured in a format that allows easy comparison. Data that would be relevant would include task estimates and actual implementation times and velocities. The software engineering process group would take responsibility for collecting and analysing this data, supporting their work for the SQA KPA. This then enables much more accurate estimates. (Martinsson, Maturing XP through the CMM, 2003)
SQM requires quantitative measures of software quality in order to ensure customer satisfaction. XP already addresses the issue of customer satisfaction, however it fails to provide quantitative data that can be analysed. Here Martinsson recommends simply doing what the CMM describes: using “surveys, focus groups, and product evaluations to find out the quality needs” and then translating them into XP acceptance tests. The status of these tests can then be used to measure quality throughout the project. (Martinsson, Maturing XP through the CMM, 2003)
The KPAs that need addressing for CMM level 5 are Technology Change Management (TCM) and Process Change Management (PCM). TCM involves constantly reviewing new technologies to see if they can yield an improvement in the process, and accepting that this may mean a shift away from XP as new techniques emerge. TCM would normally be the responsibility of the software engineering process group. PCM, also the responsibility of the software engineering process group, is achieved through training and education in order to involve the every member of the organisation in process improvement by making suggestions to the software engineering process group. (Martinsson, Maturing XP through the CMM, 2003)
Having discussed how to extend core XP practice to achieve a mature and defined process, it is worth noting that both Paulk (Extreme Programming from a CMM Perspective, 2001) and Mateos-Garcia and Sapsed (Adopting Agile and Scrum Practices as Organizational Becoming, 2008) point out that XP is just one methodology, one tool, and not a silver bullet. Process should always be adapted to the project context.
Despite that, this essay has discussed how to implement an XP development process and discussed how to improve upon the core practices to produce a more mature process in line with the CMM view of process quality. To finally answer the original question, it is possible to implement XP successfully into a defined process.
Bibliography
Beck, K. (1999). Embracing Change with Extreme Programming. Computer , 32 (10), 70-77.
Martinsson, J. (2002, October). Maturing extreme programming through the CMM. Lund: Department of Computer Science, Lund University.
Martinsson, J. (2003). Maturing XP through the CMM. (M. Marchesi, & G. Succi, Eds.) Lecture Notes in Computer Science (2675), 80-87.
Mateos-Garcia, J., & Sapsed, J. (2008). Adopting Agile and Scrum Practices as Organizational Becoming. British Academy of Management Annual Conference. Harrogate, UK: British Academy of Management.
Paulk, M. C. (2001). Extreme Programming from a CMM Perspective. IEEE Software , 18 (6), 19-26.
Pressman, R. S. (2005). Chapter 4: An Agile View of Process. In Software Engineering: A Practitioner’s Approach (6th Edition ed., pp. 110-113). New York, US: McGraw-Hill.
eXtreme Programming and the Capability Maturity Model
(C) Lisamarie Babik
An essay I wrote for my software measurement and quality assurance module discussing how eXtreme programming can be implemented in a business and in such a way that it can satisfy the capability maturity model.
How can extreme programming be implemented successfully in an organisation? Can it be incorporated into a defined software process?
Extreme Programming (XP) has become a popular agile process. This essay will discuss how XP principles and core practices can be implemented in an organisation, and extended into mature and defined software process that satisfies the various Capability Maturity Model (CMM) levels.
XP promotes, from the perspective of traditional approaches, a radical orientation to change that Mateos-Garcia and Sapsed (Adopting Agile and Scrum Practices as Organizational Becoming, 2008) believe can “give rise to new structures for project management” (pp. 2-3)
XP is based on iterative process models and includes the familiar stages of planning, design, coding, and testing, within each stage there are tools and practices. For example, user stories during planning, class responsibility-collaborator (CRC) cards and prototypes during design, developing unit tests prior to coding and pair programming during coding to improve quality, and acceptance tests based on user stories. (Pressman, 2005)
What makes XP so radical is how it “turns conventional software process sideways” (Beck, 1999), which in practice means that the distinct planning, design, coding, and testing phases of the iterative processes, from which XP evolved, merge and are conducted simultaneously.
Beck’s article (Embracing Change with Extreme Programming, 1999), though old, explains XPs core practices and how they can be implemented. The organisation implementing XP should focus on releasing working increments through short iterations.
The features to be included in an iteration are determined by the “planning game” (Beck, 1999) where clients rate the priority and developers estimate the time required for each feature, and the client selects the most important features until all the developer time is used up. Honest and clear communication with the client is essential throughout the project, but particularly during the planning game.
Features are broken down into tasks that are allocated to developers, who then write tests based on client input to determine when a feature is working satisfactorily and then implement the feature to satisfy the tests. This test-driven development helps the organisation rapidly produce working code, and if automated can be used to continuously integrate new code ensuring the latest build of the product is always working.
Coding is done in pairs so that code is reviewed as it is written and refactoring existing code is encouraged. Refactoring is supported by the notion of collective ownership: the idea that each developer is responsible for code across the project and should take opportunities to improve it if such an opportunity arises.
Beck’s “sideways” process is evident in the way that testing, design, and coding are merged as tests are written and executed throughout the development and design by refactoring is conducted during coding.
However, extreme programming (XP) may seem at odds with large scale software development and the planning and control such development entails, but the truth is that XP methods can successfully be integrated into organisations using defined software processes.
Implementation of agile principles and XP is largely dependent, as with a project, on the circumstances. There is no silver bullet for development processes; any implementation must be tailored to the context of the project. Mateos-Garcia et al acknowledge this when they conclude “[t]he emphasis on change, flexibility and structural emergence… needs to be balanced with an acceptance of the fact that stability can in some cases be a goal that organisations should strive to”. Studio B provides an example of implementing a balanced approach (Mateos-Garcia & Sapsed, 2008, pp. 11-12) as they have implemented agile practices in a particular area of the product where agility is beneficial (experimental AI) while maintaining stability across the project as a whole. They achieve this by organising the agile element as unit operating within a traditional structure, thus externally the organisation is able to maintain stability, while internally react agilely to changes.
Martinsson (Maturing XP through the CMM, 2003) argues that eXtreme Programming (XP) and the Capability Maturity Model (CMM) are complementary models of software development and can be used together to ensure high quality software products. He believes that the CMM indicates what to do, while XP can suggest how to do it. In spite of this apparent synergy, the CMM already makes suggestions about how to implement its key performance areas (KPAs) (citation needed?), however Martinsson notes it only “suggest[s] possible routes” and “is not mandating how to achieve the associated goals”.
However, when implemented alone, XP’s core practices don’t even meet all the criteria for CMM level 2. The organisation relying purely on XP will not progress beyond the ad-hoc process of CMM level 1. Despite this, core XP practice does fulfil 22 of the 53 CMM goals across 11 of the 18 KPAs. A further 10 goals across 6 KPAs can be fulfilled “either through XP’s values or by using additional common [XP] practices”. (Martinsson, Maturing XP through the CMM, 2003)
To fully integrate XP into a defined software process, driven by the CMM, additional measures are needed to fully address the following KPAs:
Software quality assurance (CMM L2) can be integrated into XP by applying “objective scrutiny” (Martinsson, Maturing XP through the CMM, 2003) and selecting metrics that allow such scrutiny to be applied. In the context of XP, such metrics could be:
(Martinsson, Maturing XP through the CMM, 2003)
These metrics all support the core XP practices and build on what XP already does to provide suitable data to measure quality. Objectivity should be maintained by ensuring the person responsible for the measurements is not involved in developing for that project. That person is also responsible for communicating the metrics to affected parties and the daily stand up meetings or team notice board are ideal means of doing so in an XP driven project. (Martinsson, Maturing XP through the CMM, 2003)
CMM level 3 is reached by formally establishing the XP process in an organisation process definition and identifying strengths and weaknesses in order to improve, and customising the organisation process definition to the circumstances of each project. Doing so satisfies the Organisation Process Focus (OPF) and Integrated Software Management (ISM) KPAs. To achieve OPF, the CMM suggests a software engineering process group to oversee the management of the process and improvements to it based on regular assessment. ISM is achieved by tailoring the organisation’s standard process to suit individual projects based on feedback from other projects. Process modifications may include altering the iteration length, the frequency of releases, or using different units of estimation for user stories and tasks. (Martinsson, Maturing XP through the CMM, 2003)
Quantitative Process Management (QPM) and Software Quality Management (SQM) are required for CMM level 4. QPM involves using data from past projects to improve the execution of future projects and establish what is possible using that process. For XP to achieve this data from past projects will need to be captured in a format that allows easy comparison. Data that would be relevant would include task estimates and actual implementation times and velocities. The software engineering process group would take responsibility for collecting and analysing this data, supporting their work for the SQA KPA. This then enables much more accurate estimates. (Martinsson, Maturing XP through the CMM, 2003)
SQM requires quantitative measures of software quality in order to ensure customer satisfaction. XP already addresses the issue of customer satisfaction, however it fails to provide quantitative data that can be analysed. Here Martinsson recommends simply doing what the CMM describes: using “surveys, focus groups, and product evaluations to find out the quality needs” and then translating them into XP acceptance tests. The status of these tests can then be used to measure quality throughout the project. (Martinsson, Maturing XP through the CMM, 2003)
The KPAs that need addressing for CMM level 5 are Technology Change Management (TCM) and Process Change Management (PCM). TCM involves constantly reviewing new technologies to see if they can yield an improvement in the process, and accepting that this may mean a shift away from XP as new techniques emerge. TCM would normally be the responsibility of the software engineering process group. PCM, also the responsibility of the software engineering process group, is achieved through training and education in order to involve the every member of the organisation in process improvement by making suggestions to the software engineering process group. (Martinsson, Maturing XP through the CMM, 2003)
Having discussed how to extend core XP practice to achieve a mature and defined process, it is worth noting that both Paulk (Extreme Programming from a CMM Perspective, 2001) and Mateos-Garcia and Sapsed (Adopting Agile and Scrum Practices as Organizational Becoming, 2008) point out that XP is just one methodology, one tool, and not a silver bullet. Process should always be adapted to the project context.
Despite that, this essay has discussed how to implement an XP development process and discussed how to improve upon the core practices to produce a more mature process in line with the CMM view of process quality. To finally answer the original question, it is possible to implement XP successfully into a defined process.
Bibliography
Beck, K. (1999). Embracing Change with Extreme Programming. Computer , 32 (10), 70-77.
Martinsson, J. (2002, October). Maturing extreme programming through the CMM. Lund: Department of Computer Science, Lund University.
Martinsson, J. (2003). Maturing XP through the CMM. (M. Marchesi, & G. Succi, Eds.) Lecture Notes in Computer Science (2675), 80-87.
Mateos-Garcia, J., & Sapsed, J. (2008). Adopting Agile and Scrum Practices as Organizational Becoming. British Academy of Management Annual Conference. Harrogate, UK: British Academy of Management.
Paulk, M. C. (2001). Extreme Programming from a CMM Perspective. IEEE Software , 18 (6), 19-26.
Pressman, R. S. (2005). Chapter 4: An Agile View of Process. In Software Engineering: A Practitioner’s Approach (6th Edition ed., pp. 110-113). New York, US: McGraw-Hill.