No full-text available
To read the full-text of this research,
you can request a copy directly from the author.
XP Practices: A Successful Tool for Increasing and Transferring Practical Knowledge in Short-Life Software Development Projects
Abstract
The Gemplus and Axalto’s horizontal merge in 2006, brought several challenges, resulting in a period of general instability
in the newly created company. As a result, the Gemplus Personalization Team for Latin America put in place five of the twelve
Extreme Programming Practices as a tool for incrementing and transferring knowledge between the two companies and among the
existing/new members of the team.
In addition to a successful knowledge transfer, results from this newly adopted approach, showed several benefits: collective
code ownership, development autonomy, cleaner/more readable code, and an increment in development productivity, proving that
in addition to being useful for practical knowledge transfer, XP Practices are a successful ’tool kit’ to improve the software
development process performance in short-life projects.
... This is particularly the case for agile software development [15], [16], [17]. Few studies report on practical knowledge of agile approaches being transferred, e.g., [18] . It is clear that while knowledge transfer is desirable in agile software development it also meets barriers -some which are easily overcome and some which are inherently difficult [13], [19], [20]. ...
... A lack of network ties can result in ignorance on both ends of the transfer. Differences, such as age, gender, educational levels and ethnic background between the participants can hinder the knowledge transfer process, as power issues and problems understanding each other may occur [18], [23]. The skills and emotions of the individual play an important role. ...
... The case study by [18] is interesting because it is based on a framework of knowledge transfer and it specifically addresses how this led to several benefits. The case study is brief, but it does convey experiences with forming deliberate knowledge transfer through moving experiences developers between teams. ...
Agile practices to systems development are believed to depend largely on the developers’ competences, experience and knowledge and to a lesser degree on formal development processes and methods. In this paper we investigate the knowledge transfer and barriers to the transfer of agile development practices in an interpretive case study. The case company is a pharmaceutical firm where we studied how they develop software and how they transfer their own experience. Based on the literature we develop an initial framework of barriers to knowledge transfer and apply it to interpret the case study. From this case study we are able to discuss the initial framework and extend it to a framework of knowledge transfer of agile practices. The framework provides a better understanding of the barriers to knowledge transfer of agile practices. The paper contributes with (1) an application of the framework to explain knowledge transfer and barriers, and (2) specifically explicate potential barriers hindering knowledge transfer of agile practices. This has implications for the implementation of agile development practices.
... Little focus has, so far, been on knowledge transfer of agile practices between teams. An exception to this shows how knowledge of practices related to the agile method, Extreme Programming (XP) was transferred between departments in a large software company (Tellez-Morales, 2009). It is clear that while knowledge transfer is desirable between agile teams, it also encounters barriers. ...
Agile software practices are widely used in a great variety of organizations, and the shift from traditional plan-driven approaches entails a redefinition of processes in these organizations. Intrafirm knowledge transfer of agile software practices between projects is a key concern in this redefinition. While knowledge transfer is essential for an organization to develop or keep its competitive advantage, it is also both difficult and time consuming, due to a wide range of barriers. Transferring knowledge on agile practices is even more complex due to there being a high degree of tacit knowledge. Research on knowledge of agile practices focuses on adoption of agile practices within a single team, thus extant research lacks focus on intrafirm transfer. Through a case study, this article investigates the intrafirm knowledge transfer of agile practices. With a starting point as the theory of barriers to knowledge transfer, we modify and extend the framework to transferring knowledge of agile practices. This framework is subsequently applied for interpreting and analyzing the case study data. The analysis shows how these barriers (e.g., the organizational culture, time and resources, knowledge strategy, and motivation and willingness) are related and that they cannot be understood in isolation. The barriers and their relations are brought together in a conceptual model and its relevance is discussed.
This paper analyses and evaluates the knowledge creation and sharing experiences of teams in the Agile software development domain. Over a series of three empirical phases a method is developed to evaluate the advantages and limitations of Agile practices in knowledge creation and sharing for Agile teams. In the first phase, initial issues and characteristics concerning agile methodologies were collected with a scoping review of the period since the manifesto for Agile software development emerged. The second phase represents a hermeneutic analysis of the result set obtained in the first phase. Using a SWOT analysis, the third phase assesses Agile processes, their relationships with knowledge transfer management and their effects on the productivity of software development teams. This research offers some key insights for decision makers considering the adoption of Agile methodologies in software development activities.
Job satisfaction has been studied by economists and psychologists. We believe this factor is very important in that it influences
the effectiveness of the software development process. This paper reports the first results of a comparative analytic study
on the job satisfaction of developers that use XP practices and others that do not use XP practices. By determining the factors
that are highly valued by developers, the research can provide insight in currently practised software development processes,
and help make changes that increase their strategic value.
This paper discusses the adoption level of and experiences from using agile practices in three software development projects in a large Telecom company. The use of agile practices was more emergent than planned. Project managers and developers simply used practices they considered efficient and natural. The most widely adopted agile practices were to measure progress by working code, to have developers estimate task efforts, to use coding standards, having no continuous overtime, to have the team develop its own processes, to use limited documentation, and to have the team in one physical location. The projects used conventional testing approaches. Adoption of agile testing practices, i.e., test first and automated unit tests, was low. Some agile practices can just emerge without conscious adoption, because developers find them useful. However, it seems that an emergent process aiming for agility may also neglect important agile practices.
Commercial pressures to produce faster and more dependable software prompt management initiatives to improve software practices.
Technical solutions such as CASE tools, 4GLs, Interactive Development Environments and more recent modeling notations and
tools have made some contribution. This article concentrates on the introduction of new development methodologies that are
shown to have a positive on software development practices.
A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time
Abstract All I Really Need to Know I Learned in Kindergarten By Robert Fulghum (Fulghum 1988) Share everything. Play fair. Don’t hit people. Put things back where you found them. Clean up your own mess. Don’t take things that aren’t yours. Say you’re sorry when,you hurt somebody. Wash your hands before you eat. Flush. Warm cookies and cold milk are good for you. Live a balanced life – learn some,and think some,and draw and paint and sing and
In this article, the author shares how ThoughtWorks introduced XP into an organization and successfully completed a bleeding
edge technology project with client staff that had no previous experience using an Agile development approach. This article
illustrates not only how XP helped make the project a success, but provides other valuable lessons learned regarding the introduction
of XP at client sites.
Many of the twelve carefully defined practices of Extreme Programming are tightly coupled. The various practices have checks
and balances on each other and are, in many ways, dependant on each other. Therefore, neglecting essential practices can have
sub-optimal or negative consequences to team results. The practices that are actually utilized in team development can often
be attributed to the perceptions of the value and difficulty of the practices by the developers on the team. Through two surveys
answered by 27 developers, we have assessed the utilization of and the sentiments towards the XP practices. In general, these
developers we surveyed valued and utilized most of the practices.
It is generally prescribed that XP be adopted in full. However, a review of existing XP adoption case studies suggests that
full adoption is exceptional; most companies adopt XP only partially and they adapt XP to fit existing practices and philosophies.
Drawing on interviews with industry participants, the paper recommends using XP as a ‘tool kit’ of techniques and philosophies.
What is special about XP teams? Adopting XP involves social change as well as technical change, but what characterises a successful team? What happens when a team takes on the 12 practices and four underlying values? This paper contributes empirical findings that help answer such questions. We expand on previous work that suggested four characteristics of an XP team by analysing the data from both the previous study and from a further study of another mature XP team. While there are clear differences between the two teams in terms of operating environment, their detailed implementation of the 12 practices and the team's overall character, we find that the four characteristics are present in both teams. The paper describes the characteristics in detail and discusses how those characteristics are embedded in the detail of the practices of XP as observed in the two particular settings.