Inhalt : Agile project management in a multi-cultural context - an example from Saudi-Arabia

Abstract

Every politicians' first 100 days in a new position are crucial. yThe need to gain an overview over their area of responsibility quickly in order to take first decisions, allowing for realizing "Quick-wins". Furthermore, a strategic direction needs to be set for future development of the organization at hand. The authors of this article are business consultants that attempted primarily to facilitate the first of the mentioned objectives: Get an overview of the situation quickly. The "Performance management" workstream they worked for had the objective to install a monthly performance reporting. The scope, being undefined in the beginning, was shaped continuously and amended in an ad-hoc manner throughout the bespoke politician's first 100 days in charge. The authors chose to respond to this environment with agile practices, which the deployed within their team of both consultants and employees of the client organization.

This article gives an example of how agile management practices can add substantial value, also in contexts of multi-nationality and multi-culturality. Problems and potential solutions are presented, implications discussed.

Introduction

The outbreak of the Corona virus (MERS-CoV) shed light on significant deficiencies within the Ministry of Health (MoH) in Saudi Arabia. In the waves of this emerging crisis, His Excellency, Abdullah bin Abdulaziz Al Rabiah, the Minister of Health of Saudi Arabia had been relieved of his duties with effect of 11 May 2015. His preliminary successor was H.E. Adel Fakieh, who at the time in parallel headed the Ministry of Labor. Like other politicians, H.E., the Minister was willing to obtain a quick yet valid overview over the situation of the Ministry of Health and, in this specific case, the current state of the healthcare system of the Kingdom of Saudi Arabia. To gain both, a quick and holistic overview, a 100-days program comprising eight streams was set up with the help of many external consultants focussing on the following key-aspects:

• Clinical

• Regulations

• Facilities

• Technology

• Performance Management

This chapter focusses on the agile handling of the Performance Management Stream and highlights inter-cultural problems that the project team encountered throughout the project.

 Scope and Objectives of the engagement

The authors’ employing company was engaged for assistance throughout these first 100 days of the new minister’s reign, specifically responsible for the performance management workstream. This workstream consisted of four consultants in addition to the two authors and one managing partner. It had the main objective to install a monthly performance reporting. The exact scope of the performance management was undefined in the beginning. The minister himself shaped and amended the scope continuously as he obtained more information about low performance of either the healthcare system or the ministry.

Such a project environment calls for agile methods, although not being a software development project: high needs for early and continuous delivery of a visible, minimum viable product prevail. The product in this case was a report for top executives, well founded and of highest quality. With 100 days being a very tight schedule for setting up a performance reporting, the team quickly and unanimously agreed to employ agile practices. Initial training of the delivery team was conducted internally, product owner and Scrum master were determined, before initial planning of the product backlog began.

In the following, we explain the project environment in detail, emphasizing the context of Middle Eastern culture, which was new to the whole team of consultants. The subsequent chapter explains the specifics of our approach to agile management within the project. Lastly, we summarize our findings and derive recommendations for future agile practitioners in multi-cultural contexts.

 Environment

The project was embedded into a very specific and challenging environment. This is true for both, the macro-environment (Saudi Arabia and Islamic culture) and the micro-environment (MoH organizational structure and team composition).

When working on projects in the Middle East, and particularly in Saudi Arabia, the intercultural context in terms of identity, values, basic assumptions, competencies and behaviour becomes a leading success factor. Saudi-Arabia is an absolute monarchy with a uniquely strong connection to the principles and teachings of Islam. Religious aspects play an essential part in daily routine, behaviour and decision making among Saudi Arabian citizens. In addition, family ties and relationships are valued extremely high and can much easier affect dedication to work than would be experienced in western cultures. Hence, in order to deliver a multi-stakeholder project like ours successfully, it was essential to adapt the efficiency-driven approach we were used to to the cultural requirements of Saudi Arabia.

In addition to the general intercultural challenges, we found ourselves in a situation of particular uncertainty due to the organizational transformation that the Ministry of Health was undergoing during the initiation phase of our project. H.E., the Acting Minister of Health, was - despite his uncontested political skills and outstanding business acumen - a newcomer in the subject of healthcare. By contrast, all second-level management posts (Director Generals) were held by medical doctors with little experience and enthusiasm for performance measurement and target orientation. Satisfying the performance management requirements of H.E., the Acting Minister, while at the same time building relationships with the Director Generals became a continuous balancing act for our team.

The project situation was further complicated by our core team structure. The project owner was the Assistant Deputy Minister of Planning & Training and our counterpart team was the Decision Support Unit (DSU). This unit consisted of five members, three females and two males, who combined basic medical and analytical skills. The challenge was that the DSU was not part of the Ministry’s organizational chart and acted more or less as a “shadow squad” for ad-hoc requests addressed to the Assistant Deputy Minister of Planning & Training. In a culture, where hierarchy, power, trust and seniority are major incentives for cooperation, obtaining information or even meetings is a daunting task without a well-recognized team acting as “door-opener” and “engagement manager”.

After initial failures to produce the required results, the team sought to engage the DSU team properly within the agile process from the very beginning. Our main challenge in this was to build appropriate and culturally-accepted stakeholder relationships with the counterpart team.

We structure our experiences along the scrum process. For each of its steps we point out noteworthy situations for each of the dimensions identity, Values and Basic Assumptions, Competencies and Behavior.

 The Agile Setup

1. Sprints

After the delivery of a concept which demonstrated our approach to performance management, we received challenging feedback. It was believed that we would not deliver to our committed approach.

We started the Scrum process with very short sprint cycles of merely two hours (at the end of the 100 days, we were sustaining weekly sprint-cycles but still had a ready-to-deliver product each night). While this approach can righteously be assumed to create a massive amount of overhead, it gave the product owner the possibility to align the team onto his product vision very frequently. Assumptions and beliefs could be clarified rapidly in this very early stage, from which especially the younger consultants on the team benefited greatly. Over the passing of the first few days, we noticed how the high amount of “routine-time” led to an utterly rapid identity forming of the team. The consultants realized the necessity of the approach and started to believe in the team’s ability to adhere to its self-set delivery promise - a first performance management report, if meagre in substance, by the end of the first working week. Also, the visibility on expert knowledge within the team was high from the very beginning, so the team could sequence their activities effectiveley and self-managed, based on an integrated overview over competencies and work capacity.

While this approach indeed led to a successful creation of a shippable product by the end of the working week, the team noticed that it had done the work all by themselves. The data needed for the product creation had been readily available before, so no interaction with the Saudi counterpart team had been necessary. In a retrospective, it was found that the DSU team should be integrated more closely into the the Scrum process, from which it had abstained within the first week.

1. Standup meeting

Beginning with the second week, we started to attempt exactly this, and invited the DSU team to our, now daily, standup meetings. We noticed how suspicious the DSU team members were at the beginning to participate in meetings that involved group discussions and especially the moving of task stickers on the Scrum board. We later found out that what we experienced was a reflection of a social conflict. The working culture we entered was utterly used to top-down command-and-control, which reflects the Arabian hierarchy-emphasizing culture. Unfortunately, we were socially unaware of this conflict - it would traditionally not be addressed as directly as it would be in a western culture. We altered our Scrum process insofar as we would primarily address the most senior team member of the DSU team and ask for approval of task assignments. The conflict gradually subsided and the team started to see and live an acceptable working mode that circumvented hierarchical conflicts. After a few weeks’ time the team grew closer together. Our team was utterly excited to be invited for lunch and dinner on an almost regular basis, which we gauged as a good indicator of team-team-fit.

+ Kanbanization (bigger team sizes -> longer standups -> empowered juniors organized their own kanban board)

1. Scrum board & Tools

 The agile project set-up was supported by the active use of various tools. The selection and introduction of these tools always derived from a concrete demand from a project team member and was an integral part of the daily standup meetings or sprint retrospectives. The following graph shows an overview of the major tools used in the project.

1. Scrum Board

An analogue scrum board was used as the central tool for planning, organizing and managing stories, tasks and impediments. In the course of the project the scrum board was continuously enhanced with additional elements such as a velocity-counter to count the number of completed story-points during the past sprint or a review-clock that showed a defined point of time for consolidation of the various work elements into the product format or a special area for blocked stories and for “after-sprint” tasks, i.e. stories that were to be completed after the actual review meeting. In particular the “after-sprint” tasks reflected the particular conditions of conceptual consulting projects, where information is gathered throughout the conventional working day and processed afterwards.

1. TeamUp

As part of the retrospective after completion and delivery of the first report to H.E., the team analyzed repetitive tasks occurring throughout the sprint. The time-planning of these activities was conducted in the online tool Teamup. The tool helped the core team as well as external team members to gain an accurate overview on the time-planning of the activities at any time.

1. Trello

By the time the project arrived at a more mature and complex stage it became critical to collaborate via a tool that is capable of integrating and providing complex contents. After a joint exploration the team found Trello, an online collaboration tool that proved to be an excellent solution for defining, clustering and managing activities. Color coding and the option to set due dates allowed the project managers to gain a rapid estimation of project risks. Although Trello provides all features to digitalize the scrum-board but the team jointly agreed that the experience of the physical presence of a project plan in the project room is important and precious. Nevertheless, Trello replaced a Kanban-board that was previously established by the team for managing repetitive tasks during the scrum cycle. To ensure data security shortcuts were developed to describe activities and no names were used.

1. Digital communication channels for project communication

Due to the specific framework that the project was embedded into, teamwork was also considerably influenced by influences from outside the project team. To respond to these influences, the rather young project team integrated new digital communication channels such as WhatsApp or Yammer into the project work. It is important to notice that these communication channels play a considerably more important role in the business life of Saudi Arabia than in Germany. Therefore, these communication channels constituted a strong advantage, if not a precondition, for the efficient teamwork between Saudi and German team members. Concerns regarding data security could easily be mitigated by setting simple agreements. One principle was for example that WhatsApp is only used for internal team organization and -communication without connection to project content.

The decisive factor for using tools in an agile project setup is a continuous reflection of the team regarding the necessity and the expected value of a certain tool. A truly agile team will stop using a tool once it comes to the conclusion that the expected value cannot be realized.

 Conclusion

During the described 100 days initiative, the Performance Management stream continuously enthused the client. The main reason behind this was the choice of agile methods in order to enable quick, early and continuous delivery of a product, in this case a management report. This clearly underlines the ability of methodologies like Scrum to support in non-software-development projects. Beyond this, the project team identified several key success factors for the successful delivery of the project.

First, willingness and enablement of the team to work autonomously was important in order to leverage all resources from the very beginning and keep motivation up. Secondly, acceptance on sides of the customer that “early deliverables” will either exclude scope or quality was quickly thought for. Third, a clear the concept of “done” throughout the team that was addressed as one of the first things during the project. Lastly, fourth, efficient employment of digital helpers to assist the agile processes.

These findings correlate with typical findings from Scrum practitioners in agile software development environments.

Retrospectively, however, additional learnings emerged that can help the project team as well as future practitioners become even better at working with agile methods. For example: a strict belief in hierarchies stands in the way of agile teams. For experienced users of agile methods this is not a new insight at all. Yet for projects in intercultural settings this may be a challenge larger than expected. Beware of cultural conflicts before they arise. On the other and, flexible use of free and ready-to-employ tools is not only a driver of efficiency but may become grounds for communication that builds bridges among cultures. As an example, the use of WhatsApp was an unexpected enabler for mending two halves of a team together. But in extent to that, agile teams should continuously keep track of new methods and tools that support agile implementation at each stage of their collaboration. Tools may quickly become impediments instead of enablers of they are not continuously challenged. Be prepared to reserve time for setting up and challenging tools, no matter how easy they seem to be implementable.

With these findings, we hope to have shared our most valuable insights as well as recommendations for future agile implementations and wish all agile teams throughout the world best of luck for delivering value early and continuously.