Globalization has forced organizations to consider global competition and resources to remain competitive: Project Management Case Study, UCD, Ireland

Globalization has forced organizations to consider global competition and resources to remain competitive. Improved information technology infrastructure has made it possible to outsource systems development beyond the organization’s national border, more precisely dubbed offshore outsourcing. Global inter-organizational software development, including outsourcing, subcontracting and partnerships, has recently become increasingly common. In addition, there is a demand for approaches able to deal with the increasing complexity of software development. A family of potential approaches that has received a lot of attention from software engineers and software researchers the later years has adopted the term “agile” (Abrahamsson et al., 2003).

Agile software development is introduced as a software development approach promoting teamwork, innovation, flexibility, and communication (Agerfalk and Fitzgerald, 2006). There is a growing interest in assessing the viability of using agile practices for distributed teams. This study describes how two global software development projects applied agile methods to coordinate their work.

Case Study 1: Project

Alpha The project was partly outsourced to India and aimed to develop a system for integrity management of pipelines both offshore and onshore. Scrum was introduced one year after the project had started. The project consists of six developers working full time (one is a Scrum master), two GUI designers, one product owner, and one project manager working 50% on this project. Four of the developers are situated in India together with one tester. The sprints usually last three weeks and ends on a Friday with a retrospective and review meeting. The next sprint is planned the following Monday. The team organizes a 15-minute Scrum meeting every morning discussing project related issues. The product owner is usually attending all the Scrum meetings. Coordinating software development work in the project. Before using Scrum, the team relied on standardization and direct supervision when coordinating work with their Indian team. In the beginning, the remote team was given some easy tasks specified by the Norwegian team. The Scrum master said: “The quality was varying in the beginning, and we thought they should only concentrate on the testing. Then they said “No, this is not fun, please give us something more exiting to work on?, so we gave them different tasks, and this worked pretty well.” After using Scrum for 6 months the project had implemented all the Scrum practices, and felt they were succeeding with continuously improving their Scrum process.

The team tried to work as if they were all collocated, ignoring the geographical and time differences. The Scrum master said: “Being distributed is a big barrier. We used a lot of time on discussions between people in the two sub teams. It didn’t work. The solution was to appoint one of the remote developers the role of a local Scrum master. Then we mostly communicated with her. It was much more efficient to delegate the responsibility to one person.” It was hard to achieve mutual adjustment because of the time-consuming communication. To improve the communication, it was decided to let the Indian Scrum master stay in Norway for a period. The Scrum master said: “This improved the situation a lot. The productivity increased while she was here. The important issue is to communicate with only one person.” She was participating in all the Scrum meetings as an integrated member of the team while situated in Norway. The Scrum master gave her credit and said that: “She is very good at coming up with ideas and show initiative.” At the same time, it was also decided to let the remote team work on its own module. Even though they started applying Scrum and assigned a member of the remote team as a local Scrum master, the coordination between the two teams is still described as a traditional way of developing software. During the planning meetings in Norway, the local team plans and suggests initial estimates for all the tasks in the project, and then assigns tasks to their remote partner. The remote team turns the tasks into sub-tasks and provides new estimates. In the end, the Norwegian team checks the results. The Scrum master said: “We decide what tasks are appropriate for them. Tasks are assigned to them and verified.” They are clearly coordinating the remote team through direct supervision. The Norwegian Scrum master, the Scrum master from India and one of the Norwegian developers had frequent meetings (2-3 times a week) with the remote team. This was a kind of distributed Scrum meeting. In the meetings between the two sub-teams, they relied on chat and e-mail. The Scrum master said: “We tried to use telephone-conferences, but it didn’t work very well, because of language problems. Written communication is easier to understand. Extensive use of chatting even makes it possible to ask a question right away. It takes time to organize a telephone conference.” He continued: “It was also difficult to use only 15 minutes on the telephone. It usually took an hour. Chat is better.” The Scrum master from India is involved in the planning and daily meetings standing equal to the other members, but then she coordinates the remote team by deciding who should do what. Their primary coordinating mechanism is direct supervision. The remote and local team are working on the same codebase and development environment. This allows for some transparency of who has done what. They have also managed to establish an automated build system, which allows everyone to see the progress or impediments if the build fails. When the Indian Scrum master is in India, scrum meetings are semi-daily, as the Scrum master said: “Although not daily, we have regularly meetings equivalent to daily scrums, but just including me and the remote Scrum master, and possibly one more.” When collocated, she takes part in the regular daily scrum. The Scrum master claims that this is beneficial, because: “When she was collocated with us we had an increase in productivity. It was quite substantial.” It seems that the transparency increased some, because the Scrum master said: “Before she joined the team, the remote team implemented exactly as specified even when they received an obviously erroneous specification. They must have understood that it was a mistake, but the point, for them, was to have their back clear. This has improved.” While this is more a cultural issue, the Scrum master would have been able to resolve it earlier if he was continuously aware of their work.

Case Study 2: Project Beta

This project was partly internally offshored to Eastern Europe. The goal of the project was to develop a system for collection and visualization of data from ship inspections. When ships are inspected, the results are stored in the system, and the collected data are visualized through 3D models. The 3D engine was first developed as a prototype five years ago, before it was integrated into the core system and then released. Each time the product is sold to a new customer it requires adaptation and modification of the system. Several contracts with different customers from all over the world have been signed. Four to five developers are situated in the remote team in an East European country, while two developers are situated in Norway, together with two persons from the support department, one from sales and a project manager acting as a product owner.

The Norwegian team implements the daily Scrum. These meetings are also used for discussion of future solutions. They tried to implement sprints for the whole project but failed. Tasks are mostly assigned to the Norwegian team’s members by the project manager, who said, while pointing at the backlog: “I’ve been putting some signatures on who is going to do what.” The project was originally applying a traditional, waterfall inspired model. This changed a year ago when a new project manager was assigned. The two distributed teams tried to use a common Scrum process. They were conducting several joint Scrum meetings each week and implemented shared responsibilities with mutual adjustment. Originally, the remote team was only responsible for the creation of 3D models, but when it was decided to integrate them in the total development process, they faced new challenges. The project manager said: “We thought that we should try Scrum, but because we wanted the remote team to take part in development and bug fixing, daily Scrum became a challenge. […] We didn’t manage to interact and cooperate. It became too time consuming.” According to the project manager, the remote team was unfamiliar with the system. This unfamiliarity made communication time consuming. The project manager said: “We felt that the Norwegian team members used too much time communicating with the remote team.” The project manager also felt that the remote team did not deliver as expected. She said: “The software did sometimes seem inadequately tested.” This dissatisfaction was communicated to the remote team. The project manager considered the problem to be difficulties gaining a thorough understanding of the complex source code and commented on how tasks were divided: “If we had managed to identify bigger chunks of new functionality to be developed by the remote team, it might have been easier for them.” To improve the situation, it was decided to divide responsibility between the teams and to give the remote team tasks that required less cross-site coordination. The Norwegian team is now responsible for the core system, bug fixing, new functionality and customer relations, while the remote team is mainly responsible for system configuration and the creation of 3D models for each customer. The project manager said: “Because of their 3D competency, it works, because then they don’t have to communicate with us all the time. […] It’s only if they lack a specification or domain knowledge, for instance when they miss an overview of what to put on the ship, then they come back and ask.” She also reported a lack of initiative. Coordination of work between the teams is mainly based on standardization and direct supervision.

The project manager said: “They get told all the way, and they get asked all the way.” The project manager complained about low awareness in the project: “There are things that we just discover by incidence, things that we don’t control. I feel that I don’t control the resources. For instance, we don’t know when they are at work.” The local team provides some transparency through a spreadsheet with project data, mostly broken down to a ship-by-ship level, including data on who has implemented what. There was also a collocation of the teams for a two-week period. The project manager said: “We didn’t manage to bring them through all the nitty-gritty stuff, so there was a lot of chat, mail and telephone afterwards.” They also had a common platform for development, with tools and logs containing bugs and enhancements. The daily builds posed a particular problem, according to the project manager, who said: “When the daily build failed, we had to find out who checked in the code that broke the build, and if it was someone remote, it might be that he wasn’t there when we needed him.” Despite the common infrastructure, there was low awareness in crucial areas. The project manager thought it would be better if they were collocated. “You can think out loud, and when you sit together, someone will answer, but you lose this if they sit in another country.

You have to initiate a conversation to get the answer instead of just turning your head and ask.” There was also low awareness of competencies and resources, as the project manager mentioned when she said: “It was typically things they could have asked anybody about, not just that single person, but he sat there and felt that he had to assist them continuously.” She also said that: “If they had been sitting next to me, we could have done it together, seen the result and adjusted,” indicating that higher awareness and collocation could have solved some problems. Conclusion All projects were using Scrum for the first time, and it is possible that more mature Scrum teams would communicate more efficiently because they may be more knowledgeable about and have a better understanding of issues related to applying an agile approach in a global software development project. Furthermore, none of the remote teams were trained in Scrum and this probably resulted in a lack of process understanding. Dyba and Dingsoyr report that no less than 73 % of the studies on agile projects were on projects with less than a year of experience in agile development. This is, unfortunately, the case for the projects in this study as well. The projects failed in implementing mutual adjustment, and Scrum was only implemented in two local teams. In the end, the less mature projects applied a subset of Scrum practices.

Assignment Detail Based on your reading and analysis of the two case studies, you’re then asked to report back on the following questions:

• What conditions lead to the issues experienced in the two IT projects?

• Referring to IT project management literature, how could these issues have been avoided and/or overcome? Provide an in-depth analysis of the case:

• Read (and re-read) to ensure that your analysis is directly informed by the case study rather than your own assumptions.

• Select a few key challenges that you will explore in detail E.g., as relevant to time, scope, budget mgmt. Use references to back up your recommendations.