Search

Can research projects be agile? In this paper we describe our proposal of applying Scrum for the management of an European research project aimed at developing an agent-based software platform for European economic policy design. The use of an agile, adaptive methodology is justified because successful research projects are complex, unstable processes, that should be continuously adapted along their way. We describe in detail the roles, artifacts and practices of the proposed process, and the first steps of its adoption. [ABSTRACT FROM AUTHOR]

Software describes an imagined machine. To be software, the description must be executable, which means written so a computer can animate it. Non-executable descriptions (specifications, designs, &c.) are instrumental to this work; they are intermediate texts. We advance a model of software development as the collaborative writing of a series of descriptions. We propose the chief distinction of agile development to be the exclusion from this process of the human translation of intermediate texts. We distinguish supported and unsupported communication. We analyse the success of Extreme Programming in terms of avoiding unsupported communication and prioritising feedback from executable descriptions. We describe functional programming techniques to construct notations that allow programmers and users to collaborate writing executable system descriptions, collapsing distinctions between analysis, design, coding and testing. We describe a metric of code clarity, semantic density, which has been essential to the success of this work. We report the use of these techniques in the Pensions division of Britain's largest insurer, and its effect on the business. [ABSTRACT FROM AUTHOR]

Does the discipline inherent in Agile/XP methods change the way a company does business in contrast to the influences of "traditional" plan-driven or ad-hoc software development practices? Are there differences in strategies for customer engagement, staff resourcing, and program management? Companies live or die depending on the accuracy of scheduling/budgeting projections and the ability to do more with less. Lean development, SCRUM, XP, and other agile methods may stress companies in hitherto unanticipated ways leading to both evolutionary and revolutionary organizational change. This panel will dis cuss the differences and similarities between XP/Agile and more traditional software development practices with regard to their impact on companies. [ABSTRACT FROM AUTHOR]

Politics and Religion are traditionally taboo topics in polite after-dinner conversation. In this panel, we are going to discuss taboo topics in agile software development. Technical teams ought to choose technology based on the immediate needs of the current project and organization. But we all know that technology and methodology choices are often driven by people enhancing their resume - this conflict can start religious wars! On agile projects, we ask our customers to prioritize stories purely by business value, as if this is a straightforward thing to do and company politics are irrelevant. We need to recognize that projects that only deliver working software can still be classed as failures from an organizational perspective. If we pretend that the political dimension does not exist on agile projects then we cannot develop and share practices that help us handle these situations. This panel brings industry professionals to share their perspectives and experiences, the audience should come prepared to both ask and answer questions. [ABSTRACT FROM AUTHOR]

Open Source Software (contrasted with proprietary or "closed" software) has become a more widely accepted enterprise solution not withstanding some issues related to intellectual property rights and issues of liability and indemnification. Open Source Software (OSS) takes collaborative software development to a global extreme - OSS also provides a mechanism for decreasing time-to-market, improved quality, and reduced development costs. This panel will serve as a catalyst to discuss strategies, tools, and communities focused on the development and application of open source software. [ABSTRACT FROM AUTHOR]

Faced with challenges in relation to interpretation of requirements, issues with build and deployment and excessive integration defects, this paper examines how a software team propose using a novel combination of Covey's ‘First Things First' principle and Cockburn's Methodology Shaping, as a potential solution to examine their current process and define a new set of working conventions which will address these issues. Keywords: Methodology, software, agile, time-management. [ABSTRACT FROM AUTHOR]

This paper describes the practices created, adopted and evolved in a Distributed Open Source Project (PyPy) project. PyPy is a hybrid project, combining the different aspects of Agile and Distributed Development within the context of an Open Source community. The project is partially funded by the European Commission through the 6th Framework Program. Influences and adoptions of techniques such as "sprinting" has been a core balancing act for the project since its inception. "Sprints" in the Python community differs from the Scrum version of sprints and in this paper we will present how this evolved agile method acts as a primary method of quality assuring the aspects of distributed and dispersed work style of the PyPy project and insures an ongoing interaction with the Open Source aspects of the project. [ABSTRACT FROM AUTHOR]

A prototype test driven development tool for embedded systems has been developed with hardware-oriented extensions to CPPUnitLite. However xUnit tests are written in the language of the solution; problematic in the development of biomedical instruments as the customer, the "doctor", does not have "extensive knowledge of the domain". The biomedical application is often prototyped within MATLAB before movement down to the "plumbing level" on a high-speed, highly parallel, processor to meet the requirement for real-time application in a safe and secure manner "in the surgical theatre" or "on the ward". A long term research goal is an investigation of how to gain, as with standard business desktop system, the full advantage of using Fit and FitNesse as communication tools under these circumstances. We demonstrate the practical application of using indirection to permit a single set of Fit tests for both MATLAB and embedded system verification for a biomedical instrument. [ABSTRACT FROM AUTHOR]

This article presents the Automatic Changes Propagation tool, which is used in one of Polish software companies. This system tries to solve the problem of introducing changes in deployed system versions when an error in the head version is found. The tool was created to speed the process of changes propagation for the application used in more than 12 Polish financial institutions. Unfortunately, the customers have different system versions and therefore it is not enough to correct only the newest one. Because the manual changes are time-consuming, monotonous and error-prone the automatic way is very desired. Moreover, the Automatic Changes Propagation tool prepares the application patches which are ready for deployment. [ABSTRACT FROM AUTHOR]

Very little has been written to date on how to prioritize and sequence the development of new features and capabilities on an agile software development project. Agile product managers have been advised to prioritize based on "business value." While this seems an appropriate goal, it is vague and provides little specific guidance. Our approach to optimizing "business value" uses tactics to minimize costs and maximize benefits through strategic learning. In order to provide specific and actionable advice to agile product managers, we present two guidelines. These guidelines are meant to provide a set of considerations and a process by which an agile product manager can achieve the goal of optimizing "business value" while recognizing that different product managers will vary in their notions of what "business value" is. [ABSTRACT FROM AUTHOR]

Agile approaches including XP and Scrum grew out of one particular team's practice, so its advice contains hidden assumptions we need to identify. If we do not, we risk seeing these techniques fail a team, or a team fail with these techniques. This report describes one team's experience learning adaptive planning, and the steps it took to augment the out-of-the-box process that the agile literature suggests. It shows how the team's environment has motivated these changes while allowing the team to continue to engage in an evidence-based continuous improvement program. [ABSTRACT FROM AUTHOR]

Large software development projects are not agile by nature. Large projects are not easy to implement, they are even harder to implement using agile methodologies. Based on over 6 years of experience building software systems using agile methodologies we found that we can modify agile methodologies to be successfully applied to large projects. In this paper, we will introduce a development practice, which we call Divide After You Conquer to reduce some of the challenges during the development of large agile projects. By solving the base problem first with a smaller development team (Conquer phase) before expanding the team to its full size (Divide phase) we can solve many of the problems that occur with larger projects using agile methodologies. [ABSTRACT FROM AUTHOR]

Security is a critical part of systems development, particularly for web-based systems. There is little known about how to effectively integrate security into incremental development processes such as Extreme Programming. This paper presents the results of a project that used Extreme Programming practices and deferred consideration of security until system functionality was complete. The findings suggest that refactorings within incremental development processes are capable of delivering high quality security solutions, and provide insights into how security requirements can be incorporated in the planning game. [ABSTRACT FROM AUTHOR]

Due to a number of similarities between user-centred design (UCD) and agile development, coupled with an appreciation that developers are rarely usability experts, it seems attractive to integrate these two approaches. However, although agile methods share some of the same aims as UCD, there are also distinct differences. These differences have made the use of these methods on development projects problematic. This paper reports a field study designed to investigate the use of agile methods alongside UCD in one particular organization. The aim of the study was to develop a framework for use by project teams wishing to integrate UCD practices with agile development. The study, its findings and five principles for integrating UCD and agile development arising from this work are discussed. [ABSTRACT FROM AUTHOR]

This article introduces a new practice to eXtreme Programming (XP): Developer stories. The goal of these stories and their creation process is to incorporate architectural planning to XP thus ensuring a viable architecture. By conducting a small development project using XP, we find that establishing a viable architecture might be problematic. Arguing that architectural quality criteria in XP are traceable to traditional criteria, and by pointing to related work regarding incremental continous design, requirements management and large-scale refactorings, we find support for this claim. We proceed by describing the new practice ensuring that it embraces the values, and supports existing practices of XP. [ABSTRACT FROM AUTHOR]

Software engineering is fundamentally driven by economics. One of the issues that software teams face is employee turnover which has a serious economic impact. The effect of job dissatisfaction on high turnover is consistently supported by evidence from multiple disciplines. The study investigates if and how job satisfaction relates to development processes that are being used and the determinants of job satisfaction across a wide range of teams, regions and employees. A moderate positive correlation between the level of experience with agile methods and the overall job satisfaction was found. The evidence suggests that there are twice as many members of agile teams who are satisfied with their jobs (vs members of non-agile teams). The ability to influence decisions that affect you, the opportunity to work on interesting projects, and the relationships with users were found to be statisticcally significant satisfiers. [ABSTRACT FROM AUTHOR]

This paperThe described work is part of the EUREKA-ITEA AGILE project, and partly funded by the Flemish government institution IWT (Institute for the Promotion of Innovation by Science and Technology in Flanders). takes a look at how XP and other agile practices can improve a software process for the development of avionics software. Developers of mission critical airborne software are heavily constrained by the RTCA DO-178B regulations [8]. These regulations impose strict rules regarding traceability and documentation that make it extremely hard to employ an iterative software development process. In particular, the extra validation overhead increases the time spent on small iteration cycles (for example, a bug-fix) to several weeks. Currently, this sector is also pressed to switch to a more agile, customer driven approach. In this paper we investigate how to speed up development and cope with changing requirements using agile techniques. The research was carried out in cooperation with Barco, a major Belgian avionics equipment supplier. We explain why certain agile techniques have less effect as the project progresses. We point out the stadia in which each XP practice is beneficial and where XP practices might cause a slowdown. [ABSTRACT FROM AUTHOR]

The DICEDICE is a registered trademark of The Boston Consulting Group, Inc. framework provides means for predicting the outcome of change management initiatives. The four factors: duration, integrity, commitment, and effort are evaluated and a score is calculated. The DICE® score is used to classify projects into win, worry, or woe zones. In this paper, we apply the DICE® framework to predict the outcome of a software project that is migrating from waterfall to agile practices. We propose fine-tuning of the four factors to improve the score and show how to use DICE® for communication with the stakeholders. Finally, we make a claim that evaluation against the DICE® framework confirms that agile projects have a higher chance of success than traditional waterfall projects. [ABSTRACT FROM AUTHOR]

The traditional versus agile project debate is most often represented in terms of polar positions of the life cycle - the process is either traditional or agile, waterfall or highly iterative. This may be effective in intellectual discussions, but it is highly unlikely to be useful to practitioners, especially those practitioners that are facing traditional project pressures and trying to find the "home ground" for their situation that will increase the likelihood that they will succeed. In this paper, we discuss extensions to Boehm and Turner's five dimensions for determining a project's "home ground" - that is, the process configuration that might best fit the situation at hand. We have added dimensions to the basic framework provided by Boehm and Turner and have considered the process configuration question as a process itself and increased its scope to include both management and engineering key practice areas. [ABSTRACT FROM AUTHOR]

Usage of test-driven development (TDD) is said to lead to better testable programs. However, no study answers either the question how this better testability can be measured nor whether the feature of better testability exists. To answer both questions we present the concept of the controllability of assignments. We studied this metric on various TDD and conventional projects. Assignment controllability seems to support the rules of thumb for testable code, e.g. small classes with low coupling are better testable than large classes with high coupling. And as opposed to the Chidamber and Kemerer metric suite for object-oriented design, controllability of assignments seems to be an indicator whether a project was developed with TDD or not. [ABSTRACT FROM AUTHOR]

This paper analyzes the development of a project initiated by a co-located agile team that subsequently evolved into a distributed context. The project, named JAPS (Java Agile Portal System) [1], has been monitored on a regular basis since it started in January 2005, collecting both process and product metrics. Product metrics have been calculated by checking out the source code history from the CVS repository. By analyzing the evolution of these metrics, it has been possible to evaluate how the distribution of the team has impacted the source code quality. [ABSTRACT FROM AUTHOR]

The variety of code smells deserves a numerous set of detectors capable of sensing them. There exist several sources of data that may be examined: code metrics, existence of particular elements in an abstract syntax tree, specific code behavior or subsequent changes in the code. Another factor that can be used for this purpose is the knowledge of other, already detected or rejected smells. In the paper we define and analyze different relations that exist among smells and provide tips how they could be exploited to alleviate detection of other smells. Keywords: Refactoring, bad code smells, inter-smell relations. [ABSTRACT FROM AUTHOR]

This paper is inspired by an article by Müller and Padberg who study the feelgood factor and programming experience, as candidate drivers for the pair programming performance. We not only reveal a possible threat to validity of empirical results presented by Müller and Padberg but also perform an independent research. Our objective is to provide empirical evidence whether external code quality is correlated with the feelgood factor, or with programming experience. Our empirical study is based on a controlled experiment with MSc students. It appeared that the external code quality is correlated with the feelgood factor, and programming experience, in the case of pairs using a classic (test-last) testing approach. The generalization of the results is limited due to the fact that MSc students participated in the study. The research revealed that both the feelgood factor and programming experience may be the external code quality drivers. [ABSTRACT FROM AUTHOR]

This paper considers the nature of pair programming. It focuses on using pair programmers' verbalizations as an indicator of collaboration. A review of the literature considers the benefits and costs of co-operative and collaborative verbalization. We then report on a set of four one-week studies of commercial pair programmers. From recordings of their conversations we analyze which generic sub-tasks were discussed and use the contribution of new information as a means of discerning the extent to which each pair collaborated. We also consider whether a particular role is more likely to contribute to a particular sub-task. We conclude that pair programming is highly collaborative in nature, however the level of collaboration varies according to task. We also find that tasks do not seem aligned to particular roles, rather the driver tends to contribute slightly more across almost all tasks. [ABSTRACT FROM AUTHOR]

This paper presents two controlled experiments (a pilot and the main one) investigating the impact of developer personalities and temperaments on communication, collaboration-pair viability and ultimately effectiveness in pair programming. The objective of the experiments was to compare pairs of mixed/ heterogeneous developer personalities and temperaments with pairs of the same personalities and temperaments, in terms of pair effectiveness. Pair effectiveness is expressed in terms of pair performance, measured by communication, velocity, productivity and customer satisfaction, and pair collaboration-viability measured by developers' satisfaction, knowledge acquisition and participation (collaboration satisfaction ratio, nuisance ratio, voluntary or mandatory preference, and driver or navigator preference). The results have shown that there is significant difference between the two groups, indicating better communication and collaboration-viability for the pairs with mixed personalities/temperaments. [ABSTRACT FROM AUTHOR]

There are few studies of how software developers make decisions in software design and none that places agile in the context of these decision making processes. In this paper, we present results of interviewing agile software developers and mentors to determine how design decision making aligns with rational decision making or naturalistic decision making. We present results of twelve case studies evaluating how agile professionals make design decisions, comparing mentor perspectives to developer perspectives. We describe our interview technique, content analysis used to analyze interview transcripts, and the interpretation of our results, to answer the question: how do agile designers make design decisions? Our results show that naturalistic decision making dominates design decision making but is supported by rational decision making. [ABSTRACT FROM AUTHOR]

Distributed cognition is a framework for analysing collaborative work. It focuses on interactions between people, between people and their environment and between people and artefacts that are created and manipulated in the course of doing work, and it emphasises information flow and information transformation. Analyses conducted using the distributed cognition framework highlight breakdowns and potential problem areas in the collaborative work being studied; distributed cognition has been used to study a wide variety of collaborative work situations. XP teams are highly collaborative, relying heavily on interactions between team members and their environment. In this paper we present accounts of four mature XP teams based on the distributed cognition framework. [ABSTRACT FROM AUTHOR]

Along with growing popularity of agile methodologies and open source movement, unit testing has become one of the core practices in modern software engineering. It is particularly important in eXtreme Programming [1], which explicitly diminish the importance of other artifacts than source code and tests cases. In XP unit test cases not only verify if software meets functional requirements, but also enable refactoring, alleviate comprehension and provide guidance on how the production code should be used. Therefore, they contribute to many other important practices of XP, which explicitly or implicitly rely on their ability to effectively discover bugs. [ABSTRACT FROM AUTHOR]

In far too many software projects the value of the documentation delivered is not high enough to motivate the effort spent to write it. An outdated document can be as misleading as a good, up to date one can be helpful. This demonstration will show how unit tests complemented with descriptive comments can be used to generate documentation that is constantly up to date. It is demonstrated by example how both the static and dynamic features of a software system can be salvaged with very little effort to be presented to a bigger audience as relevant, readable documentation. [ABSTRACT FROM AUTHOR]

In order to popularize the Test Driven Development (TDD) practice in Chinese offshore companies, an experimental research was firstly conducted to compare TDD with the traditional waterfall development in a small-scale project. Although the project scale was small and all the subjects were students, this experiment was designed very strictly to guarantee the reliable evaluation of the efficacy of TDD. Furthermore, it is also the first time to evaluate the maintainability and the flexibility of TDD by experiment. [ABSTRACT FROM AUTHOR]

Over the past years, a great number of organizations have started utilizing agile principles and practices in their software development [1, 2]. Despite of the promising experience reports, the deployment of agile practices is a challenging task which requires adjustment and dedication from all the stakeholders involved in the development process [3, 4]. In order to fit the agile practices into organization's software development context, agile specific guidelines and methods to support their selection, deployment and tailoring are needed [5]. However, the existing software process improvement (SPI) approaches have originally been targeted for the context of the traditional software development thus lacking some central aspects such as iterative process adaptation [5] and procedures for suitable organizational learning [6]. Agile Assessment and Post-Iteration Workshops (PIWs) are technologies that can be used in the deployment of agile software development methods. [ABSTRACT FROM AUTHOR]

It is widely accepted that the absence of a structured approach to spreadsheet engineering is a key factor in the high level of spreadsheet errors. In this paper we propose and investigate the application of Test-Driven Development to the creation of spreadsheets. Through a pair of case studies we demonstrate that Test-Driven Development can be applied to the development of spreadsheets. A supporting tool under development by the authors is also documented along with proposed research to determine the effectiveness of the methodology and the associated tool. [ABSTRACT FROM AUTHOR]

Despite the existence of 75 "different" xUNIT frameworks, their domain of application differs only in the programming language, compiler or operating system supported. If one is working in the embedded world, unit testing is still needed, but now our "testing requirements" differ significantly from the testing framework needed for the desktop world. Embedded systems often have significant non-functional requirements, which demand validation at the unit level. In addition, they interact intimately with hardware resources and often have only very limited input/output capabilities - imagine a xUNIT framework where printing to the screen is a technical challenge! [ABSTRACT FROM AUTHOR]

Software product lines are sets of software systems that share common features. Product lines are built as if they were a family of products, identifying those features that change and those that can be reused. There is an evident incompatibility between the requirements of software product lines and agile practices. We report on experiments that used Feature-Driven Development to build software product lines, and describe the minor extensions that were useful for developing software product lines. [ABSTRACT FROM AUTHOR]

Johanna Hunt is a first year DPhil researcher and Associate Tutor at the University of Sussex, and a Research Assistant in Algorithms at the University of Hertfordshire. Her research is concerned with investigating the community of Agile Systems practitioners. She is particularly looking at notions of identity, boundary, communication and space as demonstrable in conversational storytelling and personal narratives from this practitioner-group. [ABSTRACT FROM AUTHOR]