Using an ethnographic process to conduct requirements analysis for agile systems development

Scrum is an agile software development methodology that suggests highly structured and iterative processes of software development by small autonomous teams (Schwaber & Sutherland, 2011). It is hypothesized that Scrum can be implemented in a way that supports and potentially improves Development Team members’ self-control. High self-control yields positive effects in countless life domains (Tangney, Baumeister, & Boone, 2004). One correlative study with 23 Development Teams and a total of 171 team members from an international software company investigated relevant conditions of Scrum to support and improve the self-control of Development Team members. Findings indicate a potential self-control improvement by the creation of a moderate concrete plan, the Sprint Backlog, at the beginning of a development cycle (Sprint), and performing an active team internal progress monitoring during the Sprint in short daily meetings (Daily Scrum Meetings). Planning and monitoring correlated simultaneously with high trait self-control and with low state self-control, indicating a possible self- control improvement through Scrum. Frequent team internal discussions targeting process improvements in Sprint Retrospective Meetings were related to high state self-control. In addition to correlations found with team members’ self-control, high team performance correlated with finishing committed Sprint Backlog Items by the end of the Sprints and reviewing these in the Sprint Review Meetings. Development Team members’ good health and low stress correlated with high team members’ self- control. High team autonomy was an essential requirement of the potential self-control improvement process. Moreover, high team autonomy correlated positively with high team performance and low experienced stress of Development Team members. Adding to these results, one laboratory experiment found indications that Sprint Backlog Item specificity may affect self-control during the processing of that item, suggesting a preference for moderate as opposed to low or highly specific Sprint Backlog Items. A second laboratory experiment failed to reproduce and extend this finding, probably because of the plan specificity operationalization. Overall, theoretical considerations and empirical indications are presented that Scrum could be implemented in a way that supports and potentially improves Development Team members’ self-control and health, reduces Development Team members’ experienced stress, and improves performance of the Development Team.

Information system development projects engage organizational members in a process with potential for conflict. Managing such conflicts in project groups is an important but often neglected aspect of systems development. This research assesses group process during the development of an information system in an insurance company, using questionnaires, recorded transcripts of group meetings, interviews, and archival data. We describe the relationships among four variables in a model of conflict—participation, influence, conflict, and conflict resolution—at five different periods over a 22-month period. Our results show that in every time period participation positively affected influence and that influence positively affected both conflict and conflict resolution. These findings are supported by an analysis of communication patterns within four project meetings and by qualitative data collected during the project. The practical implications of conflict and group processes in system development are discussed.

The Internet economy has altered the rules of software engineering. Traditional development methodologies are too cumbersome to meet the rapidly changing requirements and short product cycles demanded by business. To meet these changing requirements, software developers have developed agile software development methodologies (SDMs) utilizing iterative development, prototyping, and templates. This research project investigated agile SDM implementation using an online survey sent to practitioners worldwide. This survey data were used to identify factors related to agile SDM implementation. Factors that included training, management involvement, access to external resources, and corporate size were found to impact implementation of an agile software development methodology. Factors such as using models, having an implementation plan, collocating the development team, and developing software for Internet or intranet use did not impact the implementation of an agile software development methodology. Several of the factors that impact the implementation of an agile development methodology are under the control of management. Organizations considering the implementation of an agile methodology may wish to manipulate some of these factors to increase the opportunities for success of their methodology.

Agile practices have recently gained popularity among large number of companies as a mechanism for reducing cost and increasing ability to handle change in dynamic market conditions. Based on the principles of the Agile manifesto [1, 2], researchers and practitioners have proposed several software development approaches such as Extreme Programming, Scrum and Feature-Driven Development. These and other agile approaches have had significant impact on industrial software development practices. However, there is also a significant concern and perplexity about the role and importance of the issues related to a system’s software architecture, which is considered one of the most important initial design artefacts. It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. Many practitioners of Agile approaches appear to view software architecture in the context of the plan-driven development paradigm [3]. For them, upfront design and evaluation of software architecture requires too much work, which may have very little value to the customers of a system. Hence, they perceive architectural work as part of high ceremony processes, which usually require large amount of documentation. We maintain that these two seemingly opposing views to software engineering can be integrated but it requires that experts from both fields work together to overcome evident challenges in bridging these two paradigms together. Indeed, software architecture researchers and practitioners appear to believe that sound architectural practices cannot be followed using Agile approaches. However, these two extreme views of Agile and architecture appear to neglect that many agile experts emphasises the importance of paying attention to good design and architecture early in the development process [4, 5]. Recently, there is growing recognition of the importance of paying more attention to architectural aspects in agile approaches [3, 6, 7]. We argue that there is a vital need for devising a research agenda for identifying and dealing with architecture-centric challenges in agile software development. Such research agenda should make it possible to guide the future research on integrating architecture-centric methods in agile approaches and give advice to the software industry on dealing with architecture related challenges. Some of the questions to stimulate discussion in the workshop are: What is the role of software architecture in Agile software development? What are the key architecture-centric challenges and potential solutions in Agile software development projects? What is the strength of the evidence that attention to architectural issues can be counterproductive in Agile development or vice versa? What are the prerequisites for integrating Architecture-Centric methods in agile development and potential implications of such integration?

Organizations of all sorts adopt agile software development, but they rarely implement it “by the book.” Instead, agile practices evolve after initial adoption and often drift in different directions as organizations translate agile into their institutional environments. We studied the implementation of agile development in four organizations from much different institutional contexts: a startup technology company, a consulting firm, a government organization, and an industrial manufacturer. We found two core dimensions of their institutional contexts that shape agile translation: dynamism and pluralism. Dynamism refers to how fast requirements and environments change, and pluralism refers to how many diverse stakeholders are involved. These two dimensions influence the direction of agile translation. We show that agile practices evolve through a “ratcheting” process, whereby a sequence of incremental, interdependent changes gradually move teams closer to or further away from canonical agile practices. High pluralism in the institutional context, for example, tends to increase documentation, whereas low dynamism appears to slow iteration cycles. Agile software development is no longer limited to startups or software teams; it is adapted by all sorts of organizations as a way to flexibly innovate. Understanding why agile evolves differently across contexts helps managers move beyond one-size-fits-all prescriptions and set realistic expectations for agile development in their organizations.

With increasing competition in the software market, software companies are using new management strategies to increase their competitiveness. In recent years, with the prevalence of agile methodologies in software development, paying attention to human resources, and selecting and managing talented human resources have become inevitable. This should be achieved by adopting appropriate talent management processes. However, in software engineering, talent management has not yet been seriously considered. Due to the critical role of agile methodologies in human resources, and the authority and freedom of individuals in agile teams, the benefit of talent management in these methodologies is vital. As a starting point, this article tries to provide a concise overview of talent management in agile software development and address the ambiguities and research gaps facing software researchers in this regard. The initial results of this study show that several ambiguities such as appropriate models of talent management applicable in agile methodologies, how to use them, effective factors in talent assessment, and the relationship between talent management and the quality of teamwork are some of the most noticeable research gaps in this area.

Today, the most vital step is software testing, especially in product quality. Agile software development is exceedingly difficult and has contentious issues in literature and business. Since most Agile techniques place more emphasis on development than software testing activities, different people have varying opinions about how software testing fits into these methodologies. Agile places a high emphasis on frequent deliveries and tight client connections. However, software testing is complex because agile does not incorporate many destructive testing techniques typically required for a product of higher-quality. The study reveals industry-wide Agile testing procedures and the main problems that arise when Agile development is used. Additionally covered are the differences between manual and automated testing, best automation practices, and ways to lead different testing teams in an agile testing environment. This study covers every facet of the Agile software testing process. Agile development has shown that testing is not a distinct stage but rather a crucial component of software development along with the coding. The agile team employs an overall strategy to produce software products of the highest quality. As part of an agile team, testers collect customer samples of the desired behaviour and collaborate with the developer's team to help the coders translate these examples into executable specifications. Coding and testing are done iteratively and incrementally, developing every item until it is valuable enough to release in production. It addresses several testing modalities. The classification provided by its quadrants aids teams in determining and organizing the necessary tests. To increase quality assurance, this article will examine various and improved Agile Testing Processes and methodologies. Additionally, the topic of Agile development's software testing method is covered. Agile development processes can be improved and more advantageous by incorporating testing procedures.

Engineering-based processes and agile methodologies for software development: a comparative case study

PurposeThe purpose of this study is to reflect upon the feasibility of agile methodologies, Scrum in particular, to supplement the procedural design and implementation of performance measurement systems (PMS).Design/methodology/approachThe study is an interventionist case study that applied agile methodologies in the PMS development. Researchers actively participated in the PMS development, e.g. researchers designed some of the performance measurement prototypes in order to facilitate the agile development.FindingsThe study outlines an agile approach suitable for PMS development. The paper answers the topical needs for adaptability and agility in management accounting, by applying agile methodologies into PMS development. PMS development does not take place only as a project or process that systematically progresses from the measure selection to measure implementation. Instead, as the requirements for the PMS change during the development project, management may reject some measures and new measures emerge as the understanding about changing situations increase. Agile methodologies are a methodological way to respond to the inevitable change and to enhance management accounting adaptability.Research limitations/implicationsThis study contributes to the PMS literature by proposing that agile development methodologies can advance organizational features that increase management accounting adaptability. As a result, the study proposes a new approach for PMS development to supplement existing ones. Agile methodologies are especially suitable for extending the PMS in new, yet relatively immature areas of performance measurement. The new approach applies Scrum principles in PMS development. By drawing from the theories of performance measurement (system) development and enabling PMS, the paper furthers academic understanding about agile development of accounting information systems.Practical implicationsCompanies can use the proposed approach in PMS development, particularly after the initial system implementation in redesigning the system. The approach may increase the PMS impact in organizations and prevent PMS implementation failures.Originality/valueThe paper identifies the potential of using agile methodologies to enhance PMS adaptability and provides preliminary evidence of the potential of such approach in supplementing processual PMS development frameworks.

agile information systems, flexible information systems development, distributed information systems development, global software development, software development, special issue

Bridging knowledge boundaries among project team members is essential to prevent delays or complete failure of software development projects. Prior researchers have reported that software prototypes can be used to help bridge knowledge boundaries between team members in traditional software development settings, yet their use in an agile development setting remains unexplored. Agile development centers the interactions between team members on emerging representations of the prototype whose properties are prone to change over time. Therefore, we conducted an in‐depth study of an agile development project to enhance our understanding on how software prototypes are used as boundary objects in a distributed team setting. Our analyses of team member interactions during 46 virtual meetings that took place over a period of 6 months revealed four different prototype use practices (exemplifying, contrasting, relating, framing) that were effective in bridging syntactic, semantic, or pragmatic knowledge boundaries. We also provide empirically grounded evidence of how variations in object properties can afford different use practices, how the use practices take advantage of these properties, and how object properties are reshaped through these use practices as different types of knowledge boundaries are bridged. These findings bear important implications for research on prototypes as boundary objects in software development in particular and boundary object use in general.

The paper deals with possibilities of information technologies when improving communicative skills of children with specific disorders, such as autistic spectrum disorders, Down syndrome, mental retardation, etc. The development of an application stemming from the communication system PECS (The Picture Exchange Communication System) and its Czech variant VOKS is the base of this paper to show specificity of the development and verification of software for the given group of handicapped users. The paper shows suitability of using agile methods of software development for a concrete application which is designed for users with specific disorders. It tries to show advantages and disadvantages of new methodologies, particularly Extreme Programming. Agile methodologies of software development appeared in the second half of the 90's of the last century. Thus it concerns new ways which have not been spread massively yet.

Software industries are progressively adopting the agile development practices of customized models such as Extreme Programming (XP) or Scrum or Rational Unified Process (RUP). Scrum and Extreme Programming (XP) are frequently used agile models, whereas Rational Unified Process (RUP) is one popular classic plan driven software development methodology. Both agile and plan driven models have their own merits & demerits such as XP has good engineering practices, team collaboration and on the other hand weak documentation, poor performance in medium & large scale projects. Scrum is based on project management practices. RUP model has some limitations such as impractical for small and fast paced projects, tendency to be over budgeted, condemn rapid changes in requirements. This research paper based on proposes hybrid framework eXSRUP by combining strengths of Scrum, XP and RUP by suppressing their limitations to produce high quality software.

Effort estimation is an important practice in agile software development. The agile community believes that developers’ estimates get more accurate over time due to the cumulative effect of learning from short and frequent feedback. However, there is no empirical evidence of an improvement in estimation accuracy over time, nor have prior studies examined effort estimation in different development activities, which are associated with substantial costs. This study fills the knowledge gap in the field of software estimation in agile software development by investigating estimations across time and different development activities based on data collected from a large agile project. This study investigated effort estimation in various development activities, including feature development, bug fixing, and refactoring in agile software development. The results indicate that estimation of agile development does not improve over time, as claimed in the literature. Our data also indicate that no difference exists in the magnitude of estimation errors between feature tasks and bug-fixing/refactoring tasks, while bug-fixing and refactoring tasks are overestimated more frequently than feature tasks. This study also contributes to our knowledge about overestimation and underestimation patterns in agile software development.

Discussions on agile software development methodologies have a tendency to develop into an argument between proponents of agile methods and proponents of more traditional process-oriented methodologies. The terminology used in these debates is often unhelpful, and in many cases are inaccurate and biased representations. It needs to be accepted that there are no “silver bullets” providing universal solutions (Jeffries, 2001). Bearing this in mind, the decision to adopt a particular software development methodology is a difficult one, and the decision to choose an agile method is no exception. In theory, as in practice, definitions and descriptions of the various agile methods are presented, yet the factors considered in the decision to adopt, or not adopt, an agile method are not addressed. While agile methodologies try to avoid the excessive use of procedures or tools (Beck & Fowler, 2001), one agile methodology, dynamic systems development method (DSDM), does recommend the use of appropriate tools during the development process (Coesmans, 2003). However, it appears that none of the available agile methodologies suggest a tool to assist decision makers at the project initiation phase, therefore, the debate on agile suitability is usually a debate on agile versus traditional methods (DeMarco & Boehm, 2002), rather than an examination of the suitability of agile methods for a particular project. While the “agile debate” rages, individual projects are not adequately assessed prior to the adoption of a method.