Tài liệu Lack of verbal communication in agile development team a case of digital co., ltd

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 1 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 2 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. 3 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. 4 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. 5 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 clientoriented 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. 6 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. 7 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 8 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 standup 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. 9 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. 10 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 11 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 Year 2016 2017 2018 (if finish successfully) Vietstar contract value 208 312 395 1,300 DSC Revenue 2,900 3,600 4,600 5,000 % 7.2 8.7 8.6 10 (Unit: million VND) (Source: Internal source) 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) 12 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 Phase length Contract value Project’s size (month) (million/month) Definition 4 1 60 – 89 Small 4 2-3 90 – 199 Medium 8 3-4 >= 200 Big Number of men (Source: Internal source) For the project with Vietstar, firstly, DSC directed team A with 4 developers to deploy. But for the last sprint with the changed spec, it was risky and too overload based on CEO’s 13 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 Days per Hours per Overtime Total Project’s team sprint day (hours/day) Man-days size (1) (2) (3) (4) =(1)x(2)x(3)+(4) definition 4 developers 14 5 0-<2 280 - 391 Small 4 developers 14 5 2-<4 392 - 503 Medium 4 developers 14 5 >=4 >=504 Big (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. 14 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 15 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 Vietstar’s For team A+B requirement 32 man-day = 4 working days 1 working day (Source: Internal Source) Table 4 shows the different time estimation between normal calculation with Vietstar’s requirement. Normally, it would take 32 man-days to finish the new spec similar with this second request. There were eight members in the team, so they needed to have four working days to update. That means new spec needed to be done within one working day is an impossible task with the team. 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. 16 Table 5. Record of customer’s complaint from 2015 to 2019 Year Number of complaints 2015 2016 0 0 2017 2018 2019 0 0 2 (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 Complaints Customer Year Contents of complaints 1st Vietstar 2019 Fail to meet requirement 2nd Vietstar 2019 Behind schedule (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.