Experience Report

Dragon Dance: Large Scale Agile Transformation in Traditional Telecommunication Company

About this Publication

The journey of leading large scale agile transformation is extremely tough. There are hundreds of ways that might lead to a dead end, but one particular path works. This topic will present a proven successful example of how to meet various challenges and overcome obstacles and difficulties during different phases in the agile transformation for one 500+ people organization of a traditional Chinese telecommunications company. This real-experience story will start from how to design and layout the agile transformation strategies and tactics. The following transformation phases then include Alignment, Pilot, Reorganization and Rollout. This paper will present audience with a multi-angle perspective of agile transformation with aspects of obstacles, difficulties, coaching skills, techniques, mindsets, and pitfalls from both the enterprise dimension and teams dimension. At last, this topic will summarize the insights and introspects about Alignment, Rituals, Momentum, the Secret of leading change, and an agile coach’s True north.


ZTE Cooperation, a Chinese giant dragon with about 50,000 employees worldwide, is a leading global telecommunication equipment and network solution provider. However, this traditional telecommunication company suffered from enormous pains such as a very long product lead-time (typically more than 1 year), low efficiency, heavy process, and boundaries between departments.  The major problems in program and project level were: requirements were misunderstood layers by layers, projects priority conflict, resource conflict, estimations made by patting head, development work load cannot be shared between different teams, project delayed, etc.

As an external agile consultant, I was invited to ZTE Corporation as their Enterprise agile coach by the Head of EPG (Enterprise Process Group) in November 2013. My mission was to lead the agile transformation for Fixed Network Business Unit, a 500+ people organization that included 3 R&D departments, 1 System Testing department, and 1 System and Architecture department. The organization’s functions and responsibilities cross between Marketing, Product Planning, Product and Project Management, Software Development, Hardware Development, and Integration & System Testing to Pre-production. My goal was to reduce Product TTM (Time To Market) and increase efficiency at the company level and to solve problems at the program and project level.


The agile transformation journey started with interviewing key stakeholders and all counterparts, including Head of Fixed Network, Business Owner, Head of R&D departments, Head of Sales, Product Managers, Project Managers, Developers, QAs, System Testing Engineers, EPG leader, etc. Following the interviews, I planned out an agile transformation solution that included four major phases:  Alignment, Pilot, Reorganization, and Rollout.

2.1 Alignment

One of the biggest obstacles to the agile transformation was that very few people in the organization knew and understood Agile and the majority of people were skeptical towards what we were planning to achieve. I conducted the ‘Influence-Interest’ analysis to identify ‘Powerful Supporters’ (Quarter I. High Influence and High Interest of agile transformation) and ‘Solicit Supporters’ (Quarter II. High Influence and low Interest of agile transformation) and pulled them in as the members of the ETC (Enterprise Transformation Community) team. The Influence-Interest diagram is shown as Figure 1 in the attachment. My strategy was to let “Quarter I. Powerful Supporters” to be the transformation Engine and, by showing the proven successful example, to pull in “Quarter II. Solicit Supporter” gradually into the Quarter I.

Another major challenge was that very few people were willing to step forward to lead changes inside the organization. The approach was to allow the organization’s top leaders to change themselves and to lead change by themselves. I initiated 11 Epic User Stories to empower change and played the roles of a director and a producer in the backstage for the drama of agile transformation. These 11 Epics were Business Strategy, Organization Restructure, Process Redesign, Agile Team Initiation and Development, Competence Mastery, Continuous Integration, System Testing Preposition, Career Path Redesign, Measurement, Performance Appraisal, and Agile culture and environment.

The most important approach used was to let each department head be one specific Epic owner (we called this role the “CEO” or Chief Epic Owner) and to be responsible for the Epic’s end-to-end delivery. ETC team was setup as a Scrum team which ran one week Sprints. These “CEOs” were Scrum team members, I was the Scrum Master, and the head of System and Architecture department was the Product Owner. For each Epic in every Sprint, we held Planning on Monday mornings, Review on Friday afternoons followed by Retrospective; Daily Standups were held every morning at 9am. This tactic was to ensure that the “CEOs” would feel ownership and collaborate with each other, as well as to allow “CEOs” to see progress and feel fulfilled about the every Sprint outcome.

The people in EPG (Enterprise Process Group) had a passion and an interest to lead change. However, they did not have much power or influence in this organization. I identified EPG people as ‘Solid Ally’ (see Figure 1. Quarter III. High Interest and Low Influence). My Strategy was first to teach them about Scrum methodology, and then by practicing Scrum let them contribute to several Epics development (such as Continuous Integration, Career Path Redesign, Measurement, etc.). By pairing “CEOs,” who were key stakeholders (and also our ‘Powerful supporters’), with people in EPG (Solid Ally), and having “CEOs” mentor people in EPG, EPG ‘s capability and influence increased rapidly.

As designed, we held an ETC kickoff meeting. This was an important ritual where the Head of Fixed Network (the “Godfather”) stated the organization’s current state, what the pain points were, the agile transformation goal and the direction of the organization. There was a procedure that every manager write down his/her signature as an explicit commitment to the agile transformation project and their determination to succeed.  I call this is the art of ritual – psychology works invisibly and subconsciously.

2.2 Pilot

In Chinese culture, especially within a traditional company, the majority of people are more likely to reserve their opinion and avoid being the first person to try something new with high risk. The approach to push transformation forward was to demonstrate proven successful examples and to remove all impediments such as fear. We did the pilot by setting up 3 new feature teams whose team members came from different component teams and the system testing department. These feature teams each had full responsibility of end-to-end product delivery, including requirement analysis, architecture and UI design, implementation, testing, integration and customer field delivery.

In the team initiative phase, I facilitated the “Self-design Feature Team workshop” on day 0 (the day before Scrum team setup). After giving initial constraints, such like team size (5~9 team member), gender balance, cross-functional, and a feature team basic profile, the engineers designed the team member structure by themselves via total three rounds. I gave them initial constraints in the first round; each team refined their own constrains in the second round; in the third round, we picked up a current on-going project, and had a simulation that if we setup team like that, would something bad happen or would the team be able to deliver? Then, we found the “bugs” and corrected them. They enjoyed the process of finding their right partners in the same camp. Then for each team we created the team vision, value, team slogan and working agreement.

After feature teams were setup we met some mindset impediments and dysfunctions at the very beginning. Team members were reluctant to learn the “new component” and afraid to touch other’s codebase. Developers didn’t have much motivation to do testing. System Testing engineer felt himself like an orphan in orphanage. To address these problems, I applied ‘The Five Dysfunctions of a Team” pyramid [1] to develop the new feature teams.

I facilitated the “Trust Building Workshop” by using “Personal Journey” [2] to encourage team members learn of each other’s history and personal stories. I still remember that there were many touching moments where team members were about to cry when they heard of their buddies’ difficult stories. After that workshop, team members understood each other much more deeply and knew why they were previously acting in certain ways and who they were truly.

After building the foundation layer of Trust, we used ‘Team Technique Skill Map’ to develop team members’ competence from “I” (Specialist) to “T” (Generalist and Specialist) and towards to goal of “O” (Universal Specialist). Meanwhile, I was continuously instilling the “All-stack Engineer” concept and “Working without job title” mindset to team.  Later, team members started XP engineering practices such as pair working to learn each other’s component, pair programming, peer code review/group code review, creating CI (Continuous Integration) framework, and writing automatic test case.

Nothing acts as fast as the speed of trust [3]. Team members collaborated with each other much more smoothly and effectively as one family. After 2 to 3 Sprints, these 3 pilot teams’ competency increased incredibly, and they were even able to do integration and system testing in full configuration test bench. At the end of the 3rd Sprint, one Team found 8 system level bugs (including 3 critical bugs) during their system testing. The feature cycle time reduced from 32days to 20days. The deliverable product versions increased by 20%. The feature teams’ members felt the joy of greater achievement they have never seen before.

2.3 Reorganization

2.3.1 Foundation Layout for Reorganization

The success stories behind these 3 feature teams increased the confidence of ETC team. As the same time, I delivered Agile, Scrum Framework and Kanban trainings. This was to lay the solid foundation of shared understanding of Agile values, principles and methodologies, and to ensure everyone knew the WHY and the Purpose.

In parallel, in order to develop internal coaches and shift the traditional managers to be organizational coaches or Scrum Masters, I organized the Coach CoP (Community of Practice), which was held every Thursday afternoon for 1.5 hours.  The Coach CoP members were people who had the willingness to be an internal coach and included the heads of departments, EPG group members, Scrum Masters, Product Owners, QAs, etc.

There were two phases of the Coach CoP. During the first phase, I directly coached the first wave of coaches that included the heads of departments and several Scrum Masters. I called them ‘Seeded Coaches.’ During the second phase, the Seeded Coaches (the Heads of departments) coached their own Scrum Masters via running their own Scrum Master CoP in their own departments.

The biggest challenge and setback for me happened when I was coaching the R&D heads. One R&D head whom I will call Penny, was once typical ‘Command and Control’ manager. Her management style was to micromanage inside of her department and be very tough to her peers who had to collaborate with her. Some conflicts occurred happened between Penny and the Product managers. I spent a lot of time coaching her. I tried to be a mirror, let her have the awareness about what had happened, and give her feedback from others and my observations. I tried to show her the true image. She recognized her problem but, due to long-term inertia, found it very difficult change herself within a short time.

Also conflicts happened between she and her boss, the Head of Fixed Network. The Head considered replacing her, but I convinced the Head several times to give her more chances since I knew her purpose and intention was not bad. However, this R&D head thought it was because of me after I arrive at this organization and shared my observations with her boss that exposed her weakness in front of everybody.

Later on, during the coach sessions, in front of the department heads, Penny became angry towards me when she had different opinions. I felt very embarrassed and frustrated. But I encouraged myself and recognized that she was not against me but just held different opinions.   Penny did have good intentions and purpose towards building a better organization.

The following day, I refreshed myself and decided start from zero. I reminded myself about “clean communication” [4], seeking to understand and recognizing the perfection first, instead of offering advices. I came to Penny and had a very deep conversation with her for more than 4 hours until late evening after work. We opened our hearts, exchanged our ideas about management, talked about the life and dreams. Suddenly I found she was a new person I never knew. I really appreciated that she put almost all her effort and passion to the work and to this company.

After several times of deep conversations, both of us had changed. This was a bidirectional growing up procedure for her and also for me.  I improved the way in how I listened. I starting giving more neutral feedback, while Penny started to make consciousness efforts to try servant leadership in coaching style. My lesson learnt for this case is the ‘True North’ of an agile coach is to put my full true heart to work with. Only one true heart can open the door of another true heart. Without a true heart, it doesn’t matter how many coaching skills I have, I cannot reach the other person, setup the connection and grow up together with him/her.

During continuous learning and practicing, the Seeded Coaches were more conscious to change their management style gradually from ‘Command and Control’ to ‘Servant leadership’ and ‘Coach style’.

Instead of traditional appointment of Scrum Masters, we opened the Scrum Master role publicly to all employees. In this way, everybody got the chance to think about these 2 questions: Do I have the willingness to be a Scrum Master? How to be a good Scrum Master? The first wave, 25 Scrum Masters had been selected based on willingness and potential capability.

2.3.2 Reorganization Design and Deployment

After we went through the pilot phase successfully and laid a solid foundation, we took advantage of the positive momentum and started to implement re-organization. In order to shorten the product end-to-end delivery time, we reorganize the Component-based teams to Feature-based teams based on the customization of LeSS (Large Scale Scrum) framework [5]. As shown as Figure 2, previously product delivery were based on components development and then followed by integration and system testing while, after reorganization, product delivery was based on customer-oriented feature delivery.

Since the size of this organization is over 500+ people, I applied LeSS Huge [6], and did the customization according to the telecommunication product characteristics.  As shown as Figure 3. After reorganization, each product (total 3 Fixed Network products) has one CPO (Chief Product Owner), who transitioned from previous Product Manager. Each product was divided into 3 RAs (Requirement Areas). RA was the requirement area of customer-oriented product feature, including the slice of network management, application, and driver. Each RA had one APO (Area Product Owner) whose responsibility was to focus on the product feature end-to-end delivery.

Since the chip drivers’ high technique barrier and high learning cost, after balancing of ROI (Return on Investment), we kept the driver teams still as the previous component teams. All other above layers components are sliced and reorganized as feature teams.

According to teams’ specific situation, feature teams adopted Scrum; platform component teams, such as driver teams, adopted either Kanban or Scrumban. Based on initiative rules, everyone had the right to choose their Team and with the Product Owner and Scrum Master he/she wanted to work.  In this way, we planted the self-organized seeds in this re-born organization.

2.4 Rollout

After reorganization, we rolled out the Agile methodologies to all products and all Agile teams. There were a total of 42 teams, and they adopted either Scrum or Kanban or Scrumban. Every product had its own single Product Backlog. The PBI (Product Backlog Item) was prioritized according to ROI by CPO, APOs and POs.

To progress the agile transformation 11 Epics forward, the ETC team took one week Sprints, and every 4 Sprints were organized as 1 release. By the end of every month, we held a Release Review to show the outputs and outcomes to all key stakeholders inside and outside of the organization, to keep them informed of what had happened as well as the improvement results.

Based on feedback from key stakeholders, we continuously inspected and adapted our actions to the next Release and following Sprints. The ETC team held a transformation Summary and Retrospective at the end of every phase.


The most traditional companies use metrics and KPIs (Key Performance Indexes) to evaluate performance. However, during my quite long time’s observation, whenever management team wants to use KPI for performance evaluation, KPI data may not be reliable. People from every level always can find ways to come out with good KPIs which may be far from the truth. In order to avoid the KPI pitfall, I abstracted one rule of measurement: “Continuous Improvement over Performance Evaluation”. That is to let management team to use the metrics and data’s informational functionality to drive continuous improvement rather than to conduct performance evaluation. I coached ETC members to understand the purpose of measurement and this rule from the very beginning.

Based on this, we designed measurement indexes, which measures from a higher level. Starting from the beginning of agile transformation until now (14 months), we have achieved the following results:

  • Average product TTM (Time To Market) decreased from 1 year to 102 days, decreased 72%.
  • Overall Customer Satisfaction increased 6%.
  • Average Feature Lead Time reduced from 30 days to 8 days, decreased by 73%.
  • Average R&D efficiency increased 12%.

By guiding with the concept of “Collaboration over Accountability”, “CEOs” of ETC team were closely working with each other and supporting each other. The departments’ boundaries finally had been taken down. The heads of departments were glad to help each other solve problems. ‘Working without job title’ and pair working happened with everyone every day. Work duplication and rework decreased. Scrum team members were working together back and forth to clarify the requirements. Since all teams were dedicated to contribute to one product, there were no resource conflicts anymore. Scrum teams were building up gradually to have the capability to share the development load; The estimation for user stories were based on story points, and team made commitment according to their history. Projects were seldom delayed anymore.

Results from the employee satisfaction survey saw high scores in aspects of Process of Product/Project management, Communication, Collaboration, Ownership, Efficiency, and Do the right things. This traditional Chinese dragon is flying in the sky.

On my last day of this agile transformation project, The Head of Fixed Network and ETC team held an Acknowledgement party to thank me for my Enterprise agile coaching job in their organization for past 11 months. They sent me their new product (hasn’t started selling on the market yet) as a gift plus a very nice photo album full of photos from my working moments. And most impressively, they made a video to express their thoughts: “What are the impressions of Sunny; what we learnt; what we changed”. At the end of the party, the Head said: “I have never seen you all like you are right now with such great passion to get things done! I am proud of everyone! Thanks Sunny for leading us to achieve this!”


The journey of Leading a large scale agile transformation for a traditional company is extremely tough. Before starting the journey of transformation, alignment with every stakeholder (including powerful supporter, solicit supporter and solid allay) really does matter.  The enterprise agile Coach should be the backstage person, designing the transformation scripts, setting up the show stage, guiding the acting, and letting all stakeholders bring themselves into the full play. These stakeholders were organized as one ETC Scrum team, empowered from the very beginning from the agile transformation kickoff meeting and every release review meeting. These meetings were important rituals to let psychology of success work invisibly and subconsciously. In the pilot phase, self-organized culture was fostered from Day 0 by letting Scrum teams design their own team’s structure, vision and culture. After the pilot was successful, we needed to take the positive momentum to make a bigger change – reorganization happen.

All organizational stakeholders owned their decisions and commitments, engaged their actions, and they enjoyed their outcomes and achievements. This was the secret to how an external Agile consultant was able to introduce a big change for a large organization and build up this organization’s capability for continuous improvement.

The last and most important thing is that as an agile coach I do find my true north, that my TRUE heart is to make the people better and the organization better. No matter how skillful you are, only with your true heart can you unlock doors for people and never give up during the extremely tough journeys.


This paper would not have been possible without the help of many great people. There are three people in particular I would like to thank: Su ChunShan, Lv Yi, and Charles Mak. Su Chunshan, the EPG head of ZTE Cooperation, is my best partner to make this large scale agile transformation happen. Lv Yi keeps mentoring me about selection of paper’s perspective and helps me generate valuable insights. Without my fiancé Charles Mak’s encouragement and support, this paper would be a mere shadow of itself.

Finally, I would sincerely thank Johanna Rothman, my dearest shepherd, for guiding me in writing a professional paper. Her book “Manage it! Your Guide to Modern, Pragmatic Project Management” opened a door for me to a new world of agile project management 8 years ago.  And I was so lucky that I met her in Agile 2014 Orlando Conference. Her great patience and rich energy impressed me a lot. During this paper shepherding, she asked me a lot of powerful questions and allowed me think much more deeply. Furthermore, she mentored me about how to improve work efficiency, and provided plenty of wise and practical advices about career development and personal life. She is my role model and a woman I want to be.


[1] Patrick Lencioni, The Five Dysfunctions of a Team. Jossey-Bass. April 11, 2002. ISBN-13: 978-0787960759

[2] Lyssa Adkins, Coaching Agile Teams: A companion for Scrum Masters, Agile Coaches, and Project Managers in Transition. Addison-Wesley Professional. May 28, 2010. ISBN-13: 078-5342647700

[3] Stephen M.R. Covey, The speed of trust: The One Thing that Changes Everything. FREE PRESS.  February 5, 2008. ISBN-13: 978-1416549000.

[4] Thomas Leonard, 15 coaching Proficiencies. http://www.bestofthomas.com/profs/

[5] LeSS, Large Scale Scrum, http://less.works/

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related Agile Experience Reports

The ongoing transformation of ExxonMobil Information Technology began with a fistful of passionate Agile proponents. Along the way, their efforts have led to increased support, influence and a growing portfolio of high-performing Agile teams. 1.     …
The ongoing transformation of ExxonMobil Information Technology began with a fistful of passionate Agile proponents. Along the way, their efforts have led to increased support, influence and a growing portfolio of high-performing Agile teams. 1.     …

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now