Jump to content

Distributed agile software development

Add links
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Amkgp (talk | contribs) at 10:28, 13 May 2020. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines

Distributed Agile Software Development is a research area that considers the effects of applying the principles of Agile software development to software development in a globally distributed development setting. The goal of applying these principles is overcoming challenges in projects which are geographically distributed.

While the principles of Agile software development already provide structures to promote better communication, not having face-to-face interaction takes away one of the core principles of Agile. This makes Distributed Agile Software Development more challenging than Agile Software Development in general.


History / Research

The increasing globalization with the aid of novel capabilities provided by the technological efficacy of the Internet has led software development companies to offshore their development efforts to more economically attractive areas. This phenomenon began in the 90s, while its strategic importance was realized in the 2000s [1]. Most initial related studies also date from around this time [2].


During this time, the Agile manifesto was released [3], which represents a departure from the traditional waterfall approach to software development. This naturally led to the question, "can distributed software development be Agile?". One of the first comprehensive reviews trying to answer this question was done in 2006 [4]. Later, in 2014, a systematic literature review (SLR) was done to identify the main problems in getting Agile to work in a distributed fashion [5]. In 2019, a similar SLR was done [6]. Moreover, a general review on the subject was done in [7].

In all, Agile distributed software development remains a highly dynamic field. Research continues to be done on all of its facets, indicating that it offers unique opportunities and advantages over more traditional methods, but not without imposing its own challenges and risks.


Challenges & Risks

Distributed software development has its own inherent challenges due to spatial, temporal, and socio-cultural differences between distributed teams. Combining it with the Agile method, in turn, increases the severity of the risks involved, as both methods are in direct contrast with each other. Agile was originally intended to be used by co-located teams, as it is based on informal communication and close collaboration. Distributed development, however, requires formal communication, clear standards, set guidelines and rigid structure. [8] This section describes the risks and challenges involved in Agile distributed software engineering as a result of the aforementioned compatibility issues.

Challenges

Inherently Agile has a large emphasis on face to face communication as is reflected in principle number six of the agile software development manifesto. This is however not possible when working in a distributed environment. Because of this conflict, some of the challenges which can arise are as follows [9]:

Documentation

Offshore organizations favor plan-driven design where detailed requirements are sent offshore to be constructed.[10] This conflicts with the common practice of agile teams who give documentation a lower priority. The result of this situation is that misunderstandings are a lot more likely to arise.

Pair programming

Where two programmers work side by side to work on a particular problem is common in Agile. It has been shown to yield better products in less time while keeping the programmers content in the process [11]. Because of the distance between teams this is a lot harder to achieve. It is, therefore, a challenge that exists in distributed agile software development.

Different time zones

Depending on the time zone of each distributed team it makes it more challenging to arrange meetings at times when both teams are available. The situation can easily arise in which one team member is available and the other is not for meetings. This especially is a problem if an immediate task has components of the program which are tightly coupled, in such a case one team would not be able to proceed without the feedback of the other.

Teaching

In a distributed setting the downside of not being able to practice close communication is most felt with inexperienced developers who need to go through a training phase. Training employees who are not co-located is challenging, think of the differences in background and cultural differences which make it difficult to bring these inexperienced team members up to speed. Because of this, alternative ways of teaching need to be considered.

Distribution of work

From all the aforementioned challenges this is the most important one. We want to avoid the architecture to reflect the team’s geographical distribution by distributing the work based on the location. Because of this, it is better to distribute tasks relating to a single user story across the whole team, thinking in terms of the stories, not the components [12].

Risks

A study done in 2013 has tried to consolidate the literature on risk management in distributed Agile development [8]. A more comprehensive study has tried to categorize the risk factors for distributed agile projects in [13], this was done utilizing both research literature and real-world experience from thirteen IT organizations. For the sake of brevity, the full list of forty-five risk factors, with corresponding management techniques is omitted. Instead, a brief summary of the main categories and overall management techniques is given.


Software Development Life Cycle

This category comprises the risk factors related to various activities of software development like customer specification of requirements and planning, modeling, construction and deployment of software application [14]. Many of the risk factors in this category stem from ineffective knowledge sharing. Unclear objectives, requirements, differences in practices of standard processes or inconsistencies across designs to name a few. Many of these risks can be managed by making sure that knowledge is shared effectively. More specifically, make sure that the objective of the project is crystal clear across teams, as well as the requirements. Automate and standardize as much of the development cycle as possible, so that each team is working with the same technology stack and infrastructure. In short, ensure that everyone is on the same page.

Project Management

Project management relates to tasks such as project planning, project organizing, project staffing, project directing and control. This category involves risks due to interactions between development activities, and managerial activities. The adoption of distributed Agile development will transform the way in which the project needs to be managed. If this is not done carefully, risks might include a lower initial velocity, teams reorganizing every sprint or, a lack of uniformity in multisite team's capabilities.

Group Awareness

Risk factors related to a lack of group awareness are grouped in this category. Group awareness requires intensive communication, coordination, collaboration, and trust among the group members. Co-located teams achieve this awareness more easily, as it flows more naturally from being in the same physical location. To manage the risks involved with a lack of group awareness, spatially dispersed teams will have to use a more disciplined approach in communication using the latest technological tools. Practices such as co-locating initially, to set the track for the project, have proved to be effective in managing risk.

External Stakeholder Collaboration

These factors relate to the collaboration with customers, vendors, and third-party developers. Managing its risks boils down to making sure that the coordination and communication with these external actors are done efficiently and clearly.

Technology Setup

Risk factors that arise due to inappropriate tool usage are grouped in this category. For example, a lack of communication structure can be solved by providing the teams with the means to do video conference calls. Besides that, choosing the right tools to use during a project is important. This can vary across projects, teams and use cases, so an analysis beforehand on the tools to use is recommended.

Opportunities

Global Software Development (or Distribution of Development) appears to cause diminished perceivability of the agile process or status of project dependent on short ceaseless iterations. These iterations make it simpler to visualize the issues or criticalities on the initial stages of the project. Continuous integration of programming code, which is one of the focal pieces of agile methodology, additionally serves to reduce setup of the executive issues. Utilization of agile principles appears to positively affect correspondence between groups as advancement in cycles makes it simpler for members to see the short-term objectives. Sprint reviews can be seen as a powerful method to improve external correspondence whilst they help to share data about the features and prerequisite conditions between partners or stakeholders. Agile practices also assist in building trust between various teams associated with the process by stimulating consistent communication and conveyance of programming deliverables. As indicated by an investigation made by Passivara, Durasiewicz and, Lassenius, the software quality and correspondence are improved and communication and coordinated effort are more regular comparatively as a result of the Scrum approach utilized in the undertaking. Additionally, the inspiration of colleagues was accounted for to have expanded [15]. Along these lines, enforcing agile in a distributed environment has demonstrated to be valuable for the quality of the project and its execution. Thus, these can be seen as some of the advantages achieved by combining agile in Distributed Development [16], however, the list is exhaustive. The main benefits can be listed as follows [17]:

  1. Enhanced inter and intra cultural diversity
  2. Flexible working plans that encourage an expanded duty to the organization.
  3. Teams can traverse time-zones, in this manner access as long as 24-hour limit.
  4. Can incorporate individuals with incapacities and mobility limitations.
  5. Increased levels of prosperity.
  6. Reduces travel costs as it opens up the platform to communicate via video conferencing and other feasible options
  7. Increased input because of the iterative idea of Agile.
  8. Increases the ranges of abilities of groups by getting to a more extensive pool of worldwide HR.
  9. Reduces office space and different related work things.

Iterative improvement with continuous delivery to the client is a central practice in agile software improvement, and one that legitimately identifies one of the significant difficulties of an offshore turn of events: diminished perceivability into project status. Regular physical meetings allow team leaders, project managers, clients, and customers to keep track of the progress of the project by the measure of working programming they have obtained.

Tools and best practices

Communication

One of the most important factors in overcoming the challenges faced with distributed agile software development is to improve communication [9]. This means minimizing the time it takes to set up and tear down a communication session and favor video conferencing over voice conferencing if it is available.

Face-to-face contact opportunities with the whole team should be encouraged in order to help build rapport. It is beneficial to do this at the start to set out a plan to which the team can adhere throughout the project. In addition, it is also beneficial in the last few iterations before the release of the final deliverable [12].

Time-zone differences

One option with regards to dealing with the problem of availability for meetings due to time zones is to appoint a representative for the team which serves as an intermediary for the two teams having formed good rapport with both. Another option is to use nested scrum with multilevel reporting and multiple daily scrum meetings [18].

A solution for having scrum meetings in teams which cope with time-zone differences is making a distinction between local team meetings and global scrum meetings [19]. Each team has a local meeting at the start of their day and a global meeting at another time of the day. This is only possible if their working days have overlapping time.

Keeping up with Agile practices

Due to the distributed nature, a team might veer off of solid established practices of Agile. Therefore there should be someone with the role of the coach that keeps the team on track. They should also take it upon themselves to think of alternatives for the distributed work environment using agile.

To keep every team member informed about the agile process, it is important to maintain documentation for the project. This improves the group collaboration in using agile in a DSD setting [18] [20] [21] [22]. For this, various tools can be used which support the team in maintaining the documentation [20].

Use of tools

Various tools and platforms can be used to improve communication in a distributed setting. These are even more essential than in a non-distributed setting in order to minimize the virtual distance between the distributed teams.

Communication

There are various tools available to support Communication in Distributed Software Development. Asynchronous tools like e-mail, synchronous tools like audio and video conferencing software and hybrid tools like instant messaging provide team members with the means to have the necessary meetings and communications. Another example is tools that support social networking to create a shared experience between team members across locations.

Project management

To guide the project and make sure that all teams and team members have a clear vision of what work has to be done, project management platforms like issue management tools should be used.

Development tools

To provide a shared experience for every team member, every team member should have access to the same tools for their development [23]. Having the same software configuration management tools linked to project management tools enables developers to work at the same pace and communicate about the development in a similar way.

Knowledge management

To give every team member access to the same knowledge about the product and the development, tools like wiki software or knowledge bases can be used.

Submission for review

References

  1. ^ Jiménez, M., Piattini, M., & Vizcaíno, A. (2009). Challenges and improvements in distributed software development: A systematic review. *Advances in Software Engineering*, *2009*.
  2. ^ Prikladnicki, R., Damian, D., & Audy, J. L. N. (2008, June). Patterns of evolution in the practice of distributed software development: quantitative results from a systematic review. In *12th International Conference on Evaluation and Assessment in Software Engineering (EASE) 12* (pp. 1-10)
  3. ^ Fowler, M., & Highsmith, J. (2001). The agile manifesto. Software Development, 9(8), 28-35.
  4. ^ Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile?. Communications of the ACM, 49(10), 41-46.
  5. ^ Razavi, A. M., & Ahmad, R. (2014, September). Agile development in large and distributed environments: A systematic literature review on organizational, managerial and cultural aspects. In 2014 8th. Malaysian Software Engineering Conference (MySEC) (pp. 216-221). IEEE.
  6. ^ Ghani, I., Lim, A., Hasnain, M., Ghani, I., & Babar, M. I. (2019). Challenges in Distributed Agile Software Development Environment: A Systematic Literature Review. KSII Transactions on Internet & Information Systems, 13(9).
  7. ^ [6] Shrivastava, S. V. (2010). Distributed agile software development: A review. *arXiv preprint arXiv:1006.1955*.
  8. ^ a b Shrivastava, S.V. and Rathod, U., 2014. Risks in distributed agile development: A review. Procedia-Social and Behavioral Sciences, 133, pp.417-424.
  9. ^ a b Shrivastava, S.V., 2010. Distributed agile software development: A review. arXiv preprint arXiv:1006.1955.
  10. ^ M. Fowler, ” Using an Agile Software Process with Offshore development”, http://martinfowler.com/articles/agileOffshore.html, July 2006 (Retrieved on May 11, 2020)
  11. ^ Williams, L., Kessler, R.R., Cunningham, W. and Jeffries, R., 2000. Strengthening the case for pair programming. IEEE software, 17(4), pp.19-25
  12. ^ a b Ade Miller,” Distributed Agile Development at Microsoft patterns and practices”, Microsoft patterns and practices, http://www.pnpguidance.net/Post/DistributedAgile 16 DevelopmentMicrosoftPatternsPractices, October 2008. (retrieved on May 11, 2020)
  13. ^ Shrivastava, S. V., & Rathod, U. (2015). Categorization of risk factors for distributed agile projects. *Information and Software Technology*, *58*, 373-387.
  14. ^ Pressman, R. S. (2005). *Software engineering: a practitioner's approach*. Palgrave macmillan.
  15. ^ M.Paasivaara, S. Durasiewicz, C.Lassenius, Using Scrum in Distributed Agile Development: A Multiple Case Study, IEEE International Conference on Global Software Engineering , p.195-204, 2009
  16. ^ Shrivastava, S. V and Date, H. (2010). Distributed Agile Software Development: A Review. Seo-chogu: Journal of computer science and engineering. 10-17
  17. ^ https://www.knowledgehut.com/blog/agile/key-factors-to-succeed-agile-teams
  18. ^ a b Smits, H. and Pshigoda, G., 2007, August. Implementing scrum in a distributed software development organization. In Agile 2007 (AGILE 2007) (pp. 371-375). IEEE.
  19. ^ J. Sutherland, A. Viktorov, J. Blount and N. Puntikov, "Distributed Scrum: Agile Project Management with Outsourced Development Teams," 2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07), Waikoloa, HI, 2007, pp. 274a-274a, doi: 10.1109/HICSS.2007.180.
  20. ^ a b Hossain, E., Babar, M.A., Paik, H.Y. and Verner, J., 2009, December. Risk identification and mitigation processes for using scrum in global software development: A conceptual framework. In 2009 16th Asia-Pacific Software Engineering Conference (pp. 457-464). IEEE.
  21. ^ Holmström, H., Fitzgerald, B., Ågerfalk, P.J. and Conchúir, E.Ó., 2006. Agile practices reduce distance in global software development. Information systems management, 23(3), pp.7-18.
  22. ^ Berczuk, S., 2007, August. Back to basics: The role of agile principles in success with an distributed scrum team. In Agile 2007 (AGILE 2007) (pp. 382-388). IEEE.
  23. ^ Sutherland, J. (2020, February 28). Distributed Teams: How To Mitigate A Significant Business Risk Of The Coronavirus. Retrieved May 13, 2020, from https://www.scruminc.com/distributed-teams-how-to-mitigate-a-significant-business-risk-of-the-coronavirus/
Retrieved from "https://en.wikipedia.org/w/index.php?title=Distributed_agile_software_development&oldid=956438172"