A De Ryck

H P Zhu
email: h.zhu@uws.edu.au

S M Wu

A B Yu

P Zulli

Numerical and theoretical investigation of the surface flows of granular materials on heaps

Keywords:

Flows of granular material on 'non-frozen' and 'frozen' heaps are considered numerically and theoretically in this work. The surface flow on a 'non-frozen' heap is first investigated numerically using the discrete element method. The flow profiles of the surface granular flow and the creep motion of particles in the heap are studied. It is shown that the mean velocity of the surface flow exhibits a linear relationship with the distance from the heap surface, while that of the particles in the heap decays exponentially with the distance. The existence of such a creep motion may be attributed to the variation of the porosity distribution of the heap. The granular flow on a 'frozen' static heap is also simulated, and compared with the one on the corresponding 'non-frozen' heap. The results show that the surface conditions of the heap, to some extent, affect the flow upon it. The surface flow on a static heap is then theoretically examined in detail by using a recently developed continuum model. The depth of the steady-state surface flow and its dependence on wall friction and heap width are investigated. In addition, the theoretical results are compared with the DEM simulation results and the experimental ones in the literature, and qualitatively good agreements are observed.

Introduction

Surface flow of granular materials is often observed in many industrial processes such as those in mining, iron-making, chemical and civil engineering [START_REF] Rajchenbach | Granular flows[END_REF], and geophysical situations such as landslides [START_REF] Hungr | A model for the runout analysis of rapid flow slides, debris flows, and avalanches[END_REF] and snow avalanches [START_REF] Kern | The rheology of snow in large chute flows[END_REF]. The study of the dynamical behaviour of such flow is of significance for formulation of optimal design and control strategies under industrial conditions and development of the rheology of granular material [START_REF] Savage | The motion of a finite mass of granular material down a rough incline[END_REF][START_REF] Midi | On dense granular flows[END_REF].

In the past, many theoretical, numerical and experimental efforts have been conducted to study surface flows on heaps. Bagnold [START_REF] Bagnold | Experiments on a gravity free dispersion of large solid spheres in a Newtonian fluid under shear[END_REF] contributed his pioneered work on the fundamental laws at work inside surface flows. Savage and Hutter [START_REF] Savage | The motion of a finite mass of granular material down a rough incline[END_REF] developed a general model to describe the flows based on depth-averaged mass and momentum balance equations. Pouliquen and Renaut [START_REF] Pouliquen | Onset of granular flows on an inclined rough surface: dilatancy effects[END_REF] investigated the effect of the dilatancy on the onset of granular flows on an inclined rough surface. Brewster et al. [START_REF] Brewster | Plug flow and the breakdown of bagnold scaling in cohesive granular flows[END_REF] studied the plug flow and breakdown of Bagnold scaling in cohesive flows. Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] proposed a continuum model for surface flows by introducing a strain rate law in the constant friction model developed by Jenike [START_REF] Jenike | A theory of flow of particulate solids in converging and diverging channels based on a conical yield function[END_REF]. de Ryck et al. [START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part I: non-cohesive materials[END_REF] and de Ryck [START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part II: cohesive materials[END_REF] developed the model of Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] to investigate the velocity field of parallel flows of non-cohesive and cohesive particles. These studies are mainly restricted to the flows over static heaps (referred to as 'frozen' heaps here) or chutes. Recently, the experimental study of Komatsu et al. [START_REF] Komatsu | Creep motion in a granular pile exihibiting steady surface flow[END_REF] and the numerical study of Richard et al. [START_REF] Richard | Rheology of confined granular flows: scale invariance, glass transition, and friction weakening[END_REF] suggest that in the case of free surface flows on a heap (referred to as 'non-frozen' heap here), even the particles in the deep of the heap still exhibit slow flow. Such creep motion can be detected anywhere in the heap. Although these above studies are useful to the development of the dynamics of granular material, there is still a lack of the systematic study of the description of the surface flows in heaps. The difficulty lies in the coexistence of both liquid and solid behaviours of the material when a layer of granular material flows on the surface of a heap.

In this work, flows of granular material on 'non-frozen' and 'frozen' heaps are investigated numerically and theoretically. The granular flow on a 'non-frozen' heap is first numerically studied using the discrete element method (DEM). The flow profiles of the flow and the creep motion of particles in the heap are investigated. The flow on a 'frozen' static heap is also simulated, and compared with the one on the corresponding 'non-frozen' heap. The continuum model proposed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] is then developed to predict theoretically the depth of the surface flow on a static heap. The theoretical results are also compared with the DEM simulation results and the experimental ones in the literature.

Simulation method and conditions

DEM is used for the present numerical simulation. In this method, the motion of a particle in a considered system, which can undergo translational and rotational motions, is described by Newton's laws of motion. The equations of motion are based on the forces and torques originated from its interactions with neighboring particles. Our present numerical study is only focused on the case of non-cohesive granular media. Therefore, the equations can be written as:

m i dv i dt = ∑ k c j = 1 F ij + m i g ð1Þ
I i dω i dt = ∑ k c j = 1 T ij ð2Þ
where m i and I i are the mass and moment of inertia of particle i, respectively, v i and ω i are the translational and angular velocities of the particle, and k c is the number of particles in interaction with the particle. The forces involved are: inter-particle forces between particles, F ij , and gravitational force, m i g (g is the gravity acceleration). The torque acting on particle i by particle j, T ij , includes two components: one is generated by the tangential force and causes particle i to rotate, and another commonly known as the rolling friction torque, is generated by asymmetric normal forces and slows down the relative rotation between particles. A particle may undergo multiple interactions, so the individual interaction forces and torques are summed over the k c particles interacting with particle i. The equations used to calculate the particleparticle interaction forces and torques are listed in Table 1, which have been adopted in our previous studies [START_REF] Zhu | The effects of wall and rolling resistance on the couple stress of granular materials in vertical flow[END_REF][START_REF] Zhu | Micromechanic analysis of hopper flow of granular materials[END_REF][START_REF] Wu | Numerical investigation of crater phenomena in a particle stream impact onto a granular bed[END_REF]. The equations of motion are solved by using an explicit time-stepping scheme. Numerical experiments have been carried out using a twodimensional slot model and different spherical particles: wooden balls and glass beads. The model geometry is shown in Fig. 1, consisting of two parts: a container and a hopper upon it. The container is used to form a heap of particles, while the hopper is used to load particles discharged towards the heap. To ensure a stable granular heap and shear flow layer formed and maintained, there is a short wall on the right side of the container. There are two treatments on the front and rear walls. First, the real walls are used in order that the numerical experiments are comparable with physical ones. Then, in the further numerical experiments, periodic boundary conditions are implemented to eliminate the influence of the front and rear walls. The properties of particles in the present simulations, listed in Table 2, are quoted from our previous work [START_REF] Wu | Numerical investigation of crater phenomena in a particle stream impact onto a granular bed[END_REF].

A simulation involves a few steps. First, particles to be used to form a heap are charged into the hopper. These particles pass through the orifice of the hopper, and settle down to form a heap under gravity in the container. Secondly, the orifice of the hopper is closed, particles to be used to form a shear flow layer on the heap are charged in the hopper. Finally, the orifice of the hopper is opened so that these surface flow layer particles fall down under gravity, and then move along the surface of the heap towards the right side of the container. In order to form a steady flow on the surface of the heap, particles moving out are re-filled into the hopper. Once the outflux of particles on the right side is equal to the influx on the left, a steady state is considered to be established.

Two cases are simulated in this work. One is the case with 'nonfrozen' heap, where the particles in the heap can move under the impact of the particles in the surface flow layer. Another is the case with 'frozen' static heap. In this case, all particles of the heap are considered to be static after the heap is formed.

Mathematical formulation for theoretical study

Surface flow on static heap is also studied theoretically using the continuum model recently proposed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF]. The flows considered are assumed to be parallel symmetric steady-state flows and confined by the lateral walls. Fig. 2 shows the sketch of the geometry of the flow considered in this work. The heap has a width of 2a and an angle of θ from the horizontal plane, and the surface flow layer on the heap has a thickness of D (D is set to be high enough in order to have a remaining static layer of grains below the surface flow). The behaviour of the flow is analyzed in a fixed frame (x, y, z) whose origin of the coordinates is at the midway of the free surface Table 1 Components of force and torque acting on particle i.

Force and torque Symbol Equation

Normal elastic force

F cn,ij -4 3 E * ij ffiffiffiffiffi ffi R * ij q δ 3 = 2 n n Normal damping force F dn,ij -cn 8m ij E * ij ffiffiffiffiffiffiffiffiffiffi R * ij δn q 1 = 2 V n;ij

Tangential elastic force

F ct,ij -μ p |F cn,ij |(1 -(1 -δ t /δ t,max ) 3/2 )δ ̂t (δ t b δ t,max )
Tangential damping force from the walls, with the x-axis horizontally along the surface, the yaxis perpendicular to the surface downwards, and the z-axis along the surface downwards. For a steady-state flow, the velocities of particles are oriented by the z-axis and do not depend on z. Therefore, we only need to consider the velocity field with a set of iso-velocity lines on a cross-section plane (x, y) (Fig. 2). The flow is assumed to be non-cohesive and satisfy a conical yield criterion and a co-axiality between the stress and strain rate tensor, with no dilatancy [START_REF] Jop | A constitutive law for dense granular flows[END_REF][START_REF] Jenike | A theory of flow of particulate solids in converging and diverging channels based on a conical yield function[END_REF]:

F dt,ij -ct 6μpm ij jF cn;ij j ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi ffi 1-jvt j= δt;max p =δt;max À Á 1 = 2 V t;ij (δ t b δ t,max ) Coulomb friction force F t,ij -μ p |F cn,ij |δ ̂t (δ t ≥ δ t,max ) Torque T t,ij R i × (F ct,ij + F dt,ij ) Rolling friction torque T n,ij μ r,ij |F n,ij |ω ̑t,ij n where 1 R ij à = 1 jRi j + 1 jRj j ; E * ij = 1 2 ð Ei 2 1-v 2 i ð Þ + Ej 2ð1-v 2 j Þ Þ 1 m ij = 1 mi + 1 mj ; ⌢ ω t;ij = ωt;ij jωt;ij j ; δt = δt jδt j ; δt;max = μp 2-v 2 1-v ð Þ δn; V ij = V j -V i + ω j × R j -ω i × R i , V n,ij =(V ij •n)n, V t,ij =(V ij × n)×n. Note that tangential forces (F ct,ij + F dt,ij ) should be replaced by F t, ij when δ t ≥ δ t,max .
σ = -PI + μ I ð ÞP γ ‖ γ‖ ; ð3Þ
where σ is the stress tensor, P = σ ii /3 the mean pressure, I the unit matrix, γ̇the strain rate tensor, and ‖ γ‖ = ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi γij γij = 2 q the second invariant of γ. I is the inertial number, given by I = ‖ γ‖d = ffiffiffiffiffiffiffiffiffiffi P = ρ p (where d is the diameter of particles, and ρ the bulk density). μ(I) is the coefficient of bulk friction, increasing from μ s to a finite value μ ∞ when I increases from zero to infinity, and satisfying (μμ s )∝I m , with exponent m being between 0 and 2 when I → 0. Accelerated flows may occur for cases with slopes greater than μ ∞ , while intermittent avalanche flows may be triggered for cases with slopes lower than μ s . Since only steady-state flows are concerned, we will not consider the two cases.

The force balance along a slope can be integrated, and leads to an exact differential equation along an iso-velocity line in the crosssection plane. Thus, the shape of the velocity field can be given by a set of parametric equations for the iso-velocity lines. Therefore, similar to the derivations of [START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part I: non-cohesive materials[END_REF] and [START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part II: cohesive materials[END_REF], we can obtain the equations to determine the iso-velocity line passing through point (0, h):

dx ds = μ 0 h ð Þ-tanθ ð Þ h + y-y w A ϕ tan θ + μ w y w ð Þy w ffiffiffiffiffiffiffiffiffiffiffiffi ffi 1-δ 2 p A ϕ ; ð4Þ
dy ds 2 = μ 2 y 2 - dx ds 2 ; ð5Þ
where s is a curvilinear co-ordinate along the iso-velocity line. μ 0 (h) is the friction coefficient at the point (0, h), μ w (y w ) is the friction at the point (±a, y w ), A ϕ = ∫

Eq. ( 6) gives an implicit relation between the depth of the flow zone, h max , and the depth of the slip zone at the walls, y w . The latter can be obtained by writing the force balance on the flowing layer contour, that is

∫ y w hmax y 2 dy ds dy + δ 2 y 2 w 2 - tanθ μ s ∫ y w hmax dx ds dy ds ydy = 0: ð7Þ
The first and the second terms in Eq. ( 7) are respectively the scaled basal and lateral shear forces, and the third is the scaled weight along the slope.

The lateral shear force is explicitly known for a smooth wall for which δ 2 = δ. For rough walls, the friction on the wall is the bulk friction and its distribution depends on the exact shape of function μ(I). In such a case, the exact value for μ w cannot be obtained but only a range since μ(I) ranges between μ s and μ ∞ , and δ 2 is a number between 1 and μ ∞ /μ s .

Eqs. ( 6) and ( 7), with Eqs. ( 4) and ( 5), form a closed system. Therefore, for the case of a smooth wall (for which the wall friction does not identify to the bulk friction), we can use these equations to determine the ratios h max /a and y w /h max with respect to R = tanθ/μ s , δ and the exponent m of the asymptotic behaviour of the bulk coefficient of friction when the shear rate tends to zero. For the case of a rough wall (for which the wall friction identifies to the bulk friction), without the knowledge of the exact form of μ(I), we only obtain a scope of values using 1 b δ 2 b (μ ∞ /μ s ).

Results and discussion

Numerical investigation

Simple physical and numerical experiments have been first carried out in a 2-D slot model with real front and rear walls. Both experimental and simulation conditions, including the geometrical and operational conditions, are similar. For each experimental run, a triangle shape heap of particles is first formed in the container. Particles are then continuously fed into the hopper, and then discharged to form a shear flow layer on the surface of the heap. All the physical experimental processes have been recorded by a digital video camera. Two cases have been considered for the comparative study: one in which glass beads are used, another where blue and red wooden balls are utilised to form heap and flow layer respectively. It has been observed that the flow patterns for physical and numerical experiments are quite similar in the two cases. Two different layers can be identified: a stable granular heap and a steady-state surface flow upon it. In the experiments with glass beads, the interface between the two layers is not clear in the photos captured in the experiments as all glass beads have the same colour. Therefore, only the results for the case with wooden balls are shown here (Fig. 3). The similarity of the flow patterns in both numerical and physical experiments demonstrates the applicability of the numerical model in this work. Then, in the further numerical experiments, periodic boundary conditions are implemented to eliminate the influence of the front and rear walls. Glass beads are used to form the heap and surface flow layer.

In the surface flow layer, particle velocities are approximately parallel to the surface of the layer. So only the velocity in the direction parallel to the surface is considered here. For the convenience of description, we employ a coordinates similar to that defined in Fig. 2, which is fixed at the centre of the surface of the flow layer. Fig. 4 shows the variation of the mean velocity along the y-axis, where the mean velocity, v(y i ), is the average of the velocities of particles whose mass centres are in the range of [l, l] × [y i , y i + Δy]. Δy and l are one and three blue wooden ball diameters, respectively. It can be observed that the velocity profile contains two distinct parts, respectively corresponding to the two layers. Roughly, the flow layer has a linear velocity distribution, as shown in Fig. 4(b). Increasing y will decrease the velocity. Under the flow layer, the heap undergoes a slow creep motion. Such a motion can be detected anywhere in the heap. Furthermore, our results show that the mean velocity of the particles in the heap exponentially varies with the distance from the surface of the heap. This feature is similar to that obtained by the experiments of Komatsu et al. [START_REF] Komatsu | Creep motion in a granular pile exihibiting steady surface flow[END_REF].

It has been known that the flow rate of the particles discharged from a hopper would affect the particle flow on heaps [START_REF] Lemieux | From avalanches to fluid flow: a continuous picture of grain dynamics down a heap[END_REF][START_REF] Khakhar | Surface flow of granular materials: model and experiments in heap formation[END_REF]. This has also been confirmed in the present numerical simulations. The increase of flow rate is realized by increasing the hopper orifice size here. Four sizes, namely 4d, 6d, 8d and 10d have been considered. It has been shown that the slope and thickness of the flow layer increase with the flow rate. But the slow creep motions of particles in the heap for different flow rates have very similar distributions.

Angular velocity distribution of particles has also been examined in this work. It has been observed that the angular velocities about the y and z axes are very small. The angular velocity about the x-axis is relatively large and linearly decreases with y in the flow layer. These results are not shown here for brevity.

The flow structure of particles is examined in terms of porosity. A snapshot of porosity distribution is shown in Fig. 5(a). It can be seen that the static layer has a lower porosity while the flow layer a higher porosity. The high porosity should be from the relatively unconfined movement of particles. In order to consider the variation of the porosity, four representative regions are chosen: A is in the flow layer, B the interface region between the static and flow layers, C the lower part near the interface and D the deep region in the heap. As shown in Fig. 5(b), the porosities of the four regions vary with time, although the variation is getting smaller from A to D. The large variation in the flow layer means that the particles can move more freely, while the small variation in the deep region indicates that more contacts between particles occur in the static layer. The particles in the regions with lower porosity may move to the regions with higher porosity, which may be the reason causing the creep motion of particles in the heap.

In order to consider the influence of the surface conditions of the heap on the surface flow, a case with the so called 'frozen' static heap is simulated. This case is similar to the surface flow on an inclined plate, a case extensively investigated in the past [START_REF] Kern | The rheology of snow in large chute flows[END_REF][START_REF] Savage | The motion of a finite mass of granular material down a rough incline[END_REF][START_REF] Midi | On dense granular flows[END_REF][START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part I: non-cohesive materials[END_REF][START_REF] De Ryck | Granular flows down inclined channels with a strain-rate dependent friction coefficient, part II: cohesive materials[END_REF]. Fig. 6 shows the velocity profiles along the y-axis for both cases with the 'frozen' and 'non-frozen' heaps. The velocity profiles for the two cases are similar, but the value of the velocity for the 'non-frozen' heap is larger than that for the 'frozen' heap. The result indicates that the surface conditions of heap affect the velocity profiles of surface flow.

Furthermore, we also have performed DEM simulations to examine the effect of the slope angle of the static heap. Fig. 7 gives the surface velocities and depth velocity profiles at the centre of the channel for slope angles ranging from 22°to 36°. The flow at 22°is at the onset of the present model, where the boundary between the flow and deadzone does not attain the lateral walls (see the dashed line in Fig. 7(a)). In Fig. 7(b), we notice that the velocities of the particles upon the static heap are non zero, but two distinct zones are observed: a creep zone where the velocity field exponentially decrease with the decrease of the distance from the static heap surface, and an upper zone where the particles have higher velocities. It can be observed that the depth of the flow zone (upper zone) increases with the increase of the slope angle of static heap.

Theoretical investigation

In the theoretical study, the flows on a static heap with smooth or rough lateral walls are considered, and the prediction of the depth of the flow layer is focused on.

Fig. 8 shows the influence of the lateral walls friction conditions on the depth of the flow layer. For smooth lateral walls, the results are represented by the continuous lines. The thick one is for μ w = μ s and the thin ones are for δ = 0.2, 0.4, 0.6 and 0.8. It can be seen that the depth is affected by the wall friction. The smaller the wall friction, the bigger the depth. The dependence of the depth on parameter m is small, so the results in Fig. 8 remain valid for all the values of m between 0 and 2. For the case of rough walls, we have considered different μ ∞ /μ s values, which are represented by the dashed lines below the thick continuous line in Fig. 8. These dashed lines are for μ ∞ / μ s = 2, 3, 5 and 10. It can be observed that the larger the ratio, the lower the flow layer depth. Note that these dashed curves end at a point. This is because there is no steady-state solution when the heap slope is greater than μ ∞ . Fig. 9 shows the ratio y w /h max as a function of the relative difference between the slope and static coefficient of friction for the same values of the properties used in Fig. 8. Similar to the depth of the flow at the centre, the depth at walls decreases with the increase of the wall friction for smooth lateral walls or ratio μ ∞ /μ s for rough walls.

We can also investigate the asymptotic behaviour when the heap inclination angle tends to the angle of repose (R → 1) or when it tends to the value with R ≫ 1. The asymptotic development of Eqs. ( 6) and ( 7) for R close to 1 leads to:

h max ∼ 2 ffiffiffi 6 p = π a ffiffiffiffiffiffiffiffiffiffi ffi R-1 p f m ð Þ
, and y w /h max ∼1 -3(R -1), where f(m) is a function which ranges from 1.015 ± 0.001 to 1 when m ranges from 0 to 2. Practically, the asymptotic behaviour only depends on the relative difference between the actual slope and the slope at the onset of flow. For high inclination angles, the asymptotic behaviour is: h max∼ 2aR/δ 2 , and

y w = h max ∼1-δ 2 1- ffiffiffiffiffiffiffiffiffiffiffiffi ffi 1-δ 2 p = 2Rδ ð
Þ, but remains a limit since there is no steady-state solutions for tan θ N μ ∞ , i.e. R N δ 2 .

The theoretical results obtained for the depth of a granular surface flow are compared with the numerical results obtained in the above section. From Fig. 7, we can determine the values of the depth of the flow at the centre h max and the depth of the flow at the lateral walls y w for different slope angle, as shown in Fig. 10, where h max and y w , scaled by the half-width of the channel, versus the slope angle are given. The relevant theoretical results are also given in this figure for comparison. Two variables, the apparent static angle of friction ϕ s = 20.6 0 ± 1 0 and the ratio μ w /μ s = 0.8 ± 0.1, have been adjusted in order to fit both h max and y w with the present theory within a 10% error.

Taberlet et al. [START_REF] Taberlet | Superstable granular heap in a thin channel[END_REF] have reported their experimental results on the depth at the walls of granular flows in narrow channels. Here, we attempt to compare our theoretical results with the measured ones. In their experimental study, y w was not considered. But we can estimate the value of y w from the velocity profile they presented in [START_REF] Taberlet | Superstable granular heap in a thin channel[END_REF]. It was found that y w is approximately 50 to 70% higher than the depth they obtained based on the extrapolation of the slope at the inflexion point of the velocity profile. The data are reported in Fig. 11 with the corresponding error bars (stars, black and white squares for a channel width of 5, 10 and 20 times the particle size respectively). In this figure, the theoretical prediction obtained based on the rheology proposed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] and smooth walls (similar to the conditions of the experiments) is also shown to compare with the experimental data. Since the coefficient of friction between the granular material and the glass windows is not documented in the study of Taberlet et al. [START_REF] Taberlet | Superstable granular heap in a thin channel[END_REF], we compare the experimental data points with the theoretical results obtained with different wall friction: μ w = μ s (upper dashed line), μ w = 0.8 μ s (middle dashed line), and μ w = 0.6 μ s (lower dashed line). It can be observed that there is a qualitatively good agreement between the experiments and the theory with a smooth wall whose friction is about 80% the static bulk friction, and a static bulk friction μ s = tan(27.4 °).

The agreements based on the above comparisons confirm the applicability of the theory proposed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] to the description of the flow profiles of granular surface flow on static heaps.

Conclusions

Surface flows on 'non-frozen' and 'frozen' granular heaps have been studied numerically using the discrete element method. It has been observed that the mean velocity of the surface flow on 'nonfrozen' heap exhibits a linear relationship with the distance from the heap surface. Slow creep motion can be observed anywhere in the heap. The mean velocity of the particles in the heap decays exponentially with the distance from the heap surface. The existence of such a creep motion may be attributed to the variation of the porosity distribution of the heap. The granular flow on a 'frozen' static heap is also simulated, and compared with the one on the corresponding 'nonfrozen' heap. The results show that the surface conditions of the heap, to some extent, affect the flow upon it. In particular, the 'non-frozen' heap surface would lead to a larger flow velocity.

The surface flow on static heaps is also examined theoretically using the continuum model recently developed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF]. The theoretical study illustrates that the depth of the surface flow can be exactly obtained in the case of a smooth wall, and within a range in the case of a rough wall, irrespectively of the detailed knowledge of the relationship between the coefficient of friction and the strain rate. Thus, we can readily predict the depth of flow layer on static heaps. The study of the steady-state surface flow on a heap indicates that the flow layer depth depends on the ratios: wall to bulk static friction μ w / μ s , particle size to heap width d/a for a smooth wall. More precisely, the depth decreases with the increase of the wall friction for smooth lateral walls or ratio μ∞/μ s for rough walls. In addition, the theoretical results have been compared with the DEM simulation results and the experimental ones in literature. Qualitatively good agreements have been observed, which confirms the applicability of the theory proposed by Jop et al. [START_REF] Jop | A constitutive law for dense granular flows[END_REF] to the description of the flow profiles of granular surface flow on static heaps.

Fig. 1 .

 1 Fig. 1. Geometry of the model used (units: mm).

  δ = min μ w = μ s ;1 ð Þ . The boundary between the dead and flow zones can be obtained by considering the limit when the inertial number I tends to zero, i.e. for μ ≈ μ s andA ϕ ≈ h b -y b À Á = h b -y b w À Á , with b = 1m/2, and the depth of a flow layer at the centre, h max , can be given by:

Fig. 2 .

 2 Fig. 2. Sketch of: (a), surface flow on a static heap and the coordinates fixed on it; and (b), iso-velocity lines in a cross-sectional plane for the theoretical study.

Fig. 3 .

 3 Fig. 3. Flow patterns observed in: (a), physical experiments; and (b), numerical experiments. Most particles above the white line are red wooden balls, while those below the line are mainly blue wooden balls.

Fig. 4 .

 4 Fig. 4. Mean velocity distribution along the y-axis: (a), whole region; and (b), flow layer, where y 0 is the flow layer thickness, v is the mean velocity of particles, v 0 is the mean velocity at y = y 0 .

Fig. 5 .

 5 Fig. 5. (a), Porosity distribution in the heap and surface flow layer; and (b), variation of porosity in different regions with time.

Fig. 6 .

 6 Fig. 6. Velocity profiles of the flow layers for the cases with the 'frozen' and 'non-frozen' heaps.

Fig. 7 .

 7 Fig. 7. (a), Surface velocity versus the axial position x/d (from top to bottom, the slope angle θ ranges from 36°to 22°by a 2°step. Dashed line: θ = 22°); and (b), depth velocity profile for x = 0 (from bottom to top, the slope angle θ ranges from 36°to 22°b y a 2°step. Dashed line: θ = 22°).

Fig. 8 .

 8 Fig. 8. Depth of the flow layer scaled by the half-width of the heap versus the relative difference between the heap slope and the static coefficient of friction. Continuous lines: smooth wall with μ w /μ s = 1 (thick line), 0.8, 0.6, 0.4 and 0.2 (thin lines from bottom to top). Dashed lines: minimum value for rough wall with μ ∞ /μ s = 2, 3, 5 and 10. These lines end at R = μ ∞ /μ s (represented by circles).

Fig. 9 .

 9 Fig. 9. Depth of the flow layer at the walls scaled by the half-width of the heap versus the relative difference between the slope and the static coefficient of friction. The same symbols as in Fig. 8 have been used.

Fig. 10 .

 10 Fig. 10. (a), Depth of the flow layer scaled by the half-width of the heap versus the slope angle θ; and (b), depth of the flow layer at the walls scaled by the half-width of the heap versus the slope angle θ. Data points: results from DEM experiments. The black points are for a slope angle higher than 24°. The white point is for θ = 22°, for which there is no slip at the walls. Dashed line: theory for ϕ s = 20.6 0 and μ w /μ s = 0.8.

1 v

 1 between particles c t tangential damping coefficient between particles d diameter of particles (m) D thickness of surface flow layer (m) E Young's Modulus (kg/m s 2 ) F inter-particle forces (N) g gravitational acceleration (m/s 2 ) h max depth of flow layer midway from walls (m) I i moment of inertia of particle i (kg⋅m 2 ) I unit matrix I inertial number T torque (N⋅m) m mass of particles (kg) n exponent for the asymptotic behaviour of µ versus I when I tends to zero b exponent, equals to 1n/2 P mean pressure (Pa) R vector from the mass centre of particle to contact point (m) zone at walls (m)Greek letters δ t vector of the accumulated tangential displacement between particles (m) δ ̂t unit vector defined by δ ̂t = δ t /|δ t | δ n normal displacement between particles (m) δ = min μw μs ; Poisson ratio ω particle angular velocity, s -1 ω̂unit vector defined by ω̂= ω/|ω| ρ bulk density (kg m -3 ) σ stress tensor (Pa) γ̇strain rate tensor (s -1 ) μ coefficient of bulk friction

Fig. 11 .

 11 Fig. 11. Heap slope versus the depth at the wall scaled by the half-width of the heap. Stars, black and white squares: experimental results of Taberlet et al.[START_REF] Taberlet | Superstable granular heap in a thin channel[END_REF] for respectively a channel width of 5, 10 and 20 mm. Dashed lines: present theoretical results for a smooth wall (from bottom to top, μ w /μ s = 0.6, 0.8 and 1) and μ s = 0.52.

Table 2

 2 Parameters used in the simulations.

	Variables	Glass beads	Wooden balls
	Particle diameter (mm)	10	14 (blue)
			13.9 (pink)
	Particle density (kg/m 3 )	2450	583 (blue)
			573 (pink)
	Sliding friction (PP) (-)	0.3	0.5
	Sliding friction (PW) (-)	0.3	0.3
	Rolling friction (PP, PW) (mm)	1%d	1%d
	Young's modulus (PP, PW) (Nm 2 )	1 0 6	10 6
	Poisson ratio (PP, PW) (-)	0.3	0.3
	Damping coefficient (PP, PW)	0.3	0.3

  μ s static friction coefficient (with no shear rate), μ ∞ friction coefficient when shear rate tends to infinity μ 0 (h) friction coefficient at point (0,h) μ w (y w ) friction coefficient at point (±a, y w ) μ p friction coefficient between particles δ 2 equals to δ (smooth wall) or a number between 1 and μ ∞ /μ s

		(rough wall)
	δ t,max θ	= μ p angle of heap surface from the horizontal plane 2-v 2 1-v ð Þ δ n
	Subscripts
	i	particle i
	ij	between particles i and j
	j	particle j
	n	normal component
	r	rolling friction
	t	tangential component

Acknowledgments

The authors are grateful to the Australian Research Council (ARC) for the financial support of their work. AdR would also like to thank UNSW for hosting his sabbatical leave in 2007.


Aymeric Hemon
email: aymeric.hemon@univ-nantes.fr

Barbara Lyonnet
email: barbara.lyonnet@univ-nantes.fr

Frantz Rowe
email: frantz.rowe@univ-nantes.fr

Brian Fitzgerald
email: brian.fitzgerald@ul.ie

Conceptualizing the Transition From Agile to DevOps: A Maturity Model for a Smarter IS Function Full Paper

Keywords: DevOps, agile, roles, skills, collaboration

Agile development approaches have become the norm for almost all software development now. While agile approaches can deliver more frequent releases of working software, it quickly became apparent in many organisations that they were not able to leverage these frequent releases due to the disconnect between the development and operations functions, with the latter typically responsible for releasing software to customers. This resulted in the move towards closer integration of these functions through the DevOps movement. As the trend towards digitalisation continues, companies are increasingly implementing DevOps. We propose a maturity model for this agile to DevOps transition with three levels: agile, continuous integration, continuous delivery. Based on an in-depth case study in an organisation which has several years' experience of DevOps, we identify a fundamental disruption in the soft skills and competences that software teams are expected to possess, and in the patterns of collaboration among teams. The latter is especially salient for release managers, project managers, production engineers and even architects. Arguably, smartness may be characterized as being flexible, teaming up with people who have a different profile, belonging to a different function, and delivering more quickly what had been designed. In light of this, we argue that DevOps leads to greater smartness for the Information Systems (IS) function.

Introduction

Agile methods seek to ensure a close link between the customer and developers to ensure that software meets market needs. Agile methods also strive for a more rapid release schedule. However, while agile methods can achieve a more frequent cadence of development of software, a bottleneck has emerged in that the Operations function (Ops), who coordinate the actual release of software in organizations, are typically not aligned with the Development function (Dev). A release could take weeks to be launched. Consequently, organizations were not able to achieve faster software releases to customers. In order to solve this problem, Debois advocated a tighter integration between the Dev and Ops functions which is termed DevOps [START_REF] Brunnert | Performanceoriented DevOps: A research agenda[END_REF][START_REF] Debois | DevOpsDaysGhent. DevOpsDays[END_REF][START_REF] Debois | Devops: A software revolution in the making[END_REF]. Emerging as it did from practice, there is not a great deal of work thus far outlining the conceptual or theoretical underpinnings of DevOps. A similar situation occurred in the case of agile methods, which was also practice-led, and some important definitional work appeared later [START_REF] Conboy | People over process: the implications of agile for IS skills and Human Resource Management[END_REF]. We believe that many companies are in the transition from agile to DevOps, and we suggest three maturity levels to reflect this: Agile, Continuous Integration, Continuous Delivery. Each level builds cumulatively on the previous one. We analyse five key job roles in DevOps (Release Manager, Architect, Product Owner, Department/Project Manager and Production Engineer) and describe the key collaborations across these and other DevOps roles. We then describe the skills for each of these roles, dividing them into 'hard' and 'soft' skills [START_REF] Gallivan | Changing patterns in IT skill sets 1988-2003: a content analysis of classified advertising[END_REF][START_REF] Wong | Non-technical skills and personal attributes: the Soft Matter Most[END_REF]. We consider how soft skills (SSk) vary by level of maturity.

The paper is structured as follows. In section 2, we discuss other relevant work in this area. Section 3 presents our research method and section 4 our findings. Finally, section 5 discusses the implications of our findings for research and practice.

Literature

Roles, skills and competencies of Information Technology (IT) jobs

"A skill is a combination of ability, knowledge and experience that enables a person to do something well." [START_REF] Boyatzis | From learning styles to learning skills: The executive skills profile[END_REF]. Skills are specific to a domain and developed by practice [START_REF] Boyatzis | From learning styles to learning skills: The executive skills profile[END_REF]. Hard skills refer to the ability to perform, to do something well, using knowledge, techniques, practices. Robles [START_REF] Robles | Executive perceptions of the top 10 soft skills needed in today's workplace[END_REF] defines "soft skills as intangible, nontechnical, personality-specific skills that determine one's strengths as a leader, facilitator, mediator, and negotiator" (see Table 1). This paper will focus on SSk. Gallivan et al. [START_REF] Gallivan | Changing patterns in IT skill sets 1988-2003: a content analysis of classified advertising[END_REF] identify a "long history of IT-skills studies" which suggest that soft or non-technical skills are more important. Wong [START_REF] Wong | Non-technical skills and personal attributes: the Soft Matter Most[END_REF] also emphasises the relative importance of SSkflexibility, adaptability, motivation and good communication. Non-technical skills include interpersonal, leadership, organization, independence/motivation, and creativity skills. However, studies found that non-technical skills were far less valued than technical skills in recruitment advertisements. They concluded that despite the emphasis on hiring well rounded employees with good business knowledge and SSk, the recruitment process focuses on "hard skills" be-cause they were easier to screen. Thus, they confirmed the "recruitment gap" that had been identified earlier [START_REF] Todd | The evolution of IS job skills: a content analysis of IS job advertisements from 1970 to[END_REF][START_REF] Trauth | The IS expectation gap: Industry expectations versus academic preparation[END_REF]. This lack of recognition is harmful as some SSk have been identified as important in agile software teams [START_REF] Vivian | The development of a dashboard tool for visualising online teamwork discussions[END_REF]. In addition, Wiedemann et al [START_REF] Wiedemann | Key Capabilities of DevOps Teams and their Influence on Software Process Innovation: A Resource-Based View[END_REF] investigated key capabilities of DevOps teams which could foster competitive advantage. They identified seven key capabilities (Change Readiness, Decision Making, Culture, Collaboration, Intrapreneurship Skills, Agile Project Management, IT Technical Skills, Continuous Skills). However, they mixed capabilities with skills without determining precisely which skills were a source of competitive advantage. In their study, they suggested some ways to foster collaboration within DevOps team but did not specify the extent of such collaboration. In a companion study focusing on new forms of collaboration, Wiedemann [START_REF] Wiedemann | A New Form of Collaboration in IT Teams-Exploring the DevOps Phenomenon[END_REF] highlighted assimilation stages of innovation within DevOps teams but did not consider the question of the extent of the collaboration. Hence our research questions:

• To what extent are soft skills perceived as important by IS Function members transitioning from agile to DevOps? • What are the implications for collaboration when transitioning to DevOps? Positive attitudeoptimistic, enthusiastic, encouraging, happy, confident •Professionalismbusinesslike, well-dressed, appearance, poised •(RS) Responsibilityaccountable, reliable, gets the job done, resourceful, selfdisciplined, wants to do well, conscientious, common sense •(TS) Teamworkcooperative, gets along with others, agreeable, supportive, helpful •Work Ethichard working, loyal, initiative, self-motivated, on time/attendance

Agile, DevOps and IT jobs

Agility is defined as "the continual readiness of an entity to rapidly or inherently, proactively or reactively, embrace change, through high quality, simplistic, economical components and relationships with its environment" [START_REF] Conboy | Toward a conceptual framework of agile methods: a study of agility in different disciplines[END_REF]. Agile methods arise from the inability of conventional methods, i.e. Waterfall, to give satisfaction in a changing environment [START_REF] Highsmith | Agile software development: The business of innovation[END_REF]. DevOps initiative was launched to extend the movement towards the agile by including Operations and Quality. The idea was to solve the problem of bottleneck present when Development teams were delivering to Operations faster and more frequently. Thus, agile methods form a base for DevOps. Agile methods impact teams as well as jobs on management styles, collaboration, control, new skills set, training or recruitment [START_REF] Conboy | People over process: key people challenges in agile development[END_REF][START_REF] Coram | The impact of agile methods on software project management[END_REF][START_REF] Nerur | Challenges of migrating to agile methodologies[END_REF]. DevOps philosophy leads to build bridges between Development and Operations teams. DevOps foster the creation of cross-functional teams where each team member need to consider and anticipate the job to be done by other members. For example, developers need to understand realworld production environment where their colleagues will release the code. In the same way, Operations need to integrate the way Developers will produce the code, will test it and will build the delivery package. It is therefore fundamental in a DevOps configuration to increase test automation [START_REF] Lwakatare | Dimensions of devops[END_REF] to optimize end-to-end deployment processes. Indeed, "automation is the key to efficient collaboration and tight integration between development and operations." [START_REF] Wettinger | Standards-based DevOps automation and integration using TOSCA[END_REF].

Roles, competencies of IT jobs in the transition from agile to DevOps

Humble et al. [START_REF] Humble | Why enterprises must adopt devops to enable continuous delivery[END_REF] presented four core values for DevOps: Culture, Automation, Measurement and Sharing. In the recent DevOps handbook, Kim et al [START_REF] Kim | The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations[END_REF] suggest that "a high-trust culture that enables all departments to work together effectively, where all work is transparently prioritized and there is sufficient slack in the system to allow high-priority work to be completed quickly". In the IS literature, Ghobadi and Mathiassen [START_REF] Ghobadi | Perceived barriers to effective knowledge sharing in agile software teams[END_REF] study knowledge-sharing barriers in agile software teams. Knowledge sharing is important in these teams as it is essential for collaboration across different specialties. They focus on four jobs: user representative, project manager, developer and tester. While tester can be part of development teams, they can also be considered as part of the operations. In this paper, we focus on the jobs which are a priori most impacted by DevOps in terms of skills and competencies. In consultation with industry experts, we selected five jobs of core interest: 1) product owner (a more commonly used title than user representative), 2) managers, 3) architects, 4) production engineers who perform the tests as Ops (in fact developers also perform tests in a DevOps mode), 5) release managers. We did not consider developers in this paper. Although developers are certainly also impacted in the way they share knowledge and collaborate, we did not see particular high challenges for them in moving towards DevOps, while greater challenges were identified and anticipated for others. This view was confirmed by the industry experts. The main argument was that the core activity for developers is coding and that while they would have to take into account additional factors when coding in a DevOps context, the coding role would still be central, and they would not have to evolve as much as others.

The Product Owner (PO) role is essential when working in agile with Scrum. POs play a dual role, as representative of the client needs, but also with a real operational role that links the business to project management. POs are responsible for optimizing the value of what development teams produce. Autonomy is essential for POs to succeed and their decisions must be respected by all stakeholders [START_REF] Coyle | An exploration of the relationship between contribution behaviours and the decision making process in agile teams[END_REF][START_REF] Schwaber | The scrum guide[END_REF]. There is some debate as to whether POs can also act as project managers (PM). They can definitely be managers as indicated in the Scrum guide, "Product Owner is the sole person responsible for managing the Product Backlog" [START_REF] Schwaber | The scrum guide[END_REF]. However, there is no clear indication regarding project management in the Scrum method. The Scrum guide mentions that "Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team" and "Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person" [START_REF] Schwaber | The scrum guide[END_REF]. Therefore, this means implicitly that self-organization is compulsory which avoids the possibility for the team to be managed by a PM from the team or external to the team. Theoretically in the Scrum method, POs are managers, but not PM. POs are associated with business ownership and not project management even if they are accountable for the product backlog management and the final product delivery. However, in reality a PO can also assume the function of PM. Beyond, the distinction between the PO and the PM, some studies mix the PM profile with Scrum Master (SM) profile to identify Scrum Product Owner competences [START_REF] Oomen | How can Scrum be successful? Competences of the Scrum Product Owner[END_REF].

The notion of Manager (DPM for Department & Project Manager) is very large, and the literature contains many definitions. In our conception, a manager is a person with the responsibility to deal with resources, tangible and intangible, to serve a specific objective. The Managers may be project leaders or simply team leaders, or both. It is simply a feature of the hierarchy that often places these two roles in the same person. Others like SM are either not always present or are played by the more traditional role of developer or PM. Team Managers (TM) include different professions: development/operational or supervisory team leader, and qualification-integration manager. PM define and manage an IT project from conception to delivery to get an optimal result for customer requirements of quality, performance, cost, time and security. The architect (AR) role is evolving. The AR is often brought to develop multiple skills, whether it is a technical AR, a software-application AR, or a functional AR. On the Ops side, Production Engineers (PE) or production integrators and testers are responsible for production, operations, incident monitoring, support and user support. PEs participate in the development of architectural files and the production of applications. PEs also provide the expertise and support for incident resolution. Finally, on the Ops side, the Release Manager (RM) is key to ensuring the success of projects. RMs are responsible for the deployment processes. They follow the different versions and coordinate between the development and test teams and the deployment teams. The RM is associated, in the French context, with the function of PM Implementation. This is an essential activity but the scope is questioned by DevOps. We investigated to what extent SSk were perceived as important by these five roles when transitioning from agile to DevOps and the implications for collaboration (See figure 1).

Methodology

This study was conducted in a large European services firm with thousands of IT Staff using agile methods since 2010 and DevOps since 2016.

We followed case study method combining interviews, observations and documentation [START_REF] Yin | Validity and generalization in future case study evaluations[END_REF]. We studied 5 job roles and their scope of collaboration in 11 project teams, which involved 54 in-depth face to face individual interviews (these were recorded and lasted 90 minutes on average). About DPM, we interviewed six PM and six TM. Interviews were conducted by three interviewers and were subsequently transcribed and coded. Codification was triangulated to verify if codes were consistent and similar. This can be viewed as an embedded case study, where job roles are embedded in teams and are centered on collaborative relationships with other job roles.

First, a review of the literature identified the appropriate criteria for selecting the sample of 54 individuals. Second, we observed and interviewed four teams for 15 days (mat. 2 and 3) to compare elements in the literature and those in practice, i.e. size of the team, agile to DevOps maturity (as per our model), and level of externalization. Third, we conducted a series of interviews with 12 strategists in IS and Human Resources, to incorporate their vision and to validate the selected sample.

Three criteria were retained to select the sample: 1-the size of the project measured in terms of number of staff assigned to the project [START_REF] Rolland | Problematizing agile in the large: alternative assumptions for large-scale agile development[END_REF] with small project equal to or less than 14 people and large project larger than 15 people; 2-the outsourcing policy and more precisely the degree and nature of outsourcing on the project, e.g. we realized that fixed-price contracts can pose specific problems when working in agile mode. We contrasted two situations: some project activities carried out in work package and fixed price mode, and project without outsourcing or with an outsourced technical assistance contract; 3-the level of maturity in terms of the agile to DevOps transition as presented in section 2.3 above. All theoretically possible configurations allowed us to identify 12 distinct types of projects. This document covers 11 projects whose analysis has been completed. The case of fixed-price outsourcing, maturity level 2 and large project was not completed. Then, agile stage: agile can be considered maturity level 1 in the transition to DevOps, because it facilitates more frequent releases as development becomes more iterative. However, DevOps is not realized because Dev and Ops continue to work in silos with limited sharing, common culture and automation of releases. Maturity level 2 is that of Continuous Integration: the Ops function has to be aligned with the Dev function and both begin to perform various tests (unit and non-regression tests) [START_REF] Ståhl | Modeling continuous integration practice differences in industry software development[END_REF] which are synchronised with code development. Lastly, maturity level 3 is that of Continuous Delivery Stage: integration tests with the other components, end-to-end tests, performance tests, user acceptance tests are then performed by Ops and co-designed with the Dev function [START_REF] Chen | Continuous delivery: overcoming adoption challenges[END_REF]. Documents, observations and interviews performed in the first stage considerably helped us in interpretation of the 54 interviews in the second stage. Collaboration scope was parsed by interviewing individuals to express with whom they worked the most. While it is susceptible to bias, we did not want to induce other biases by repeating this question for each possible job role they could have collaborated with. Collaboration enrichment was examined through responses to whether and how individuals were satisfied or unsatisfied in our semi-structured interview. To investigate the skills issue in the 54 interviews, we asked what skills (know-how, behaviour) were necessary for the evolution of their jobs. We then analysed SSk detecting the presence of any subcategories in keeping with Robles [START_REF] Robles | Executive perceptions of the top 10 soft skills needed in today's workplace[END_REF] set of SSk (cf. Table 1).

Findings

Changes in SSk Perceptions when Considering Maturity Levels

Codification of interviewee skill perceptions allowed us to complete nine of the ten groups of SSk identified by [START_REF] Robles | Executive perceptions of the top 10 soft skills needed in today's workplace[END_REF]. Only half of Robles [START_REF] Robles | Executive perceptions of the top 10 soft skills needed in today's workplace[END_REF] 10 groups of SSk are mentioned by interviewees for each maturity level. Five groups of SSk are underrepresented if not absent within representations of Agile and DevOps teams whatever maturity level, i.e. integrity, work ethic, courtesy. Among them, positive attitude clusters various skills, i.e. being optimistic, enthusiastic, confident, encouraging, and is only cited by PO and DPM at higher level of maturity (2 and 3). Beyond these results, we came across five groups of SSk represented in each maturity level.

Communication skills (CS) refer to the ability to communicate both orally and in writing, presenting and listening, and are present at each maturity level. A RM highlighted the importance of CS: "I think you have to know how to communicate" (RM, mat.1). This perception is shared by many people on both sides, Dev and Ops, e.g. a PO (mat.2): "You have to listen, so especially not having the posture of "I know, I have experience", especially today". A DPM (mat.3) confirms the central position of communication saying that "Communication is still a fundamental basis of teamwork. And I think that often, either because we are partitioned (…) we are somewhat inclined to understand or integrate neither the constraints of the rest of the team nor other people from other teams". We noted that the perception of CS was slightly higher in terms of diversity and frequency of mentioned skills when maturity level was going up. These previous verbatim show CS at mat.1 covering basic CS principles as to convey an information between two or more stakeholders, then CS at mat.2 with a stress on listening skills integrating humility, and finally CS at mat.3 with a wider coverage and a higher degree of CS incorporating large understanding skills and their usage to interact with teams and integrate their constraints.

Interpersonal skills (ISk) are related to sociability, empathy, nurturing, friendly, patience; self-control capacity. As for CS, ISk appear at each maturity level. A PO underlined the importance of ISk to satisfy different stakeholders and reach final goal: "Coordination, of course, then relational, because everyone is not going necessarily in the same direction or does not necessarily have the same objectives (…) On the one hand, the production and the operations managers ask to limit the number of releases or production launches (…) on the other hand, we have businesses that always ask for more." (PO, mat.1), a shared vision by a DPM (mat.3): "Stakeholders analysis! I change partners very often. So, know how to evaluate a situation quickly, if I have someone who is supportive, or if someone who is perhaps a little more reluctant (…) You are asked to get closer to a certain number of people with whom you are not used to work with (…) so it requires human qualities.". The perception of ISk was slightly larger in terms of diversity and frequency of skills when maturity level was higher.

Flexibility skills (FS) signify to be ready to change, to learn throughout the life, to accept new things, to adjust, to adapt. FS are present at all levels of maturity and on both Dev and Ops sides. Moreover, people from maturity level 3 seem to have a clearer and wider representation of FS. A PE (mat.1) simply mentioned one sub-skill of FS group, adaptability: "Adaptation is perhaps most important, because it changes all the time, businesses, tools, applications and technologies". At a similar position, a PE (mat.3) asserted: "Everything evolves so quickly…it is better to know how to learn than to develop know-how because that will change, it is important to be open to the novelty". A PO (mat. 2) stated that: "You have to feel and accept the error. One must accept sometimes and assume one has made a mistake, and it is a step backwards". The skill is about adaptability but with a deeper and larger interpretation of learning and adaptability. Finally, a DPM (mat.3) on a small project suggested: "You must be humble or agree hat you don't know…your neighbor knows better and will show you. (It is better) not to impose your vision either." Meanwhile another DPM (mat.3) confirmed this "The challenge is to change the subject -just able to juggle these topics. It necessarily requires great flexibility and adaptability. A questioning, because suddenly, you've been in the business a long time, have already proven worth in the past, and you are asked to work in an-other way". We discovered that FS perception was broader and much more important in terms of diversity and frequency of mentioned skills when maturity level was higher.

Teamwork skills (TS) indicate a capacity to cooperate, to be supportive, collaborative, helpful. TS are intimately linked to Agile Principles, i.e. "Business people and developers must work together daily throughout the project", as well as Agile Methodologies (Scrum, XP), Agile Practices (daily stand-up, sprint review) or DevOps philosophy breaking silos between Dev and Ops and building bridges and fostering new teams. As mentioned by a PO, it is important to "understand that we do not work each one in his own corner (…) it must be shared a minimum, that every-one knows where the others are (…) all the developers do not need to know where all the integrators are, but we can have a roughly correct and almost real-world view of where we are. to know how to adjust, to know how to project also." (PO, mat.1). From the Operations side, an RM highlighted a cultural change regarding Teamwork: "We do not ask for technical expertise anymore, because we really want people to stop solving the problem technically. (We prefer) to get the problem solved by a community. It is really a different positioning". (RM, mat.2), a vision confirmed by another Ops: "You really need to have the vision of belonging to the same team, and not to say: "Me, I do represent Production (Ops)", to feel "powerful" because we (Ops) take the decision in fine to put the application into production." (PE, mat.3). Finally, a DPM on a small project (mat.3) demonstrated her way to become supportive and collaborative integrating fully her team: "You also have to be ready to join this team even if you are a manager of some of them. We (the DPM) must also know when to take a back seat." When team members are really acculturated to work together, i.e. in advanced DevOps team, silos disappear. We figured out that the perception of TS was moderately larger in terms of diversity and frequency of mentioned skills when maturity level was higher.

Lastly, as a DPM (mat.3) stated clearly: "the responsibility necessarily, to know to be responsible.", thus Responsibility skills (RS) which covers two aspects. The first one is more evoked by PE: get the job done, and well done, conscientious, accountable. The second one is more perceived by DPM: trustworthy, astute, common sense imply to get the job done, to be conscientious, accountable, reliable. These skills are mostly cited by DPM, afterwards PE and to a lesser extent RM, and then few PO and very few AR. A large and complex PM suggested: "I to say for commitment too. If they are self-organized, they must get in deep. They take a subject, they go to the end. They bring their ideas, they apply their ideas, and then when they fail, they repair. We must assume." About conscientiousness, the sense of getting the job well done and being resourceful, a PE on a large project (mat.3) declared: "You do not have to be an expert to find the solution. You must understand what's going on. And about the know-how-to-be well, you must listen rather than talk." We identified this same preoccupation of consciousness, reaching objectives with POs trying to stay the course: "do not do the wind vane. We can be wrong, but on the other hand, we do not return every day on what we said the day before. (…) It is disastrous for the progress of work." (PO, mat.1) We detected that the perception of RS was decreasing in terms of diversity and frequency of mentioned skills when maturity level was higher.

To conclude, we found that Agile maturity is a factor impacting SSk perception. First, FS are much higher in team members in a more mature agile environment (mat.3). Secondly, the higher the maturity level, the more the presence and the diversity of CS and ISk increase. Third, TS and team spirit, are more present in a mat.3 project compared to a mat.2 or 1, which may seem logical but not obvious, particularly when considering the fundamentals of the agile approach which require a Teamwork culture. Fourth, surprisingly, RS are more present in a lower agility context (mat.1) and decrease when maturity is higher. This could mean that in an agile environment, the sense of responsibility is more formally distributed, and in a mature DevOps configuration, the sense of responsibility is more shared within the team. In a DevOps environment, we can explain this result with Automation that could reduce and /or transfer responsibilities and therefore responsibility skills.

Type of Outsourcing may have an impact on SSk 'perceptions. Some competences, such as sense of responsibility or teamwork are more present when the project is internal. In contrast, outsourcing seems to be a factor which results in increasing FS and ISk. The perception of SSk seems to vary less with project size than with type of outsourcing. Overall maturity level is the most important.

Roles and Collaboration Analysis

To the question about the actors with whom they interacted the most, all interviewees cited more than 15 different co-worker's functions. For maturity 1, projects, main collaborations between Dev and Ops are less numerous [START_REF] Wettinger | Standards-based DevOps automation and integration using TOSCA[END_REF] than those within Dev and within Ops [START_REF] Tan | Training future software developers to acquire agile development skills[END_REF]. Collaborations crossing the two functions become more numerous than those internal either to Dev or to Ops (20 against 16) for projects in maturity 2, and then become balanced (31 against 32) for projects in maturity 3. This balancing with DevOps means that collaboration with members of other function are perceived as important as internal collaborations within Dev and Ops functions respectively. Table 3 lists these main collaborations by role/profession; for example, 4 of the 10 RM reported the developer as a main co-worker. Some similarities and differences in collaborations are observed for the five key interviewed roles. As expected, the DPM reported the highest number of collaboration with different co-workers in comparison to the four other interviewed roles. This highlights their large scope of collaborations. Another important observation is the key role of the PO: all interviewed professions have mentioned their collaboration with the latter.

In table 3, we can see more precisely the main collaborations between Dev and Ops. From the Dev side, we highlight collaborations between PO and RM, AR with operators or DPM with PE and operators. From the Ops side, we see a strong collaboration between PE and Developers, between RM and PO and with developers. Given the question asked, in traditional developments mode or in agile (mat.1), these collaborations would not have been considered as main collaborations. Moreover, all respondents have highlighted an improvement of the collaboration's quality between co-workers in an agile context. As mentioned during the interviews, the setting up of daily meetings or sprint reviews, but also the use of collaboration tools (such as the Mingle) could partly explain this finding. Indeed, the setting up of these daily meetings will rhythm the collaborations in a formal way. However, the frequency of meetings can be perceived as an overwork. For each role, we also describe the different forms of collaboration and types of actors involved.

Release Manager (RM). The RM is at the center of numerous collaborations within the company and in particular with the production team. All RMs underlined interactions with the project manager, generally on a weekly basis. This collaboration is, and must be, continuous to prioritize certain tasks and thus ensure the success of projects. For example, a RM explained (mat.3): "every week we establish a point called the "Common Work Plan of Exploitability" where we exchange. We go through all actions, all activities in progress, and ... we see what has to be prioritized in the case of new actions". These collaborations are often real driving forces to create a dynamic for all teams working on the same project. In addition, almost all RMs reported collaborations with production engineers (see Table 3). Their exchanges are frequent, (RM mat.2): "we discuss certain points between us before going to meet the project manager. Given the slightest problem, one goes to see the other and vice versa. "It should be also noted that in this context, the setting-up of project group meetings provided the opportunity to gather RMs, developers and operators. The maturity level in the transition from agile to DevOps could influence the frequency of these collaborations. In fact, "The developers for me are hidden behind the project manager. But this evolves within the most advanced projects in the DevOps approach " (RM mat.3). Thus, an advanced application level of agile and DevOps methods and concepts might naturally lead to establishing more interactions with developers.

Product Owner (PO). As expected, most POs reported collaborations with developers. Some of these interactions are required for the validation of the sprint during the demos. The maturity level in the transition from agile to DevOps has a direct impact on the frequency and quality of these interactions. Thus, a PO suggested that to feel part of an integrated team (mat.3): "Today we are really an integrated team with marketing, developers." In the case where several POs participate in the same project, they collaborate with each other daily via email or telephone and during the weekly "sales meeting". This meeting is also a moment of exchange with the Product Manager and line managers. Moreover, some POs mentioned multiple exchanges with functional architects. In line with the various roles inherent to the PO roles, the majority of POs also reported collaborations with business sponsors or users, albeit not considered main ones. It should be noted that several POs highlighted the limited collaborative exchanges with supervisor-operators (mat.2): "Those with whom I exchange the least, are probably exploitation"; "I have difficulties to express myself on this point, they ("supervisor-operators") are more related to developers." Architect (AR). As in previous findings, the two main co-workers mentioned by the architects were PMs and developers (see Table 3). Most architects reported interactions with PMs to share information and views on a project. Collaborations were also reported with development team to exchange information, especially during sprint reviews and demos. An architect stressed the importance of this (mat.3): "we have to be precise on how to proceed, and if feasible, establish a stronger, detailed collaboration with the technical manager". These exchanges take place regularly.

Several architects mentioned information exchange with the RM profession, especially to agree on norms, standards and good practices (mat.2): "he (RM) is supposed to hand over to his team, to read the technical architectural file". An AR (mat.3) highlighted the impact of the transition to DevOps on his work and collaborating: "it's an approach allowing better understanding the role of each person involved in the project. In the end, each remains accountable; but decision-making in an architecture problem (…) will be more shared than before (...) thus, problems disappear."

Production engineer (PE). The main collaborations cited by PEs are with the PM and developers (see Table 3). Thus, most PEs agree on the existence of a significant mutual collaboration with developers (mat.2 and 3): "we inform each other, it's natu-ral…with the developers, we are becoming a unique team: the DevOps one." In addition, in their daily activities the PMs must provide applications to PEs so significant collaboration with shared responsibilities have been reported. However, some difficulties of co-operation have been mentioned, for instance a PE pointed out the following (mat.2): "I was the one who explained what I expected in terms of documentation, whereas it's their job." PEs also discussed their collaborations with RMs. However, the frequency of these collaborations can vary a lot across projects. Indeed, in a context where the RM is entirely dedicated to the team's projects, collaborations are frequent. A PE described this collaboration as follows (mat.2): "In our organization, the role of RM was created because of administrative importance of our project, it's useful to lighten our work (...) The role of the RM is to anticipate complex operations, to be sure we do not forget anything". A PE (mat.3) explained his view of the evolution of collaboration in a DevOps team: "the roles of PM and RM no longer exist in a DevOps team; At the development team level, the role of PM is operated by the Scrum Master; at the planning level, project management role is a crucial role covered by the team. And the role of RM is operated both by PO, technical expert, and production engineers, and operators".

Department and Project Managers (DPM). PMs are at the center of multiple collaborations, both inter and intra-team. The manager profile collaborates with many actors (see Table 3). Most also mentioned collaborations with other PM and POs, in particular to discuss budget, tracking, prioritization of items. Several Managers also highlighted a close relationship with functional architects (mat.2): "I work early with our functional architects to define and schedule future development." In addition, although the PM is not a functional expert, he approves the conformity of the result.

To conclude, the collaborative scope within the main collaborators clearly changed and is now more balanced. The perceived greater richness of collaboration reflects a better understanding among members. This greater richness appears to be more salient when projects are in maturity 3. Consequently, considering our findings on skills and collaboration, we could describe a three levels maturity model as follow. At maturity 1, there is a lower range of collaborations which could be explained by the DevOps philosophy itself opening collaboration to a new extent between Dev and Ops while Agile limits collaboration among Dev. Because agile methodologies ask for it, communication skills are very important and responsibility skills very developed as interpersonal skills. However, surprisingly, flexibility and teamwork are less present in their discourses. At maturity 2, the extent of collaboration is thus wider than for mat.1. All the SSk are more represented at this level, except for RS which are decreasing. At maturity 3, the extent of collaboration is similar to mat.2 or can slightly decrease. We explain this finding because when teams reach mat.3, they know better that anyone with who to collaborate to be more efficient, hence they limit or cancel collaboration with some stakeholders. SSk increase in comparison to mat.2, except for RS, and this is particularly true for FS, TS and ISk.

Discussion and conclusion

DevOps and Agile methods impact collaboration and existing IT skills; therefore, it is essential to understand the requirement for new skills [START_REF] Tan | Training future software developers to acquire agile development skills[END_REF] and new curricula for IT students [START_REF] Bang | A grounded theory analysis of modern web applications: knowledge, skills, and abilities for DevOps[END_REF][START_REF] Betz | The Impacts of Digital Transformation, Agile, and DevOps on Future IT curricula[END_REF]. Companies struggle to determine the most important tasks for IT teams, specifically future Release/DevOps engineers [START_REF] Kerzazi | Who needs release and devops engineers, and why?[END_REF]. Understanding the evolution of IT skills would help organizations to hire skills that fit their needs [START_REF] Trauth | The IS expectation gap: Industry expectations versus academic preparation[END_REF]. This is lacking in DevOps job advertisements which largely neglect SSk [START_REF] Hussain | Emerging trends for global DevOps: a New Zealand perspective[END_REF] and focus on hard skills, e.g. technical skills, thus confirming a recruitment gap [START_REF] Todd | The evolution of IS job skills: a content analysis of IS job advertisements from 1970 to[END_REF][START_REF] Trauth | The IS expectation gap: Industry expectations versus academic preparation[END_REF]. We sought to investigate what skills and competencies are required notably for the collaboration culture between Dev and Ops when a firm engages in Agile and DevOps.

Our study provides compelling evidence that the move from Agile to DevOps Maturity has an impact on perceived skills in use or in making. While all agile software projects require significant SSk, these are even greater in DevOps especially at mat. 3. Our study shows flexibility and interpersonal skills are important for agile teams [START_REF] Vivian | The development of a dashboard tool for visualising online teamwork discussions[END_REF], and also extends this to others SSk such as teamwork and communication and suggests that SSk are even more important for DevOps. Our findings are largely congruent with that of Wiedemann et al. [START_REF] Wiedemann | Key Capabilities of DevOps Teams and their Influence on Software Process Innovation: A Resource-Based View[END_REF] and complement with an in-depth analysis of SSk in Agile and DevOps teams. Beyond key capabilities highlighted by Wiedemann et al. [START_REF] Wiedemann | Key Capabilities of DevOps Teams and their Influence on Software Process Innovation: A Resource-Based View[END_REF], we identified characteristic features of DevOps teams.

Regarding collaboration, we showed that collaborative scope among the main collaborators has drastically changed and is now more balanced. Also, the perceived greater richness of collaboration reflects a better understanding of roles in the overall project. We provide greater clarity about collaborations within a DevOps team than previously available (e.g., [START_REF] Wiedemann | A New Form of Collaboration in IT Teams-Exploring the DevOps Phenomenon[END_REF]). Our findings align with Humble [START_REF] Humble | Why enterprises must adopt devops to enable continuous delivery[END_REF] who highlighted the importance of collaboration and shared responsibilities and more specifically with skills, experience and mindset of Ops people. This expression of greater richness seems more salient when projects are in continuous delivery (mat. 3).

Overall, these results show disruption in collaboration between agile and DevOps. The transition to DevOps facilitates the IS function becoming smart for three reasons. Firstly, adaptability is considered an indicator of smartness. Extending collaboration across functions within IS is a sign of adaptation where there is an evident need. The fact that delivery can be continuous at DevOps stage is also a sign of adaptation to a more demanding environment and of higher performance. DevOps is the agile approach whereby better sharing of information and developing a common culture can happen across different roles and jobs throughout the IS function as a whole which overcomes the traditional distinction between Dev and Ops.

Figure 1 .

 1 Figure 1. Existing 5 Roles related to 3 Maturity Levels

Table 1 .

 1 Soft Skills (SSk) as identified by Robles (2012) •(CS) Communicationoral, speaking capability, written, presenting, listening •Courtesymanners, etiquette, business etiquette, gracious, respectful •(FS) Flexibilityadaptability, willing to change, lifelong learner, accepts new things, adjusts, teachable •Integrityhonest, ethical, high morals, has personal values, does what's right •(ISk) Interpersonal Skillsnice, personable, sense of humor, friendly, nurturing, empathetic, has self-control, patient, sociability, warmth, social skills

Table 2 .

 2 Distribution

	of 54 interviews per contingencies
	Project Size: 25 Small (min: 5; max: 14) / 29 Large (min: 15; max: 80)
	Type & Degree of Sourcing: 24 Outsourced Fixed-Price/ 30 Other (Internal or other)
	Agile Maturity: Mat.1: 19 / Mat.2: 15 / Mat.3: 20

Table 3 .

 3 Main collaborations reported by each role.

	PO	DPM	AR	PE	RM
	(N=11)	(N=12)	(N=10)	(N=11)	(N=10)