FREE ELECTRONIC LIBRARY - Thesis, documentation, books

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |

«ABSTRACT The purpose of this research study is to perform a comparison and contrast analysis on three F. Davis Cardwell published longitudinal case ...»

-- [ Page 4 ] --

Scrum teams work in short iterations, often between 2 weeks and 30 days long. In Scrum, the current iteration is called a “sprint.” A sprint planning meeting is held with the Scrum development team: testers, management, the project manager, and the product owner. In the sprint planning meeting, this group chooses which features from the product backlog are to be included in the next iteration, driven by highest business value, risk and the capacity of the team. Once a sprint begins, it is locked; at that point, features cannot be added to the current sprint. Daily 10-to-15 minute Scrum meetings are held. While these meetings are open, only members of the Scrum team are allowed to actively participate; all others may only observe. Each team member answers the following questions: “What have you done since the last daily Scrum? What will you do between now and the next daily Scrum? What is getting in the way of you doing your work?” (Williams, Brown, et al., 2011, p. 2) At the end of a sprint, a sprint review takes place to review progress and to demonstrate completed features to the product owner, management, users, and the team members. After the sprint review, the team conducts a retrospective meeting. In the retrospective meeting, the team discusses what went well in the last sprint and how they might improve for the next one. (Williams, et al., 2011, pp.

1 – 2)



Figure 8. The Scrum Process (Abrahamsson, et al., 2002, p. 28)

• The Crystal Family of Methodologies. Crystal was founded by Alistair Cockburn, one of the authors of the agile manifesto. He developed the Crystal family of software development processes as a group of approaches tailored to fit different size teams. Crystal is seen as a family because of the belief that different approaches are needed, depending on the size of the development team and the criticality of the application.

Figure 9. The Crystal Family (Abrahamsson, et al., 2002, p. 37)

Each color in the Crystal family denotes its “heaviness;” the darker the color, the heavier or more plandriven the method. The character symbols in the illustration represent the potential loss due to a system failure: Comfort [C], Discretionary money [D], Essential money [E], and Life [L]. Currently, only


Crystal Clear and Crystal Orange are realized. All Crystal approaches share common features; they all have three priorities: safety [in project outcome,] efficiency, and habitability [developers can live with the process.] They also share common properties, of which the most important are: frequent delivery, reflective improvement, and close communication. The focus on habitability is an important part of the Crystal mindset. The overarching goal of Crystal is to put into place the smallest effective amount of process possible. As a result, Crystal requires less discipline than XP, trading off efficiency for greater habitability and reduced chance of failure. (Fowler, 2005, pp. 23 – 24)

Figure 10. One Crystal Orange Increment (Abrahamsson, et al., 2002, p. 41)

• Dynamic Systems Development Method. DSDM is a development process based on agile principles, including iterative and incremental development and continuous user/customer involvement. DSDM consists of five phases: [1] feasibility study, [2] business study, [3] functional model iteration, [4] design and build iteration, and [5] implementation. DSDM incorporates iterations through time boxes; a time box lasts for a predetermined period of time, and the iteration ends with the expiration of the time box. DSDM fixes cost, quality, and time at the outset and uses prioritization of scope into musts, shoulds, coulds, and won’t haves to adjust the project deliverable

to meet the fixed business constraints. There are nine underlying principles of DSDM:

1. Active user involvement is imperative.

2. Teams are empowered to make decisions.

3. The focus is on frequent delivery of products.

4. Fitness for business purposes is the essential criterion for acceptance of deliverables.

5. Iterative and incremental development is necessary in order to converge on an accurate business solution.

6. All changes during development are reversible.



7. Requirements are base lined at a high level.

8. Testing is integrated throughout the life-cycle.

9. A collaborative and cooperative approach shared by all stakeholders is essential. (Abrahamsson, et al., 2002, pp. 61 – 64) Figure 11. The DSDM Process (Abrahamsson, et al., 2002, p. 62)

• Feature-Driven Development. FDD is an agile, highly adaptive software development process that is based on multiple short iterations. FDD emphasizes quality at all steps; delivers frequent, tangible working results; and provides accurate and meaningful progress and status information

with the minimum of overhead and disruption for the developers. FDD is composed of five phases:

[1] Develop an overall model, [2] build a feature list, [3] plan by feature, [4] design by feature, and [5] build by feature.

FDD decomposes the entire problem domain into tiny problems, called features, which can be solved in a small period of time, usually two weeks. A feature is a small, client-valued function that can be implemented in the time allotted. In a business system, a feature maps to a step in an activity within a business process. Any function deemed too complex to be implemented within two weeks is further decomposed into smaller functions until each sub-problem is small enough to be called a feature. Features are then developed independently. Unlike some other agile methods, FDD claims to be suitable for the development of critical systems. (Abrahamsson, et al., 2002, pp.

47 – 49)



Figure 12. The FDD Process (Abrahamsson, et al., 2002, p. 48)

• Adaptive Software Development. ASD is an agile software development process that grew out of rapid application development work done by James A. Highsmith III and Sam Bayer. The central principle of ASD is that continuous adaptation of the process to the work at hand is the normal state of affairs. ASD replaces the traditional waterfall cycle with a repeating series of phases: speculate, collaborate, and learn. The ASD process is mission focused, feature based, iterative, time boxed, risk driven, and change tolerant. The phases are named as they are to emphasize the role of change throughout the process. The word “speculate” is used rather than plan, because of the common assumption that a deviation from the plan is a failure. Likewise, “collaboration” refers to the teamwork necessary to effectively develop software under changing circumstances. The word “learning” acknowledges that mistakes are inevitable when developing software in a rapidly changing environment; the key is to learn from correcting the mistakes, which leads to greater experience and eventually mastery over the problem domain. (Abrahamsson, et al., 2002, pp. 68 – 71) Figure 13. The ASD Process (Abrahamsson, et al., 2002, p. 70)



This is by no means a comprehensive list of all of the existing agile development processes. Some of the additional processes that are considered part of the agile development family include the Rational Unified Process [RUP], Agile Modeling, Pragmatic Programming, and Context Driven Planning, to name a few. Some of these, such as RUP, are more properly considered to be development frameworks that can be imposed upon any software development method regardless of whether it is agile or traditional. Others, such as Agile Modeling, are not stand-alone processes, but can be used within a complete process. These processes and other agile processes that have not been mentioned are outside of the scope of this paper. [See Appendix B for a table showing comparative features of the agile software development processes described.]


The reaction of the software development community to the introduction of agile methods has been mixed. Proponents of agile methods have strenuously and vociferously promoted agile methods as a panacea for all software development problem domains. Opponents have just as strenuously argued that a structured and planned methodology is necessary to successfully develop software, especially for safety-critical systems. There is quite a bit of anecdotal evidence that agile methods are effective in certain situations; as experience with agile methods has grown, a body of evidence has slowly emerged as to its practical effectiveness. By 2001, there was enough practical experience with agile development to conclude that agile development works, given a relatively narrow set of circumstantial parameters; specifically, agile processes can be said to work where the project is non safety-critical, has volatile requirements, and is developed by small, skilled teams located near enough to one another that rapid and consistent communication is possible. Although the agile value set can be adapted to work under different circumstances, experience to date seems to be defining the boundary conditions for truly agile behavior to this parameter set. (Williams & Cockburn, 2011, p. 40)


There are three related case studies supporting this research; the first is a longitudinal case study performed by Layman, Williams, & Cunningham (2004a.) This case study evaluates the effects of adopting the Extreme Programming [XP] methodology in an industrial environment [i.e., Sabre Airline Solutions]. The case study compares two releases of the same product. The first release was developed using traditional development methods, immediately prior to the team’s adoption of XP methodology. The second release was completed after approximately two years of XP use. The second case study is a similar study, done by the same research team in the same industrial environment. This study compares the release of a larger project developed using XP to published industry averages. (Layman, Williams, & Cunningham 2004b) The third case study compares the second and third releases of a Servlet/XML application developed by a seven-person team at IBM for a toolkit that is used to create products for external customers. (Williams, Krebs, et al., 2004, p. 2.) The team used a subset of XP practices deemed “safe” and appropriate for their team culture and project characteristics. In the second release, the team began their initial adoption of XP practices.

The team then expanded their XP adoption in the third release. Supporting these three studies is an evaluation framework developed by Williams, Krebs, & Layman (17 June, 2004) which provides a benchmark measurement method to assess how thoroughly and how effectively an organization has adopted XP practices. Additional research data are drawn from Hanssen & Fægri (2006), which presents data concerning customer engagement for both traditional development methods and agile methods, as experienced by a small software product company. Additional empirical data are provided by Lindvall, Basili, Boehm, Costa, Dangle, Shull,... Zelkowitz (2002.) An empirical case study concerning stakeholder satisfaction within agile development projects is presented by Ferreira & Cohen (2008.) Data concerning project failure within software development projects of all methods are presented in a case study by Linberg (1999.) These data are useful in determining the effects of software development methods on product quality. Additional data are drawn from a case study presented by Williams, Brown, et al. (2011), which describes the experiences of three development teams implementing Scrum at Microsoft. A method for determining the optimal development method


based on project risk factors is provided by Boehm and Turner (2003.) Evaluation of the research data is facilitated by Ho, Johnson, Williams, & Maximilien (2006) in a paper that provides information on evaluating agile performance requirements, specifications, and testing. Abbas, et al., (2008) explore the historical roots of development methods, and discuss the impact of agile thinking on the development process. Brooks (1995) provides a framework for understanding schedule performance within software development projects. Dalcher (2005) provides an overview of methods for understanding quality issues within software development projects. Finally, Siakas & Siakas (2007) explore ways in which agile professional culture impacts software development quality.




To provide a framework for drawing useful conclusions from the case study data that follows, the chapter begins with an explanation of the XP evaluation framework. Next the chapter presents findings gleaned from the case studies used as the foundation for this paper. Finally, the selected data are compared and evaluated in terms of their impact on development costs, development schedule, quality, and stakeholder satisfaction.


One of the reasons that this particular set of case studies was chosen from the relevant literature is the existence of an evaluation framework used throughout the studies to organize the data. This framework, the XP evaluation framework, version 1.4 (Williams, Krebs, & Layman, 2004), is useful because it helps to normalize the inevitable differences in particulars between the compared projects.

Pages:     | 1 |   ...   | 2 | 3 || 5 | 6 |   ...   | 9 |

Similar works:

«Goat meat comprises 63 percent of all red meat that is consumed worldwide. Currently, goats are the main source of animal protein in many North African and Middle Eastern nations, and are also important in Southeast Asia, the Caribbean, and other tropical regions. Cabrito, a delicacy in Central and South America, is meat from goat kids slaughtered when 1 to 3 months of age weighing less than 50 pounds. Chevon is meat from goat kids 6 to 9 months of age weighing from 50 to 75 pounds. With a...»

«Position Paper: Cultural Competence in Supervision By: Shadee Hardy, MSW, LICSW Edited by: Paula Tracey, MSW, LICSW The Supervision Task Force Group on Cultural Competence: This position paper was developed in collaboration during a series of roundtable discussions with social work practitioners and educators from around the state of Minnesota committed to the issue of cultural competence as it relates to supervision. The Task Force Group was a subgroup of the Minnesota Coalition of Licensed...»

«Locum Vicar Parish Link The Rt Rev’d George Hearn, Sunday 26th July, 2015 T 9840 7816 Email: ANGLICAN PARISH OF BOX HILL georgeahearn@optusnet.com.au Ninth Sunday after Pentecost Honorary Clergy Seasonal colour: Green The Rev’ds Betty Bracken 9939 5881 John Stockdale 9890 8388 Harry Kerr 9893 4946 Sudanese Priest Mission Statement Rev’d Joseph Arou Sharing the Good News T 0431 541 535 Telling the story afresh E lokagai@hotmail.com Expressing God’s love Nurturing and sharing faith...»

«Andreas Cordes andreas.cordes@online.de Job profile and training requirements for European Flight Dispatchers Submitted as part of the requirements for the award of MSc in Air Transport Management at City University London I certify that this project is wholly my own work and that all material that has been extracted from others has been clearly referenced Signed Supervisor: Professor Roger Wootton January 2007 Word Count: 14266 Unrestricted circulation Executive Summary While operational...»

«Brabazon, Philip G. and MacCarthy, Bart L. (2007) Consideration of the relevance of standard quality techniques in Mass Customisation. International Journal of Mass Customisation, 2 (1/2). pp. 76-94.Access from the University of Nottingham repository: http://eprints.nottingham.ac.uk/527/1/Consideration_of_quality_for_MC.pdf Copyright and reuse: The Nottingham ePrints service makes this work by researchers of the University of Nottingham available open access under the following conditions. This...»

«Permutation and Sampling with Maximum Length CA for Pseudorandom Number Generation Sastra Wijaya, Syn Kiat Tan, Sheng-Uei Guan1 Department of Electrical and Computer Engineering National University of Singapore 10 Kent Ridge Crescent, Singapore 119260 Abstract—In this paper, we study the effect of dynamic permutation and sampling on the randomness quality of sequences generated by cellular automata (CA). Dynamic permutation and sampling have not been explored in previous CA work and a...»

«Telecommunication Engineering University of Twente University of Twente Faculty of Electrical Engineering Chair for Telecommunication Engineering EMC STUDY OF AN AUTOMOTIVE APPLICATION by Dongsheng Zhao Master thesis Executed from August 2003 to April 2004 Supervisor: prof. dr. ir. F.B.J. Leferink, University of Twente J. van Duijn, NEDAP Advisor: prof. dr. ir. W.C. van Etten, University of Twente Telecommunication Engineering University of Twente University of Twente Faculty of Electrical...»

«Five Cents a Day: Innovative Programs for Reaching the Destitute with Microcredit, No-interest Loans, and other Instruments: The Experience of Grameen Bank Written by: Dipal Chandra Barua Deputy Managing Director Grameen Bank Mirpur-2, Dhaka-1216 Email: dipal@grameen.com Bangladesh Paper presented at Global Microcredit Summit held Nov 12-15, 2006 in Halifax, Nova Scotia, Canada CONTENTS Origin of Grameen Bank Transformation into Bank: Owned by the poor Organizational structure of Grameen Bank...»

«Interactive Augmented Reality in Digital Broadcasting Environments Diplomarbeit vorgelegt von Tobias Daniel Kammann als Teil der Voraussetzung zur Erlangung des Titels Diplom-Informatiker im Studiengang Computervisualistik Institut für Computervisualistik VICOMTech Mitglied des Arbeitsgruppe Computergraphik Visual Communication Inigraphics.net Technologies Prüfer: Prof. Dr.-Ing. Stefan Müller Betreuer: Dip. Ing. Igor García Olaizola November 2005 Eidesstattliche Erklärung Hiermit erkläre...»

«MT-093 TUTORIAL Thermal Design Basics INTRODUCTION For reliability reasons, integrated circuits handling appreciable power are increasingly called upon to observe thermal management. All semiconductors have some specified safe upper limit for junction temperature (TJ), usually on the order of 150°C (sometimes 175°C). Like maximum power supply voltages, maximum junction temperature is a worst case limitation which must not be exceeded. In conservative designs, it won’t be approached by less...»

«NBSL Web Services Standard Terms & Conditions Version 1.1 (29 Sepember 2014) By signing the NBSL Web Services Agreement, you (the “Customer”) agree to accept and abide by the following terms and conditions. Definitions “NBSL” means Nielsen Book Services Limited, trading as Nielsen BookData, registered in England and Wales, with company number 00070437, whose registered office is at 3rd Floor, Midas House, 62 Goldsworth Road, Woking, Surrey GU21 6LQ, UK. “Customer” means the company...»

«www.mscibarra.com MSCI China A Index Methodology INDEX OBJECTIVES, CONSTRUCTION AND MAINTAINANCE METHODOLOGY FOR THE MSCI CHINA A INDEX August 2008 MSCI China A Index Methodology Guide Notice and Disclaimer This document and all of the information contained in it, including without limitation all text, data, graphs, charts (collectively, the “Information”) is the property of MSCl Inc. (“MSCI”), Barra, Inc. (“Barra”), or their affiliates (including without limitation Financial...»

<<  HOME   |    CONTACTS
2016 www.thesis.xlibx.info - Thesis, documentation, books

Materials of this site are available for review, all rights belong to their respective owners.
If you do not agree with the fact that your material is placed on this site, please, email us, we will within 1-2 business days delete him.