The organization behind the case study in this thesis is a Vietnam branch of a leading Japanese multinational corporation (called 'parent company', or 'JP company'0F in this document) headquartered in Japan. The business of this parent company relates to design and development of a wide range of AV and IT products, including consumer electronics, such as cameras, music players, TVs, mobile phones, home theaters, and professional products, such as professional cameras, projectors. The major technology areas are mechanical design, electronic hardware design and embedded software design for its own products.
The parent company outsources software projects to its subsidiaries outside Japan, as part of the globalization trend for reducing operational expenses. The subsidiaries have been established in developing nations such as China, India, and South East Asia countries. A software outsourcing center was also built in Vietnam (called 'company', or 'VN company') several years ago with the core team of five permanent Vietnamese staffs and a Japanese general manager (GM). Because of its limited resources in Vietnam subsidiary, only small embedded software development (ESD) projects are outsourced to the Vietnam. These software projects are part of larger ones that involve multiple disciplines such as mechanical engineering, hardware and software development, and others. Occasionally, the VN company hires temporary staffs, either testers or developers, from local software companies to work together with the in-house software development team. The collaboration of both Japanese staffs of the parent company and Vietnamese staffs of the VN company in these projects forms a distributed and multicultural working environment. Figure 1 depicts the hierarchy of the global corporation with the VN company inside the red circle.
Figure 1. Organization hierarchy and the scope of the case study
Software development process
Regarding software development methodology in the Vietnam subsidiary, traditional V-Shaped model  is adopted. Formerly, the software development team attempted to build a customized set of software processes, procedures and document templates for in-house use, but it is bureaucratic and impractical for small-scale software projects. In addition, the company has no metrics to evaluate projects; therefore, no historical data is stored for future reference.
As an effort to resolve some issues of traditional software development processes, the management once applied Scrum practices to a pilot project, which was a distributed project with project members located in both the Japan headquarters and the Vietnam branch. However, the adoption was not well prepared, for example, lack of relevant Scrum trainings for Vietnamese staffs. Consequently, the Vietnamese employees did not recognize the principles and benefits of Scrum and thus they could not make it work in their daily operations. It seemed that the team had no positive improvement, thus the management decided to switch back to traditional software development methodology.
Currently, the uncertainty in the quality of deliverables, long development time, inconsistent project management methods, and communication issues between Japan headquarters and Vietnam branch are some major problems. For this reason, the VN company gains low trust from its parent company, which results that the management in headquarters hesitates in transferring key projects to Vietnam. The consequence is that the business of the VN company has not been expanded since its foundation. As a senior employee of the VN company, the author found that it is essential to improve the current software development processes of the company by applying a more suitable management framework.
Why agile adoption in embedded software development?
For over last decade, agile methodology has been adopted widely in many software companies worldwide, including leading ones such as Yahoo, Microsoft, Google, Motorola, Nokia, Siemens, Salesforce . Agile has been known as a powerful management method in terms of flexibility and customer collaboration, thereby improving quality and shortening time-to-market. In late 2013, there was a survey about current status and overall trends of Agile adoption sponsored by VersionOne , a leading provider of all-in-one agile management tools, with over 3500 responses from software development community worldwide. The survey indicated that agile development has brought benefits and improvement in many dimensions. From the statistical figures of VersionOne during 2011-2013 , there has been an increase of 11% in the number of answers agreeing that agile helps shorten development time.
Furthermore, many academic publications showed successful case studies of agile adoption in Embedded Software Development (ESD). Particularly, there have been several systematic literature reviews (SLR) recently reported about current state and trends of applying agile in ESD . These papers conclude that agile has been adopted successfully in many cases in embedded domain. However, the authors of these SLRs have also pinpointed some unique challenges, limitations and remaining issues when applying agile methods to ESD.
Although Agile methods are being widely used over the world , there have been few cases of successful adoption of Agile in Vietnam . For these reasons, it would be worth to conduct research on how to apply agile methodologies in software projects of this Japanese-owned company as the final master thesis.
1.2. Research contributions
The goal of this master thesis was to offer a persuasive proposal of applying an agile-based management framework for embedded software development in a Japanese-owned company. The ultimate purpose was to get the approval of the management to substitute the existing software processes with this new project management framework in the software development.
1.3. Research questions
The main purpose of this master thesis is to propose a customized management framework for embedded software development in a Japanese-owned outsourcing center in Vietnam. The software development projects are geographically distributed because project members are located in both Japan and Vietnam. The project members may include Japanese staffs in the Japan headquarters, permanent Vietnamese employees, and temporary Vietnamese employees hired from other local software companies in Vietnam. Thus, these projects form a multicultural working environment where both Japanese and Vietnamese cultures coexist.
In order to apply agile methods in these outsourced, distributed, and multicultural projects, the main concerns of the author when doing this research were (1) whether agile methodology can be adopted in embedded software domain or not, and (2) if agile is suitable for such embedded projects, how it deals with cultural differences and geographically distributed teams. From above concerns, the author came up with the first research question:
RQ1. Is Agile a suitable project management method for embedded software development (ESD) in multicultural, distributed and outsourced projects?
In order to answer the first research question, it is crucial to identify the current state of agile adoption in the embedded domain. This can be fulfilled by a comprehensive literature review on publications from well-known literature sources. Through preliminary searches of this research, the author discovered that there have been a considerable number of case studies using agile in embedded domain with positive results reported. Therefore, the answer was that agile could be applied for such ESD projects. However, the author also found out that agile methods and practices are highly customized to fit certain organization; this means we cannot re-use a management framework from another organization without revamping it. From this finding, it is essential to get insights into how to tailor agile methods and practices to fit into the company. This led to the second research question:
RQ2. How to adopt and implement agile principles and practices in the Vietnam branch of this Japanese-owned company?
The literature review described above can be carried out to answer part of this second research question, but it requires information that is more detailed and case specific. Through the literature review, success factors as well as challenges of agile adoption in ESD could be identified. Furthermore, agile adoption concerns about organizational changes, thus an analysis on the status quo of the company should be made. Based on these findings, enhancement of the current processes and practices of the company can be proposed. In other words, this customized agile-based management framework is backed by best practices collected from success stories in reliable academic sources, and by rational analysis of the status quo of the organization.
1.4. Research method
In order to answer the two research questions, a qualitative research was conducted in this project. The research comprised three steps as follows.
First, a literature review was carried out. In the review, the author made a brief summary about fundamentals of agile software development and then contrasted it with traditional software process models. The aim of this review was to explain why agile is premier approach among the others. Next, a comprehensive review of literature from well-known sources was conducted to understand how other companies adopt agile methods in embedded software development, thereby critical success factors of agile adoption were identified.
Secondly, a qualitative analysis of the current situation of the organization was performed. This analysis assessed multiple dimensions of the company such as organizational structure and culture, business model, people, and as-is processes and practices. As the author of this thesis was being a member of the software team, this analysis was based on ethnographic approach, which involved collecting data from the development team using semi-structured interviews, peer conversations, and participant observations.
Finally, a customized project management framework based on agile methodology was proposed in order to resolve the existing issues. The proposals addressed how software development projects are managed during their life cycle - for example, specific processes, procedures, and tools ' to improve product quality and productivity of the development team.
1.5. Expected results
As this research is an enhancement project for an established organization, it is necessary to get permission of the top management in order to apply it. In other words, the framework proposed in this thesis must be persuasive enough to get the approval of the management. Therefore, the author concentrated on collecting relevant literature, reading them, and then extracting data in order to build up a well-organized framework that was backed by solid theoretical background and rational analysis.
For this reason, the thesis is expected to result in proposing a project management framework based on agile methods, which can be approved by the management to apply in a pilot project for proof of suitability and feasibility.
The proposals were expected to provide following information:
' Documentation defining software processes, procedures and tools customized for ESD in the company
' Document templates and guidelines using for daily operations in all phases of software projects such as requirement, design, implementation, testing, and deployment
' Deployment roadmap of the new project management framework
1.6. Research scope
Building embedded systems often requires collaboration of several different disciplines such as mechanical development, electronic hardware design, and software development. The research scope of this thesis only focused on software development, because the company mentioned in this thesis is a software outsourcing center of a multinational company. Other development such as mechanical or hardware development is done outside Vietnam, which is out of the scope of this thesis.
There are various agile methods being used in software development, thus, it is impossible to apply all of them in this case study. Literature points out that Scrum and XP are the most widely used agile methods in in ESD . Because of limited time of the research, this thesis only concentrates on how to adopt practices of Scrum and XP methods in the case study.
In addition, the proposed management framework is customized for an established company. The framework is revamped from the existing processes of the company; therefore, it may be unsuitable for other organizations even operating in the same business field. However, this thesis can be a source of reference for one who is interested in agile adoption for ESD.
1.7. Related research
During the research of this project, the author found out dozens of articles about adoption of agile methods for embedded domain in other countries  . However, the application of agile in ESD in Vietnam seemed to be rare. In VGU, there had been other master theses made by BIS students about agile adoption in Vietnamese organizations, but only one is about embedded development. The first thesis was written by Hang Bui (BIS-2009) in 2012, which was about implementation of Scrum in a software development company with CMMi level 3 certificated located in HCMC. The second research was conducted by Quang Nguyen (BIS-2010) in 2013 , which discovered the current state of Agile adoption in Vietnam. There are two other studies were made by two BIS-2011 students in 2014, in parallel with this thesis, one related to applying Scrum framework to an Vietnamese embedded system development firm, the other implemented distributed Scrum practices in an outsourcing center of a foreign-owned company in Vietnam.
1.8. Thesis structure
The rest of the thesis is organized as follows:
Chapter 2, Literature review, is the review about agile fundamentals and agile adoption in embedded software development. This chapter is further divided into three sub-sections: literature selection, agile fundamentals, and agile adoption in embedded domain.
Chapter 3, Organizational analysis, analyzes the status quo of the company in the case study. The chapter is divided into four main parts. The first part describes about how data was collected. The second part presents the findings about organizational structure, corporate culture, management style, people, as well as as-is software development practices and processes. The third part analyzes existing problems of the company. The forth part assesses possibility of agile adoption in this organization.
Chapter 4, Proposals for enhancement, is the final result of the thesis. This chapter proposes solutions for enhancement, which are based on the outputs of Chapter 2 and Chapter 3. The chapter discusses how agile can resolve the existing problems. It also describes about customization of agile practices that are specialized for this case study. Finally, the chapter outlines adoption strategy and roadmap for agile transition.
Chapter 5, Conclusion, is the recap of the thesis content. The chapter summarizes and evaluates the results of this research. It also points out the limitations of this thesis and recommendations for further development.
2. Literature review
This chapter summarizes the basic knowledge of agile software development and the status quo of agile adoption in embedded system development as the theoretical background of the thesis. For the sake of convenience, the chapter is divided into three parts. The first part describes about how literature sources were selected. The second part mentions about the fundamentals of agile methodology, including a sub section about agile in distributed environment. The third part summarizes the findings about agile adoption in embedded software development.
2.1. Literature selection
The major purpose of this literature review is to answer the research question RQ1, which concerns about the current state of agile adoption in ESD, as well as its application in outsourced and distributed software projects. In order to answer this research question, firstly a basic understanding of agile software development is required. Next, a comprehensive literature review on the topic 'agile adoption in embedded system development' is necessary to explore the current state and trends of agile adoption in ESD. Therefore, to get the proper results, it is essential to identify relevant literature sources and search strategy. This section explains how the literature review was implemented in order to answer the concerns addressed in following questions:
' What is agile development?
' Can agile be adopted in ESD?
' Which agile methods and practices are being used in ESD?
' What are the most popular agile practices for ESD?
' Which is most suitable for ESD?
' What are the results of agile adoption in ESD so far?
2.1.1. Literature sources
The literature sources of this review include both non-academic and academic ones. The author made use of non-academic literature to have an overview of agile methodology. Meanwhile, the academic resources were used to identify the current state of agile adoption in embedded software development. For non-academic literature, the author collected online documents and websites as the major sources of information. For academic materials, the author gathered articles from well-known online scientific magazines and journals with an account granted by VGU. The databases used in this research for searching relevant academic literature are listed in Table 1.
Table 1. Academic databases used for literature search
No. Source name URL
1 IEEE Xplore http://ieeexplore.ieee.org/Xplore/home.jsp
2 Springer Link http://link.springer.com/
3 ProQuest http://www.proquest.com/
4 Taylor Francis Online http://www.tandfonline.com/
5 ScienceDirect http://www.sciencedirect.com/
6 Wiley Online Library http://onlinelibrary.wiley.com/
2.1.2. Search strategy
For basic understanding of agile methodology, the author used Google search engine to search for relevant articles and books related to agile, and then refined them for review. Meanwhile, the author found out that to identify reliably the status quo and trends of agile adoption in embedded development, a systematic literature review (SLR) would be necessary. According to Kitchenham and Charters , who wrote the guidelines for conducting Systematic Literature Review in software engineering, SLR is a kind of secondary study which is 'means of evaluating all the available research relevant to a particular research question'. There are two major purposes of this review: (1) identifying gaps in the current research and suggest further areas of investigation; (2) providing reference upon which new research topics can be built . Actually, the main purpose of the literature review in this thesis was neither (1) nor (2); instead, the author was interested in revealing the current adoption of agile methods in ESD. Therefore, if an existing SLR is relevant and correct, it can be a good source of reference for this research, and the author do not need to perform another SLR.
For this reason, the author firstly searched for systematic literature reviews about the same topic. In case no SLR was found, he had to perform the SLR himself. During search process of SLRs, it is essential to find out relevant articles by defining keywords for searching from academic databases described in Table 1 above. Thus, keywords used in the searches include 'agile' and 'systematic review', 'systematic literature review' and 'embedded systems', 'embedded software'.
Once a SLR was found in the previous step, the title and abstract were quickly read to check if this was a relevant SLR. If the title and abstract were still unclear, a quick screening through headlines, introduction, and conclusion was made. If this step was passed, all the primary articles that were referred in this SLR were collected to verify the correctness of the SLR. In the final step, the SLR was included in the list of literatures for this review. Then the data was extracted from both the SLR and its primary studies and synthesized as findings of the review.
2.1.3. Academic literature search results
During the search process through the academic sources, the author found out three recent SLRs that were published in international conference proceedings and scientific journals (see Table 2). The three SLRs analyzed articles published during the period 2002-2012, and they have the similar research questions concerning about current state of applying agile methods in ESD. After the procedure of correctness checking, the author concluded that the three SLRs could be relevant sources of reference. For this reason, the findings of these SLRs can be reused in this thesis, and performing another SLR on the same topic is not necessary.
Table 2. Summary of found SLRs
Author Title Publication Included primary studies
Albuquerque et al. An Investigation into Agile Methods in Embedded Systems Development Conference proceedings - Computational Science and Its Applications ' ICCSA 2012 23
Shen et al. Applying agile methods to embedded software development: A systematic review Conference proceedings - 2012 Second International Workshop on Software Engineering for Embedded Systems 40
Kaisti et al. Agile methods for embedded systems development - a literature review and a mapping study Journal article - EURASIP Journal on Embedded Systems - 2013 28
The first found SLR was made by Albuquerque et al. in 2011, which contains 23 primary studies on the same topic from seven well-known academic sources . The second SLR by Shen et al. in 2012 collected 40 primary studies from even larger number of academic libraries (thirteen databases) . The third SLR conducted by Kaisti et al. includes 28 papers from ten academic databases ; this SLR contains the first and second SLR mentioned above as two of the main reference sources. The total number of primary papers listed in these SLRs is 91; however, twelve of referred articles were overlapped among the three SLRs. Therefore, only 71 out of 91 referred papers of the three SLRs were counted. In the refinement process, the author skimmed through and selected the most relevant articles that describe about agile adoption for ESD for further reference.
In general, these SLRs discuss the adoption of Agile in embedded system development. They were aimed to provide an overview of agile adoption in embedded system development in recent years (2002-2012). Their outputs confirm that agile methods have brought benefits to ESD. In addition, pitfalls, limitations and challenges when applying agile in ESD have been addressed in these SLRs.
Meanwhile, there are slight differences among these SLRs. The first and second SLRs emphasized on applying agile methodology in ESD. The major difference of the two is that in the first SLR Albuquerque et al.  focuses on the adoption of particular agile methods in ESD (mostly Scrum and XP), while the second SLR of Shen et al  concentrates on the application of Agile principles in ESD. The third SLR by Kaisti et al.  provides a broader scope of research by examining Agile adoption in both embedded software and embedded system development, which means that this research is more focused on embedded hardware. The scope of  is also wider than the others in that no particular agile method is addressed, instead, it includes any methods related to agility such as lean method.
2.2. Agile software development overview
This section aims to provide an overview of agile values, principles and practices. Firstly, some key concepts of agile methodology are summarized. Secondly, some of popular agile methods are mentioned. Finally, a sub-section about applying agile for distributed environment is discussed.
2.2.1. Agile methodologies introduction
Agile software development is a lightweight, iterative and incremental development methodology that relies on self-organizing and cross-functional teams. Agile highlights adaptive planning, evolutionary development and rapid reaction to change. Agile methods were originated from other iterative and incremental development methodologies such as spiral, RAD (rapid application development), and RUP (Rational Unified Process) . Actually, agile management is a mindset, which comprises a collection of development methods rather than a sole approach of development . Some methods in agile family include Scrum, eXtreme Programming, Crystal Clear, Feature Driven Development, Adaptive Software Development. In 2001, the core values and goals of agile methodologies were generalized and defined in Agile Manifesto (agilemanifesto.org) by a group of software practitioners in a concise paragraph :
'Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan'
The core values of agile are self-explanatory. Agile highlights collaboration between project members and customer representatives in order to develop high quality software products that satisfy the changeable demands of customers. Other supplementary artifacts such as documentation, processes, tools, contracts, and plans play minor roles in this management style. This does not mean that such artifacts are not important at all. Though it is expensive for documentation creation and maintenance, agile teams still need documents at certain level. In other words, agile does not eliminate all kinds of documentation; discipline, processes and tools are still having place in agile, but people and their interaction play more important role to make software projects successful .
Agile manifesto is further supported by twelve principles which are also published at agilemanifesto.org :
'Customer satisfaction by rapid delivery of useful software
Welcome changing requirements, even late in development
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Sustainable development, able to maintain a constant pace
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication (co-location)
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity'the art of maximizing the amount of work not done'is essential
Regular adaptation to changing circumstances'
Agile Manifesto and principles are the foundation of all agile practices. Figure 2 illustrates the relationship among agile values, principles and practices. Agile practices are 'activities that are used to manifest or implement the agile principles and values' [28, p. 9]. An agile method generally comprises a subset of these practices to concentrate on a specific aspect of development. For instance, Scrum consists of practices which are more suited for project management , and XP includes more technical oriented ones .
Figure 2. Agile mindset overview[28, p. 6]
Agile methods are characterized by iterative and evolutionary development . Iterative development means each project is divided into smaller portions which are ease of use and highly flexible, especially when requirements change. These portions are implemented as if they are sub projects of the larger project until all customers' requirements are satisfied and the final product is delivered. After each smaller portion of the project is complete, it will be delivered to customer for evaluation. The customer may change the requirement or add new features into the product as the consequent action. The development team can update or revamp the product following these new requests without making it from scratch again. This is known as evolutionary development.
Applying agile is not a straightforward process , it is not just selecting agile practices and using them, but it requires insights into the core values and principles of agile methodology. This process may take a lot of efforts and time because of cultural changes when migrating an existing process to a more agile one [28, p. 36]. Thus, agile experts suggested that agile should be customized to fit organization's environment and constraints [28, p. 36].
Benefits of agile development
Nowadays agile methods have become the best choices for customers, developers, and software development companies because of flexibility, diversity and effectiveness. Agile has been the replacement for traditional linear, plan-driven development methodologies, such as Waterfall, which dominated software engineering industries for decades . Traditional development methods are most suitable for projects with stable requirements and risks are well identified . However, when requirements are vague and evolving, agile is a more proper choice. Agile is best suitable for projects with (1) small and skilled team working on the same location, normally from two to eight members; (2) frequent changes from customers; (3) great collaboration among team members . On the other hand, other heavy-weight and complicated processes such as CMM would be best suited to large projects, and it would take time for use in small projects, especially embedded projects .
Figure 3 outlines the major differences between traditional plan-driven development and agile development. In plan-driven software development such as Waterfall model and its variances, development phases are sequenced downward throughout project life cycles and products are delivered to customers at the end of projects. This model implies high risk because there is a high level of uncertainty at the planning phase, which may lead to surprising gaps between estimation and actual development.
In agile development, the project life cycle is divided into smaller chunks; each chunk contains all development activities and a delivery at the end. This style of development brings benefits to the organization if it is applied properly . Firstly, agile can deliver the value to customer earlier than traditional development with deliverables in the very first iterations. Secondly, agile offers quick adaption to changes and uncertainty. By working closely with the customer through early delivery, it helps reduce risks because the customer can give feedback promptly to the development team so that the correctness of implementation is ensured. This also results in improvement of quality, higher productivity and decrease of development time.
Figure 3. Plan-driven and agile software development 
2.2.2. Agile methods
The figures from VersionOne's survey in 2013 have shown that among Agile methods and practices in software development, Scrum and Scrum variants are the most popular agile methodologies being used with 73% (Scrum: 55%, Scrum/XP hybrid:11%, Scrumban: 7%) . The popularity of other agile methods such as Kanban, lean, feature-driven development, and XP are far below the above number with 5%, 3%, 2%, and 1%, respectively . Meanwhile, XP is the widest employed method in ESD . This section summarizes the fundamentals of some popular agile methods for ESD.
Scrum is the most popular agile method being applied in software development . Its principles emphasize constructing project's organization, and in a Scrum based project, any change or adjustment is relied on experience instead of theory . A Scrum project consists of a number of time-boxed iterations called sprints . The length of a sprint is typically two to four weeks. During a sprint, the team fully develops a set of features, tests and integrates them into the evolving product.
Scrum defines three main roles: Product Owner, Scrum Master, and Team Members. In addition, Scrum consists of four deliverables, which are product backlog, sprint backlog, burn down chart, and shippable functionality, and five key practices, which are release planning, sprint planning (iteration planning), daily Scrum meeting (daily planning), sprint review (iteration review), and sprint retrospective (iteration retrospective). The Scrum process can be graphically illustrated in Figure 4.
Figure 4. Overview of Scrum lifecycle 
Product Owner is the person who is in charge of defining functionalities of a product. In other words, he plays the role of customer .
Scrum Master acts as a project manager who manages the overall status of the project. His responsibilities include: tracking the project progress via releases, monitoring the productivity of the team and collaboration of team members, as well as eliminating obstacles during project life-cycle .
Team members are developers of the team except for Product Owner and Scrum Master, who construct and test the product before delivery. A team in Scrum is cross-functional, which means that team members are able to implement a feature from the beginning to the end .
Product backlog contains a list of features need to be supported by the software product. It is created and prioritized by the product owner. Each item in the product backlog is normally a user story, which is a summary of a feature from the viewpoint of customer. 
Sprint backlog is created by development team at the beginning of a sprint. It is the breakdown of the items in the product backlog, which are selected for a sprint. The sprint backlog can be seen as a list of tasks the developers have to fulfill in order to build up the required features. Sprint backlog can be visualized on a Scrum task board. 
Burndown charts present the remaining work to be done in a sprint. It is an effective way to track the progress of a sprint or to determine if a release is done on time or not .
Sprint Planning Meeting happens at the start of each sprint or iteration. This is a very popular technique in agile management . The planning meetings are conducted by the development team, including the product owner and Scrum master, to determine what features to be developed in a sprint and then put them into sprint backlog .
Scrum Daily Meetings are means for work synchronization among team members . The meetings are held by the team every day on a specific time and they are normally time-boxed to 15 minutes. Each team member is expected to answer the three questions :
' 'What did you do yesterday?
' What will you do today?
' Are there any impediments in your way'?
Sprint Review Meeting is conducted at the end of a sprint by the team to present new features developed in the sprint to the Product Owner and other stakeholders. Feedbacks can be collected for enhancement in the next sprints .
Sprint Retrospective happens at the end of a sprint, normally after Sprint review meeting, in which the team members, product owner and Scrum master participate. It is a chance for the whole team to review their achievements and to identify what should be improved .
188.8.131.52. Extreme Programming (XP)
XP is one of the most prevalent agile methods being used in software development, particularly in embedded domain . XP principles and practices are initially described by Kent Beck in his book 'eXtreme Programming eXplained' . XP was developed to solve the issues of software development in small teams where requirements are vague and may be changed frequently. Coding is the key activity in XP; therefore, programmers play critical roles to ensure the successful adoption of this method.
XP focuses on customer satisfactions by actively reacting to new requests or changes from customers [33, p. 26]. To fulfill this task, XP values 'high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals (1-3 weeks)' . The method relies on four values and twelve practices . The values are simplicity, communication, feedback, and courage. Twelve practices are listed in Table 3. An overview of XP process in a software project can be visualized in Figure 5.
According to Drobka et al. , XP is not a 'one-size-fits-all process', and it has to be customized to fit into specific organization. He also recommended that the organization should employ an external coach or consultant who has experience with XP to make the transition easily.
Table 3. XP practices (adapted from , )
No. Practices Meanings
1 Planning Game The planning process from high-level planning, by business people, to detailed planning, by technical people
2 Small Releases Frequent small deployment is preferred to accumulate self-confidence and gain customer's trust
3 Customer Acceptance Tests Detailed requirements are defined when customer performs acceptance test
4 Simple Design Simplest coding is preferred. No duplicate code, fewest classes and methods
5 Pair Programming Mutually coding and reviewing by a pair of two programmers on one screen
6 Test-Driven Development (TDD) Test code should be created in advance, then functional code is written to make test code run successfully
7 Refactoring Frequently applying small changes to improve designs and for ease of maintenance
8 Continuous Integration Team members should check in frequently so that the whole team is updated as early as possible
9 Collective Code Ownership Project artifacts can be edited or viewed by any team member for ensuring transparency and accountability
10 Coding Standards The team should obey coding guidelines and standard
11 Metaphor The team should collectively have enough ability to implement functionalities of a system
12 Sustainable Pace Stably and gradually improve velocity
Figure 5. Overview of XP process
184.108.40.206. Lean and Kanban software development
Lean is a JIT (Just-In-Time) process originated from Japan manufacturing industry, which aims to reduce inventory storage of parts and finished goods, thus leads to a lower investment . Nowadays lean principles are applicable in software development. Lean contains seven principles which are 'eliminate waste, build in quality, create knowledge, defer commitment, deliver quickly, respect people, and optimize the whole' .
Kanban is a lean method which comprises of practices for continuous improvement . Applying Kanban can help improve product quality and productivity . Kanban defines three principles: limiting WIP (work in progress), visualizing workflow, and enhancing flow. Limiting WIP means that reducing lead-time by identifying and removing the issues that are blocking the production queue. The terminology 'lead time' originated from Toyota Production System and it is 'the time between a request being made and being fulfilled' . Kanban approach can improve processes by visualizing workflow in order to measure performance and optimize the whole system . The team can visualize their workflows by filling their tasks on a kanban board (Figure 6). The tasks are put in columns, which represent different processing states: in progress, done, ready for test, etc. The team uses this board in daily meetings for updating development progress, identifying issues, thus optimizing the production system.
Figure 6. A Kanban board 
2.2.3. Agile and distributed working environment
Nowadays outsourcing software development to other countries has been a growing trend globally. Thus, distributed organizations, in which employees work and communicate remotely with their coworkers from distance, have become more popular [41, p. 5]. Therefore, agile adopters should embrace this change, and special considerations should be focused when applying agile in blooming distributed projects. There are many successful stories of agile adoption for small, collocated teams where all members are in the same location . However, things would be harder for distributed teams because visibility of project is often diminished in distributed environment . This section reviews some challenges and solutions in the application of agile practices for distributing environment.
Challenges in applying agile for distributed teams
There are a number of challenges when one adopts agility for distributed teams. Agile relies on closed, face-to-face collaboration, not only among team members but also with the customer, thus communication issues are the most common in distributed projects.
The first issue is that team members in a distributed project are not collocated, thus the lack of daily face-to-face verbal conversation may lead to the fact that some pieces of project information cannot be well understood . Verbal conversations not only convey the meaning of words, but also carry nonverbal cues which may account for 65% of the meaning [41, p. 20]. Even the latest technologies such as telephone or video conference cannot dismiss this gap. For this reason, more efforts would be put on documentation to minimize the communication gap. Thus, the team has to spend extra time to make documentation, which may ultimately be a waste.
The second challenge is the communication style differences among non-collocated members in a distributed team. The challenge is more severe if members are not from the same country, where cultural and language barriers are major causes [41, p. 11]. For example, it is unsuitable for some cultures to admit that one cannot understand the others [41, p. 21]. Another example about cultural misunderstanding is that, when a Japanese person says 'yes' in his own Japanese language, it means that he is listening rather than his agreement . Thus, it is more difficult for both training and applying agile practices due to communication gap among team members .
Another issue relates to differences in working hours. There are some business reasons for distributing working environment in software industry, but a common reason is that software is outsourced to developing countries for cost reduction [41, p. 6]. Teams in outsourced projects are often distributed, and team members sometimes have to work in countries with different time zones. In some cases where time zones have some overlapping work hours, the members can interact during each other's normal working time. However, when there has no overlapping work hours, it is harder for direct communication among the team. Figure 7 illustrates a distributed team that has members in California, Texas, and Beijing with different time zones. California and Texas have six work hours of overlapping, whereas both of these cities have no overlapping work hours with Beijing. Therefore, doing daily communication between Beijing team members and America located teams is a major challenge.
Figure 7. Distributed with Overlapping and No Overlapping work hours[41, p. 11]
Solutions for agile adoption in distributed software development
In order to apply agile successfully in distributed projects, tools and techniques should be utilized for shortening communication gap among team members who do not work in the same location . In addition, team structures have to be re-organized to adapt to distributed environment. An example for handling distributed teams in IBM is to apply one of the three Scrum models: Isolated Scrum, Distributed Scrum of Scrums, or Totally Integrated Scrums [41, p. 12].
In Isolated Scrum, a distributed team is further divided into sub-teams that consist of members in the same location. These cross-functional teams are separate Scrum teams and no collaboration is required among teams. This is the ideal model for scaling Scrum.
'Distributed Scrum of Scrums' means a distributed team is organized in several smaller collocated, cross-functional Scrum teams. These teams are similar to those of Isolated Scrum model. The difference is that the sub-teams collaborate with the others via 'Scrum of Scrum meetings' in which representatives of each team attend remotely. In this case, the Product Owner may not be a single person; instead, there is a team of Product Owners working in different locations.
'Totally Integrated Scrums' is applied when distributed teams cannot be avoided, in another word, the team cannot be further divided into collocated and cross-functional teams like in the cases of Isolated Scrum and Distributed Scrum of Scrums. This happens in projects where team members from multiple locations work on the same delivery, for example, development team makes a release and then delivers to testing team located in a remote place. In Totally Integrated Scrums model, Distributed Scrum of Scrums techniques such as 'Scrum of Scrum meetings' are used with attendance of all Scrum team members.
Sutherland et al. insisted that productivity of distributed and outsourced teams can be as good as that of collocated teams if distributed Scrum is implemented properly . All members of distributed teams should be linked by right tools, for instance, single build repository and unique tracking and report tool, so that they can work seamlessly and be able to make daily communication regardless location.
2.3. Agile adoption in embedded software development
This section lists out the findings about agile adoption in embedded domain, which includes success factors, challenges as well as pitfalls of agile adoption. This is the foundation for the organizational analysis and the proposed management framework in next chapters.
2.3.1. Characteristics of embedded software development and challenges to agile adoption
Embedded software development has to confront with specific challenges of embedded domain. Getting insight into these challenges is necessary for agile adopters and it should be a prerequisite for adopting agile in this special field of software development.
Agile is originally applied for the development of common software applications which are independent from hardware . In embedded world, however, things are much more diversified. Embedded systems are computer systems comprising of both hardware and software which are designed for particular purposes . Nowadays embedded systems appear in many places with a variety of use, ranging from industrial manufacturing to household appliances. There have been numerous of platforms with hardware and operating systems from various providers over the world. The hardware itself has to be tailored according to the need of each unique application. As embedded systems involve multi-disciplinary development, implementation of embedded software is more difficult than conventional software . While general software development requires only programming skills, embedded software developers are often expected to have higher technical skills: programming skills and domain knowledge .
Hardware dependency is a trait of embedded software. Comparing to desktop-based software industry, higher performance is required in embedded systems, such as real-time constraints and safety regulations in medical instruments. Nonetheless, embedded software has to deal with hardware resource limitations, such as limited memory, storage, CPU speed, and so on. Although embedded software highly depends on hardware, software development cannot wait for the completion of hardware development because of business reasons such as time-to-market, competitive edge, and others. Grenning  stated that concurrent development of hardware and software is popular in embedded domain. Another paper pointed out that embedded software is normally developed in advance before availability of hardware . Because hardware is developed in parallel with software development, hardware availability may be a problem for software testing.
According to Mellor , testing must be performed before any release when applying XP practices such as 'small release'. With non-embedded software, the generic desktop platforms running the software are always available, thus it is not problematic with this practice on non-embedded software. However, in ESD, hardware infrastructure is built concurrently with software, therefore hardware platforms for testing before every 'small release' is almost impossible. Normally, development teams have to use similar platforms or simulation environment to test certain functionalities of embedded software. Consequently, changes in embedded system development are more severe because any replacement in hardware substantially impacts to software .
Uncertainty of requirements is another issue in embedded development. According to , embedded system development projects often start with fixed release dates while requirement specifications are not finalized yet. There are some causes of this uncertainty, for example, the strong competition of embedded industry such as short time-to-market, or R&D budget limitation. As a result, development teams have to face with the problem of requirement changes, and efforts have to be spent for rework in later phases.
2.3.2. The status quo of agile adoption in embedded domain
220.127.116.11. Agile adoption in embedded system development resulted positive effects
Agile methods and practices has been used in embedded industry, and a number of case studies witnessed the successful adoption of agile methods in embedded domain; however, their popularity is still rare . Various agile methods and practices have been employed in this domain, including XP, Scrum, FDD, AASD, RUP, TDD, Crystal, UCD, platform-based design, and hybrid methods (i.e. combination of agile methods).
There were various types of embedded projects, from small to large-scale, applying agile with positive results. SLR  pointed out that embedded project and team sizes were small in most cases. This finding also confirms that agile is suitable for small teams.
Greene stated in an article that a hybrid method which was customized by the combination of Scrum and XP well suited small firmware development projects at Intel . However, Greene also concluded that although agile theories are quite simple for one to understand, making it work in reality may be a challenging task, and it may require much time for process improvement.
In another paper, Fletcher et al. showed their experience in developing firmware for small embedded systems using agile practices . They confirmed that although many engineers initially suspect the applicability of agile for embedded development, agile practices were successfully applied for their firmware development projects. The authors pointed out that agile could be adapted for embedded projects as long as the team had enough motivation for the transition to agility.
In , Smith et al. proposed testing frameworks originated from desktop development for their test-driven development processes of digital signal processing which were applicable on a variety of standalone and multi-processor systems. The process was customized on top of XP practices such as TDD, refactoring, simple design, pair programming, and continuous integration. The authors concluded that although the processes had not been fully developed, these agile-based processes could effectively prevent defects in the production of embedded software.
Some case studies reported positive effects of agile adoption in large-scale telecommunication software development. Gul et al. in  shared their experience about customizing XP practices in their large-scale and complex software applications for mobile telecommunication. They reported that although there was resistance from team members for applying XP at the beginning, some XP practices such as planning, small release, pair programming, 40-hour week, and on-site customer were well adapted in their projects.
In another study, Scrum method was applied for large-scale system engineering projects which enclosed not only real-time ESD but also included other components and disciplines such as hardware, mechanics, algorithms and more . Originally, these multi-disciplinary projects followed traditional linear process, but many issues came up such as requirement changes, increasing expenses, and team communication. Thus, the management decided to apply agile practices for a pilot software team up to 15 members, which was then restructured in four sub-teams. During the course of tailoring agile practices to suite the project, the authors identified many challenges, for example, cultural and organizational changes, or integration tasks among multidisciplinary teams with different development methods. They finally suggested that besides the changes in development methodology, improvement in both human and organization should be required to resolve these challenges.
Agile was also adopted in a large and complicated project of the U.S. government where a software application for scheduling satellite tracking system was developed . Prior to this project, there had been several attempts to build such applications but they all failed either by user's rejection or by distrust of stakeholders. By applying agile practices for internal process such as embracing customer's involvement, reducing work volume of complex requirement to simpler user stories, refactoring the code, the team was able to deliver the software product to its customer successfully.
18.104.22.168. Agile adoption in embedded domain was diversified
Organizations adopted agile in different ways. According to , it could be categorized in three main groups of agile adopters in ESD. The first group concentrated on applying existing well-known agile methods such as XP or Scrum; the second group customized their own practices, which were based on the existing agile practices; and the third group purely relied on agile values and principles stated in Agile Manifesto and made them work in their software development processes.
Article  mentioned about some cases that belongs to the second and third groups. According to the paper, existing processes of ESD are supplemented with particular principles of agile or with individual agile practices in some companies; however, the applied practices were often tailored to suite the domain. Besides, Savolainen et al.  advised that existing practices should be used in combination with new agile practices. In addition, he insisted that skilled engineers should be a condition for a successful agile adoption.
Case study  is an example of this diversification. The paper reported about agile adoption in a software development project for government system. The government constrained software development and delivery process to Waterfall model. Thus, the team maintained two processes concurrently: agile process for internal use, and traditional waterfall process for delivering products to customer.
22.214.171.124. XP and Scrum have been the most popular agile method used in ESD
Scrum and XP are the most well-known agile methods in software development . Another fact is that the most popular Agile method applied in common software development is Scrum (66%) . However, XP is the most common used agile method in ESD, as pointed out by the SLRs of Albuquerque et al. (with 54%) , Shen et al. (with 70%) , and Kaisti et al. (with 34%) . According to these SLRs, Scrum is the second most popular method in the development of embedded systems, with 27%, 30%, and 17%, respectively. In some case studies, combinations of different agile methods, e.g. XP and Scrum, were applied .
This finding is also consistent with opinions of some authors in that ESD requires high technical skills , while XP practices are more technically oriented  [28, p. 9], therefore, XP is likely to be well suited for ESD. Also from , XP seemed to be the most suitable agile methods for ESD because its practices are relatively ease of use for developers. At Intel, best practices of XP are particularly suitable for software engineers who have hardware background . On the other hand, Scrum has been more popular in 'pure' software projects because it concerns more about project management [28, p. 9].
126.96.36.199. Mixes of agile methods were used in ESD
Rarely a single agile method was employed for embedded development. Instead, part or subset of agile practices were tailored and combined to make them adequate for each organization . In fact, mixes of XP and Scrum has been widely employed in embedded development. In , 22.5% of case studies involve both XP and Scrum practices. In  and , the authors concluded that XP and Scrum are complementary methods and both of which can be used in embedded system development.
188.8.131.52. Agile methods were highly tailored to fit domain and organization structure
Embedded systems are often constrained by domain specific requirements, thus, sometimes it is hard for tailoring agile methods to adapt domain-specific characteristics . For example, the constraint of quality certifications such as ISO standards may partly prevent applying certain agile practices. In reality, few teams applied original agile methods, instead, some teams tailored agile methods to fit into specific characteristics of embedded systems, domains and organization . Kaisti et al.  also pointed out that the nature of agile methodology is not completely suited for embedded systems. In order to overcome these challenges, mixes of agile methods, such as XP and Scrum, or combinations of traditional practices and agile practices, were used in many case studies . Albuquerque et al.  concluded that there would be no single agile method that was best suitable for embedded software development.
184.108.40.206. Transition to agile often requires external coaching
Inexperience of agile development may lead to failure, thus, many case studies reported that the companies had to hire agile experts to coach the teams during the transition from a traditional development process to a more agile one . In the study , external agile consultants were hired to participate in Sprint review and retrospective sessions at the end of each iteration. The consultants spent about one hour together with the team to review and then give their feedbacks. This was to improve their processes and help team members to gain insights into agile methodology.
On the other hand, Srinivasan et al. recommended that the agile process should be tailored by a member of the organization in order to match with the industry and product's features, and this tailoring process should be mentored by an external coach who is an expert in agile methods .
2.3.3. Factors affecting the success of agile adoption
Agile requires regular involvement of customer . This is one of the core values of agile methodologies. Getting early feedbacks from customers can help development teams to develop right products and to build up collaborating environment. In cases where real customers cannot be part of agile project teams, proxies of customers playing by team members should be substitutes. This 'proxy customers' are similar to Product Owners in Scrum .
Agile adoption requires support at organizational level. According to Srinivasan et al., there are two kinds of issues of agile adoption in embedded development: technical and organizational . This means that besides resolving the issues of software development activities such as requirement and testing, adoption of agile can be successful only if the team receives top management support regarding to organizational issues . This support includes process improvement, knowledge sharing, cultural change, and infrastructure investment (for example, proper tools for controlling software lifecycle, or wiki and social networking tools for communication and collaboration) . Without support from the management, agile teams can hardly get customer involvement in their daily activities, and thus they may have to sustain two separated development processes: one is for internal use and the other is for the management .
Change management is important when adopting new agile practices and processes . Employees tend to resist changes when they are already familiar to their current processes and routines . In this transition, companies that already have a culture of promoting new ideas and willingness to changes gets more chances to be successful . Particularly, cultural change management is crucial in agile transitioning, because the process involves much about 'soft factors' . However, cultural change management is not a simple process . For example, many developers who are not familiar to TDD technique tend to write code before implementing unit tests, and it is a touch process to change this habit . Morgan  suggested that a successful transition to agile requires a gradual and transparent transformation in the mindsets of team members towards agility. During this transition process, managers should lead the team instead of forcing them to apply new processes or practices. If following this way, agility of a team will evolve throughout this process.
Knowledge sharing is crucial for the success of agile adoption . This means that agile requires high collaboration of the team, thus it only works if the environment is open enough so that knowledge can be transferred among team members.
2.3.4. Scrum and XP practices in embedded software development
This section delves into some popular Scrum and XP practices and their variants that were used in the referred case studies of embedded software development. The purpose is to get insights into the applications of these practices in order to apply them properly. To make it easy in mapping these agile practices into the as-is software processes of the company in this thesis, these practices are categorized in perspectives of project management and conventional software development. Project management involves planning, executing, monitoring, controlling, and delivery. Software development typically includes requirement, design, implementation, testing, and deployment.
220.127.116.11. Project management
Organizing people with Scrum roles
Scrum defines three main roles: Product Owner, Scrum Master, and Team Members . However, sometimes Scrum roles were not explicitly defined. In , the team did not clearly define Product Owner and Scrum Master roles. Instead, there were project roles such as 'tracker', 'process engineer', 'architect', 'project manager', 'proxy customer' who shared the tasks of Scrum roles.
Agile management requires customer involvement for early feedbacks, thus the presence of customer in an agile team is necessary. When the real customer cannot be reached, there should be a 'customer proxy' role within the team to direct the team for developing the right functionalities of products .
Sometimes the involvement of a customer proxy does not suffice, thus real customers' feedbacks are required. In , the authors shared that in their large project for satellite tracking system, there was a large number of end users who had the rights to accept or reject the products. However, the development team rarely had chances to interact with them. Instead, the team worked with supervisors and key personnel who represented the roles of customer. Meanwhile, some prior projects had failed because the project teams were unable to get feedbacks from these end users during the development. To resolve this serious issue, the team demonstrated their product monthly to the end users in order to receive feedbacks from them, and thus the product was able to evolve successfully from those feedbacks.
Project planning, executing and delivering with iterations/sprints
Agile development divides the project into smaller iterations (or sprints). The iterations are short enough, normally two weeks, so that the team can do estimation correctly . The team delivers working software that is able to execute for demonstration to stakeholders and then receives feedback from them at the end of iteration. This is common practice in non-embedded software projects; however, in embedded development it becomes impractical to deliver small increments to the customer when hardware is unavailable. Grenning  discussed that deliverables in iterations could indicate the real progress of projects, thus, if the real product is unavailable, at least demos should be shown to customers in simulation environment. He argued that customer's feedbacks on the real product could be essential instrument for the team to ensure the correctness of their implementation. Other non-executable artifacts such as design documents only contains high level concepts, thus potential issues cannot be foreseen until later iterations.
Grenning also noted that these early demos should be built on the real code . It is because incremental development is a characteristic of agile methods, which means the software has to evolve through iterations. This differs from the case that a prototype is used for demonstration only, and then it is thrown away without reuse the code.
Another challenge in embedded development is that initial implementations of software often confront with hardware uncertainty when hardware requirement specifications are not available yet. Creating hardware abstractions in software to isolate hardware related code and software implementation details can be a solution . This solution helps minimize the rework and the software team is still able to do testing with simulation environment prior to hardware availability. Hardware abstraction also allows injecting test events, which are used in automated testing on virtual instrumentation. This technique helps the team to resolve the problem of hardware dependency of software, thus the team can deliver demos to the customer in early iterations.
Project monitoring/controlling with daily meetings, iteration reviews and retrospectives
Daily stand-up meetings are the most employed technique in agile world . These time-boxed meetings play important role in improving communication among team members . A stand-up meeting aims to address three things: (1) what is done yesterday, (2) what will be done today, and (3) what is the current problem. The meetings require the participation of all project members to be effective. Shatil et al. stated that in their large-scale, complex embedded system development project, all 15 developers of four sub-team, a proxy customer and sometimes the project manager, participated in stand-up meetings every morning .
The meetings should be conducted in the right way, otherwise team members may feel bored with repeated report activities; this may leads to unexpected consequence of this practice. Greene  shared that team members at Intel felt more comfortable when the daily meetings focus more on (2) and (3). Moreover, communication tools are essential in daily meetings when the team is not collocated. At Intel, even the team had two members in other cities; they could keep effective stand-up meetings via telephone bridge.
For further effectiveness of daily meetings, Gul et al. suggested that if an important decision was made during stand-up meeting, for example, adoption of new technologies or algorithms, formal written messages should be recorded and sent to all members .
Sprint reviews and Sprint retrospectives happen at the end of each sprint; therefore, they can be combined in a single meeting. In , sprint planning, sprint review, and sprint retrospective were all conducted in the same meeting. A dedicated day at the end of every sprint was reserved for these activities. A team member took responsibility to prepare and organize the activities. The team carried out various activities in this day, for example, new feature demos, team accomplishment assessment, feedback collection, analysis of measured metrics during the sprint, and next sprint planning.
Project metrics are necessary for management to evaluate project results. They can help measure performance of the whole team and each individual in a project. In addition, metrics are important for overall communication, because they provide more visual indicators in order to get the awareness of employees about the need of change [4, p. 25].
In order to evaluate agile projects, agile teams can establish their project metrics based on dimensions that are varied in different organizations. For instance, the team in  used following figures which were recorded daily or after each iteration: 'non-technical meeting hours, unplanned activities hours, burndown chart, burnup chart, planning vs. accomplishment, and number of open defects'
18.104.22.168. Software development activities
In agile software development, requirements are often divided into smaller user stories which can be estimated, implemented, and delivered within an iteration . To reduce the time of writing lengthy requirement specifications, which might be waste later, requirements are developed in parallel with the design and implementation of software. This is fundamental in agile development, and it is called as concurrent engineering. Grenning defined concurrent engineering as 'a business strategy designed to shorten development time-to-market by doing development activities in parallel that have traditionally been done serially' . Concurrent engineering leads to a fact that once requirements are not clearly defined, requirement misconceptions and thus wrong implementation can occur. However, the agile iterations are short enough so customer feedbacks can be received promptly right at the end of iteration, and then the team can rework with minimal efforts. A way to reduce the risk of wrong implementation is to prioritize the requirements and implement the most significant functionalities of the product, because these core features often encompass high value and lower risk . For example, in any smart phone, making and receiving phone calls are core functions, thus they should be implemented before other features that do not always exist in all kinds of mobile phones such as photographing or media playing.
In embedded development, breaking down the system requirements into more detailed stories to fit into an time-boxed iteration can be a challenging task due to the interaction of hardware and software . Another issue involves the delivery of requirement specifications when changing from traditional development to agile development . In traditional development, stakeholders expect to receive complete and detailed requirement specifications. Meanwhile, in agile development, the time span of iteration may not be enough for completing requirement documentation. Thus, immature requirement specifications, which are delivered in early iterations, can only address requirement items that contain high customer's value. Therefore, it is necessary to inform stakeholders about this change.
Agile software development focuses on delivering working software and disregards documentation, thus design specifications are kept to a minimum. In , design documents were written in order to keep developers being on the right track and thus less refactoring is required. However, the team only created documentation for high-level design at architectural level; low-level design documents were not created. Instead, the detailed design tasks were covered by pair programming.
Refactoring can be carried out to refine the design. The team can do minor refactoring whenever they want, however, critical refactoring should be carried out at the end of iteration or after each release to avoid unexpected problems affecting other part of the software . The reason is that refactoring involves code modification, and this activity may generate bugs that easily break down the software system. Sometimes it takes extensive time to detect the bugs by manual testing. Thus, automated testing is often used with refactoring to detect defects, thereby reducing the defect rate of each release. Beside, automated tests also release the burden of regression test on existing features when new features are integrated into the software .
Implementation and testing
Traditional software development follows code-first scheme that separates coding and testing. In agile development, however, test-first is common technique for reduction of defect rate. Thus, implementation often adheres testing in agile projects.
Pair programming can help eliminate misunderstanding of team members about requirement [41, p. 21]. Working in pairs is also a good mean for knowledge transfer; however, this collaboration style also exposes some issues to consider . Firstly, it is hard to determine the responsibility when the code becomes good or bad. The second issue is that if the two members in a pair have different knowledge level, the task might be solely done by the superior one. Particularly, software development that closed to hardware requires engineers to have a certain level of specific domain knowledge . Thus, when two engineers in a pair possess different levels of domain knowledge, pair programming may lead to decrease of productivity.
In paper , the team at Intel customized this practice to suite their firmware development in assembly language. However, pair programming takes extensive time because it requires two programmers working on a single monitor sharing a same task. To ensure the effectiveness, pair programming only happened during detailed design and initial coding, and then the code was developed by each individual following a peer review. For a pair that was not collocated, remote pairing can also be accomplished by making use of both remote desktop sharing (e.g. using VNC) and audio communication via telephone.
Coding standards and collective ownership
Conforming to coding conventions is important, but coding standards should be defined at a generic level because the team is not able to applied if it is too detailed .
Collective ownership for the whole system can be feasible when the code is small enough, but it may not be true for large scale systems . For large and complicated software where each team member can only master part of the source code, collective ownership should be limited within a module or component.
Test Driven Development (TDD)
TDD (or 'test-first') is a popular XP practice. Grenning defined TDD as '' the practice of writing automated test code concurrently with the production code' . It is the widest used agile practice in embedded software development because it contributes to quality improvement . Smith et al. also confirmed that TDD is the superb method for ESD to reduce defects . However, cultural change may be needed in order to apply TDD technique, because team members have to change dramatically their development scheme, from coding-first to test-first . In reality, many developers who are not familiar to TDD technique tend to write code before implementing unit tests, and it is a touch process to change this habit .
TDD relies heavily on automated testing for both unit tests and acceptance tests. Automated unit tests are normally implemented by software engineers in a programming language. However, automated acceptance tests are the results of collaboration of test engineers and customer representatives, who may have non-programming background. Automated acceptance tests can be written in domain specific language with the support of free acceptance testing tools such as FitNesse .
In embedded domain, test automation for entire embedded system is impractical because of high cost in investing physical instrumentation. However, it can be performed at certain extend by using virtual instrumentation through hardware abstractions to inject events for testing . There have been several case studies found in the literature as follows.
In a study at Intel , TDD was applied in the development of firmware for Itanium processor in assembly language, in which the team made their own test automation tool for unit testing and regression testing. The paper confirmed that TDD was the most valuable practice and it brought dramatic improvement on the quality of code.
In another study , the team developed firmware for small Microchip-based boards using C language, TDD was used for both unit testing and system testing. In the project, unit tests were written before making the firmware. The team leveraged Ruby scripts combining with C 'mock objects' to perform automated unit tests. These unit tests automatically executed whenever the system was rebuilt. In order to inject unit tests into the main source code, they split the source code into three layers. The top layer contained the code related to system logic. The bottom layer was hardware dependent code, which was in charge of controlling the real hardware. The middle layer played the mediator role to forward events and data between the two other layers. This architecture allowed injecting unit test code via the middle layer. Automated system testing was also executed using proper software tools for automation testing. The software tools enabled developers to make test scripts in Ruby called 'Systir', and the hardware tool combining with its software libraries helped the team to measure the outputs for each test case.
In , Smith et al. applied TDD and other XP practices such as refactoring, simple design, pair programming, and continuous integration in the development process of digital signal processing. This process had four-stage life cycle. In the first stage, developers and customer collaborated to define acceptance test cases in FitNesse format, a wiki-based automated testing framework. This testing framework had been customized by the team for embedded software development. The framework allowed a non-IT customer with limited knowledge about low-level engineering could still participate in development team as an agile-style customer. The second stage was the design phase in which the development team developed a simulation prototype in Matlab/IDL. Additionally, the team developed a unit test framework called 'Embedded xUnit' in C++, which could be used in both simulation and embedded environment. Then the team used both the unit test framework and the acceptance test framework for validation of the prototype. Once the prototype passed all the unit tests and acceptance tests, the team entered the third stage by transforming the prototype code from Matlab to the C/C++ language of the target system, however, it still run on simulation environment on host machine. The tests in previous stages were modified and then used to test this initial production system. In the fourth stage, the software was migrated to the real target board, and then the unit and acceptance testing were repeated again for the real system. During the course of applying agile practices in this process, the authors recommended that testing tools such as FitNesse and 'Embedded xUnit' were essential in TDD. In addition, they identified some issues when moving the software from prototyping to final target system, for example, some unit tests passed in the prototype, but they failed in the real system after refactoring.
3. Organization analysis
This chapter provides a detailed analysis about the status quo of the organization in this case study regarding aspects of agile methodology adoption. The chapter is divided into four main sections. The first section describes about how data was collected for the analysis. Next, the second section presents the main findings about the organization, software development team, and as-is software development practices. The last two sections analyze the findings; one section is for identification and analysis of existing problems in the as-is situation, and the other assesses possibility of agile adoption in this company.
3.1. Data collection methods
Multiple data sources were considered to collect reliable data for the analysis. Yin [51, p. 97] mentioned bout six possible data sources for qualitative case study research: documentation, achieved records, interviews, direct observation, participant observation, and physical artifacts. Furthermore, he recommended that more than one source of evidence should be used for reliability. In this research, three data sources were selected: documentation, participant observation, and interviews.
Documents describing organization structure and management system - such as organization charts, MBO process guide, and other administrative documents - were collected to give an overall view about organization. Besides, documentation of previous projects was used to discover as-is software development. Some examples of project documents are project plans, schedules, meeting minutes, reports, and presentation slides.
During this research, the researcher was being one of the members of this software development team, and he had been participating in all software activities almost from the foundation of the company. Thus, participant observation by the researcher can be suitable in this case, as pointed out by Yin [51, p. 94]. The findings of participant observation were further discussed in face-to-face interviews with other team members for their confirmation.
Qualitative interviews with all five permanent employees of the software department of the VN company were used as another source of evidence. Face-to-face interview sessions were carried out separately. Four Vietnamese employees were interviewed in Vietnamese language. Another interview was conducted in English with the Japanese general manager, who heads the department.
Semi-structured interview format was used in this research. The interviews were guided by open-ended questions that had been prepared and grouped in topics. Thereby, the researcher could get insights into software development practices, not only from perspectives of a participant observer, but also from viewpoints of other team members. Based on the collected data, aspects related to agile adoption could be identified objectively. In addition, problems that had been foreseen by the researcher were also discussed in the interviews. Table 4 includes a list of interview topics. Appendix B contains a set of interview questions for further reference.
Before interviews, interview questions and answer sheets were sent to all interviewees for their preparation. Interviewees were recommended to make short answers into the answer sheets. The answer sheets were then sent back to the interviewer. During interviews, notes were further recorded into these answer sheets, and each item in the answer sheets was confirmed by interviewees at the end of each interview, or by further discussions later on.
Table 4. Topics discussed in interviews
Area of investigation Topics Interviewees Covered contents
Organization Culture and management style Vietnamese developers Cognition of Vietnamese staffs about company's culture and management method
Management's expectation Japanese GM Japanese managers' expectation and their evaluation for performance of the team
Attitudes to changes From management Japanese GM Possibility to change as-is software processes toward agility, constraints from management
From development team Vietnamese developers Motivation of developers for continuous improvement
Software development team Skills Vietnamese developers Technical skills and experience of each developer, how they match software projects' needs
Knowledge sharing Vietnamese developers How the team capture and share knowledge
Communication and collaboration Vietnamese developers How team members communicate with others and with Japan teams
Software development practices Software projects Vietnamese developers Types of software products, customers, project sizes
Software process Vietnamese developers As-is adopted software methodology
Software tools Vietnamese developers Software tools being used by the team in software projects
Project management Vietnamese developers Planning, executing, monitoring, controlling, delivering, metrics, review
Software development activities Vietnamese developers Customer involvement, Requirement engineering, analysis and design, implementation, testing, dealing with HW dependency
3.2.1. Organization's structure, management and culture
The VN company is a subsidiary of a large Japanese corporation. The company has hundreds of employees and it operates in several business domains besides software development, such as sales and marketing for electronic products. In this thesis, however, only the business of software development is mentioned, and other business units are out of scope.
The company is structured as a linear organization in which each department is identified by its function (see Figure 8). The board of directors (BOD) is on the top of the organizational chart, responsible for highest strategic decisions. Besides other major business units that are not mentioned in this paper, there are three supportive departments: accounting, IT support (IS) and human resource (HR). Software development (SW) department is one of major business units of this firm; however, the software department is a very small business. SW department operates as an in-house outsourcing center of the parent company from Japan. The business of SW department is based on software development projects that are outsourced from the parent company, thus it can be said that its only customer is the parent company.
As a subsidiary of a well-established international corporation, the VN company has modern working environment that is well equipped for daily operations; however, the company has to comply with the headquarters' policies and regulations. Regulations are defined and applied strictly within the company, such as business standards, behavioral rules, business ethics, and others. The software department is a business unit of this corporation; thus, it has to comply with these corporate rules as well. Understanding of these restrictions is vital because the constraints may prevent necessary changes for a successful agile adoption.
Figure 8. Organizational structure of the VN company
Being a Japanese-owned firm, the VN company is managed with Japanese management philosophy. In this company, job security is a key policy, and promotion is based on seniority. The company values employees' loyalty through its human resource policies. The organization maintains a competitive welfare programs to retain and foster talent employees. The management system leverages modern management techniques and tools for both behavior-oriented and result-oriented assessments. For example, web-based performance appraisal system and 360-degree feedback system are used in managerial development and promotion. Another instrument is the management-by-objective (MBO) system for annual bonus assessments. With this MBO system, the company attempts to distribute its business profits proportionally to the employees basing on their contribution. This management system somehow has retained employees for many years. However, working in such secured environment can deactivate staff's motivation to some extent.
Employees are encouraged to learn new knowledge. With the approval from the right management level, they are also allowed to apply new ideas for continuous improvement in their daily routines. On-the-job-training is the preferred method, and official education is rarely offered to the employees. Although the company has annual budged for training, but it is limited to a number of employees. For example, English classes are organized once per year for intermediate level only.
Like many other Japanese companies, job rotation is applied for Japanese managers in this company. The general manager position of software department is changed every three to five years. Most of candidates of this position have technical background in software engineering. Besides, all of them can speak English, and they try to learn Vietnamese language when living in Vietnam.
3.2.2. Software development team
This section describes about the software development team in the VN company. A summary of the findings is shown in Table 5. The details are described in following sections.
Table 5. Summary of findings about the SW development team
Categories As-is state, practices and tools
Development team ' A collocated team with five permanent Vietnamese engineers managed by a Japanese manager. Beside, temporary developers are hired on demands
' Team members have different backgrounds and skill sets
All engineers have average English skills
' Most of engineers have not known about agile methodologies
Structures of project teams ' There are two structural types of project teams: collocated team and distributed team. In both cases, project managers are Japanese located in the headquarters in Japan
Collocated team: only Vietnamese engineers work in a project in Vietnam
Distributed team: both Vietnamese and Japanese engineers work in a project across the two countries
Communication among team members ' Relying on peer, face-to-face discussion.
' Emails, messages on JIRA, online chatting are other written means of communication
' Meetings are on demands, there is no daily or weekly meeting
Communication with JP team ' Communication is relied on Japanese bridge engineers at the two sides. Messages are conveyed to Vietnamese staffs via Japanese-English translation, and vice versa
' In distributed team structure, Vietnamese and Japanese engineers can join weekly video conferences, but the same communication mechanism is applied.
' Emails, messages on JIRA, online chatting are other written means of communication
Knowledge sharing ' The team has knowledge sharing sessions, however they are not organized on regular paces
' Documentation (Design documents, Meeting minutes, ') are often written in MS Word or Excel or PowerPoint formats, then stored on VSS
Attitudes toward changes for enhancement ' No individual objected changes for enhancement
' All team members are quite busy with software development projects, thus, they have little time to think about how to improve their as-is practices
22.214.171.124. Team structure
Figure 9 illustrates the structure of the software department in Vietnam and its typical communication mechanism with Japan teams. The Japanese general manager (briefly called 'GM' in this paper) is the head of the software department. Vietnamese staffs of software department report directly to him. There are totally five permanent Vietnamese employees - four developers and one tester. Depending on the needs of particular projects, temporary Vietnamese software engineers and testers are hired from other local software companies. These temporary developers work together with permanent Vietnamese engineers at the office of the VN company. So far, the total number of project members has never exceeded 10 resources for all types of projects.
In software development, the SW department works directly with the parent company with minimal intervention from the BOD of the VN company. Therefore, from perspective of software development, the Japanese GM is the top management of SW department who has authority for decision-making in the department.
In the parent company, the software department undertakes software developments for embedded products. This software department outsources parts of software development projects to the VN company as subprojects. So far, software projects have been managed in a distributed approach. In these projects, Japanese project managers always stay in Japan, and members of development teams may be located both in Japan and in Vietnam. However, Japanese and Vietnamese developers seldom do direct communication with the other in common language, but mainly through representatives of two sides.
Typically, in a project, a Japanese staff is often assigned as the bridge engineer in Japan headquarters. This onsite bridge engineer can be a project leader or project manager as well. At Vietnam site, the Japanese GM acts as both general manager and bridge engineer. Because Japanese staffs, except for the GM, are incapable of spoken English, while Vietnamese engineers can only communicate in Vietnamese and English, the Japanese GM has to play the role of a Japanese-English translator.
There are two other departments in the parent company, which are mechanical engineering and hardware engineering. These departments involve in the development of these embedded systems; however, the Vietnam team never directly with these departments.
Figure 9. Vietnam team's structure and its communication with Japan team
126.96.36.199. Skills and experience
Table 6 gives a summary of skill sets of the Vietnamese engineers. Five members of software development team possess five to fifteen years of experience in ESD. There are two technical leaders among the four developers, who are capable in project management, so they are often appointed as project leaders. Three out of the four developers have hardware background, thus some of them do not have solid programming foundation. The tester knows little about coding but she is the only one in the team who owns professional testing skills.
The VN team is familiar with server-side and desktop development, as well with embedded platforms used in the products of the parent company. A broad range of software technologies and programming languages has been used by the team in previous projects. The most common programming languages are C/C++ and Java. Assembly and scripting languages also present in some projects but it is quite rare.
Because of rich-featured products in the parent company, each developer owns a specific set of software development techniques, which is different from those of the others. In addition, none of them can master all the technologies needed in company's products. For instance, a developer has expertise with embedded platforms such as Android, Qt, iTron, but he is incapable of desktop application development in Microsoft .NET. Another developer knows well about .NET technology and web application programing, but he has no experience with Qt platform. Another fact is that while technical leaders are able to write documentation quite well, some less experienced engineers are weak in this skill.
All Vietnamese members can communicate in English, both written and verbal, at certain level of proficiency. The team is capable of writing documentation in English with some minor mistakes. All software staffs have been learning Japanese for several years, but they can only speak very simple Japanese sentences, thus their Japanese cannot be used in communication with Japanese staffs. English is still the official language in the company.
In software department, only experienced candidates have been recruited. Thus, software team members have different working backgrounds from their previous jobs with previous employers. This trait has somehow affected the collaboration of team members in common activities of software development. For example, developers who had their previous job in large software company with well-defined processes tend to advocate formal software process, whilst the ones who originated from smaller firms often follow informal procedures in their work.
The team members have limited knowledge about agile development. When the author conducted a short seminar to introduce the fundamentals of agile methodology for the team, most of attendees admitted that they did not know much about agile development.
Table 6. Skill sets of Vietnamese engineers
TL1 TL2 SSE1 SSE2 Tester
Total years of experience 15 14 9 5 10
Background HW HW HW SW SW
Platforms/OSes Embedded, desktop, mobile
Windows, Linux, iTron, Android, Qt, VxWorks Embedded, desktop, server
Windows, iTron, Android, non-OS Embedded, desktop, mobile
Windows, iTron, Android, Qt Embedded, desktop, server
Windows, Linux, iTron, Android NA
Programming languages C/C++, Java, assembly, scripting C/C++, C#, Java, assembly C/C++, Java, assembly C/C++, C#, Java, scripting, HTML5 NA
Types of SW development Device driver, BSP, middleware, application Device driver, middleware, application Device driver, middleware, application Middleware, application, server-side application Testing
English proficiency level Intermediate Intermediate Intermediate Intermediate Intermediate
Japanese proficiency level Beginner Beginner Beginner Beginner Beginner
Preferred software process Informal Formal Formal Informal Formal
Knowledge about agile SW development Limited experience Very limited Knows a little Very limited Knows a little
Internal communication among Vietnam team members
The development team's members, except the GM who has just moved in Vietnam for one year, have been working together for three to five years; some members even were co-worker in their ex-company before joining this company. Thanks to the open design of the workspace without cubical wall between desks, a developer can easily make face-to-face with others. In software development, developers spend most of their working time with their computers. However, the team can always reserve time for open discussions, not only about technical affairs, but also for relaxation activities such as foreign language learning, or chatting about an arbitrary topic for relaxation.
The organization has equipped basic communication facilities for its employees. The traditional and simplest one is telephone set at every desk. Besides, the company provides each developer a powerful PC with preinstalled communication softwares such as MS Exchange email client, or MS Communicator. In addition, the company policy allows staffs to install communicating programs such as Yahoo Messenger, Skype. Hence, there has been no obstacle preventing straightforward communication among Vietnamese employees, even when they work remotely outside the office.
The software team has neither daily meeting nor weekly meeting. Instead, members use peer discussion to exchange information. Meetings are decided on-demand by the GM or project leaders when there are issues or new information needs to be updated. Thanks to the open workspace, manager and developers can freely exchange information anytime at one's desk, or in quick stand-up meetings. The latest information or issues of the projects are further written on JIRA system; this system in turn sends notification emails to the related members.
External communication with Japan teams
The two countries only differ two hours from the other; thus, time zone difference is a minor issue. This means that the VN team and JP team have six hours of overlapped working time per day. Thus, the teams almost have no trouble to allocate time for meeting, chatting or emailing. The infrastructure of the company allows both Japan and Vietnam sides work on the same virtual network seamlessly via VPN, thus the teams can always leverage MS Exchange to arrange meetings or other events, this helps eliminate the misunderstanding of time zone, because MS Exchange automatically maps the correct local time of each side.
On the other hand, due to geographical distance between JP and VN sites, face-to-face meetings among project members are very rare. The projects often have no budget for staffs' travelling. In most of projects, Vietnamese and Japanese members have never met the others, and they would have never known the faces of the others if they had not joined video conferences. To establish a closer relationship between the JP headquarter and the VN subsidiary, the management recently decided to reserve budget for staff travelling between the two sites, but this budget is very limited and it is constrained to fiscal year budgeting.
Depending on project types, communication between VN company and JP headquarter can be carried out in several ways to deal with challenges of distributed environment. In general, the GM is the bridge of communication between Vietnamese and Japanese staffs. The two sides can exchange information via emails, JIRA system, MS Communicator chatting, or remote meetings via video conference system.
In some projects, the VN team works as an independent team without participation of the Japanese developers. In these projects, Japanese staffs appear to the VN team as customer proxies who provide requirements of development. Communication between customer proxies in Japan and the VN team is carried out through the GM with minimum involvement of Vietnamese staffs. In weekly video conferences, only the GM meets with Japan team without participation of Vietnamese staffs.
However, in some other cases, there has been need of collaborative work of both sites in the same project, which forms distributed work environment. The project teams consist of both Japanese engineers working in Japan and Vietnamese engineers working in Vietnam. In these projects, the team members often use emails and JIRA system for sending written messages. For verbal communication, weekly video conferences are employed with participation of Vietnamese engineers. The team leaders at Japan site, the GM and the Vietnamese project leaders are required in these meetings. With his adequate proficiency in English, the GM plays the role of a Japanese-English translator in the video conferences. During the meetings, the Vietnamese project leader reports directly to the Japanese team members. He reports verbally in English, then the GM translates into Japanese so that all Japanese members can understand what the team leader wants to convey. The reverse communication is done in the similar way, i.e. the GM translates message from Japanese staffs into English verbally. This kind of communication is somewhat ambiguous and consumes time. Therefore, MS Communicator software is often used in parallel to share the same written report on a computer screen at the two sides. Thereby, explanation can be easily made based on this report.
188.8.131.52. Knowledge learning and sharing
Besides participation in software development projects, the Vietnamese staffs reserve their time for internal study activities to enhance technical knowledge as well as soft skills. The team then stores documentation and source code of these internal studies on VSS repository for future references.
An individual does research himself on a particular new technology, for example, new web technologies. During his study, he documents some key notes in PowerPoint format or in other similar tools. He then can request the team to attend a short knowledge transfer session or seminar. During this session, he shares his findings with others, and answers questions from them. He can even do further demonstration by showing his real software deliverables. The team in turn can give feedbacks to the presenter for improvement.
Besides technological topics, one can pick other area of knowledge, for example, a developer chose 5S methodology as his favorite study. In another seminar, the tester gave a presentation on automated testing technique. As a member of this team, the author actually did research on agile methodologies as his interested topic. In addition, the author leveraged this useful practice to convey the fundamentals of agile development to the team. In another knowledge transfer section, some findings of this thesis ware summarized and presented to the team.
These activities can be parts of MBO objectives of the department and of each individual, which are set at the beginning of every fiscal year. During MBO setting phase, an individual can select his interested area of study and register it as a MBO objective with the GM.
These activities are very useful for knowledge transferring among individuals; however, they have been carried out randomly. When the team members are not busy with projects, they can give presentations once or twice per month, but when there are many assigned tasks, the team ignores these activities for months. Thus, sometimes no presentation was performed for long time up to several months.
184.108.40.206. Attitude toward changes for enhancement
When being asked about their opinions to change in software development practices, all Vietnamese interviewees said that it would be good to improve as-is processes and practices. However, they confessed that they had been busy getting their daily tasks done to meet deadlines of projects. Thus, team members probably had no time to think about how to enhance weaknesses in their software development practices. There was a fact that some individuals had registered their research topics for knowledge transfer sessions as MBO goals, however, due to the pressure of projects, they had no time for these research activities.
3.2.3. As-is software development practices
This section presents the findings of as-is software development of the VN team. A summary of the findings is shown in Table 7. The detailed information of each item in the table is described in the next sub-sections.
Table 7. Summary of findings about as-is software development of the VN team
Categories As-is state, practices and tools
Infrastructure, facilities, and tools ' Well-equipped working environment for both local and remote working, open workplace
' The team use a mix of both local softwares tools (VSS, Bugzilla) and centralized, distributed tools (GIT, JIRA)
' The team has not make use of some powerful tools that are already in place (Confluence, JIRA Agile, Fisheye, Crucible)
Software development products ' Diversified software products with different platforms (8-bit to 32-bit)
' Various OSes (Windows, Linux, Android, Qt, VxWorks, iTron')
' Many types of SW development (application, device drivers, middleware')
Software process ' Traditional V-model is adopted
The Vietnamese engineers does not always participate in all software development phases. They mostly work with design, implementation, and testing. Requirement documents are often written by Japanese staffs.
' Projects with long implementation phases are often divided into multiple iterations of 1-3 weeks
Project management ' Project planning: Individual estimation in person-days, review by team, stored in MS Project and Excel
' Project monitoring/controlling: relying on peer talks, project progress is updated on MS Project
' JIRA is used for issue tracking and change request management
Project delivery ' Manually copy source code and documentation from local VSS to remote GIT or file servers
Requirement engineering ' The team seldom writes requirement specifications
' Requirement specification format: Traditional requirement style with user cases written in MS Word format, stored on local VSS
Design ' Upfront design, stored in MS Word format and VSS
' Engineers spend much time for design documentation
Implementation ' The team applies code-first scheme, i.e. coding is followed by unit tests and system tests
' Source code is stored on local VSS
Code integration, build and test are manual
' Code reviews are rarely carried out
Testing/Quality assurance ' Rely on manual testing
Project reviews ' The team has review meetings at the end of projects
Dealing with HW dependency ' Real HW devices are seldom shipped to Vietnam
' The team has solutions to minimize impacts of HW dependency (developing only platform-independent software, using alternative HW, remote debugging/testing, working onsite, developing dual-targeting source code)
220.127.116.11. Infrastructure, facilities, and tools
All members of software team work in the same room, which is separated from other departments. Each member has a large engineering desk enough for two LCD monitors and other equipment that is necessary for embedded software development. The workspace of staffs is open, i.e. there is no cubicle or wall between two desks. Thus, every member can easily make face-to-face communication with others, even when he stays in his desk.
Inside the room, there is a meeting area enough for the whole team up to ten members. The meeting area is equipped with a LCD TV and a whiteboard. The facilities inside the room allow the team to discuss whenever they want, without having to book a meeting room. In reality, the team often makes use of the LCD TV for documentation and design reviews. The whiteboard is often used for brainstorming or taking notes.
There are dedicated meeting rooms equipped with video conference systems, beamers, and whiteboards. These meeting rooms are often used for weekly remote meetings with Japan site. However, meeting rooms are shared with other departments; therefore, meetings require registration in advance.
All employees' computers are equipped with common office softwares such as MS Word, Excel, Visio, and so on. Besides, employees can also install extra software tools as needed by their tasks if they can get the approval from the GM.
Several software tools are installed for use in software engineering. Visual SourceSafe (VSS) is used as a local repository for storing artifacts of projects, including documentation and source code. Bugzilla has been setup as bug tracking system; however, it is rarely used because the team prefers Excel worksheet for bug tracking due to its handiness. Local file servers are general-purpose sharing space for all members. Internal releases of projects and other artifacts are often stored on local file servers. VSS, Bugzilla and file servers can only be accessed by local employees who work at the Vietnam office.
Some application servers have been established at Japan site in order to exchange data between JP headquarters and VN team, including GIT repository, JIRA system, and file servers. These systems can be access by both Japanese staffs and Vietnamese development team via VPN. GIT repository is used for source code sharing, for example, storing software releases by VN team. JIRA is used for multiple purposes, such as issue tracking, change request controlling, requirement clarifying, bug reporting, project management, and so on. File servers are often used for exchanging large files that cannot be put on GIT or JIRA.
Thanks to this study, the author found out that the parent company has purchased several powerful software tools from Atlassian  such as Confluence, Fisheye, and Crucible, which can be linked to JIRA for use in software engineering. These tools are installed on servers of the headquarters in Japan, but they can be accessed from the VN company through VPN. Unfortunately, the VN team has no experience with these new tools except for JIRA.
18.104.22.168. Software development projects
Development of new products (or product series) is initiated by the parent company in Japan. There are a wide range of products, such as cameras, music players, mobile phones, home theaters, educational system, and many more. The rich-featured products of the company has led to the fact that various platforms have been developed, ranging from simple 8-bit CPUs to complicated 32-bit systems. Software development for these products is also diversified and it requires a large workforce. There are many types of software development. Some of them are closed to hardware such as device drivers and board support packages. The others are higher-level software development that is platform independent, such as network protocol stack or application development and porting. These software products may run on many platforms. They can run on server or desktop platforms such as Windows, Linux, or embedded targets such as Android, Qt, VxWorks, embedded Linux, or non-OS. Because multi-platform software is more and more popular, porting a software package to other platforms also is one of the most common tasks of the software development team.
Development of a new product in the headquarters is the close cooperation of multiple disciplines from three separated departments: mechanic, hardware, and software (see Figure 10). The mechanic department designs mechanical parts of products such as frames and covers. The hardware department is in charge of development of electronic circuits of products. The software department develops software for these products. The software department of the Vietnam subsidiary is a sub unit of this software department, working as a software-outsourcing center in Vietnam, thus its software products are depended on software projects of the parent company. The projects of VN company are sub-projects of the larger software development project in Japan, which often relate to new product development, feature expansion, porting to other platforms, and maintenance.
Figure 10. Cooperation of the three departments across countries to develop a new product
22.214.171.124. Software processes
A major number of software projects outsourced from JP headquarters to VN company follow traditional V-model. The activities in a project are often shared between JP team and VN team. In a typical V-model project, the development life cycle consists of five phases: (1) requirement, (2) design, (3) implementation, (4) testing, and (5) deployment. However, only approximately one-third of projects in Vietnam cover all these five phases. Because the real hardware platforms are rarely shipped to Vietnam, JP team normally undertakes tasks belonging to phase (1) and (5). This means that software requirement specifications are often written by the JP company. They also do integration of software developed by the VN team with the real hardware target system in Japan, and then perform acceptance tests. Meanwhile, most of projects in the VN company involve the activities of phase (2), (3), and (4), which are design, implementation, and testing. Figure 11 illustrates the frequent activities in software development projects of the VN company, which is bounded inside the red rectangle.
The software development in this company follows Waterfall-based model, thus the team cannot deliver the real software products at early phases of the projects, but very late at the end of the project. In fact, only documents and sometimes software prototypes are delivered to the Japan headquarters in requirement and design phases. Recently, the team has tried to enhance the processes by dividing the implementation phase into multiple shorter iterations in order to deliver earlier some features to the Japan team. The lengths of these iterations ranged from one to three weeks, which were quite similar to those of a Scrum's sprint. However, it typically took long time at the beginning of a project ' often in months ' to deliver the first working software, because the team had to complete the requirement and design documentation prior to coding. This means that the VN team still works with a traditional software development mindset.
Figure 11. Common software development activities in VN company (modified from )
126.96.36.199. Software engineering practices
The VN team applies different planning approaches depending on project sizes. In very small projects that take only one or two members working for a few weeks, upfront planning is often made with minimal changes. In these projects, developers estimate and make the development schedule individually, and then submit directly to the GM for review.
In larger projects, estimation and scheduling are made by all team members. During project planning, team members compromise with the others on task assignment; one can select his favorite features to work on. The team breaks down requirements in smaller units, which then are distributed to individual team members. Each individual estimates his assigned tasks in person-day or person-hour units. Then the team leader collects the estimation and holds a review meeting with all team members. The meeting may take hours of discussion. The final development schedule is sent to the GM and then to the headquarters for approval.
In a project, the team often creates two plans with MS Project software. The master plan is made at very first stages of project to give an overall view of the estimation to the JP team. This master plan can be adjusted in later phases. The detailed plan is completed later when requirements and technology obstacles have been clarified to some extent. Normally, the detailed plan is fixed during the life cycle of project, but sometimes it can be changed with reasonable explanation, and changes require approvals from JP team.
Project monitoring and controlling
Throughout life cycle of a project, team members update their progress in a shared schedule stored in MS Project format on VSS. However, this activity is not carried out on regular pace, e.g. daily or weekly. In addition, the team has no daily or weekly meetings for exchanging information among team members. Communication is relied on adhoc style, which means each person communicates with the others by peer talking. The team leader asks developers for their work status, summarizes and then reports to the GM. Therefore, sometimes project's progress could not be well aware by all members.
JIRA is often used for issue tracking in certain projects. Every team member is able to follow an issue posted on JIRA until it is closed. JIRA is also a helpful tool for bug tracking, because it releases the team from the burden of updating bug status with Excel worksheets. However, in small-scale projects, the tester still prefers Excel files for bug tracking.
JIRA is also used in change request management. Members of Japan team create new JIRA issue whenever they make a change and assign it to a member of the VN team, normally the GM or a project leader. JIRA allows both teams to track the change until it is completed.
Normally, the leader of a project integrates source code manually from local VSS repository, and then makes builds on his workstation. Finally, he put the deliverables on a local file server for testing. The tester gets the builds and performs testing. After testing is completed, if the build is good enough, the project leader delivers the release to the JP team by committing to GIT repository or copying deliverables to remote file servers. JIRA system can be used to notify the JP team about release. Documentation can be put on JIRA or file servers as well.
Requirement specifications can be written by either the JP team or the VN team depending on each project. In the latter case, the VN team captures requirements through emails from the JP team, or through primary documents sent from JP team. Once a requirement specification is completed, it must be approved by the right person of the JP team, and then the VN team can use it in next phases of development. Requirement specifications are often stored in MS Word documents in traditional style, i.e. requirements are described in user cases.
Because the software development activities of VN team mostly relate to design, implementation, and testing, there is a fact that VN engineers are in short of requirement engineering skills. The team lacks of resources who can write well requirement specifications. Normally, technical leaders, or even the tester, involve in this task.
In a project, the team often spends much time in early phases creating high level and low-level design specifications before coding. Architectural designs are quite useful for team members to have common understanding about the overall of software system, and thus enable them to implement the system correctly. However, some developers prefer writing low-level design documentation in very detailed way prior to coding. For projects with high level of technical uncertainty, the team often creates prototypes in design phases for feasibility study. These prototypes are then sent to the JP team for verification.
Coding and code integration
The VN team follows code-first scheme in implementation of all software products. The concept of test-first approach seems to be strange for them. Some engineers even said that he could not imagine how he could do testing before implementing.
All developers are familiar with unit testing techniques. However, there has been no common method for unit tests in the team, and rarely unit test documentation is made. In some urgent projects, developers did not carry out enough unit tests, which led to many bugs of internal release, thus the team leader had to make many internal releases. This practice consumes time for both manual code build and regression testing.
In all projects, there is no automated tool for building releases. Developers write code on their workstations, do unit tests and then commit to VSS repository. Code integrations do not follow regular paces. This means that developers can commit their code any time they want. There is also no procedure to check if a newly added code is valid or not prior to committing into the repository. In addition, code reviews are rarely carried out.
In this company, all tests are done manually. Developers are responsible for unit testing and integration testing, and the tester is in charge of writing system test plan and test cases, and then doing system testing for most projects. Automated testing has been never applied. Developers have very limited knowledge about automated testing. The tester is the only person who has experience with automated testing for desktop GUI applications in her previous jobs. However, she has never applied it in embedded software testing.
At the end of projects, the VN team carries out 'post mortem' sections to review about the project's achievement, issues, limitations, and to discuss solutions for improvement. In a project, the project leader initiates review sections by sending an email to ask all project members to brainstorm about above aspects in an Excel sheet. After a few days, the leader collects all the sheets from the team, synthesizes them into a single worksheet, and then holds review meetings. In review meetings, each member explains about the items he put in the brainstorming sheet, then other members discuss if the items is suitable or not. The review sections may be broken into multi-hour meetings because there may be many issues to be discussed. Finally, the leader collects all feedbacks and put into a post mortem report in MS Excel or MS Word format, which can be used as lessons learned for the next projects. The reports are stored in local VSS repository where all VN team members can access.
The outputs of these project reviews were useful for problem identification. Actually, during the course of writing this thesis, the author collected the reports of these project reviews as a source of data for problem analysis.
Dealing with hardware dependencies
Hardware dependency is a typical characteristic of embedded software. This means software developers always require dedicated hardware platforms for testing their software. For confidential reason, however, hardware platforms are not allowed to ship outside Japan in many projects, especially for development of new products or new technologies. Thus, dedicated hardware is rarely shipped to the Vietnam office. This is a major obstacle to outsource embedded software projects from the parent company in Japan to its subsidiary in Vietnam. The development teams of both sides have to find alternative solutions to minimize this challenge. There have been several solutions selected by the teams to reduce the impact of hardware dependency, but none of them is the perfect solution. For this reason, the teams decide which solution is best suitable for a particular project.
The first solution is that only part of software development that is platform-independent can be outsourced to Vietnam. Applications are mostly platform-independent, therefore these types of projects are often chosen for offshore development in Vietnam. However, some products have lightweight software frameworks, such as voice recorders or home theaters. These software frameworks are mostly platform dependent, and they cannot be split into smaller portions to form a sub-project for Vietnam side. Hence, this solution cannot be applied for all types of product development.
The second choice is that the VN team can do unit test (and integration test if possible) by utilizing alternative hardware that is similar to the real target. The alternative hardware may be general-purpose devices that can be easily purchased in Vietnam or shipped from Japan, for example, tablets or smartphones. The system testing is carried out by the JP team on the real hardware in Japan. This solution sometimes takes time for both sides to resolve integration problems because software developed and tested by the VN team on dummy hardware does not always work smoothly on the real system in Japan.
Remote debugging and testing has been selected as the third solution. After writing the source code, Vietnamese developers can do unit test remotely via remote desktop software. This testing is sometimes slow because of network lagging, and it requires a supporter on-site for setting up the test system. For this reason, this solution is rarely chosen in most projects.
The forth solution is sending Vietnamese staffs to work on-site in Japan. The staffs can work in Japan from the beginning of project, or they just come for testing after completing the implementation in Vietnam. This solution is expensive due to high expenditure of travel and accommodation in Japan. For this reason, this choice is only approved by the management when the project is urgent and stay time in Japan is short enough.
In embedded software projects that contain high volume of graphic user interface (GUI), the team often develops dual-targeting source code that can run on both desktop and the embedded target. For example, a Qt GUI application can run with full features on the target platform, but it can also run on Windows with limited features. This software architecture isolates hardware specific code and functional code, thus it allows the team to design, implement and test quickly on desktop before transforming to the target platform.
3.3. Problem analysis
3.3.1. Concerns from viewpoints of Japanese managers
In the VN company, it is hard to prove existence of a problem using empirical evidence, because there is no historical data of project management in the form of statistical figures. However, there is a fact that MBO assessment results of the VN software department have never reached 100% of the settings in recent years. In the last two years (2012-2013), the MBO scores were only 75% and 90% of the targets, respectively. Meanwhile, the results of MBO evaluation were decided directly by the GM and indirectly by the Japanese management of the parent company.
Thus, the author tried to get insights into Japanese people's perspective to understand how the GM and Japanese staffs evaluate the performance of the VN team. It would be best if the author could get feedbacks from Japanese staffs who acted as customer representatives in the headquarters. However, due to geographical distances and language barriers, it was impossible to do that. Therefore, feedbacks from customer's perspective were indirectly collected by interview discussions with the Japanese GM at the Vietnam office.
There were some findings when the author asked the GM about how the Japanese management assesses the VN team's performance. The GM explained that the parent company makes use of Kaizen management philosophy for continuous improvement of the organization. In a project, Kaizen management simultaneously measures three dimensions of customer satisfaction: Quality, Cost, and Delivery (also known as QCD). Among these, Quality is the most important one.
Figure 12. Three dimensions of Kaizen management
According to the comments of the GM, from the viewpoint of QCD measurements, Japanese managers were concerned about Quality and Cost dimensions of the software department team in the VN company. This was indicated by the fluctuated quality of software deliverables, and long development time spent for the projects. Thus, the objectives of MBO were marked as 'not achieved'. From the discussions with the Japanese GM, the author summarized the two issues as follows.
Issues 1: Quality uncertainty
According to the GM, a number of projects developed by VN team had unexpected quality. Common issues involve product quality can be listed as follows.
' In several projects, the team did wrong implementation of functionalities that is not as expectation of customers. This happened for both functional and non-functional requirements. The team sometimes implemented features that were not required, but left the others unimplemented. For example, an educational system required interactive inputs of many users from multiple distributed nodes in real-time. However, the team implemented it as a non-realtime system; inputs from users could only be updated after seconds. Finally, the team had to redesign the system architecture in order to support this feature. This took extra time to correct the mistake.
' Bug rates could not be controlled at final releases. The team has been adopting traditional V-model, thus the pressure of bug fixing is quite high at the end of projects. In some projects, when developers modified code for fixing bugs, sometimes they had not enough time for unit testing. Consequently, these modifications generated new bugs, and the team had to make many internal builds. Meanwhile, it took time for manual builds. Thus, the team had little time for system testing. These bugs were often detected by the tester; however, developers could not fix some bugs due to limited time. In some other cases, the tester did not have enough time for regression tests, thus identified bugs may re-occur. In fact, some of bugs were detected by customer representatives in Japan. Occasionally, the team even had to delay release dates because deliverables contain too many bugs.
Issue 2: Low productivity
According to the feedbacks from the GM and Japanese development teams, the VN team did not always have expected productivity. In certain projects, the JP teams complained that the VN team estimated too long time for development. In reality, some of these projects even had longer development time than estimated. In 2013, for instance, a project took approximately 150% of original estimated efforts to be completed. Thus, developers had to spend extra time for development at the end of projects, and releases had to be delayed.
Furthermore, during project review sessions, the VN team found out that some activities at early phases of projects took much time, for example, documenting requirements and designs, but the deliverables of these activities were rarely used. The team agreed that these activities might be sources of waste and need to be improved.
3.3.2. Identification of problems
From the reflection of the GM about the two issues of quality and productivity, the author discussed with the development team to find out the causes of these issues. Table 8 summarizes seven problems that were identified as the root causes of quality and productivity. These problems were synthesized from interview results, some of which were originated from project reviews that had been aware by the team in 2013 and 2014. The next sub sections give detailed explanation about each item in the table.
Table 8. Summary of existing problems
Problems Consented by team members
TL1 TL2 SSE1 SSE2 Tester
P1-Ineffective project management
Predefined processes could not be applied for small-size projects yes yes yes yes yes
Lack of project metrics yes yes yes yes yes
Misunderstanding between VN team and JP team yes yes yes NA NA
Mismatch of expectation between the Japanese GM and Vietnamese subordinates yes yes yes yes yes
Poor task synchronization among Vietnamese developers yes yes NA NA yes
P3-Lack of customer involvement
Lack of feedback from customers yes yes yes yes yes
Language barriers yes yes NA NA NA
P4-Improper practices of requirement engineering
Poor traceability of documents yes yes NA NA yes
Poor management of requirement changes yes yes NA NA yes
P5-Mistakes from manual operations
Inconsistent software tools yes yes NA NA NA
Manual code integration yes yes yes yes NA
Manual testing yes yes NA NA yes
P6-Inefficient practices of traditional software development
Low adaptability to changes yes yes NA NA yes
Much effort spent on documentation yes yes yes yes yes
Low code reusability yes yes yes yes NA
P7-Short of in-depth technical knowledge
Diversification of used technologies yes yes yes yes NA
Lack of encouragement for technical excellence yes yes NA NA yes
TL1, TL2: Technical Leaders
SSE1, SSE2: Senior Software Engineers
NA: the interviewee was not aware of the problem or had no opinion about it
188.8.131.52. Ineffective project management
All developers agreed that predefined processes could not be applied for many small-size projects, thus quality of software products sometimes were not well controlled. In addition, they consented that the team lacks of metrics to evaluate performance of projects.
Predefined processes could not be applied for small-size projects
The software projects of VN company are parts of larger software development projects in the parent company. The sizes of these projects are small, ranging from less than a person-month to several person-months. To support for managing these projects, the company has a set of predefined processes and workflows for each phase of software engineering, for examples, documentation review processes, or code review process. However, there have been no tools to enforce the team to comply with them, thus team members easily ignore them. In reality, these processes would be applicable in large enough projects rather than in very small-scale projects.
In large enough projects, one of the two technical leaders was often appointed as the leader for a project, who cared all activities of project management. The GM rarely involved in project activities, instead, he only acted as the communicator between VN and JP sides. The team leader organized and initiated project activities, such as estimation, planning, implementing, monitoring and controlling. He reported to the GM about the status of the project on weekly basis. Important decisions in the project, such as technical architecture or staffing, must be approved by the GM or even by the JP teams.
However, formal processes could not always be applied in all kinds of projects. In reality, there were very small-scale projects that only required one or two developers working for several weeks. These projects were managed in an adhoc style, without conforming to defined processes. The projects often started with assignments from the GM. He picked developers for a project and then directly assigned them development tasks, and developers reported directly to the GM. In small projects, development tasks were mostly low-level design, coding, and testing. In these projects, the team often disregarded these processes because there were not enough resources to maintain the processes. For example, developers design, write code and test independently, then deliver the products without formal reviews.
Lack of project metrics
The team lacks of metrics to evaluate the results of projects. There has no instrument for measuring the successfulness of a project so far. Sometimes SLOC (Lines of source code) was used in certain projects as a simple code metric to track the volume changes after each release. However, the tool used for counting SLOC is open source and it was not very precise.
The lack of metrics has caused some management issues. One of these issues relates to annual MBO process. In this process, the objectives of the corporate are cascaded to each department, and ultimately to every staff. The management encourages each individual to set up both quantitative and qualitative objectives. In fact, the software department can hardly make quantitative ones, because there is no quantitative instrument to measure the outputs of software development operations. As a result, all MBO settings of the software department and its individuals are qualitative. The consequence happens in the MBO evaluation process, in which the GM and each individual have no glue to decide how much an objective is achieved. Thus, sometimes software staffs do not satisfy with the low evaluation from the GM. This may lead to demotivation of employees.
184.108.40.206. Communication issues
During years of working in the VN company, the author has observed that there have been existing communication issues either among Vietnamese engineers or between Vietnamese and Japanese staffs. When discussing in interviews, the interviewees were more or less aware of these issues. Although these communication issues are not too severe to cause conflicts among individuals, it may reduce effectiveness of the team.
There would be several reasons of communication issues in this company. For Vietnamese staffs, language barriers may not be the problems. It would be that the Vietnamese team members have inefficient practices for effective communication. On the other hand, language barriers and cultural differences can be the major causes of poor communication between Vietnamese and Japanese. Thus, considerations about improving awareness of cultural differences and minimizing language barriers are necessary and will be discussed in the next chapter. The issues can be further described as follows.
Misunderstanding between VN team and JP team
There were some communication issues between VN team and JP team during implementation of certain projects that were reported by Vietnamese engineers in the interviews. Miscommunication happened when the Vietnamese developers could not understand unclear instructions of the JP team; however, they did not ask the JP team for clarification. For example, in a distributed project, the JP team implemented server-side services, and the VN team was in charge of client-side application. The server services and client application had to collaborate closely via HTTP protocol to exchange data. In early phases of development, the JP team provided a dummy service with just enough implementation of APIs so that the VN team could test their client application. The JP team did not give detailed instruction of how to use the service. Although the VN team did not understand the instructions of the Japanese engineers, they did not ask Japan side for further explanation. Thus, the server-side service did not work. The Vietnamese developers then created their own server service for testing. This resulted that the client software of the VN team could not be integrated with the server service in Japan. Finally, the two teams had to spend extra time for debugging and fixing the mismatched implementation.
Mismatch of expectation between the Japanese GM and Vietnamese subordinates
Job rotation policy results that the GM position is changed every few years, and it sometimes causes inconsistency in the operation of the software department. For example, a new manager who is not familiar with Vietnamese culture may embarrass his subordinates with new management style. This may lead to misunderstanding between him and the team, e.g. disagreement in the setting and evaluating of MBO process.
Furthermore, all Vietnamese software developers complained that requests and instructions of the GM were too generic to understand. On the other hand, Vietnamese employees hesitated to confirm with him when they did not well understand his requests. This led to disagreement of the GM about the results of assigned tasks.
Poor task synchronization among Vietnamese developers
Two interviewees, the technical leader TL2 and the tester, agreed that task synchronization of Vietnamese engineers was not so good. So far, the team had no rule to enforce team members to report their work on regular paces. Information exchange was based on peer discussion. It was common that owner of a task rarely shared his detailed implementation or even his existing problems until he was requested to do so. Instead, he kept silent about the task being implemented, and he only informed the actual progress after finishing the task. For example, a developer might not merge his code into the repository until he was asked by the team leader. Some tasks might take days or weeks to complete. Thus, this practice imposes high risks because problems may occur at the end of project, which is too late to be solved.
220.127.116.11. Lack of customer involvement
All Vietnamese staffs consented that they seldom had chances to interact with customers in Japan. From the perspective of the VN company, Japanese staffs who play the roles of customer representatives, are the only customers of the VN team. These customer representatives provide project's requirements to the VN team, and do the acceptance tests for the final deliveries. In some projects, distributed development teams that consist of both Japanese engineers and the Vietnamese engineers are established, however, Japanese staffs still can be seen as customer representatives to some extent.
In software projects, the communication between the VN team and these customer representatives is relied on written messages via email or JIRA system, or through weekly video conferences for verbal information exchange. However, because of language barriers, the two sides cannot directly communicate in a common language. Instead, the Japanese GM who lives in Vietnam plays as a liaison between the two parties. With this mechanism, communication distortion may occur. In addition, the VN team hardly receives frequent feedbacks from Japan side. In certain cases, the Vietnamese staffs complained that they rarely received feedback of the JP company about the results of projects that they participated in. Thus, they did not know that how good their fulfillment is.
In some projects, poor customer involvement led to misunderstanding of requirements, which could not be resolved until the end of projects.
18.104.22.168. Improper practices of requirement engineering
Not all team members involved making requirement documentation. For example, SSE1 and SSE2 had never written requirement specifications, thus, they had no idea about this. However, the technical leader TL2 and the tester had experience with requirement specifications. Thus, they listed out two common issues: traceability of requirement specifications and management of requirement changes.
Poor traceability of documents
Requirement specifications and design specifications are normally stored in MS Word format. When the team breaks down user requirements into smaller units for design and implementation, it is hard to trace back which sections of design or source code cover which requirement items. Thus, it is hard to check if a feature has been fully implemented or not. To solve this problem, the team attempted to attach traceability tables to map requirement items and theirs breakdowns to those in design documents. However, this takes time for one to match a pair of items, and when these documents are modified, updating of these tables also consume time.
Poor management of requirement changes
Another issue in requirement engineering of the VN team is management of requirement changes. In the beginning of projects that relates to new product development or feature extension of existing products, the team can rarely identify all requests from stakeholders. Thus, requirement specifications do not fully cover all necessary requirements, and some features are left undefined in these specifications.
In such a project, the VN team found that some of these undefined features needed to be implemented before the others. The implementation of these features could be out of the scope of project, and it could take more efforts to develop. However, the team did not inform customer representatives about the changes. Instead, developers decided themselves to implement the features without approval from JP team. This made the work volume increased. Consequently, release dates were delayed, and some features had to be shifted to later phases.
22.214.171.124. Mistakes from manual operations
The interviewees consented that up to now they had not utilized any automated tool in their software development projects. Developers solely do unit testing, code integration and software builds by hand. The tester also executes tests manually, even for regression tests that consume much time. These manual operations often generate mistakes, for example, missing pieces of source code during code integration, or bug occurrence because of insufficient regression testing.
The technical leader TL2 also pointed out that inconsistency of SCM tools between the VN team and JP team could also be a reason of manual operations. While Japan side makes use of a central GIT server for source code storage and JIRA system for bug tracking, the VN team prefers local VSS and Excel worksheet for the similar purposes in some projects. Thus, when source code is released to the JP team, team leaders have to get the source code from VSS repository and then manually merge it with that on GIT server of JP team. This task takes time and if releases are made in hurry, mistakes can happens.
126.96.36.199. Inefficient practices of traditional software development
Low adaptability to changes
The team adopted tradition Waterfall-based development model for years, thus, in their mindsets, requirements should be well defined before design and implementation. The TL2 and the tester, who had worked with writing requirement specification, consented that when undefined requirement items were found during development, developers tend to blame customer representatives in Japan, rather than making quick reaction to that uncertainty. Poor management of requirement changes is another issue that is explained in other sections.
Much effort spent on documentation
All developers said that they often spent lot of time making documents in early phases of projects, especially design specifications. This is a typical issue of traditional Waterfall model. This leads to the fact that project life cycles are longer than they should be.
The author performed a review on documentation of several typical projects and found out that the team had spent too much time on making documentation. Particularly in a project, which was developed in 28 weeks, the team spent over 30% of project time for making high-level and low-level design specifications. In another 16-week project, it took 38% of total time for this task. From experience of software industry, distribution of effort for design should limited up to 20% .
Although much effort was put on documentation, reference to them was rare because of inferior quality; for example, high-level design document did not show enough necessary standard views, and detailed design documents sometimes were unnecessarily written in a too detailed way. In addition, team members often changed design during implementation; however, they did not update design documents. For this reason, design documents were rarely used for maintenance, and developers often relied on source code for this purpose.
Low code reusability
All developers admitted that sometimes they did not re-use source code efficiently. For instance, in projects with high technical uncertainty or complicated GUI applications, they often created prototypes in design phase for feasibility study; however, some of these prototypes could not be reused in later phases, and they had to make new source code for the same functionalities that had been implemented in the prototypes.
188.8.131.52. Short of in-depth technical knowledge
The parent company develops a wide range of products that are based on diversified collections of technologies. The software projects outsourced to the VN company can involve any type of these technologies. However, the resources of the VN team are limited. Thus, Vietnamese developers often jump from a technology to another in short time. Consequently, developers know a broad set of technologies; however, they hardly master these technologies in depth. Meanwhile, embedded software development requires high skilled engineers. In certain projects, the team had to struggle with technological challenges, which led to longer development time.
It is common that a developer works with Android platform for a few months, and then he is assigned to another project with a different platform and programming language. After one year or so, the management may move him to another Android project. The developer has to learn almost from scratch bundles of things about Android again, because he almost forgets what he has learned. Nowadays, technology changes rapidly, thus he has to catch up with the latest information, which may take time to do.
Lack of in-depth technical knowledge may also be consequence of low motivation of staffs for technical excellence enhancement. This demotivation would be caused by inappropriate performance evaluation, which is addressed in the other sections about project metrics and MBO evaluation. In addition, negative motivation of staffs may be the influence of management style and corporate culture as well. The company values seniority and employee's loyalty, however, it lacks of encouragement for technical excellence, as a dimension to measure individual's competency.
3.3.3. Lessons learned from previous adoption of Scrum
The VN company once applied Scrum practices in a pilot project, but it was unsuccessful adoption, and the team continued with traditional software development methodology. Analyzing the causes of this failure can be precious experience to avoid similar mistakes in future.
Several years ago, the management decided to adopt Scrum in a small software project. The project team was organized as a distributed team (see Figure 13). This pilot project was actually a similar case of 'Totally Integrated Scrums' model mentioned by Woodward et al. . Both Japanese and Vietnamese members participated in the project. The Product Owner (PO) role was played by a Japanese project manager locating at Japan site. The Scrum Master (SM) was the GM in Vietnam. Development team consisted of two Vietnamese engineers working in Vietnam, and some Japanese engineers working in Japan. The PO and Japanese engineers were incapable of speaking English, but they could read English documents to some extent.
Figure 13. Old Scrum team structure and roles mapping
Several Scrum practices were used in the project. Firstly, the product backlog was created and prioritized by the Product Owner in Japan headquarters, and then it was sent to Vietnam and translated into English by the GM. The sprint backlog was created by the Vietnamese team from the original items in the product backlog. Both product backlog and sprint backlog were stored in Excel worksheets. The project schedule was made in MS Project format.
Daily Scrum meetings were carried out from the beginning of the project with participation of the SM and two Vietnamese engineers, without the presence of team members in Japan site. The stand-up meetings were hold for a few first days, but Vietnamese developers soon felt bored with these meetings because they did not have much to say; team members reported the same things repeatedly in the meetings day after day. Another fact was that team members were anxious about stand-up meetings, as they thought that the management wanted to monitor their daily behaviors tighter. The GM then decided not to hold daily 15 minutes meetings anymore; instead, the team members sent report by email at the end of day to all members of the VN team. The reports also addressed the three questions of Scrum daily meetings: what tasks had been done, current issues, and plan for the next day.
In the beginning, the Vietnam team planned to have sprint review meetings at the end of each sprint. However, this never happened.
Analysis of root causes
Two main causes of this unsuccessful Scrum adoption are identified as follows.
The principles of agile methodology were ignored
Scrum meetings require all team members to participate, including the PO because he is also a part of the Scrum team . The absence of the PO in this case led to the fact that the team could not receive proper feedbacks from customer representatives, thus the 'customer collaboration' principle was ignored.
Even if the PO had joined the meetings remotely, the team would have overcome two obstacles of cross-cultural and distributed environment: language barriers and the lack of face-to-face communication. Firstly, the PO could not communicate in English, so he had to rely on the translation of the GM, who was playing Scrum Master role, to understand what the Vietnamese staffs reported. Secondly, while direct face-to-face conversations carry both verbal and nonverbal cues, remote meetings via video conferences may not convey the complete meanings of a conversation, because only verbal messages may be transferred. This would cause incomplete understanding and would be a waste of time.
Replacing stand-up meetings with email messages may have similar consequence, because direct communication in a stand-up meeting contains verbal messages and non-verbal signs, and it can carry more information than written messages. Obviously, the team ignored a very important principle of agile, which is 'individuals and interactions'.
Lack of training and coaching
Because Scrum concepts are substantially different from traditional software development, training and couching at the beginning of agile adoption is crucial for success [4, p. 32]. However, when the management decided to apply Scrum practices in this pilot project, no training of agile fundamentals or Scrum method was provided to the VN team. Prior to the kickoff date of this project, the GM sent a short email to inform the plan and daily meeting schedule, and that was all. The team members were expected to search information about Scrum on the Internet beforehand. Meanwhile, because the tight schedule, developers rarely had enough time to understand about agile principles as well as Scrum practices. Therefore, some important principles of agile development could not be applied correctly. For instance, the meaningful purpose of Scrum daily meeting was misunderstood, which led to non-cooperation of team members.
3.4. Agile readiness analysis
A comprehensive analysis about as-is state not only helps reduce risks during agile adoption process, but it also provide persuasive evidence to get management buy-in and support [28, pp. 44'48]. This section analyzes the possibility and feasibility of agile adoption in the company. The analysis discusses which as-is practices can be kept unchanged and what should be altered for agile adoption. In order to do this, the status quo of the organization is further assessed toward success factors of agile adoption that have been addressed in the literature review in chapter 2.
Management's support and constraints
This case study involves applying new project management practices for a small business unit in a large and well-established corporation. Therefore, getting the agreement from management for changing to agile software development is probably the most important task.
There has been evidence that the corporation advocates continuous improvement through corporate culture. For example, Kaizen management has been applied. Another fact is that Japanese managers once attempted to adopt Scrum practices for enhancement of software development in the Vietnam branch, as described in the previous section. This support from top management is important for agile adoption, because it indicates that the company has already has culture of promoting new ideas and willingness to changes, which is a success factor for agile adoption .
The GM of software department also supports for changes toward agility, as long as these changes are well controlled and they can bring benefits to the company. He accepted the proposals to try some new agile practices in software development. Furthermore, he assisted the author in setting up environment for agile practices, for instance, getting administrative permissions from the headquarters for using software tools such as Confluence, JIRA, Fisheye, GIT and SVN.
Although the organization advocates continuous improvement, there are constraints from corporate regulations. The GM suggested that changes should be limited within the VN software department, and they should not negatively influence the outputs of current software projects, as well as operations of other business units. Another constraint relates to equipping new tools required for agile processes. For example, purchasing new software needs approval of the right management level. These tools must comply with business rules of the corporation, i.e. software must be either licensed or open source.
Some authors in the literature review suggest that hiring external coaches can ease agile transition process. However, the GM recommended that the software team should learn and try adopting agile practices by its internal team members. The reason was that the company had no budget for hiring agile experts outside. In general, the management prefers self-study by the team through on-the-job-training, which is a trait of corporate culture of the company.
Environment for agile practices
The company provides proper working environment for agile practices in either collocated or distributed project teams. Equipped facilities can satisfy the necessary conditions for agile practices in collocated teams. For instance, open workspace is good for daily face-to-face communication, stand-up meetings and pairing practices. Besides, other infrastructure such as video conference system or communication software tools can be used for remote communication in distributed teams, such as planning, review or retrospective meetings.
Regarding software tools, the VN team has been familiar to JIRA for workflow control and issue tracking, as part of the as-is practices. Other powerful software tools needed for agile practices from Atlassian  - such as JIRA Agile, Confluence, Fisheye, and Crucible - are also in place. These tools can be used in practices such as requirement engineering, project planning and controlling, tracking workflows of code review, and knowledge sharing. Thereby, cost of transition to agile can be reduced dramatically. It is just about how the team members leverage these tools in software development. The next chapter will provide detailed discussions on how to utilize existing infrastructure and tools in agile practices.
The development team
Self-organizing team is a condition required by Agile Manifesto. In a self-organizing team, the management decides what goal to achieve, but not how to do; the team members are collectively responsible for the accomplishment, and they organize themselves to achieve it [4, p. 72]. From the practices described in the previous sections, it can be said that the VN team is quite closed to a self-organizing team.
The team is also satisfy the requirement of a cross-functional team, in which all necessary disciplines necessary for product development are included. There are different levels of technical skills in the team, which can help the team to do task assignment with ease, e.g. low critical tasks can be implemented by junior engineers, and tasks that are more difficult are for the superiors.
The team has practices that are good for agile software development and they can be reused. For example, team members often make use of face-to-face communication among collocated members, or important information is further confirmed by written messages. In addition, the team is familiar to practices in distributed projects such as remote meeting via video conference system, remote debugging, or making use of JIRA system for exchanging information.
However, the findings from previous sections indicate that the team is influenced by traditional software development mindset. Therefore, changes are necessary to make it become a more agile team, for example:
' Reducing the role of technical leaders
' Team members should work beyond their specialties
' More regular communication on daily basis
' Reducing documentation making by shifting written requirements and design specifications to verbal messages
' Delivering working software for demonstration at the end of shorter iterations
In addition, team members are at low level of motivation toward performance excellence. This may be the impact of corporate culture. Besides, the developers may have not enough time for self-improvement, because they are too busy with assigned tasks of software development projects. Thus, actions should be carried out to make the team more motivated. The proposals for changes will be further discussed in the chapter 4.
Agile requires closed collaboration between development team and its customer (or customer representatives). The VN team in this case study has few opportunities to do that because of organizational structure, language barriers, and cultural differences. Thus, enhancement in customer involvement should be considered and will be addressed in the chapter 4.
Dealing with challenges of embedded software development
One concern of agile development is that working software must be released at the end of iterations. In this case study, the development team already has certain alternative solutions to minimize impacts of the lack of real hardware platforms in embedded software testing. Therefore, hardware dependency of embedded software development may not affect too much on agile adoption in this company. This means that the team can manage to deliver early releases for demonstration at the end of iterations.
4. Proposals for enhancement
This chapter proposes solutions to enhance software development practices of the company in this case study. The chapter begins with discussion about selecting suitable agile practices to resolve the existing problems that are identified in chapter 3. Next, customization of agile practices, including team structures, processes, and tools, is described. Some further consideration about improvement of knowledge sharing and communication is also discussed. Finally, a roadmap of agile adoption is outlined at the end of this chapter.
4.1.1. Resolving the existing problems with agile practices
Once root causes of an issue are identified, effective solutions can be proposed and implemented to resolve the issue . In Chapter 3, seven problems have been identified as the root causes of quality and productivity issues of the VN team. This section discusses how agile practices can eliminate these root causes, as part of the total efforts to improve the performance of the VN team.
P1-Ineffective project management
From the findings of as-is software development, it can be seen that the software development in the VN company is influenced by traditional Waterfall-based methodology. Therefore, the team has faced typical issues of traditional method such as low response to changes, or long time-to-market. In addition, the team has attempted to apply heavyweight processes for very small-size projects. This is impractical because the team does not have enough resources to enforce its members to apply these formal processes. Consequently, quality of software products has been affected because some steps of quality control are ignored.
Meanwhile, agile methodologies are known as lightweight software development approach. They encapsulate bundles of simple processes and best practices, which can be suitable for small teams. If these practices are well customized for the team in this case study, some problems of project management can be solved.
Agile promotes closed communication on regular paces among project team members through practices such as daily meetings, planning meetings, retrospectives, pair programming, etc... Therefore, an effective agile team can avoid problems regarding communication such as task synchronization and misunderstanding among team members.
P3-Lack of customer involvement
Agile Manifesto points out that customers play very important roles in software development. Particularly, Scrum defines a dedicated Product Owner role that represents customer in project teams. Besides, agile development divides a project into shorter iterations with demonstrations of working software products at the end of iterations, from which customer's feedbacks can be collected for improvement. Applying such agile practices can help resolve the problem of customer involvement.
P4-Improper practices of requirement engineering
Scrum and XP have lightweight techniques such as using simple user stories to capture customer's requirements in product/sprint backlogs. These practices are aimed to deliver software products as early as possible, even in the first iterations. If applying these techniques with proper tools, such as JIRA Agile and Confluence, the team can resolve the problems of requirement management, for instance, traceability and change control.
P5-Mistakes from manual operations
XP practices such as TDD and continuous integration can reduce mistakes of manual operations. Automated testing is a popular technique in TDD; it can help testers to perform regression tests effectively with less time. Thus, they can concentrate on other tasks such as testing new features of system.
P6-Inefficient practices of traditional software development
Some existing problems can be eliminated automatically with a proper adoption of agile methodologies. By following agile principle of iterative development, a project can be divided into smaller iterations (or sprints in Scrum), which enable faster adaption to changes, thereby eliminating the issue of 'low adaptability to changes'. Evolutionary (or incremental) development is another characteristic of agile, which ensures that the software product evolve through iterations, therefore, code reusability is maximized. Besides, agile methodologies themselves disregard documentation; instead, they encourage verbal communication and closed collaboration of team members. Thus, the issues of 'much effort spent on documentation' can also be dismissed with an agile team.
P7-Short of in-depth technical knowledge
Pair programming is a good way to improve quality of software product. Besides, it is a training instrument. Pairing technique can be used to transfer technical knowledge from an experienced engineer to another one, thus, it can minimize the gap of technical knowledge required for projects of the company.
In addition, enhancement of as-is knowledge transfer sessions should be considered for effective knowledge sharing, for example, organizing monthly knowledge sharing sessions which are linking to annual MBO objectives to motivate employees, and making use of Confluence as knowledge management system.
4.1.2. Selecting agile practices
The findings of literature review in chapter 2 disclose that Scrum and XP are the most popular agile methods in embedded software development. Therefore, the author focuses on selecting best practices Scrum and XP to apply for this case study. These practices are further tailored to be applicable for different kinds of projects of the company.
Scrum practices for project management
Scrum provides a framework for project management with simple practices. Scrum practices, such as daily stand-up meetings, sprint reviews, and sprint retrospective, can be proper choices to enhance collaboration of Vietnamese developers in this company. For instance, Scrum stand-up meetings can reveal the potential issues on daily basis, thus, corrections can be carried out as soon as possible.
In addition, the organization in this case study has equipped powerful software tools of Atlassian1F that well support Scrum practices. Tools that are already in place include JIRA, JIRA Agile, Confluence, Fisheye, and Crucial. These tools can be used to enforce team members following defined processes. For example, JIRA Agile and Confluence can be used for requirement engineering or project management with product backlogs, sprint backlogs, Scrum boards, etc... These practices are not very complicated, and they are applicable for the VN team with few hours of training. Thus, the team can easily make use of Scrum practices in software development with the support of these tools.
On the other hand, there are concerns about adopting Scrum practices for different project sizes. In the VN company, there are very small-scale projects that require only one to two developers to work on. In this case, when volumes of projects are very small, applying Scrum in these projects would not be a right choice because Scrum is more suitable for larger teams with three or more developers, as pointed out by Sutherland et al. 2F . Therefore, Scrum framework should be tailored so that it can be applicable in software development projects with team sizes of one to more than three members. A customization of Scrum practices is further discussed in the next sections.
XP practices for technical excellence
Scrum does not define any technical practices for software engineering. Meanwhile, XP contains a set of practices that can be used by a single individual or by a small group to improve technical excellence. For this reason, XP practices should be adopted to complement the missing part of Scrum framework.
Another reason to choose XP practices is that software development activities of the VN team involve mostly technical tasks of design, coding and testing, as revealed in Chapter 3. XP has practices dedicated for technical excellence, such as simple design, refactoring, pair programming, TDD and continuous integration. For this reason, it would be appropriate to make use of XP practices for technical improvement.
4.1.3. Summary of solutions
From the above considerations, the proposed solutions based on Scrum and XP practices are summarized in Table 9. The details discussions about implementation of these solutions are further discussed in the next sections.
Table 9. Summary of solutions to resolve existing problems
Problems As-is practices/issues Proposed solutions
P1-Ineffective project management ' Inconsistent mgmt. style for projects with different sizes
' Predefined processes could not be applied for small-size projects
' Adhoc communication without supported by tools
' Upfront planning
' No project metrics ' Replace heavyweight processes with lightweight practices of Scrum:
o Adaptive planning
o Product/sprint backlogs stored on JIRA Agile
o Project report: supported by JIRA (burndown charts)
' Leverage software tools purchased from Atlassian for seamless operation in software engineering (JIRA Agile, GIT/SVN, Bitbucket (Fisheye/Crucible))
' Establish project metrics
P2-Communication issues ' Poor task synchronization among Vietnamese developers Misunderstanding between VN and JP teams
' Expectation mismatch between the Japanese GM and Vietnamese staffs ' Enhance collaboration among Vietnamese developers with pair programming and peer reviews
' Make use of central document management for knowledge sharing (Confluence)
' Improve communication between Vietnamese and Japanese staffs by using proper language to minimize language barriers, and by awareness of cultural differences
P3-Lack of customer involvement ' Lack of customer feedbacks
' Language barriers with customer representatives ' Set up localized 'customer proxy' role in the Vietnam office
P4-Improper practices of requirement engineering ' Poor traceability
' Poor change management ' Use Confluence as central document management system, requirement specifications are stored as Confluence pages
' Apply agile style techniques with user stories, each story links to a JIRA issue or epic
P5-Mistakes from manual operations ' Inconsistent software tools
' Manual code integration
' Manual testing ' Make use of central GIT/SVN source code repository that links to JIRA
' Replace manual operations with automatic ones
o Continuous integration with Bamboo, Jenkins, or Maven
o Automated testing with xUnit, Fitnesse
P6-Inefficient SW development practices ' Low adaptability to changes
' Low code reusability
' Extensive efforts spent on documentation ' With a proper agile adoption, iterative and incremental development can help resolve this problem
' Make use of simple design and refactoring
P7-Short of in-depth technical knowledge ' Low motivation of staffs (impacted by corporate culture)
' Technology diversification ' Make use of pairing technique, TDD
' Enhance as-is knowledge transfer sessions
4.2. Customizing Scrum and XP practices for software development
4.2.1. Proposal of Scrum team structure
As figured out in chapter 3, there are two types of project teams in this company: collocated and distributed teams. This section discusses organizing Scrum teams for these two types of project teams. In general, the proposed structure of Scrum team is considered for large enough projects. However, some Scrum practices can be applied for very small teams of one or two developers, and will be discussed later in the following sections.
Although some software projects in the company have been organized as distributed projects across Japan and Vietnam, a distributed project team can be seen as two collocated teams: a team in Japan headquarters and a team in Vietnam subsidiary. This viewpoint can minimize some challenges of agile adoption in distributed environment, because agile practices work best with collocated teams where all members stay in the same physical location.
Publications gave recommendations about applying Scrum method of distributed environment. Woodward et al. discussed three popular Scrum models for distributed projects: Isolated Scrum, Distributed Scrum of Scrums, or Totally Integrated Scrums [41, p. 12]. For this company, the project teams should be organized as 'Distributed Scrum of Scrum' model. This is recommended by the Scrum Alliance as best practice for distributed teams . In this model, a distributed team is organized as a group of several smaller Scrum teams, each of which is collocated and cross-functional.
This Scrum model can fit with both collocated and distributed projects in this case study. In a collocated project that requires only Vietnamese developers, the team in Vietnam can make use of Scrum practices as if it is an isolated Scrum team. In a distributed project, a project team in Vietnam can be organized as an isolated Scrum team, and the team in Japan can be considered another isolated Scrum team. This team structure helps minimize the changes of as-is practices which are beyond the scope of the VN company. Meanwhile, effective collaboration of the two remote teams can be ensured with Scrum-of-Scrum meetings. The structure of these Scrum teams is depicted in Figure 14.
Mapping Scrum roles
Product Owner (PO)
Let us have a further analysis of the previous unsuccessful Scrum adoption (in chapter 3) regarding mapping Scrum roles. In the previous Scrum adoption, the Scrum Master was the GM, and a member of Japanese team, who worked in the Japan headquarters, played the PO role. In such a distributed team, the Vietnamese engineers had few chances to communicate on daily basis with the PO, because of both distance and language barriers. This led to the fact that the team could not receive frequent feedbacks for their deliverables at the end of each sprint.
On the other hand, the development team of VN company seldom has chances to interact with end user, because its only 'customer' is the Japanese staffs of the parent company in Japan, who acts as customer representatives. However, these remote representatives cannot join daily activities in an agile project. Meanwhile, agile adoption requires frequent feedbacks from customers for successfulness.
Figure 14. Structure of project team: two isolated Scrum teams in Vietnam and Japan
For these reasons, another way of mapping Scrum roles is proposed. A person who belongs to VN company should play the role of 'localized customer proxy'. This customer proxy role is in charge of gathering requirements from internal and external sources and put them into high-level documentation (with user stories, for example). The team can use these documents as the basis for development. Thereby, this customer proxy role can help reduce misunderstanding of requirements. This practice can contribute to enhancing customer involvement, which was applied in some case studies found in literature . It also improved morale of the team because when developers received daily feedback from the customer proxy, they felt their 'sense of accomplishment' on the project .
In a Scrum team, this customer proxy is known as the Product Owner. For this case study, the Japanese GM should play the PO role. This Scrum team structure can eliminate the problems of language barriers in the previous adoption of Scrum, because the PO now is bilingual and collocated with the development team, thus the whole team can makes use of face-to-face discussions in English in daily meetings.
This structure also minimizes changes in the organization. In the as-is process, the GM has been acted as a communicator between the VN team and the team in Japan. Thus, the GM would be most suited to PO role because he is the only member who can communicate well in both Japanese and English with Japan team and Vietnam team, and hardly other members in the organization can replace him. It should be the best case if the GM can take over the PO role, however, in projects that he may not be available for this task, another Vietnamese member, such as technical leader, should be a substitute.
Scrum Master (SM)
In a project, a Vietnamese developer who knows well about Scrum should take over the role of Scrum Master. It should be beneficial to point out that not only can technical leaders play the Scrum Master role, but also any Vietnamese team member who has good interpersonal skills can do that. It is because technical expertise is not the only skill of a Scrum Master; he must have good people skills at well [4, p. 121]. In addition, a Scrum Master should not be decision-maker, instead, he should be a guide of a self-organizing team, in which decisions are made by individuals [4, p. 121].
4.2.2. Proposed processes and practices
The overall process of customized Scrum framework is depicted in Figure 15. The detailed process inside a sprint is shown Figure 16. In both diagrams, the processes involve the three roles: customer proxy (Product Owner), internal agile coach (Scrum Master), and developers. Comparing to a standard Scrum framework, there are some variations in the proposed practices to suit this case study as follows.
The Product Owner role can be shared by two people in a Scrum team. Normally, the PO role in a Scrum team is played by a single person who makes product backlogs, in which requirements are stored as user stories. In this case study, the GM probably is the best person for the PO role. However, he has to fulfil multiple tasks (such as management affairs, Japanese translation, and so on) thus, he may not have enough time to write detailed requirements (e.g. product backlogs with user stories). Therefore, another Vietnamese team member can support him to do this task. This team member can get high-level requirements from the GM, then break down them and write user stories in backlogs on Confluence/JIRA Agile. In the next step, the GM can check and approve these backlogs. In other words, the PO role can be shared between the GM and a Vietnamese team member.
There may be one Scrum Master for multiple Scrum teams. Typically, each Scrum project has a Scrum Master played by a single person. However, in the VN team, we do not have enough resources to allocate an independent SM for each project. Because project sizes are small and there are only few projects running at a time, a Vietnamese employee who knows well about Scrum practices can act as an 'internal agile coach' across projects. This coach plays the SM role for multiple running Scrum projects, and he should reserve his time to monitor project teams regarding Scrum practices and provide instructions for them.
Daily stand-up meetings can be omitted in very small teams. In very small projects with only one or two developers, Scrum stand-up meetings may be unnecessary. However, developers and customer proxies should have clear communication on daily basis, either via verbal discussion or via written messages with proper means such as JIRA, emailing or chatting. Pairing activities, such as peer reviews of source code and documentation, are also means for two developers to exchange information. For projects with three developers or more, the team should do Scrum stand-up meetings.
Software development process is enforced with Atlassian's software tools. For instance, customer proxies can write requirement specifications in product/sprint backlogs using Confluence. In a sprint, developers can break down sprint backlogs into JIRA issues for status tracking of implementation and testing. Source code branches can be linked to JIRA issues using Bitbucket or FishEye as well. This process is illustrated in Figure 16, and the practices in this process are further discussed in the following sub-sections.
Figure 15. Overall software process
Figure 16. Process in a sprint
184.108.40.206. Project management
Scrum method recommends sprint lengths from one to four weeks; in reality, two-week iterations would be the most popular. However, this company has many small-size projects with just few weeks of development; thus, iteration length should be shorter. In general, the team should consider iterations of one to two weeks for very small projects to deliver faster working software for demonstration.
As an agile team, the project team should replace upfront planning by adaptive planning (or just-enough planning as depicted in Figure 17). It means the team does planning at the beginning of a sprint, which is just enough for development in the sprint. All team members should contribute to the plan in planning meetings, e.g. estimation of a user story should be based on inputs from all individuals in the team.
Requirements can be captured in product backlogs and prioritized by customer proxies. Customer proxies are in charge of selecting user stories from product backlogs and put into sprint backlogs for development. During development, product and sprint backlogs can be updated when there are changes of requirement or scope.
JIRA Agile can be used for splitting requirement items stored on Confluence pages into JIRA epics and issues. Besides, estimation with story points can be entered in 'Plan' mode of JIRA Agile. The team can map story points to person-hour or person-day units later. There is no common way to do this mapping, thus the team can choose a value and then refine it through iterations. It is important that all team members understand about the same conversion method, for example, one story point equals one person-hour.
Figure 17. Illustration for 'Just-enough planning' 
In the as-is process, the GM and Vietnamese technical leaders meet with representatives of JP teams once or twice per week via video conference. For urgent projects, these remote meetings are made every day. These meetings can be reused as Scrum-of-Scrum meetings in the new Scrum team structure to minimize the impact of changes in the organization. The PO and SM of VN teams should attend these meetings to meet with the representatives of JP teams. The only difference is that more regular, daily-based Scrum-of-Scrum meetings are required in this new Scrum model.
Sprint review and retrospective
The team is already familiar to project reviews at the end of each projects. Therefore, Sprint retrospectives can be carried out in similar way, but at the end of every sprint. At the end of iterations, working software or demos on simulation environment should be shown to the JP team for receiving their feedbacks in Sprint review. Sprint retrospectives can be carried out right after Sprint reviews.
The VN team lacks of metrics for project measurement. Consequently, some issues such as mismatches of MBO settings and evaluation have been occurred. Thus, it is necessary to define project metrics as part of solutions to resolve the existing problems. Project metrics should be defined and committed by all members of the VN team. This should be used as quantitative objectives of annual MBO settings. In addition, the metrics should be simple to be applicable in different types of projects in the company. A metric can be very simple ones, for example, 'the number of features delivered per developer', however, it should reflect that an objective is achieved or not [4, pp. 440'441]. Another example of simple metrics is 'number of customer-reported defects reported', which can be normalized based on number of lines of codes or person-months [4, p. 430]. For the next steps, simple metrics can be put into balance scorecards to measure multiple perspectives of projects [4, p. 438].
220.127.116.11. Requirement engineering
Scrum practices of requirement engineering should be adopted, for example, requirements are recorded with user stories in product/sprint backlogs, to release the burden of writing lengthy requirement specifications. One can leverage Atlassian's Confluence to store requirement specifications. Confluence can be integrated with JIRA as a handy solution for requirement management. This system helps track statuses and versions of documents, as well as control requirement changes effectively. Furthermore, this system can link to source code repository to ensure traceability among requirement specifications and source code . Requirement engineering with Atlassian tools can be summarized as follows:
' Requirement items are written in user stories, each of which can be linked to a JIRA issue or epic. These JIRA issues in turn can link back to requirement document pages stored on Confluence.
' JIRA issues can be linked to GIT (or SVN) source code repositories via Bitbucket or Fisheye/Crucible. Each issue can be mapped to a code branch on GIT. In addition, JIRA users can directly create GIT branches from JIRA dashboards. Code commits on GIT are notified to JIRA dashboard as well to remind the users. Thereby, authorized JIRA users can review code modifications and then approve or reject the changes.
XP practices such as simple design and refactoring can help reduce efforts of making documentation in design phase. In XP, source code files themselves are also considered a kind of documentation. Therefore, more efforts should be put into optimizing the source code. Developers should know how to write optimal code not only for efficiently using system resources, but also for readability, maintainability and consistency. This can be fulfilled by following coding conventions and carrying out careful reviews in designing and coding .
Design documentation should be kept as simple as possible, just enough so that the team can concentrate on producing working software products for demonstration in first iterations. The design then can be enhanced by refactoring at the end of sprints or projects. Metaphors can be built during refactoring as well.
Architectural design should be defined by developers who have experience with related domain and technology. Architectural design documents are necessary to outline the system overview. These design documents guide the team to implement the right source code.
Design documentation should be stored on Confluence system for future knowledge sharing. In Confluence, design documents can be linked to JIRA issues for traceability as well.
18.104.22.168. Implementation and testing
Improving team collaboration with pairing practices
While Scrum stand-up meetings are useful for high-level communication among many team members on daily basis, pair programming is a proper practice for low-level task synchronization between two developers. This practice can improve quality by reducing defect rates, and accelerate knowledge transfer between the two team members, particularly for new members .
For this reason, pair programming should be applied for the VN team. The team can leverage the current infrastructure and facilities to start pairing practice. For instance, workspace of each staff is large enough for two developers in a same desk, and there are two monitors on each desk, so one developer can use them for pairing activities such as pair programming or peer reviews. It is just the matter of how developers learn and practice pairing technique.
It may be hard for developers who are not familiar with pair programming at first. Thus, it can be beneficial to follow recommendations from literature. A pair should consist of an experienced developer and a younger or less skilled one, because the latter can quickly capture new knowledge such as system architecture or programming technique from his surpassed partner . Besides, this activity also contributes to team building and communication enhancement .
However, pair programming takes more time than traditional coding. Therefore, experienced developers may not have a few hours per day to participate in pairing sessions. Another challenge is that it may be hard to find the right people for a pair in this practice, because it highly relies on member's personalities and experience. It is the sense of managers and team leaders to select the right people in pair programming .
According to Greene's recommendation , in cases that pair programming cannot be applied due to time limitation, it should be used in certain points of the development process, such as in detailed design or when writing the first lines of code, or in debugging and bug fixing.
Similar pairing technique should be applied for reviewing documentation. In the as-is process, important documents - such as requirement specifications or design specifications - need to be reviewed by the team and then approved by the right person. To save time in team reviews, it makes sense to have peer reviews of these documents in advance so that mistakes can be detected and corrected before team reviews. In this process, a document can be written by an individual, and then it should be reviewed by someone else. In other words, peer review should be considered a lightweight process to improve quality of documentation, and this process should be defined as part of project management framework.
Peer reviews can be carried out in projects with only one developer as well. In these projects, the Japanese GM is often the approver of project's deliverables. However, he seldom does low-level technical tasks, such as doing detailed reviews a software design specification or source code. Thus another developer, who may be working in another project, should help the developer to do peer reviews for documentation and code. The reviewer should allot small part of his total efforts (e.g. 20%) for review tasks.
Test-driven development (TDD)
TDD is highly evaluated by agile practitioners. In embedded domain, however, TDD may take much time and effort to set up for particular platforms and programming languages. It is also involve changing the team's mindset in software development. Thus, this practice should be further considered in later phases of agile adoption process.
Frameworks such as Fitnesse and xUnit can be used for TDD practice, as mentioned in chapter 2. However, the details of how to implement TDD should be further investigated through self-study activities of the VN team. Research on CI and TDD can be assigned to individuals as study topics for knowledge transfer sessions.
Continuous integration (CI)
The team should consider applying continuous integration practice with Atlassian's Bamboo tool for seamless operation. However, this tool is not available in the company and the team needs approval from the management to purchase. Another well-known CI tool is Jenkins , which is open source software. Jenkins can be integrated with JIRA system as well .
XP suggests that the team should adopt a single coding convention. However, in a small team there is no resource for controlling coding convention, and developers also may not have enough time to correct a piece of code to conform with coding convention. Therefore, conforming to coding conventions is considered part of programmer's expertise, which means programmers should know how to follow common coding standards when writing their code.
4.3. Other considerations
4.3.1. Enhancing knowledge learning and information sharing
There is a fact that both embedded domain and agile teams require high skilled engineers, however, some Vietnamese developers in this team are short of in-depth technical skills which are necessary for certain kinds of software development projects of the company. Therefore, enhancements of technical skills should be considered. The development team should focus on improving their technical knowledge and skills more frequently, either by attending training classes or by self-studying. The management should support engineers by allotting them more time for learning rather than keeping them busy with projects.
Information sharing is important in agile environment. Both new information and problems should be shared through various means, for example, daily meetings, reviews, intranet, wikis, or internal training sessions [4, p. 32]. In the as-is practices, the team already makes use of following means for information sharing: meetings, presentations, messages on JIRA and emailing, local file server, and VSS repository. A drawback of local file server and VSS is that they are poorly capable of indexing and searching.
The team should make use of Confluence system for information sharing and knowledge management. Confluence system is known as a powerful, centralized document management system. Besides, Confluence has predefined document templates that are good enough for different types of documentation.
4.3.2. Improving communication between Vietnamese and Japanese staffs
In this case study, working environment involves Vietnamese and Japanese cultures. Meanwhile, a success factor of agile adoption is closed communication among developers, customers, and stakeholders. Thus, team members should be well aware of possible communication gaps of this multi-cultural environment, thereby minimize the impacts of them.
Minimizing language barriers
Vietnamese language can be used in discussions among Vietnamese staffs as their mother tongue; however, English is the official language of the VN company. In the software department, English is the main language for both verbal and written communication between the Japanese GM and Vietnamese subordinates. There is a fact that English proficiency levels of both Japanese and Vietnamese staffs are limited to intermediate level. Woodward [41, p. 23] pointed out that the way of using language in international companies where the official language are not the first language of staffs is vital in communication. He recommended some communication rules to minimize language barriers as below, which are worth considering.
The first rule is 'keeping language simple' in both spoken and written communication [41, p. 23]. The team should use simple sentences, common words and low-level vocabulary; avoid using slang and idioms in daily meetings, documentation and email.
Confirming the verbal conversation by written messages is the second rule. This is to double check the correctness of the conveyed messages. Writing emails is a common way. However, the team should leverage dedicated communication tools because they make communication more efficient in distributed environment [41, p. 26]. A tool such as JIRA seems to be suitable for this purpose. The VN team has already experienced with JIRA for tracking issues. Thus, it is good to confirm verbal information in written form on JIRA, because one can easily follow JIRA threads and write comments inside them.
Awareness of cultural differences
In cross-cultural work environment, employees should be aware of cultural differences [41, p. 22]. This is a Japanese-owned company; therefore, the Vietnamese employees should have basic understandings about differences of culture, working style, communication style, and so on, between the Japanese and the Vietnamese. Some hints are cited from literature as below for reference.
There are some common traits of Vietnamese and Japanese cultures. According to the theory of high- and low-context culture of Edward T. Hall , Vietnam and Japan are both high-context countries. In high-context countries, relationships are built upon trusts. Therefore, face-to-face communication is crucial, and people rely on non-verbal cues - such as facial expression, eye movement, voice tone, and gestures - as means of conveying significant parts of their message. For this reason, face-to-face meetings are very important means to establish a reliable connection between the Vietnamese and Japanese staffs in this company.
Vietnamese people rely on personal credit in doing business [62, p. 577]. Thus, besides business activities, spending extra time for promoting interpersonal interaction, such as chatting, drinking, team building trips, and so on, play important role in building a strong interactive team. The Japanese also leverage business entertaining after business hours for building relationships, though it can be used for business discussion as well [62, p. 284].
On the other hand, there are cultural differences between Vietnamese and Japanese people. Decision-making of Vietnamese people relies on individuals, and it is highly influenced by their family [62, p. 576]. Meanwhile, the Japanese value collective, and their decisions are made among group members [62, p. 281].
Japanese culture has specific traits that may be hard for foreigners to comprehend, for example, embarrassment avoidance, strong group loyalty, strong work ethic, and emotional restraints [62, p. 282]. In addition, Japanese people are considered conservative. According to Hofstede [63, p. 249], Japan is at high level of uncertainty avoidance, which means Japanese people are likely discomforted with uncertainty and ambiguity; therefore, they tend to rely on structure, rules, and specialist in management.
Communication style of the Japanese was described by Conaway as follows: 'Communication in Japan is often marked by great subtlety; information is left unspoken yet is perfectly understood' [62, p. 279]. This helps explain some circumstances that subordinates cannot receive clear and detailed instructions or explanations for their assignments from the superior. Some other examples were extracted from [62, p. 283] for illustration.
' A Japanese response 'I'll consider it' may actually mean 'no.'
' Negatively phrased questions typically get a 'yes' if the Japanese speaker agrees. For example, a question such as 'Doesn't Company A want us'? will be answered 'yes' if the Japanese thinks that Company A indeed does not want you. In English, the answer would be 'No, they do not want you.'
How Japanese people process information is based on their cognitive style. They rely on their feelings for decision, which is subjective and experiential, and focus on detailed information other than a whole [62, p. 281]. Another fact is that Japanese people have strong group loyalty and they are willing to change themselves for the consensus of the group [62, p. 281].
In business, the Japanese value self-control during negotiations, and they rarely expose their emotion [62, p. 277]. In addition, they often indirectly express their negative attitude or disagreement. Thus, criticism rarely happens.
4.4. Agile adoption roadmap
When mention about transitioning to agile in this company, it is about changes of processes, habits, tools, and probably others, as summarized in Table 10. Some changes may have little impact on the current operations of the company. However, other changes may be more difficult, for example, changing the mindsets of developers who have worked for many years in traditional software development. Nevertheless, a requirement of the management is to minimize the impacts of changes to the business of the company when applying new methods. From perspectives of the management, this constraint has highest priority. Thus, it is important to prioritize the adoption of new practices to minimize the impacts of changes.
Table 10 Comparison of as-is and to-be practices
As-is practices and tools New proposed practices and tools
Project planning Individual estimation in person-days, stored in MS Project/Excel Team estimation in story points, stored on JIRA Agile
Project monitoring Peer talks, updated on MS Project, infrequent update Daily meetings, peer talks or team discussion, frequent updated on JIRA Agile (and physical Scrum board)
Project delivery Copy source code and documentation from local VSS to GIT or file servers Committing source code to central GIT, documentation is stored on Confluence
Project reviews At the end of project At the end of each sprint
Requirement engineering Traditional requirement documents with user cases written in MS Word format, stored on VSS User stories are capture in product backlogs, stored on central Confluence system that links to JIRA for traceability
Design Upfront design, stored in MS Word and VSS Simple design and refactoring, design documents are stored on Confluence
Coding Code-first Test-first with TDD
Source code integration Code is stored on VSS, manual code integration and build Code is stored on GIT, integrated with JIRA for code review, continuous integration with Bamboo or Jenkins
Testing/Quality assurance Rely on the tester and manual testing Peer code reviews before builds, automated testing with xUnit, FitNesse
Source code and document reviews Seldom for code, important documents are reviewed by team Peer review for documentation and source code, important documents are reviewed by team
Knowledge sharing Infrequent knowledge transfer sessions.
Documents are stored on VSS Monthly knowledge transfer sessions.
Adhering to MBO objectives
Documents are stored on central Confluence system
Documentation format and storage Composed with MS Word or Excel, then stored on VSS Composed with Confluence pages following default templates of Confluence
Controlling processes/workflows Processes are defined but they are not always applied Controlled via JIRA for all processes/workflows
From the previous chapter, it is clear that the VN team's mindset is influenced by traditional software development. Meanwhile, team members have limited knowledge of agile methodologies. Therefore, development habits of developers may not be changed immediately towards agile development. In addition, the management of this company advocates self-study through on-the-job-training rather than hiring agile experts for faster moving to agility. This makes the transitioning to agile development more tough.
On the other hand, the literature review in chapter 2 points out that agile adoption should be gradual and transparent to the team. Furthermore, M. Cohn [4, p. 33] advices that even when a team does not fully master agile practices, the team should start agile adoption by dividing the transition process into small steps, for example, applying test-driven for a small feature of a software product.
For these reasons, transition to agile software development in this company should be seen as a long-term process. Agile practices should be adopted step-by-step through self-study of team members. In addition, it is necessary to prioritize adopted practices for efficient transformation. Therefore, in the first step of agile adoption in this case study, practices that are simple to learn and closed to as-is situation will be applied first. In addition, reusing of existing infrastructure and tools is maximized in order to reduce investment cost.
Based on this strategy, a roadmap of agile adoption is proposed in Figure 18. This roadmap divides the adoption into three phases. The first phase consists of simple practices and tools that are in place. The second phase includes practices that need more preparation, for example, purchasing and setting up new tools, or training for the team. Some practices such as TDD, automated testing, and continuous integration requires customization for specific platforms and programming languages, thus they are difficult to adopt and should be deferred to the later phase.
Figure 18. A proposal of agile adoption roadmap
Transitioning to agile software development is a process of continuous improvement. The team should fine-tune the proposed practices during this transition. Consequently, this roadmap can be adjusted depending on real situations.
The team can leverage as-is knowledge transfer sessions, in which individuals learn new technologies by themselves and then present the results to the others, for adopting new agile practices. For instance, a developer (or a pair of them) can select his interested XP or Scrum practice, such as TDD or continuous integration, master it and then teach the others.
To motivate individuals in learning new agile practices, agile adoption process should be linked to MBO management system. In the annual MBO setting phase, the team should build up a list of objectives for the department. At individual level, each member can register his favorite practices as part of his MBO settings. For example, one can choose an annual objective like this: 'Doing three knowledge transfer sessions about agile practices this year'
Knowledge transfer sessions should be carried out on a regular pace, for instance, one to twice a month, depending on project workload. If following this strategy, the load of agile adoption is distributed to team members according as their expertise and interest.'
This final chapter summarizes and evaluates the results of this master thesis. In addition, limitations of this research project are also discussed. Some recommendations for future works are mentioned in the last words of this chapter.
5.1. Summary of research results
This master thesis presents the research project that is aimed to propose an enhanced project management framework based on agile methodologies for embedded software development of a Japanese-own company in Vietnam. In summary, the study has answered the two research questions RQ1 and RQ2 that are addressed in chapter 1; therefore, the objectives of this study have been fulfilled. The research in this thesis is summarized as follows.
The research was started with a comprehensive literature review described in Chapter 2. From the literature review, evidence of successful agile adoption in embedded software development was shown. In addition, agile adoption in distributed and multicultural environment, as well as its challenges and solutions, was also addressed. These findings answered the research question RQ1, which concerned about agile adoption for embedded software development in non-collocated and multi-cultural teams. Furthermore, the findings about characteristics of agile methodologies as well as success factors of agile adoption in ESD were used to direct the organization analysis in chapter 3.
The status quo analysis of the company in this case study was written in chapter 3. The analysis revealed important findings for agile adoption, for example, corporate culture and management, constraints from the management and company's regulations, motivation of the development team, infrastructure, and as-is software development practices. From these findings, possibility and feasibility of agile adoption in this company were assessed. In addition, the root causes of quality and productivity issues were also identified.
Based on the findings of chapter 2 and chapter 3, solutions for enhancement of software development in this company were proposed in chapter 4. This chapter addressed why Scrum and XP were selected for adoption and how they could help resolving the existing problems identified in chapter 3. Next, a customization of Scrum and XP practices specialized for the software development team was also mentioned. Finally, a roadmap of agile adoption was also outlined, which was based on the constraints from the management, corporate culture, and particular practices of the development team.
The analysis of the status quo in chapter 3 and the discussions of proposed solutions in chapter 4 have answered the research question RQ2, which involves how to adopt and implement agile practices for this case study.
Some preliminary results of the proposed solutions
With the approval of the Japanese GM, the proposed solutions have just been applied in the software development department of the VN company. By the end of this research projects, the author organized several internal training sessions about agile fundamentals and Atlassian tools for all team members. Thanks to the support of the GM and administrators from the headquarters in Japan, all Vietnamese developers could access Atlassian tools such as Confluence, JIRA Agile, Fisheye, and SVN/GIT. In addition, following activities were accomplished:
' Making use of Confluence pages and templates to store documentation such as technical notes, meeting minutes, and requirement specifications
' Linking Confluence pages to JIRA issues and vice versa for traceability
' Customizing JIRA dashboards so that all updates can be seen from a single web page
' Customizing JIRA Agile boards for each project
All staffs were quite interested in the benefits of these new software tools. For example, all activities were updated instantly on JIRA dashboards, and project leaders could monitor statuses of multiple projects via JIRA Agile boards and JIRA dashboards. The team was also interested in some social features of Confluence such as like, share, status tracking, etc...
Furthermore, some proposed agile practices were applied in the first phases of two small software development projects in the VN company. These projects were organized with collocated teams of 2-3 developers. Practices applied in the projects are summarized as follows:
' The author of this thesis temporarily played the role of 'internal agile coach' to support team members to apply new tools and practices.
' In each project, another Vietnamese engineer acted as a customer proxy for collecting requirements.
' Requirements were captured in user stories and stored in product/sprint backlogs on Confluence/JIRA Agile
' The teams did peer reviews for documents and source code
However, it might be insufficient to evaluate the effectiveness of the new practices, because these projects had just been started and some proposed practices had not been applied.
5.2. Limitations and recommendations for future works
In this thesis, the recommendations for enhancement in the chapter 4 were mainly relied on findings from literature. However, because of time constraint of this research project, there were limited numbers of referred literature. Thus, probably not all aspects of agile software development were addressed. In the next steps of agile adoption in this case study, other sources of reference should be further considered.
In addition, although some agile practices were partly applied in the early phases of small projects with collocated teams, most of proposed practices have not been fully tested in real projects. These practices should be adopted in full life cycles of both collocated and distributed project teams for validating their effectiveness. During the application of these solutions, one should fine-tune the practices and processes to suit the real situation.
Furthermore, not all Scrum and XP practices are considered in the proposed solutions. The selected practices were mainly aimed to resolve existing problems of software development in the case study. Other practices of Scrum and XP should be considered in future. Besides, other agile methodologies such as Kanban are worth for further study.'
 S. Easterbrook, 'Software Lifecycles,' University of Toronto Department of Computer Science, 2001.
 VersionOne.com, 'Agile development: a manager's roadmap for success,' Agile development: a manager's roadmap for success. [Online]. Available: http://www.versionone.com/Agile_Managers_Roadmap. [Accessed: 08-Feb-2014].
 J. L. Cooke, The Power of the Agile Business Analyst: 30 surprising ways a business analyst can add value to your Agile development team. IT Governance Ltd, 2013.
 M. Cohn, Succeeding with agile: software development using Scrum. Upper Saddle River, NJ: Addison-Wesley, 2010.
 VersionOne.com, 'Annual State of Agile Survey,' State of Agile Survey. [Online]. Available: http://stateofagile.versionone.com/. [Accessed: 08-Feb-2014].
 C. O. Albuquerque, P. O. Antonino, and E. Y. Nakagawa, 'An Investigation into Agile Methods in Embedded Systems Development,' in Computational Science and Its Applications ' ICCSA 2012, vol. 7335, B. Murgante, O. Gervasi, S. Misra, N. Nedjah, A. M. A. C. Rocha, D. Taniar, and B. O. Apduhan, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, pp. 576'591.
 M. Shen, W. Yang, G. Rong, and D. Shao, 'Applying agile methods to embedded software development: A systematic review,' 2012, pp. 30'36.
 M. Kaisti, V. Rantala, T. Mujunen, S. Hyrynsalmi, K. K??nn??l??, T. M??kil??, and T. Lehtonen, 'Agile methods for embedded systems development - a literature review and a mapping study,' EURASIP J. Embed. Syst., vol. 2013, no. 1, p. 15, 2013.
 Q. Nguyen, 'VGU master thesis BIS2010 - Agile Software Development in Vietnam.' Sep-2013.
 B. Greene, 'Agile Methods Applied to Embedded Firmware Development,' presented at the Agile Development Conference, 2004, 2004, pp. 71'77.
 J. Grenning, 'Agile Embedded Software Development,' in Embedded Systems Conference, San Jose, California, USA, 2007, vol. 2, pp. 1067'1086.
 E. Gul, T. Sekerci, A. C. Yuceturk, and U. Yildirim, 'Using XP in Telecommunication Software Development,' in Software Engineering Advances, 2008. ICSEA '08. The Third International Conference on, 2008, pp. 258'263.
 J. Srinivasan, R. Dobrin, and K. Lundqvist, ''State of the Art' in Using Agile Methods for Embedded Systems Development,' 2009, pp. 522'527.
 J. Drobka, D. Noftz, and Rekha Raghu, 'Piloting XP on four mission-critical projects,' IEEE Softw., vol. 21, no. 6, pp. 70'75, Nov. 2004.
 M. Smith, J. Miller, and S. Daeninck, 'A Test-oriented Embedded System Production Methodology,' J. Signal Process. Syst., vol. 56, no. 1, pp. 69'89, Sep. 2008.
 J. Grenning, 'Extreme programming and embedded software development,' in Embedded Systems Conference, 2002, vol. 2002.
 UBM Tech, 'Agile in the Embedded world,' Jun-2013.
 S. J. Mellor, 'Agile in the Embedded World,' 2009.
 M. Fletcher, W. Bereza, M. Karlesky, and G. Williams, 'Evolving into Embedded Develop,' in Agile Conference (AGILE), 2007, 2007, pp. 150'155.
 A. Shatil, O. Hazzan, and Y. Dubinsky, 'Agility in a Large-Scale System Engineering Project: A Case-Study of an Advanced Communication System Project,' 2010, pp. 47'54.
 D. Morgan, 'Covert Agile: Development at the Speed of… Government?,' IEEE Xplore, 24-Aug-2009. [Online]. Available: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=5261103. [Accessed: 15-Feb-2014].
 O. Salo and P. Abrahamsson, 'Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum,' IET Softw., vol. 2, no. 1, p. 58, 2008.
 B. Kitchenham and S. Charters, 'Guidelines for performing Systematic Literature Reviews in Software Engineering,' Keele University and Durham University Joint Report, EBSE 2007-001, 2007.
 'Agile software development - Wikipedia, the free encyclopedia.' [Online]. Available: http://en.wikipedia.org/wiki/Agile_software_development. [Accessed: 02-Mar-2014].
 M. Molhanec, 'The Agile Methods - an Innovative Approach in the Project Management,' 2007, pp. 304'307.
 'Manifesto for Agile Software Development.' [Online]. Available: http://agilemanifesto.org/. [Accessed: 01-Mar-2014].
 'Principles behind the Agile Manifesto.' [Online]. Available: http://www.agilemanifesto.org/principles.html. [Accessed: 02-Mar-2014].
 G. Smith and A. Sidky, Becoming agile --in an imperfect world. Greenwich, Conn.: Manning, 2009.
 L. Williams, 'A Survey of Agile Development Methodologies.' 2007.
 'Agile Software Development, Agile Software Development With Scrum, Agile Development | VersionOne.' [Online]. Available: http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/. [Accessed: 02-May-2014].
 P. Kettunen, 'Adopting key lessons from agile manufacturing to agile software product development'A comparative study,' Technovation, vol. 29, no. 6'7, pp. 408'422, Jun. 2009.
 'Agile software development methodologies and how to apply them - CodeProject.' [Online]. Available: http://www.codeproject.com/Articles/604417/Agile-software-development-methodologies-and-how-t. [Accessed: 02-Mar-2014].
 Amber, Scott and Holitza, Matthew, Agile for dummies. John Wiley & Sons, Inc., 2012.
 'Scrum Methodology and Project Management | Mountain Goat Software.' [Online]. Available: http://www.mountaingoatsoftware.com/agile/scrum. [Accessed: 13-Feb-2014].
 K. Beck, Extreme Programming Explained: Embrace Change. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2000.
 'Agile Methodology - Agile Methodologies for Software Development.' [Online]. Available: http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/. [Accessed: 13-Feb-2014].
 'XP flow Chart.' [Online]. Available: http://www.extremeprogramming.org/map/project.html. [Accessed: 22-Feb-2014].
 'Guide to Agile Practices-Kanban.' [Online]. Available: http://guide.agilealliance.org/guide/kanban.html. [Accessed: 13-Feb-2014].
 agilealliance.org, 'Guide to Agile Practices,' Lead time. [Online]. Available: http://guide.agilealliance.org/guide/leadtime.html. [Accessed: 31-May-2014].
 'Kanban - the next step in the agile evolution?,' Walk the Walk. .
 E. Woodward, S. Surdek, and M. Ganis, A practical guide to distributed Scrum. Upper Saddle River, NJ: IBM Press, 2010.
 J. Sutherland, A. Viktorov, J. Blount, and N. Puntikov, 'Distributed Scrum: Agile Project Management with Outsourced Development Teams,' in System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, 2007, p. 274a'274a.
 S. V. Shrivastava and H. Date, 'Distributed Agile Software Development: A Review,' ArXiv10061955 Cs, Jun. 2010.
 'Be careful of the meaningless 'yes' and hidden 'no.''[Online]. Available: http://www.japanese-language.aiyori.org/article6.html. [Accessed: 31-May-2014].
 'What is embedded system? - Definition from WhatIs.com.' [Online]. Available: http://searchenterpriselinux.techtarget.com/definition/embedded-system. [Accessed: 03-Jun-2014].
 J. Savolainen, J. Kuusela, and A. Vilavaara, 'Transition to Agile Development - Rediscovery of Important Requirements Engineering Practices,' in Requirements Engineering Conference (RE), 2010 18th IEEE International, 2010, pp. 289'294.
 M. Cohn, 'Differences Between Scrum and Extreme Programming,' http://www.mountaingoatsoftware.com, Apr-2007. [Online]. Available: http://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming. [Accessed: 27-Feb-2014].
 C. Berger and B. Rumpe, 'Supporting Agile Change Management by Scenario-Based Regression Simulation,' IEEE Trans. Intell. Transp. Syst., vol. 11, no. 2, pp. 504'509, Jun. 2010.
 G. Mueller and J. Borzuchowski, 'Extreme Embedded a Report from the Front Line,' in OOPSLA 2002 Practitioners Reports, New York, NY, USA, 2002, p. 1'ff.
 B. Waldmann, 'There's never enough time: Doing requirements under resource constraints, and what requirements engineering can learn from agile development,' 2011, pp. 301'305.
 R. K. Yin, Case Study Research: Design and Methods, 3rd Edition, 3rd edition. Thousand Oaks, Calif: SAGE Publications, Inc, 2002.
 'Software Development and Collaboration Software | Atlassian.' [Online]. Available: https://www.atlassian.com/software. [Accessed: 24-Jun-2014].
 Antrix Inc., 'Products Regulatory Affairs Quality Assurance Consulting Services and Products.' [Online]. Available: http://www.antrix.com/services/service_list/11_validation_computer_systems.htm. [Accessed: 07-Jun-2014].
 'Effort Distribution Across the Software Lifecycle.' [Online]. Available: http://it.toolbox.com/blogs/enterprise-solutions/effort-distribution-across-the-software-lifecycle-6304. [Accessed: 08-Jul-2014].
 'The Daily Scrum Meeting.' [Online]. Available: http://www.mountaingoatsoftware.com/agile/scrum/daily-scrum/. [Accessed: 05-Jun-2014].
 'Root Cause Analysis - Problem Solving from MindTools.com.' [Online]. Available: http://www.mindtools.com/pages/article/newTMC_80.htm. [Accessed: 07-Jul-2014].
 'How to Sustain Adaptive Planning - Scrum Alliance.' [Online]. Available: http://www.scrumalliance.org/community/articles/2010/february/how-to-sustain-adaptive-planning. [Accessed: 14-Jul-2014].
 'Confluence 5.4: Integrated with JIRA like never before - Atlassian Blogs.' [Online]. Available: http://blogs.atlassian.com/2013/12/confluence-5-4-jira-integrates-confluence-like-never-before/. [Accessed: 22-Jun-2014].
 'Welcome to Jenkins CI! | Jenkins CI.' [Online]. Available: http://jenkins-ci.org/. [Accessed: 24-Aug-2014].
 'JIRA Plugin - Jenkins - Jenkins Wiki.' [Online]. Available: https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin. [Accessed: 18-Aug-2014].
 'Context of Cultures: High and Low.' [Online]. Available: http://www2.pacific.edu/sis/culture/pub/Context_Cultures_High_and_Lo.htm. [Accessed: 30-Mar-2014].
 T. Morrison and W. A. Conaway, Kiss, Bow, or Shake Hands, Second Edition edition. Avon, Mass: Adams Media, 2006.
 L. G. Bolman and T. E. Deal, Reframing Organizations: Artistry, Choice and Leadership, 4 edition. San Francisco: Jossey-Bass, 2008.
 'Confluence Documentation Home - Confluence Latest - Atlassian Documentation.' [Online]. Available: https://confluence.atlassian.com/display/DOC/Confluence+Documentation+Home. [Accessed: 22-Jun-2014].
 'FAQ - End of Life.' [Online]. Available: https://go-dvcs.atlassian.com/display/EOL/FAQ. [Accessed: 15-Jul-2014].
Appendix A ' Glossary of Terms and Abbreviations
Term or Abbreviation Definition
ESD Embedded Software Development
SM Scrum Master
PO Product Owner
TDD Test Driven Development
CI Continuous Integration
XP eXtreme Programming
JP company The parent company in Japan
VN company The subsidiary in Vietnam
SW department The software development department in the subsidiary
GM General Manager
Japanese GM The Japanese General Manager who heads the software development department of the Vietnam branch
VN team The team of Vietnamese developers in the software development department of the Vietnam branch
TL Technical leader
SSE Senior Software Engineer
MBO Management By Objectives
QCD Quality, Cost, Delivery
Appendix B ' Interview questions
(Some questions with confidential information are not included)
A- Questions for the Japanese GM
Expectation from the management
What are expectations of the headquarters regarding performance of our SW department?
Why our MBO assessment results were quite low last several years? How did you (and your predecessors) evaluate our team's performance?
Possibility to changes
Can changes be made for software process improvement in our department?
Should we change our software development model to a more effective one, such as agile development?
Can we use tools from Atlassian that are already in place, for example, Confluence, JIRA Agile, and FishEye?
Can we purchase some new software tools? If yes, how can we buy them?
In case we adopt agile methodology, can we hire an external coach for agile adoption?
B- Questions for Vietnamese developers
What do you think about our company's management style? In your opinion, how the company retains its employees for many years?
In your opinion, who has authority for decision-making in our department?
What do you think about our company's policy of training?
In your opinion, is there any issue in our company's policy and management style?
Attitudes to changes
Do you satisfy with MBO results in last several years? Why do you think so?
What do you think about our as-is SW development processes?
In your opinion, is there any problem with our SW development practices?
What should we do to improve our software development practices?
Do you think that we should change our software development model to a more effective one, such as agile development?
SW development team
How long have you worked as software developer? What is your background?
What types of OSes/platforms have you worked with?
What programming languages and technologies have you ever used?
How long do you work with a platform/OS continuously?
What types of tasks have you done in previous projects?
Do you often write documents in software development projects? What languages do you use to write?
Can you evaluate your English/Japanese proficiency?
Do you know about agile development? (e.g. Scrum or XP)
Can you name some principles of Extreme Programming?
How do your teams store documentation?
Do you often refer to documentation of previous projects on our VSS (or local file server), for example, design specifications?
How easily can information be found on our VSS or file server?
How do your team members communicate in a project?
Do your teams have daily or weekly meetings?
How do your teams communicate with the JP team?
Have you had face-to-face meetings with Japanese staffs of the headquarters?
Software development practices
Projects, processes, and tools
Who are your customers?
Have you ever worked in a project that is not from our headquarters?
What is the average size of your projects?
Can you describe the process you use to write a piece of code, from gathering requirements to product delivery?
Which software tools did you use in your projects?
Who managed your projects?
How were your teams organized?
How were your projects planned?
How did you report progress of assigned tasks? Did you have tools to do that?
Who did estimation in a project? Who set the deadline?
How do your teams monitor progress of a project?
Did your teams have reviews (for documentation or source code) in projects?
What kinds of metrics do you use to evaluate projects?
In the projects you participated in, how were deliverables released to customer?
Software development activities
What types of software activities did you often do?
Have you ever written requirement specifications?
How does your team capture requirements?
How does your team ensure traceability of documentation?
How does your team manage changing requirements?
How do you search and find requirements? What are possible sources?
How do you prioritize requirements? Do you know different techniques?
Can you name the responsibilities of the customer and the developers in requirement process?
What do you do with requirements that are incomplete or incomprehensible?
How designs are done in your projects?
How do you create technical documents in your projects?
How would you manage changes to technical documentation, like the architecture of a product?
How do you write source code? Is there any review from other developers?
How is source code integrated? Do you use any tool for source code integration?
How are unit tests and acceptance tests done in your projects?
Which tools are essential to you for testing the quality of your code?
How did your team deal with hardware dependency of embedded software in previous projects?
Appendix C ' Atlassian's tools
JIRA is a very popular tool for project management. JIRA can be considered the skeleton for project activities; it can be used for planning, tracking issues, and controlling requests. An add-on called JIRA Agile provides visualization of workflows for Scrum and Kanban methods, such as Scrum and Kanban boards. Product backlogs and sprint backlogs can be easily created and managed with JIRA Agile as well , for example:
' User stories can be mapped to JIRA's epics or issues
' A user stories can be broken down in sub issues of JIRA
' Tracking a parent issue via its sub issues
' Measuring progress with burndown charts and others
Confluence is a wiki-based tool for team collaboration and knowledge sharing. It acts as social collaboration platform for various purposes, as depicted in Figure 19. Confluence can store a variety of content types such as text, images, video, diagrams, and other attachments. Besides, it provides extremely powerful search options , and functions for document editing that are replaceable for MS Word. Document templates can be customized and stored as well. Other features of Confluence include versioning, linking to URLs, plugin supporting, permission and security management.
In the first step, Confluence can be used for requirement engineering and knowledge management in this company. With Confluence, documentation can be created and stored in central servers, which can be accessed by all employees of the Japan headquarters and the Vietnam subsidiary, as long as they are granted sufficient access permissions.