The extreme programming bandwagon: Revolution or just revolting?

Neill, Colin J.

doi:10.1109/mitp.2003.1235612

Cited by 7 publications

(15 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The impact of changes in scope and requirements within ISD projects can vary greatly depending on the stage at which the change is introduced. The cost of change rises phenomenally throughout traditional development (Boehm 1981) while in agile projects the impact of change levels off (Neill 2003). Agile methods aim to reduce the cost of changes throughout the development of a system, but not necessarily to reduce the occurrence of changes (Highsmith and Cockburn 2001).…”

Section: Methodology Issuesmentioning

confidence: 99%

Cost Estimation in Agile Software Development Projects

Lang

Conboy

Keaveney

2013

Information Systems Development

View full text Add to dashboard Cite

Abstract. Numerous studies over the years have shown that information systems development (ISD) projects often run over budget or fail entirely. Such failures are not restricted to certain industry sectors or project types; rather they occur with some regularity in systems development projects and organizations of all types and sizes. Cost estimation has long been a difficult task in systems development, and although much research has focused on traditional methods, little is known about estimation in the agile method arena. This is somewhat ironic given that the reduction of cost and development time is the driving force behind the emergence of agile methods. This study looks at how classical problems which adversely affect cost estimation in traditional ISD are managed within the agile paradigm. A qualitative approach was followed, based on data collected from four companies. Amongst other findings, the study revealed that estimation inaccuracy was a less frequent occurrence for these companies. A number of recommendations can be drawn from the research: estimation models are not a necessary component of the process; fixed price budgets can prove beneficial for both developers and customers; and experience and past project data should be documented and used to aid future estimation efforts.

show abstract

Section: Methodology Issuesmentioning

confidence: 99%

Cost Estimation in Agile Software Development Projects

Lang

Conboy

Keaveney

2013

Information Systems Development

View full text Add to dashboard Cite

show abstract

“…An example of this is the assembling of a car on a production line. Taylorism has inspired other methodologies such as the Just in time, where an integrated supply chain and a highly adaptive manufacturing plant allows for a build-to-order approach, in contrast to the build-to-stock with large inventory systems (Neill, 2003). This gives the producer a chance to manufacture things when needed and not just store the products in a storage house.…”

Section: Traditional Project Methodologymentioning

confidence: 99%

“…Björkholm and Brattberg (2010) suggest that the teams are happier when working Agile, since it focuses on the creativity and collaboration within the team. Some authors even claim that the Agile software development is cheaper than traditional developing processes (Björkholm & Brattberg, 2010;Anderson, 2004;Neill, 2003).…”

Section: Agile Project Methodsmentioning

confidence: 99%

Agile Project Management

Schiel¹

2009

Applied Software Engineering Series

View full text Add to dashboard Cite

Thesis type:Master thesis Language: English Key words:Project methodology, Agile, Scrum, Usefulness, Values, Principles, Change, Practice AbstractThis study focus on finding how project usefulness is connected to the Agile software development process. In order to narrow the broad research area down we have decided to only focus on the most adopted methods within software development, Scrum. The research model consists of values, principles and a project process model describing how an Agile/Scrum project process ought to be together with project usefulness found in models and guidelines. Five interviews, within three different companies, were made in order to find out what their Scrum process looks like and to find project usefulness. Our findings was then discussed and analysed in comparison to the research model. A suggestion on what different features in the Scrum project process results in project usefulness is illustrated. The different features in a Scrum project process that results in the most project usefulness are: working with sprints and the daily Scrum. Daily Scrum result in more flexibility, a learning environment and more productivity. Working with sprints results in more flexibility, a closer customer relationship, a more customized product and more productivity.

show abstract

“…When XP practicers use the method for release planning, they still feel difficult in deciding what information they should collect and how to make feedbacks to customers to reach the agreement about a release plan. Some problems caused by unsuitable releasing plan in XP practice are reported such as that developers are unable to finish project for absence of integrated system viewpoints [9,10,22,23], inadequate negotiation during release planning [11], high development organization risks caused by excessive dependence on personal experiences [8], and so on. Therefore, an exact method is needed for developers to follow during XP release planning.…”

Section: Related Workmentioning

confidence: 99%

“…Some researchers reported that release planning had become the response to customers' requests entirely and been uncontrollable because of the absence of integrated system's viewpoint, inadequate negotiation among stakeholders and so on. Thus, many XP processes are full of reworks and wrong problem solutions [3,7,8,9,10,11].…”

Section: Introductionmentioning

confidence: 99%

A risk-driven method for eXtreme programming release planning

Huang

Shu

et al. 2006

Proceedings of the 28th International Conference on Software Engineering

View full text Add to dashboard Cite

XP (eXtreme Programming) has become popular for IID (Iteration and Increment Development). It is suitable for small teams, lightweight projects and vague/volatile requirements. However, some challenges are left to developers when they desire to practise XP. A critical one of them is constructing the release plan and negotiating it with customers. In this paper, we propose a risk-driven method for XP release planning. It has been applied in a case study and the results show the method is feasible and effective. XP practicers can follow it to decide a suitable release plan and control the development process.

show abstract

The extreme programming bandwagon: Revolution or just revolting?

Cited by 7 publications

References 0 publications

Cost Estimation in Agile Software Development Projects

Cost Estimation in Agile Software Development Projects

Agile Project Management

A risk-driven method for eXtreme programming release planning

Contact Info

Product

Resources

About