Agile software development methodologies encompass not only practices but also values supporting them, and thus the team setting and the tendencies of the people where Agile is deployed affects how the practices are operated. In this paper, we present our study of coaching several software development projects to promote collaboration and improve team health. In our case, we found that the organizational structure and cultural ambience of rank-consciousness and reservedness to be important factors.

1.     INTRODUCTION

Agile started from an interest in how to develop valuable software better in a small team, but has since evolved to encompass a specific culture of working in an organization. The most effective Agile transformation might be a big-bang change, but this is not the track taken for some companies. This could be due to many reasons including hesitance to take a big leap of faith. Hence, often a few pilot projects are operated without disrupting the overall structure of the organization.

We have also taken to piloting Agile to selected software development teams across the organization to improve effectiveness of the teams. As Agile Coaches, we set out to help the teams by guiding the team members on how to perform Agile practices, organizing and facilitating activities, and helping build up a more egalitarian work ambience. We started with Scrum practices as described in the Scrum guide by Schwaber and Sutherland[1] and made additions and tweaks as time went on based on what we deemed as beneficial to the team. What we soon learned was that providing training and trying to perform Agile practices is one thing, but creating the right ambience is another.

We found that operating Agile methods in our organization necessitates taking into account a working culture that has evolved over time influenced by the local cultural background. Characteristics include emphasis of rank-consciousness and functional roles, and hesitancy to speak out openly. We have selected the five factors in the Hackman model of team effectiveness[2] to delineate what to improve and utilized various Agile practices to implement the improvements. In the following sections, we will share our experiences, the current results and lessons learned on the truly bumpy track that we are traveling.

2.     BACKGROUND

Our organization produces many varieties of consumer electronic products and components that are made available across the globe. Our teams are globally distributed and we have teams on various fields such as marketing, hardware development, circuitry development, etc. However, our study is restricted to selected software development teams located in South Korea.

We have applied Agile to enhance team effectiveness for software development projects where close collaboration by members of different groups is essential. We initially started based on the various Agile materials available and the external training we received, but we soon faced situations where by-the-book guidelines specific to us were not readily available. To glimpse what situations an Agile Coach might face when rolling out Agile methodology to our teams, two important factors that affect our projects and members need to be considered.

One factor is organizational structure. Our organization is divided into functional groups to promote efficiency of the specific functions. When a project is setup for product development, members of the functional groups are selected to participate in the project. Rank-consciousness is pervasive within the organization and decision-making approvals often need to go up in the hierarchical tree.

The other factor is the cultural aspect. Local society emphasizes keeping abreast of one’s status in relation to others and showing deference to seniors. People are often hesitant of offering opinions in public due to social etiquette. Openly objecting to seniors is often considered unmannerly and offering a different opinion to the majority publicly is often refrained. People feel pressured to provide the correct answer or reply, and this leads to people not voicing their thoughts when uncertain.

3.     AGILE APPROACHES TO TEAM HEALTH

As Agile Coaches within the organization, we identified our goal as attaining better team health for our software development teams. We selected the five factors presented in Hackman’s model as the areas that we will work on to have a positive effect on team health and set out to utilize Agile methods and practices as shown in Table 1 to correspond to the five factors. Black circle indicates the approach that we selected to have positive effects to a particular factor. The numbers in brackets below each approach name denote the sub-section where we present our experiences involving the corresponding approach.

Table 1. Mapping of the Five Hackman Factors to the Agile Approaches Taken

 

3.1        Team Organization and the Product Owner

The first approach we decided upon is to organize the team and to incorporate the role of Product Owner. This approach is to have positive effects primarily in the Hackman factors of being a real team and having a compelling direction. In order to form a real team we referenced the formation of Scrums and the Whole Team concept where a Scrum team consists of all the needed people to produce a product. We grouped people of different functional groups into Scrums of about ten people each. We also designated a single Product Owner so that the person will be able to inform the Scrum members on decisions concerning the project faster than before.

Our rigid functional group structure provided some challenges. First, it made it difficult to form physically co-located cross-functional teams with everyone following a unified chain of command. It also made it confusing to decide who would be Product Owner as leader roles exist in each functional group.

When organizing Scrums, we assigned members of different functionalities into each Scrum so that planning, UX design, software development, and verification groups have representation in every Scrum. For large-scale deployment involving multiple Scrums, we organized a leader board consisting of the Product Owner, a representative of each Scrum, and a representative from each involved functional group. The role of the leader board is to coordinate priorities and issues among the Product Owner, the Scrums, and associated functional groups more effectively. The Agile Coaches emphasized that the team follow the decision of the Product Owner for cases where a consensus was not reachable within the board.

To create a more collaborative ambience of a unified team and to ease the hesitance to speak out their opinions, we conducted team-building activities early on in the project with every member participating. Team building sped up the familiarization process among the team members, propelling the members to share more information and function as a team.

The consistent interface between the Product Owner and the team members helped the team members set sight on the direction of the project. An important issue that the Agile Coaches could not make changes to was on personnel evaluation. Due to strict organizational policies, personnel evaluation within the functional groups was retained, which influenced the team members to place importance in the directives of the functional group managers. This sometimes led to slower decision making.

3.2        Workshops and Events

The second approach we decided upon is to create team workshops and events to promote information exchange and teamwork. This approach is to have primarily positive effects in the Hackman factor of having a compelling direction. When there is a hierarchy of work being defined and ordered top-down, the project members often find themselves working without clear understanding of the product vision and goals. This lowers both work motivation and pride in the product, and creates a lack of consensus on the needs of the target customer. As Agile Coaches, we wanted all the team members to share equal understanding of product vision and goals as much as possible and to enable the team members to set personal goals in alignment with the organizational goals.

We set out to hold offline workshops and events to have all the project members meet up in person to share information to promote enhanced sharing of product vision and goals. Planning such an event required gaining consensus on having the event itself. For some of the project members, it meant taking time away from the usual run of business. For example, a product planning personnel might feel that he/she already knows all the needs of the product having participated in various senior management meetings. A developer might feel that all he/she needs to do is implement his/her designated modules as defined in requirements and according to mockup design by UX designers.

We organized three types of workshops to cover defining the vision, periodic sharing of goals, and identifying product scenarios. We referenced the practices presented in the Agile Samurai by Rasmusson[3]. To gain participation from the project members concerned, we met up with the members of the functional role groups and explained the importance of the workshops and events.

The Product Vision Workshop is for the Product Owner and the team members to align and contemplate the direction of product development. The Product Owner shares the current product concepts and plans, and the team members analyze the needs from the perspective of the users and customers. The workshop helps the functional group members attain a heightened sense of common objectives and promotes discussion between the participants’ various viewpoints.

The User Story Workshop is for the members to identify usage scenarios, priorities, acceptance criteria, and the Minimum Viable Product aspects of the product being developed. Details previously shared by documentation only are brought up to be discussed in person. The reason behind each functionality and non-functionality and the value presumed are discussed. Developers are able to offer various ideas on the major specifications and functionalities of the product during the workshop. This raises their pride in defining the product and satisfaction in being able to voice concerns on technical difficulties and impact to schedule early on in the project.

The Release Planning Workshop is for establishing mid-term goals and milestones that the members collaborate towards. The workshop is often held periodically so that the PO can update the members on recent changes in the direction of the product, and the members can make plans and suggestions accordingly.

After about half of the project year has passed, we held an event we termed the Half-time Locker Room. The event encompasses reviewing the results of the first half with the team members and stakeholders to discuss what went well, what did not, and areas of improvement. We used the event to create not only consensus going into the second half of the year, but also to encourage the team using pep talks.

To create a livelier ambience, we usually organized the workshops and events at independent locations away from the immediate workplace and arranged for food and beverages. We notified the attendees of the agenda and planned timeline in advance so that they could shift their work schedules. We also always played the role of timekeeper, which often met with approval of the participants.

3.3        Sprint Operations

The third approach we decided upon is the operation of Sprints. This approach is to have positive effects primarily in the Hackman factor of teamwork enabling structure. To increase teamwork among the participating members, we decided to apply the concept of sprints specified in Scrum. As stated earlier, when a project starts, people of various functional groups are assigned to the project to perform specific functions. Sometimes the project members do not feel the need to share what they are currently doing to other members if they are not performing the same function within the team. We decided to use the Scrum framework as the baseline collaboration structure to increase teamwork even though we could not operate fully cross-functional teams.

Because members are self-conscious of hierarchical and social status, many members are reluctant to speak out their minds openly within Agile activities such as sprint planning or retrospectives. People seem hesitant to be the troublemaker and many junior members do not want to be considered impolite. Status within a group seems to be important. A reason that a functional group member said that he did not want to be in a same team with others is because he feared that his lower rank might make his opinions less valued, even though he is a representative of his functional field.

Often the few senior members of a team identified work needed to be done and assigned work to other lower ranking members. In many cases, who does what was pre-determined even before the planning meeting so planning was less involved than expected. Sometimes, a project leader states that the team is already doing Agile activities. A common practice so stated is the daily meeting. However, when we looked into the daily meeting, we sometimes find an hour-long reporting session.

All the project members were asked to participate in the major Scrum activities of planning, review, and retrospective. Members located far away in different cities participated in daily meetings by conference call. All the project members, regardless of functional groups, were asked to use the same Jira and Confluence tools, which are commercial Agile support tools provided by Atlassian company. The cadences of the Scrums of a project were aligned so that every Scrum of a project would be in identical sprint durations. Initially, reviews and retrospectives were held in a single day and planning the day after to emphasize the end and start of a sprint. However, as the projects churned on, we often adjusted to having the review, retrospective, and planning all in a single day due to request by the team members coming from far distances. They preferred doing multiple activities on a single day. To accommodate this, we had pre-planning performed using the online tools prior to the review and made adjustments after the review.

Agile Coaches created a more comfortable ambience during the activities by utilizing different tactics to facilitate conversations. These include asking the seniors to speak last in cases where seniors speaking first led to nobody voicing his or her suggestions, asking the seniors to elaborate more when seniors seem to announce a decision only crisply, asking the juniors if they understood what was being discussed to catalyze participation, and always giving a chance for a participant from each functional group to voice his or her opinions.

While the seniors still identified and planned the work needed and sometimes assigned the juniors with work, juniors were more open to making inquiries to understand the particulars of the tasks. Sometimes juniors ventured to perform the work and identified additional related work tasks. In cases of tasks that team members were reluctant to do, the team discussed how to handle them eventually leading to team members pairing on the work or having team members take turns by sprint.

Maybe having co-located cross-functional team under a single supervisor is the ideal way to go. However, when such ideal formation is not undertaken we have to make do with what we can. A mixture of mandating participation of some activities and creating an ambience where people feel asking questions is safe and valuable promotes collaboration.

3.4        Agile Training and Tools

The fourth approach we decided upon is to have everyone receive Agile training and have the teams use identical Agile tools. This approach is to have positive effects primarily in the Hackman factor of providing supportive context. In order to have every participant understand the Agile mindset and Agile practices, we organized what we termed the Agile Boot Camp that gathered all the team members together for a single day. We also setup and utilized Agile tools, both online and offline to promote information exchange and teamwork among the members.

We set up an Agile Boot Camp program for the team that incorporated various Agile practices so that the team members learn the values of Agile and start on the same page. We designed the Agile Boot Camp so that the first half focus on Agile training and the second half focus on team activities. This includes activities like making team ground rules, designing team activity flow, and drafting the elevator pitch of their actual product. The structure is designed to avoid the participants feeling that it is just another training session in a set training setting. The Agile Boot Camp turned out to be a successful event that received much positive feedback. Many teams that we did not provide coaching to asked us to hold the event for their teams.

In terms of preference between offline and online visualization boards, we tend to use online boards because in many cases team members are not co-located and thus it is easier to share information online. The online board was especially useful in large projects involving multiple Scrums. However, we used offline boards in projects where the project was newly formed, able to meet frequently, and the members were unfamiliar with one another. We found that meetings in front of physical boards, using post-its and pieces by hand, greatly sped up the familiarization process.

3.5        The Agile Coach and the Team Agile Leader

The fifth and final approach we decided upon is the role of the Agile Coach and the Team Agile Leader. This approach is to have primarily positive effects in the Hackman factor of coaching and guidance availability. Agile guidelines were included in the corporate SW development process documentation and interested teams applied Agile practices such as sprint planning, daily meeting, sprint review and retrospectives based on the guidance.

In order to help the Agile teams understand the values Agile pursues along with how to perform Agile practices, a group of Agile Coaches was formed to provide immediate coaching support to the teams. We are part of that group and are responsible for coaching the team, defining Agile practices tailored to the team organization, operating the training sessions, and spreading Agile culture to the organization.

However, we realized the limited number of Agile Coaches cannot support all the teams wanting to be Agile, so we set up a support mechanism. We defined the Team Agile Leader to be responsible for promoting Agile and training the team members internally as a role within a team. However, each team had questions about who to assign the Team Agile Leader role, the responsibilities of the role, and how it differs from a manager role. Our recommendation is a team member who feels comfortable communicating with the Product Owner and shows a knack for facilitating communication amongst the members. We provided training sessions to the Team Agile Leaders to help them function as an internal agent to catalyze Agile within the team. Team Agile Leaders within the team were valuable in providing Agile support quickly.

Additional coaching support from an Agile Coach external to the team helped the team better apply Agile. Team Agile Leaders talking directly to the PO did not work as smoothly as hoped because it was difficult for them to give negative feedback to superiors. An external Agile Coach is able to speak more frankly about topics on leadership of managers, ways of working, and so on. The Agile Coaches also operated an Agile online community website within our intranet community network and held periodic offline meetups of interested parties. The Team Agile Leaders were able to share difficulties and share experiences with each other through these channels. Agile Coaches also created training sessions for the Product Owner so that Product Owners understand the change trends in leadership and the role of Product Owner in Agile.

4.     SURVEY RESULTS

Figure 1. Improvements in Team Health Survey

While ‘team health’ may mean many things, we selected improvements in team work, information exchange, communication, self-motivation, and clear purpose as our baseline. We have attained increased team health category results as shown in Figure 1 based on surveys performed before and after Agile coaching for ten projects. We attained higher improvements in information exchange and communication. This would be affected by the operation of sprints and various tools that the Agile Coaches use to create a comfortable ambience. Project members felt that they received more information compared to before and were able to divulge their thoughts and opinions more openly. While we did not have all-day co-location implemented, having the members of different groups together for the Agile activities and using the same tools greatly helped.

However, comparatively lesser improvement results were attained in self-motivation, teamwork, and clear purpose. This is likely due to organization structure limitations. Members did state that the other team members actually felt like real people in contrast to when they only communicated using emails, phone calls, and instant messengers. The members expressed certain satisfaction that the participating members of the Scrum team took upon themselves to share information and make decisions either internally or have the Product Owner make them. However, while the Scrum teams made decisions within the team as much as they could in collaboration with the Product Owner, sometimes decisions made by the Scrum team were overturned externally afterwards. This led to the team being less motivated to make decisions, lessening the sense of one unified team, and decreasing sense of project purpose with the members feeling that their decisions are not valued.

5.     WHAT WE LEARNED

We found many of the teams that we provided coaching to be initially generally quiet. Two approaches always seem to help break the ice. One, there always seemed to be an opinion leader or two whom many of the team members are influenced by. The person may or may not be the official manager of the team. How that person interacts with the coach (to show how much value is placed in Agile) and how the person engages in creating a more egalitarian team (by showing his/her active participation) has crucial impacts on the team. If the coach is able to win the person over, this helped with quickly instilling a livelier ambience.

Second, the team members were likely to open up to the Agile Coach when the coach emphasized time keeping, especially with seniors or supervisors. The team members often are reluctant to interrupt a senior or supervisor even if the person is going on regardless of time. If the coach operates time keeping without offending the senior or supervisor involved, this led to heightened trust by the team members.

Once the right ambience is set in place and the team members feel comfortable, it turns out that many of the juniors do put forward their opinions and like to have discussions with seniors but have not done so for fear of being considered impolite. This might actually be a mental inhibition set due to years of local cultural upbringing. People have to feel that it is not losing face to say that you do not know something and need help from others. The Agile Coach’s role as the flint to set the spark to creating such comfort zone is important. Many teams stated that having an Agile Coach who does not directly answers to the manager helps getting the system to work.

We deployed several practices to enhance team health within the boundaries of functional group based structure, and have gotten some meaningful results as shown in the survey results. The organization has so far thrived in a structure of functional groups and the need to change the organizational structure to product based cross-functional teams is not felt as necessitated as many proponents of cross-functional teams preach. However, it would be interesting to see if additional benefits could be attained if even a portion of the organization was re-organized to fully cross-functional teams.

To that end, we plan to initiate a pilot where a team composed of cross-functional members is grouped together physically. Selected members of other groups will be placed into the team, and organization policies such as personal evaluations performed within the team.

6.     ACKNOWLEDGEMENTS

We would like to thank all the Agile Coaches who have participated in promoting Agile across the organization and the many project team members have collaborated with us to better practice Agile. We would especially like to mention the people who have been working together for many years to promote Agile within our organization. Mr. Joonbae Park, who has been leading and continuously supporting the Agile Coaches, Ms. Myoungju Yoo, who has been crucial in adopting Agile within our organization since the very beginning, Mr. Sejoong Kim, always a reliable coach one can depend on, Mr. Myeongsang Yu, whose many talents have been essential in our work, Ms. Hye-Young Ryu, steadfast and witty throughout the day, and Ms. Hyoeun Kristine Lee, whose cheerful demeanor and great ideas always helped. None of our work would have been possible without them. We would also like to thank Mr. Kangtae Kim, our corporate VP and Team Head, for supporting the endeavors and Mr. Tae-Hyung Kim for providing guidance and help with the report. Finally, we would like to thank our shepherd, Mr. Mark Kilby, for helping us to write up this paper and providing us with valuable comments and suggestions.

REFERENCES

[1] Schwaber, K. & Sutherland J. “The Scrum Guide”, 5th revised edition, 2017

[2] Hackman, J. R. “Leading Teams: Setting the Stage for Great Performances”, Harvard Business Press, 2002

[3] Rasmusson, J. “The Agile Samurai”, The Pragmatic Bookshelf, 2010