Introduction
Agile is a set of methodologies for Software development that was first published in 2001 by Agile manifesto. Since then, it has experienced a huge success and Agile adopters are increasing relentlessly, even becoming mainstream. Also, Agile philosophy has expanded to other industries, one of the best Agile examples is Zara, the Spanish clothing company.
The core values of Agile are in the Agilemanifesto,
which may be explained as:
- Development and Business teams close collaboration.
- Importance of direct onsite communication.
- Short period deliveries of functionalities.
- Flexibility with updates in customer requirements.
Basically, Agile methodologies seek the rapid
adaptation to changes with a high standard of quality and reduced costs,
removing any unnecessary processes, such as excessive documentation.
Scrum Methodology
Scrum is a very flexible methodology of Agile, indicated for high changeability projects and is characterised by the split in iterations called sprints.
Figure 1: The sprint-driven
Scrum project flow (Schuh 2004)
Sprint time is usually set to two weeks, so twice
a month the client receives a new release of functionalities. Apart from the
daily scrum meeting to monitor progress, Scrum has five milestones:
1.
Product backlog: list of all functionalities to be
implemented. The IT team provide the estimated effort to complete them based on
the information provided.
2.
Sprint plan: In the beginning of the sprint, the
client defines the functionalities of the sprint, which are chosen from the
product backlog.
3.
Refining or grooming: Two days before the release
date, a meeting is held to discuss cancelled and new functionalities included
in the current sprint.
4.
Retrospective: A day after refining, the whole team
meets to talk about pluses (positive points) and deltas (points to improve). An
action plan is implemented to fight most important deltas.
5.
Demo: The last day of the sprint, a demonstration is
made to the client, showing all the requirements of the sprint working. The
whole IT team attends this meeting too.
Agile Key Factor
Agile practitioners need to fight resistance to changes and distrust for new methods, also results usually take some time to be positive. Without strong commitment and support from the management tier, those issues would provoke a failure. So the key to success in Agile projects is: Support from top management.
VersionOne survey shows most of Agile professionals believe the main problems for Agile adoption are related to management support too.
Agile Benefits and Drawbacks
The most important advantages of Agile are:
- Flexibility
- Client gets directly involved in the project
- IT team acquires business point of view
- The team gets full functional and technical knowledge of the implementation
- Iterative validation to manage expectations and provide frequent feedback
- Daily meetings and team estimations build a higher commitment in the team
- Dependencies on particular individuals are removed
As the most important
disadvantages:
- Management of change gets more difficult in fixed price contracts due to continuous requirement changes
- Longer inoperative time of the team, having a lower reaction time
- Forecasts deviation occurs frequently as they are estimated by an independent team
- Dependencies from non-Agile projects
- When deadlines are in place, the Project is quite difficult to manage
Agile Limitations
Some authors highlight the limitations of Agile regarding the type of project,
especially when dealing with fixed cost contracts, critical functionalities and
distributed teams. In the following table Agile
characteristics are compiled. Most of Agile projects has some non-Agile
characteristics, however, the more they have the more difficult to manage.
Figure 2: Agile and Non-Agile
project characteristics (Schuh 2004)
Challenges in Agile Distributed Teams
Looking at the reasons for adopting Agile, the IT teams in this survey usually point out to the acceleration of product delivery and the ease to manage changes, but the enhanced management of distributed teams is the last one. Therefore, most of the companies consider little benefit from applying Agile methodologies to distributed teams. Moreover, according to Agile principles, face-to-face communication is crucial, and some authors consider offshore Agile development as a near impossible task.
The following figure shows the problems of distributed Agile categorised by: communication challenges, lack of control and lack of trust.
Figure 3:
Agile challenges with distributed development (Ramesh et al. 2006).
Despite all those challenges, there are some good success stories with offshore Agile, such as:
- The Nokia Siemens Networks experience (Korhonen 2012), which measured an increase in motivation, visibility and product quality over a period of twelve months.
- The SirsiDynix distributed scrum (Sutherland et al. 2007), it was a distributed Agile project where productivity was greatly improved, compared to the traditional waterfall approach and even to collocated scrum.
Changes in Agile Distributed Teams
As Agile is all about flexibility, project managers should be able to take the Agile principles that best fit with remote teams, avoiding others that bring no benefit. Companies have adapted Agile to face distributed challenges by implementing the following practices:
- Requirement and design iterations: In Agile projects, requirements are usually flexible and the design is not defined in detail. In remote projects it is recommended to assign the first iterations to close the critical functionalities and develop the architecture. Also, the requirements should be documented, instead of relying completely in informal communications.
- Postpone critical functionalities: Instead of tackling the critical requirements in the early stages of development, distributed teams should work first with the well-known functionalities. This way the team gains confidence adapts quicker to the new project methodology despite the distance. This approach contradicts Agile principle of delivering best value to client as soon as possible.
- Flexible time-boxed iterations: It is useful to be flexible with the iteration time, because sometimes developers could need more time to clarify doubts and define the solution.
- More formal communication and coordination: To avoid misunderstandings, companies can define a role in each location who is responsible of communication between the teams. Also, project management roles gain importance for coordinating the different locations.
- Using online communication tools: As face to face communication is not possible, companies need to rely in applications to improve collaboration and communication, as Oracle WebCenter. There are even tools specially designed for Agile projects such as VersionOne. These tools should contribute to build a cohesive group.
- Visits: In order to build trust, it is strongly recommended to plan face-to-face interactions between members of different locations. These visits would not just apply to development teams, they would include customer staff too. Despite the cost of traveling, these interactions are crucial to build trust in distributed teams and make everybody feel they are part of the same team, especially in the beginning of the project.
- Informality under control: To reassure informal communications, documentation is required in critical functionalities, even though it is usually delivered after it is implemented. Added to this, the QA team must check the quality standards of the different locations.
- Team optimisation: The size of a standard Agile team is recommended to be under 50 members. However, for distributed teams, the limit is usually set to 15. Regarding team mix, it is important to use a decentralised model, where different roles are distributed in different locations, having a multi-directional information flow.
- Practices optimisation: As a general rule, each Agile practice should be analysed and if it is not useful to the team, it should be removed.
Figure 4: Mapping between Agile Distributed Development challenges and practices that address them (Ramesh et al. 2006)
Conclusions
Despite some criticism, Agile development is widely used in the IT industry. Many companies are introducing this concept to gain more flexibility in their projects, so it is important to understand the values of Agile, which are usually misunderstood. It is also crucial to learn the limitations of this concept and the scenarios where the use of Agile would not be recommended.
Although Agile was not conceived for distributed teams, in recent times there are good examples of successful implementations using Agile with both onshore and offshore members. The key resides in adapting Agile flexible practices to a scenario where face-to-face communication is not possible, without losing their core benefits. In order to help managers with this difficult task, this document compiles specific recommendations based on real-world projects that could support a successful offshore Agile implementation.
References
Korhonen,
K. 2013, "Evaluating the impact of an agile transformation: a longitudinal
case study in a distributed context", Software Quality Journal, vol.
21, no. 4, pp. 599-624.
Ramesh,
B., Cao, L., Kannan, M. & Xu, P. (2006), "Can distributed software
development be agile?", Association for Computing
Machinery.Communications of the ACM, vol. 49, no. 10, pp. 41.
Schuh (2004), Integrating Agile Development in
the Real World, Charles River Media, Hingham, MA, USA.
Sutherland J., Viktorov A., Blount K., Puntikov
N. (2007), Distributed Scrum: Agile
Project Management with Outsourced Development Teams, IEEE.
