Lack of verbal communication in agile development team a case of digital co , ltd

UNIVERSITY OF ECONOMICS HO CHI MINH CITYInternational School of Business ---DINH THI THANH VAN LACK OF VERBAL COMMUNICATION IN AGILE DEVELOPMENT TEAM: A CASE OF DIGITAL CO., LTD MAS

UNIVERSITY OF ECONOMICS HO CHI MINH CITY

International School of Business

-DINH THI THANH VAN

LACK OF VERBAL COMMUNICATION IN AGILE

DEVELOPMENT TEAM:

A CASE OF DIGITAL CO., LTD

MASTER OF BUSINESS ADMINISTRATION

Ho Chi Minh City – Year 2020

UNIVERSITY OF ECONOMICS HO CHI MINH CITY

International School of Business

-DINH THI THANH VAN

LACK OF VERBAL COMMUNICATION IN AGILE

DEVELOPMENT TEAM:

A CASE OF DIGITAL CO., LTD

MASTER OF BUSINESS ADMINISTRATION

SUPERVISOR: Dr NGUYEN THI MAI TRANG

Ho Chi Minh City – Year 2020

TABLE OF CONTENTS

LIST OF FIGURES 1

LIST OF TABLES 1

Executive Summary 2

Acknowledgements 4

I INTRODUCTION 5

II PROBLEM CONTEXT 7

1 Organizational Structure 7

2 Team A Structure 8

2.1 Description of the role in team A 8

2.2 Description of working method Agile 9

2.3 Apply Agile for team A 10

3 The case 10

III PROBLEM IDENTIFICATION 18

1 Possible Problems 18

1.1 Insufficient information sharing 18

1.2 Work overload 20

1.3 Weak customer relationship management 22

2 Problem Validation 23

IV CAUSE VALIDATION 26

1 Possible Causes 26

1.1 Lack of verbal communication 26

1.2 Barriers with knowledge sharing 28

1.3 Lack of team goal awareness 30

2 Cause Validation 32

V ALTERNATIVE SOLUTION 33

1 Alternative Solutions 33

1.1 The first alternative solution: Using software Jira to manage the project 33

1.2 The second alternative solution: Offering training course to improve verbal skills 35

2 Solution Validation 36

VI ORGANIZATION OF ACTIONS 37

VII CONCLUSION 39

VIII SUPPORTING INFORMATION 40

REFERENCES 57

LIST OF FIGURES

Figure 1: Organizational Structure

Figure 2 Team A’s structure

Figure 3 Roles in team A

Figure 4 Agile methodology

Figure 5 Contract discussion between DSC and Vietstar

Figure 6 Preliminary Cause – and – Effect Tree

Figure 7 Main Cause – Effect Tree

LIST OF TABLES

Table 1 Contract value came from Vietstar

Table 2 Project size analysis in term of number of men and time length

Table 3 Project size analysis by DSC’s view based on man-days

Table 4 Time comparison between normal estimate and Vietstar’s requirement

Table 5 Record of customer’s complaints from 2015 to 2019

Table 6 Contents of complaints

Table 7 DSC revenue from 2015 to 2019

Table 8 Comparison between Vietstar’s requirement to change and normal workload Table 9 Action plan

Table 10 Jira tool estimate cost

Table 11 Training estimate cost

Executive Summary

IT software industry is now one of the most rapidly growing industries among south east ASIAN counties since the majority of IT software companies in China has been charging even higher than what the other developed counties do [1] Especially since Donald Trump was elected as the 45th and current president of the United States of America, it has been getting harder politically for most of the American software companies to keep involving into Chinese market [2] Many has moved their software engineering resource pool from China to other south east countries such as Taiwan, Philippine and Vietnam [3] In addition

to such tailwind for those countries, the strong political and economic supports in IT software industry by Vietnamese government toward foreign IT companies and investors and the strong labor force growth in service sector have lead Vietnam to be one of the top countries to export IT software services such as implementation and testing [4] This has led to more and more international and regional companies looking to Vietnam to build technological resources This trend has been very popular in recent years, along with that, the capacity and responsibility of the indigenous engineering team are increasingly appreciated From that, the competition in term of human resource in the market according

to investment and development trends is getting higher Therefore, the question is how to ensure the team has the capacity to compete and to meet not only customer needs but also the development trend of the industry

DSC, a 100% Vietnamese IT software development company, provides its own logistic software products and many services to foreign companies mainly in Vietnam or Japan DSC wants to keep up with the development trend, improve the competitiveness with other companies of the same scale by upgrading the operational structure of each programming team under the Agile model, which became widely known in 2016 though the publication

by the Agile Alliance [5], in order to reach the flexible and effective level of programming The application of this model to 20 employees in the company made DSC face certain difficulties related to human resource management and information sharing among employees in its organizations

This project will clarify why DSC is having problems with the radical model being applied more and more in the information technology market, in order to study feasible solutions

to strengthen the programming team's power according to Agile model effectively

Acknowledgements

Foremost, I would like to express my sincere gratitude to my supervisor Nguyen Thi Mai Trang for the continuous support of study and research, for her patience, motivation, enthusiasm, and immense knowledge Her guidance helped me in all the time of research and writing of this thesis I could not come this far without her for my study

I am feeling oblige in taking the opportunity to sincerely thanks to my friend, Tuan Hoang (CEO of DSC) and special thanks to all the members at DSC for their generous attitude and friendly behavior while participating my surveys

At last but not the least, I am thankful to all my teachers and friends who have been always helping and encouraging me though out the courses I have no valuable words to express

my thanks, but my heart is still full of the favors received from every person I have met

I INTRODUCTION

DSC is a Vietnamese logistic IT software application provider and IT software outsourcing company established in 2013, employs 20 full-time workers as of 2019 When professor Tuan, founder and CEO of DSC, worked for a university as an IT software professor, he developed a logistic enterprise software with his undergraduates as his assistants Fortunately, one of his assistants’ family was a management executive in logistic company

in Vietnam, and the executive became his first client to operate the software to manage their business including stock management and shipment management That was the time

he established his company with a name DSC, which stands for Digital System CO., LTD Working closely with the first client to understand their business operational issues that could be solved with its software, DSC has improved their product one by one Prioritizing what to implement next based on the limited number of their clients’ needs and requirements seemed promising at the early stages However, their product has been not competitive enough to take major market share in Vietnam logistic industry yet In 2015, they started offering software development and consulting outsourcing services mainly in the local enterprises based on market analysis that more and more outsourcing projects would move from China to Vietnam So far to 2019, the total number of projects reached over 160 from 5 countries Now in their organization, there are 4 separated teams

DSC’s slogan is “DSC’s success comes after client’s success.” They are meant to be oriented organization when it comes to software development and operations Based on their belief, they value their people because software is fully built up by people and used mostly by people With CEO’s strong experiences in education at undergraduate level, DSC trains undergraduates and freshers both mindsets as software engineers and practical coding and testing skills instead of recruiting experienced engineers and testers In that way, DSC tries to create family-like bonds among its employees as well as reducing labor costs at the same time

client-With the team A’s size of four members, DSC has followed Agile methodology for the full life cycle development in the logistic application development project and has developed its logistic application without critical issues related to its quality and agility

As the application becomes more complex and covering more logistic operations, the team

A, among four teams of DSC, faced more tickets failing the acceptance test from its client’s product owner In November 2019, DSC lost one existing contract with their client due to the failure to meet client’s expectations CEO said, approximately one third of their total annual sales in 2019 was lost because of the cancellation of the contract

II PROBLEM CONTEXT

1 Organizational Structure

Figure 1: Organizational Structure (Internal Source)

Flat organizational structure consists of 20 people

CEO plays CTO roles solely There is one accountant and one sale executive

There are two teams lead for 4 independent teams under CEO:

• Team A: work for DSC own product development as R&D

• Team B: work for outsourcing software development service

• Team C: work for onsite on a software development project

• Team D: work for consulting services with outsourcing software development service

This study focuses on the issues related to Team A only

2 Team A structure:

2.1 Description of the roles in team A

Team A is built up based on Agile software development methodology Together with the team, CEO plays a product owner role, the manager #1 takes the role of scrum master who

is also the tech lead, and the three engineers and one tester are categorized as scrum members Business owner belongs to Vietstar

Figure 2 Team A’s structure Figure 3 Roles in team A

(Internal source) Product owner: Mr Tuan, he represents the voice of customers This person is a connection between the development team and customers He will work with the user to describe, arrange, and correct what features will be in the next product release Mr Tuan also accepts

or reject work results and keep customers update the project’s status He collaborates with scum master to get progress smoothly

Scrum master: Mr Hoang, he is the facilitator for the project’s development team who accelerate information sharing among the team during the sprint, including leading stand-

up meetings and helping the team stay on track by resolving problems and removing obstacles Members of the team need to focus on transparency, observation, and organization

Scrum team: This team is responsible for implementing the work Together with developers, the scrum team can include testers, architects, designers, and IT operations Scrum master will help protect the team and keep them concentrate On the other hand, the team is self-managed They will be responsible for collectively deciding how to reach their goals

2.2 Description of working method Agile

Figure 4 Agile methodology

(Source: Internal training source from 2016 until now) DSC uses Agile methodology as an approach based on delivering requirements iteratively and incrementally throughout the project life cycle

DSC divides tasks into short phases of work and frequent reassessment and adaptation of plans They plan the project, build requirements for the project, execute the product, and then test the product for flaws by breaking this big cycle into small cycles or segments These small, usable segments of the software product are specified, developed, and tested

in manageable, two- to four-week cycles, are called sprints

2.3 Apply Agile for team A

The product owner, which is CEO of DSC, Mr Tuan transfers customer requirement to team manager to create a product backlog, where requirements from the client are arranged with their priorities

Team A managed by Mr Hoang comes to understand the requirements at the beginning of

a sprint and then estimates the workload roughly By walking through all the estimated tasks with product owner and business owner during review phase, all the members in the team are supposed to make everything clear enough to start developing the software Then,

Mr Hoang creates tickets, which are work tasks for members to do

During the development process, the team updates work status on a web board called

“Kanban” and conduct daily meetings to share the progress of the work as well as obstacles

in the process of working together The team is empowered to self-manage and organize their work to complete within the sprint

At the end of the sprint, the team creates software packages with complete functions, ready

to be delivered to customers The sprint review meeting at the end of the sprint will help customers see what the team has been able to deliver, what remains to be done, or what needs to be improved

After finishing the sprint assessment, the scrum master, who is also Mr Hoang, and the team hold a sprint improvement meeting to look back for any improvements that they could have done before the next sprint begins

The sprint will be repeated until the items in the product backlog are completed or when the product owner decides to stop the project based on the actual situation

3 The case - Symtom

VietStarExpress (or Vietstar) is one of DSC’s customers who provides multimedia online services, allowing their customers to access website and mobile application for making orders, checking bill of lading, booking delivery service, looking-up postcards, and parcels

online Vietstar has been choosing DSC for three years to build and upgrade their software, bringing good income to DSC from 2016 to 2018

Table 1 Contract value came from Vietstar

2019 (if finish successfully)

Yearly, in table 1, from 2016 to 2018, Vietstar contributes to DSC revenue among 7% to nearly 9% In September 2019, DSC signed a contract of 500 million VND with Vietstar

to develop Vietstar’s website and mobile application named V.Express Vietstar will sign the next contract, value of 1.6 billion VND for second stage divided in 2 durations, one in

2019 value 800 million and another same value in 2020, if DSC complete the first stage within two months In total, if DSC did well, they would earn 1.3 billion from serving Vietstar in 2019

Figure 5 Contract discussion between DSC and Vietstar

(Source: Internal source)

The point considered to start the problem began when ten day before the release day, Vietstar asked DSC to change the method on calculating money in hand because Vietstar’s accountant could not get the right number at the end of the day It turned out the status of money paid was not right at some situations That was a rush request since the last sprint already had started four days ago But for keeping loyal and potential customer and for extending the contract to next phase, CEO agreed to redo the sprint So, team A faced difficulty with the task coming up within ten days

Since CEO considered this is a huge task in term of human resource, for team A to handle,

he uses the academic method combined with current human resource in DSC to make the size definition in term of man (developer), month (the time that a team need to finish the project) and contract value, to make sure DSC can finish the task in time

Theoretically, according to DSC, with the contract that they can earn under 90 million per month, and needs four men to finish in one month, it is a small and easy one The contract that they can earn from 90 to under 200 million per month with four men working in two

to three months will be the medium And the contract that they can earn 200 million per month with eight men working from three to four months is the big one to them

Table 2 Project size analysis in term of number of men and time length

(month)

Contract value (million/month)

Project’s size Definition

estimation, so he directed team B, who were available at that time, to help team A updating the product according to customer’s new requirement Then, at that time, there were eight members The additional measurement is the task length calculated on how long members work to finish The way to calculate is showed in the next table

To be more specific, there were 8 developers in the team deployed the software together 8 hours per day within 9 days on product updating before releasing on the last day Which means in total of man-day, they had worked for 576 man-days

Table 2 and 3 proved that the spec changed was a huge task for DSC to complete because eight men spent a greater number of hours more than usual which was equivalent with four months (576/280*2) working under normal circumstance

In term of man-days in table 3, if a project has each sprint, which done by standard team with four developers, lasts less than 392 man-days, it is a small project, lasts from 392 to

503, it is a medium project, and lasts from 504 to more, it is a big one

Table 3 Project size analysis by DSC’s view based on man-days

Standard

team

(1)

Days per sprint (2)

Hours per day (3)

Overtime (hours/day) (4)

Total Man-days

=(1)x(2)x(3)+(4)

Project’s size definition

(Source: Internal source)

In fact, it took the merged team 576 man-days to finish the last new sprint, so, it is a big task for DSC to complete In another words, in term of human resource, this is a huge task for them to handle However, they finished on time So, the CEO was right at estimating how heavy new task is and directing two teams to work together

Unfortunately, in November 30th, after DSC handed out the product to Vietstar, they received the first complaint email from this customer They mentioned about product quality Vietstar still got the wrong number with money paid although they believed DSC already fixed calculating method Mr Thang, project manager from Vietstar said:

We changed the process to calculate the income and they could not follow It caused us a huge damage since we got more than 300.000 orders per day

For this complaint, Mr Hoang, manager of team A explains:

During the user acceptance test phase, Vietstar asked to change the spec on payment logic

To be exact, the original spec for the payment status was that once the end user clicks the

“order” button, the payment status is updated to be “received.” As you might notice, the original spec contains some risks that even if the actual payment would not be made, the status will still be the same as “received.” Business owner realized this potential issue while conducting the acceptance test The status on the view was very important It was to add one additional payment status on a view for Vietstar’s accountant to calculate their cash flow at the end of every working day I assumed that the team members knew that the spec change was critical for the client, so I created new tickets briefly to inform their new tasks

At stand-up meeting, I did orally mention in detail what we needed to implement the spec change within the same sprint Unfortunately, members did not change the code related to payment status They missed some details I did not write down but did require in the meeting It caused Vietstar to check up the bill on that day manually until the spec change was reflected to the software When the acceptance test on the same sprint came, the client found out that the spec change was not fixed yet After that, they sent the email to complain and require to fix that code within one day

As DSC’s CEO said, their requirement to change was reasonable based on its business analysis However, in order to fulfill the product owner’s request, DSC needed to add one status column to a transaction table which was one of the core table in their relational database The senior programmer in DSC, Mr Huynh Cong Thang showed out they needed

to redesign most of the payment logics and needed to update related tables The senior

estimated the required man-day to fix the feature including unit test, integration test, and regression test to be 32 man-days

Table 4 Time comparison between normal estimation and Vietstar’s requirement

Normal estimate For team A+B

Vietstar’s requirement

Even after their implementation and testing were completed, they were uncertain to update the tables in the commercial environment They did not have alternative solution since they had only one database server for the product So the server must be shut down during the deployment because first, DSC needed to copy all the transaction data from the database, which estimated time to copy was around 6 hours, then attached the necessary queries to the server and finally took the copied data back to the database

So, with the requirement to fix within one day, DSC tried to negotiate for additional development time However, Vietstar did not want to delay more since it caused them a huge lost with handling more than 300,000 orders per day as Mr Thang, project manager from Vietstar shared At the end, DSC failed with the second requirements of deadline to fix the problem Consequently, they received one more complaint, the second email which mentioned about the unmet requirement and to stop the contract which DSC has never faced before

Table 5 Record of customer’s complaint from 2015 to 2019

(Source: Internal report in 2019) Table 5 shows that, in a long period of time from 2015 to 2019, DSC have not got any complaint but two from only one customer in 2019, Vietstar And the contents of complaints are shown in table 6

Table 6 Contents of complaints

1st Vietstar 2019 Fail to meet requirement

(Source: Internal Source) This situation is not as simple as usual complaint It leads to losing contract, which affects DSC’s revenue and reputation

Firstly, about DSC revenue, it has grown stably in four years from 2015 to 2018 and because of losing Vietstar contract at the end of 2019, DSC’s revenue decreased 2.17% Besides, it will be harder for DSC to keep Vietstar as loyal customer and gain contract from them again since this project they failed [6] Having customer loyalty can help DSC gain several advantages like, lower costs, increased revenues, and profitability, but they just disappointed the loyal customer and lost the contract from them

Table 7 shows that in 2019, DSC’s income reduces from 4.6 to 4.5 billion VND equals with 2.17 percent deduction compared with 2018 If DSC still got the contract, the revenue would be higher

Table 7 DSC revenue from 2015 to 2019

That points out the value Vietstar can bring to DSC clearly is contribution to their revenue

in the last year which help it grow Mr Tuan added:

We discussed to get 2.5% of the earning before tax calculate on number of orders, which means up to 112,5 million per month We can pay salary for the whole team of five members with that number It was a very promised contract to me, a stable and long-term plan in term of employee’s salary, very steady monthly income for 1 year

Secondly, about reputation, DSC had never failed any customer from the starting day until this time they failed Vietstar Customers in this industry, they do not come and leave after one project but to maintain using service for long term It is not like selling one complete product The product DSC makes will need to be upgraded according to the needs and technology development And this is the very first time they failed In another word, their performance for the very first time unsuccessfully met Vietstar’s expectations, broke expected transactional standards and caused damage [7] With knowledge and experience about how service failure can affect customer satisfaction, CEO knows there is risk of not good word-of-mouth in the industry about DSC and the risk to get other current clients doubt about the firm So that, to identify what caused the failure, to understand it and recover are extremely important

In short, a big project with high value is not only a good chance for DSC to gain profit but also a huge challenge for them to get through Unfortunately, DSC could not finish the project in a proper way to meet customer’s requirement Besides, this customer is important and has cooperated with DSC for several times continuously within three years By losing

contract from them, DSC faced the sale lost and faced the risk of getting bad reputation in logistic industry which the CEO has been trying so hard to build up Therefore, as a founder

of DSC, he desperately wants to find out what the root cause(s) is(are) leading to this situation in order not to face that situation once again in the future

III PROBLEM IDENTIFICATION

1 Possible Problems

Figure 6 Preliminary cause – and – effect tree

Based on the CEO and manager’s experience, team A made a mistake at “define

requirement” phase which leaded to missed Vietstar’s requirement Mr Tuan said about team A

Reasons are various First, the way they communicate transfers insufficient information, second is work overload and the last is weak relationship with client

1.1 Insufficient information sharing

Insufficient information sharing is considered as one of the possible problems causing contract loss

Mr.Tuan explained that, developers needed to have exact and full of information about product’s requirements; therefore, they can deploy in the right way to satisfy customers With this situation since the specific request was not transferred among the team clearly

He believes:

There must be something wrong like they have lack of group verbal communication, some types of barriers prevent them from sharing knowledge or there was lack of team goal awareness so that they transferred not enough information

And

Without enough information, the team went in a wrong direction with their own assumptions and they failed

Firstly, about lack of communication, [8] the role of communication in software projects

as most of the time of programmers Some research [9] points out developers think that more communication would be beneficial But team A did not have enough talk about the case Mr Tran Huu Hoang confirmed that he expected the members to understand the function would change so he did not mention, and members thought they got the ideas, so they also kept quiet Besides [10], throughout with communication, knowledge gets transferred when information increases by individuals So, communication plays an important role for agile team to succeed And team A missed that point

Secondly, about barriers of sharing, [11] communication is more efficient with common

ground and that will help team members to share knowledge, so that they can get coordinate

in the team productively But, as Mr Hoang analyses, they have designer, developer, and tester in a team With different backgrounds, the levels of knowledge and the ability to understand every task are also different Plus, in the case, Mr Hoang also transferred four more engineers from team B to team A to support them That also affected the members as

Mr Huy, programmer from team A in DSC shared that he felt distance to share the idea with other team’s members In result, when the team members hesitate to share their

thought, it causes [12] potential risks for distributed agile projects between the team members

Thirdly, Mr Tuan mentioned lack team goal awareness was also considered as a reason leading to transferring insufficient information Normally, a team need to remain united to achieve its goals and objectives [13] But there was hesitation to talk between member and

Mr Hoang If they were closer, thought about team benefit beyond individual’s concern,

he should start the conversation or raise the question in daily meeting and to out if there is

a potential misunderstanding from manager’s interpretation Besides, there was also distance between members in the team since there were two groups merged into one to deploy the project Those factors make them difficult to have open communication, easily pass the hidden information within the team and create risk to achieve the final goal CEO insisted this problem was the most important to be solved since it caused the wrong logic implemented for customer, and the consequence began at the point

1.2 Work overload

One of the other reasons leading to lose the contract in this case is that all members were working overloaded Mr Thang, member of the team shared that, Vietstar offered DSC very tight schedule such as: 10 days to change requirement and 1 day to fix errors regardless

of the actual workload needed Those tasks were so inappropriate that they all felt under high pressure Mr Thang said:

I think they did not know about how many function, they simply thought it was just changing the math But actually, their change leaded to 39 functions changed Before error occurred, we even hardy communicate often since every one is busy and just wanted to focus to get task done We were under very high pressure

To discuss more detail about tight schedule, Mr Thang shared more about the case Vietstar changed their requirement 10 days before the release day So, they needed to restart the sprint and finish within 10 days with many tasks such as changing core table layout, relocating the data, redesigning the payment logics, and updating again the related tables

of database They lost 4 days so in order to catch up the schedule, they needed to work harder than usual with a tighter schedule

The tight schedule affected on the quality of the outcome Members had many huge tasks and they underestimate the small change’s consequences on customer’s business Mr Huynh Cong Thang, member of team A said:

We thought it was not necessary to note at the statement changed since in our point of view they were the same

It means that developers' vision was narrower Besides, with limited time set, there was lack of opportunities for them to improve the software product and process were missed, CEO declared

With normal workload, developers will have 8 days for developing in the process But with new requirement, they had to omit the previous 3-day work, so they just had 5 days left for developing and implementing Their workload is described more in detail with table 8 The next consideration is the Vietstar’s requirement to fix bug within one day which is an inappropriate requirement That was certainly an impossible task for developers based on their estimation As they analyzed from the beginning, the change related to money calculation would affect nine categories and hardly get done with short time Task assignment became overloaded

Mr Hoang said that task assignment is considered as an important activity in software project management that contributes to the success of the product, and VietStar left them

no choice to create appropriate ones for developers He also declared that only the project with Vietstar included the difficulty about workload that they hardly handle, the other smaller projects they have been doing well

Table 8 Comparison between Vietstar’s requirement to change and normal workload

3 Developing and Implementing 3 Developing and Implementing

5 Developing and Implementing 5 Define requirement

9 Developing and Implementing 9 Developing and Implementing

10 Developing and Implementing 10 Developing and Implementing

Source: Internal source)

1.3 Weak customer relationship management

The last reason that CEO mentioned is having weak relationship managment with client showed by lack of communication with client and out of control over client’s demands

Firstly, communication with customers who set requirements or change the requirements

of the project is very important In agile development, customers have to be involved in the development process, and the project information must not be hidden from them [14]

In this case, the daily meetings with customer were lasting longer than expected That caused them lose time for running their own business, so customer reduced the frequency from daily to weekly meetings At this point, scrum master got lack of skill to manage the meeting and find solution to persuade customer to stay Because according to the process, customer need to join the meetings frequently to ensure accurate information

Secondly, customer became more demanding when the unexpected bugs were found Vietstar did not have insufficient knowledge on domain but became aggressive That made the process more difficult [15] However, their reaction was understandable The errors created untrustworthy feeling about product’s quality Vietstar needed to handle the calculation manually on the day when errors appeared So, they lost some budgets for labor with unexpected task The error and consequences made Vietstar become stricter with the time of bug fixing Finally, Vietstar stopped the contract with DSC and refused to pay Customer dissatisfaction will lead to bad results such as negative reputation, sale loss or even the rate of leaving customers will increase dramatically [16] For this reason, DSC needs to focus more on customer relationship in the future, make sure their expectations

by communication, checking tools…to improve not only the service but also the relationship with them

Luckily in this project, the dissatisfaction is clearly shown so that DSC can quickly look back on the development process to find out the problem and fix it So that, they will not face the same situation in the future, CEO stated

2 Problem Validation

The problem “work overload” occurs as a consequence of DSC's lack of requirements recognition This lack of acknowledgment leads to the need for repairing in a short time Therefore, the starting point of this problem was from the fact that they did not fully get

the requirements from customers [17] A study by Buchan provides that inadequate shared information, or breakdowns in sharing from miscommunications and misunderstandings, can create a very high impact on product quality, project costs and development productivity The CEO mentioned that:

To create the exact product that customer wants, developers need to have exact and full of information about not only how it looks like but also how it works

Furthermore, Mr Hoang added:

When the acceptance test on the same sprint came, the client found out that the spec change was not fixed yet After that, they sent the email to complain and require to fix that code within one day

Similar to the work overload, the customer became uncomfortable and the more stringent requirements also appeared since they received an inappropriate product version, which affected their operation Like Mr Hoang said:

VietStar limited the time very strictly When the errors occurred, the team did not have enough time for meeting fixing and finishing the task perfectly in the way they wanted With the other projects, without big misunderstanding like this, we have stable workload Therefore, the root of the problem lies in the incomplete information transmission among group members, leading from inadequate misunderstandings about product usage, making customers more aggressive Like Mr Hoang admitted:

It turned out we did not understand well about the goal Here began the problem so we should fix the communication priorities

The main problem of DSC in this case comes from the fact that they have not communicated enough information to each other about how they understand the requirements

Mr Huy shared:

We failed to meet customer’s requirement The scrum master did not tell us more details about what customer wanted to change It was the payment feature We need to change the statement from “received” to be “on hold” But the scrum master did not mention the spec change during the standup meeting, so the payment feature was not updated or changed Actually, I was concerning about that statement but I could not get it thoroughly

[15] Lack of information is one of the challenges in Agile software development [18] Accordingly, team cannot rely on lack of information to visualize stories then address technical challenges Besides, [19] it has been noted that less mistakes are made and less rework has to be done if important information is continuously shared through informal communication [20] Incomplete information transferring can lead to the potential of negative consequences which impact on project objectives For that, with enough information transferred in the DSC team will help avoid the risk of losing contract in the firm Like Mr Hoang shared:

In advance for the next big project and strict client not to have similar problem, we should make sure every task is clearly transferred and the whole team have the same understanding about tasks to deploy in the right way at the first stage Way to do that is to get everyone share exactly what they do and how they think in details

So, this issue needs to be studied to find out the root cause which comes from within the group So that DSC can find a solution for this situation

IV.CAUSE VALIDATION

Figure 7 Main Cause – Effect Tree

1 Possible causes

1.1 Lack of verbal communication

Communication challenges appear when there is cognitive gap among Agile teams or in the presence of hidden assumption [15] Following [21], Agile practices is to mainly rely

on face to face conversations between team members to communicate, which means internal verbal communication, rather than traditional paradigm such as source code, documentation, plans and models And open communication can support knowledge and experience which are relevant to current task [13] So, having regular conversation with team members like daily stand-up meeting is a must in the team Stand-up meeting not only creates a forum for team members to have regular updates but also creates opportunity to detect the problems in early stage so that it can be quickly solved [22] But, with team A, they reduced not only the time of daily meeting (stand-up meeting) but also the frequency

to have meeting from daily to once per two days, Mr Tran Huu Hoang, manager of team

A shared

Mr Thang also mentioned that members felt there were too many meetings for them to have while they were getting not much to share after a day working So, they asked the manager to reduce the frequency of stand-up meeting But as consulted from the research [22], stand-up meeting helps to identify and avoid problems, solve problems by getting help, share information and knowledge directly and constantly Regular meetings like stand-up will help talk more often and more natural help increase possibility with problem detecting and promptly solving [22] Another point founded [23] that only when there is a stand-up, members start to talk about what they are going to do or mention an obstacle, then the communication that focus about problem will appear So, without the regular conversation, there will be high risk for hidden problem to maintain during the development related to not enough information sharing [23]

Also related to the group's communication, Mr Huy has a different experience He himself felt difficult to express his anxiety in words He realized that there might a problem with the payment shown on the system The point is he only knew the possibility that it would affect, not to get it thoroughly, so he did not know how to raise questions On the other hand, he was afraid of disturbing the group, finally, he kept quiet Huy's problem is belonging to verbal skills [21] indicates that verbal communication is more effective in sharing because it allows rapid mutual feedback and stimulate further thinking

In this situation, if Huy's speaking skills are better, he will confidently raise his concerns

If so, the team will pay attention to the point he asks and discuss together, the possibility

of the problem being found [23] and no system error with deployment are possibly happen

In agile groups, [21] people with poor interactive skills might be excluded from not only these circles but also important communication [24] conducted of communication using verbal can transfer the idea from one individual or a group to another, creates some advantages of being personal, flexible, and helpful in addressing misunderstanding Gregory et al [25] also used verbal skill to estimate the efficiency about engaging with agile practitioners’ concerns and insisted that to communicate effectively using the skill is

a challenge But if the team members practice well, the good result will be achieved

Mr Huy added:

I think the more we talk, the more we can find out the same understanding of what needed to

be done

1.2 Barriers of knowledge sharing

One of the reasons the CEO mentioned that causes the insufficient information transferred

is the barrier preventing members from sharing knowledge

Knowledge and information are different In software development, knowledge is understanding information or skills, but information is simply provided fact [26] If the members have knowledge, that means they have set of procedures to analyze information, understand it, and know what to do with it So, with more knowledge sharing, they can have more procedures for dealing with a concrete situation, a routine, allow them to cope with different situation [27] So that they can have ability to estimate the risk if there is any lack of communication’s consequences with the variable knowledge come from teammates This problem is not new in a software development team There has been a lot of research

on information sharing among an agile team learning about these barriers, such as using cross-functional members or no mutual support while cooperating with another team Firstly, about the cross-functional members As mentioned in Ghobadi [28], 2012, individuals in cross-functional project team are arranged with not only one but some functional units In the team, there are no specific professional titles for each member, for example: testers, programmers, design experts, database specialists, etc which are all called collectively is the "developer" They do not necessarily know all the skills but can fully complement each other so that the whole group has all the necessary skills [29] The fact that developers have different backgrounds is undeniable However, Mr Hoang talked about his concern about this as a possible reason causes members to understand differently about the task If they do the knowledge sharing well, people with lack of experience with developing for example might learn that knowledge and get the right assumption from the one who gets more experience with that section The result of that process can be exact as task requires