Agility as an opportunity for a new attempt at a democratic company?

Is agility an opportunity for a new attempt towards a democratic company?

Summary

Whether new production models offer opportunities for greater participation and involvement of employees has been discussed again and again since the 1980s, usually with sobering results. The article turns to the so-called “agile methods”, which play an important role in the course of the digital transformation in the area of ​​highly qualified mental work. Using two case studies in a software company and in industrial research and development, he sheds light on how these methods are actually implemented and how they are presented from the employee’s perspective. He comes to the conclusion that there is potential for an expansion of participation and involvement of the employees, the realization of which, however, depends on the specific design, in particular of the agile concept of “empowerment”.

Abstract

There has been a long-standing discussion since the 1980s about the question of whether new production models harbor a potential for extended employee participation and involvement, in most cases with disillusioning results. This paper is concerned with so called “agile methods”, which play an important part in the area of ​​knowledge work in the course of the digital transformation. On the basis of two case studies from software development and industrial R&D, the paper examines the concrete implementation of these methods and the employees’ perspective upon them and their consequences. The result is that agile methods present a potential for extended employee participation and involvement; However, the realization of this potential depends on the concrete way how the agile concept of “empowerment” is implemented.

Résumé

Depuis les années 1980, la question du potentiel des nouveaux modèles de production pour renforcer la participation et l’implication des employés dans l’entreprise fait l’objet de discussions récurrentes, dont les conclusions sont la plupart du temps décevantes. Cet article est consacré aux méthodes dites “agiles” qui jouent un rôle important dans le processus de numérisation à l’œuvre dans le domaine du travail intellectuel hautement qualifié. À partir de deux études de cas conduites chez un éditeur de logiciels et dans la recherche et le développement industriel, cet article montre comment ces méthodes sont mises en œuvre concrètement et comment elles sont perçues par les employés.

Access provided by the Specialized Presidential Council for Educ and Scientific Research Portal

introduction

Based on the discourse about the digital world of work, a new attempt to democratize companies is currently developing. In particular from some innovative small and medium-sized companies and start-ups in the IT industry, there are reports of new forms of direct participation – including the election of executives (e.g. Stoffel 2015 ). Such dazzling examples are more of an exception. Nevertheless, they express a fundamental development that is directly related to the current digital upheaval in the economy and society: the “democratic question” is being asked anew. While this connection is already widely discussed with a view to society as a whole (e.g. Hague and Loader 1999; Hindman 2009 ; Voss 2014 ), so far there have hardly been any corresponding considerations on democratization in companies.

The search for opportunities to democratize work processes and companies by expanding direct participation and involvement of employees has been the subject of progress-oriented social research since the 1970s at the latest. Starting with concepts of “co-determination in the workplace” (Vilmar 1971 ) or the program for the “humanization of working life” (Matthöfer 1980 ; Oehlke 2004 ), which were primarily based on the initiative of politics or works councils, trade unions or the social sciences themselves, It was soon mainly reflective fractions of management that in the course of “new production concepts” (Kern and Schumann 1984 ) and later “lean production” (Womack et al.1991 ) propagated new forms of participation and participation-oriented management concepts. Empirical studies had to state, however, that in practice these approaches hardly exceeded the initial stage and were also often less driven by principles of emancipation than by principles of efficiency (e.g. Dörre et al. 1993 ; Dörre 2002 ). In this area of ​​tension between emancipation and efficiency, not only the social science debates about participation and democracy in companies have since moved, but also the disputes in the companies themselves.

Even today, the question of democratization in companies is raised not least by the management itself (e.g. Sattelberger et al. 2015 ). Unlike in the 1990s, however, the current discussion is taking place on a different basis. The rise of a global “information space” (Baukrowitz and Boes 1996 ) based on the Internet creates a leap in the development of social productive forces . Driven by the structural growth pressure of capitalistically formed modern societies (Dörre 2013) companies strive to use this potential for their exploitation strategies. Established companies in particular are no longer primarily concerned with increasing the economic and technical efficiency of their existing products and processes, but rather with making the information space the new starting point for their business models, value creation and work processes. You are faced with the challenge of reinventing yourself (Boes et al. 2017 a; Boes and Ziegler 2018 ).

In this reinvention process, the concept of agility is currently crystallizing^Footnote1 outlines a new guiding orientation in companies (Boes et al. 2016 b). In contrast to the Fordist-bureaucratic type of company that has prevailed for a long time, the agile company seems to require particularly “flat” hierarchies and the active participation of employees. The traditional management culture of “Command & Control” is being called into question. Instead, approaches of personal responsibility and self-organization are gaining importance again. In contrast to the introduction of new production and management concepts in the past, the head work areas in particular are proving to be pioneers: especially in the fields of highly qualified employee work, the use of so-called “agile methods” such as Scrum^Footnote2 new forms of work organization implemented (Hodgson and Briand 2013 ; Boes et al. 2014 ). These promise not only an increase in work productivity, but also an expansion of “empowerment” – that is, the employees’ power of disposal over extensive scope for design in the work process.^Footnote3

This raises the question of the extent to which, in the course of the digital transformation, a new space for more democracy will open up in companies – on the basis of agility. In the following, the new forms of work organization based on agile methods will therefore be examined more closely. Based on a discussion of the state of research on democratization in companies as well as an introduction to the methodological approach and the empirical basis of our study (Section 2), in Section 3 we examine agile forms of work organization based on the Scrum framework as part of two case studies in pioneering companies the IT, metal and electrical industries. We work out the subjective experiences of the employees with the new forms of work organization and ask how the democratization potential is actually presented in practice. Finally, in Section 4, the empirical results are brought together and discussed with a view to the question of a new scope for more democracy in companies.

State of research, empirical basis and methodical approach

In the search for answers to the question of whether the digital transformation will create a new space for more democracy in the world of work, it is important to look at the current process of upheaval in companies. In order to be able to classify the potential of the upheaval and evaluate its significance, the previous experience with participatory and participation-oriented forms of work must first be evaluated.

Democracy and participation in the Fordist bureaucratic company

Instead of offering a differentiated product range, Henry Ford began to focus his company consistently on the production of standardized bulk goods at the beginning of the 20th century. He is therefore considered to be one of the founders of a company model that was new at the time, whose principles and organizational concepts became decisive in large parts of the economy, especially after the Second World War. The foundation of this “Fordist bureaucratic enterprise” lies in the machine system of the “big industry” (Karl Marx) and a corresponding idea of ​​organization based on the model of “scientific management” (Frederick Winslow Taylor), which strictly separates planning and execution of the work separates (Braverman 1977 ) and the logic of a “bureaucratic rationality” (Weber1988 ) follows. Scientific management and bureaucratic decision-making processes lead to an extensive differentiation of hierarchical levels and to multiple cascaded chains of decision and command (e.g. Womack et al. 1991 ). On this basis, divisionally structured organizations have emerged whose large functional pillars such as development, production and sales are largely isolated from one another and have a high degree of independence. The respective managers in these functional areas have a high degree of creative power (Beckman 1996 ); they act as “princes in the empire” who are endowed with far-reaching decision-making powers and are difficult to control from outside.

Employees also enjoy a privileged position in the areas of highly qualified mental work (Baethge et al. 1995 ). Unlike the workers on the shop floor, the brain workers can largely avoid the access of Taylorist rationalization and remain organized in a kind of “expert mode” (Boes et al. 2014 , 2015a). Despite team and project work as well as attempts at bureaucratic control, the experts always act a little in their own “knowledge silos” that are isolated from one another. Since the management cannot look into the heads of the highly qualified experts with the means of scientific management, the head work here remains a “black box”, which is characterized by large “zones of uncertainty” (Crozier and Friedberg 1979 ) and on individually bound knowledge as the central one Power resource based.

A special characteristic of the Fordist bureaucratic company is that ultimately all employees and managers in “company-centered labor markets” (Lutz 1987 ) are tied for the long term and are therefore characterized in their subjective experience by “future certainty” (Castel 2000 , p. 341) ( Bultemeier and Boes 2013 ; Boes et al. 2016 b). In addition to this relative social security, democracy mainly takes place within the mechanisms of codetermination (Boes et al. 2015a). The system of codetermination, as it has been developed in Germany since the 1950s, provides a formal legal framework and remains “generally associated with the idea of ​​institutionalized, that is, legalized participation” (Mikl-Horke 1997 , p. 259 f.). In this respect, it turns out to be complementary to the rigidly hierarchical divisional structure of the Fordist-bureaucratic company. By guaranteeing employees legal rights, the codetermination is a decisive corrective to the rule of the “princes in the empire” and contributes significantly to restricting the unilateral, structurally determined powers of employers (Hucker 2008 ).

The onset of the crisis in 1973/1974 marked the beginning of the end of the Fordist phase and thus also of the Fordist-bureaucratic company model. Its crisis led companies to turn away from Taylorist rationalization strategies and resulted in various search processes for new concepts, without, however, ultimately breaking with the Fordist-bureaucratic company model (detailed Boes et al. 2016a). On the one hand, in contrast to Taylorism, companies now switched to focusing on rationalization concepts no longer on individual segments of the production process, but instead making the process as such the subject of permanent change, restructuring and recomposition of sub-processes. On the other hand, no longer tried, as in Fordism, to seal off the specific production processes from the imponderables of the market – on the contrary, it now became the engine of the permanent reorganization of the company’s internal structures (Sauer et al. 2005 ).

In these search processes for new rationalization concepts, forms of direct participation and employee involvement were given a boost. Based on the idea of ​​a reconciliation of humanization and rationalization (critically Dörre 1996 , 2002 ; Sauer 2011 ), for example, the “new production concepts” (Kern and Schumann 1984 ) aimed at utilizing the production intelligence of employees: above all, the extended decision-making powers of the executive level followed the idea of ​​tapping important productivity potential by promoting the professional sovereignty of the workers. The same applied later to the Lean Production approach (e.g. Minssen 1993). Last but not least, the lean idea implies a flattening of the hierarchies by reducing the middle management level in particular, as well as using the ability to organize themselves and the participation of employees on the shop floor for the continuous improvement of production processes. The employees are to be empowered to make independent decisions about selected aspects of the work process that were previously reserved for management (Ohno 1993 ; also Womack et al. 1991 , p. 210).

In particular, the aspect of employee empowerment offered important starting points for expanding direct employee participation. A high degree of subjective scope for action and decision-making in groups and teams was not only considered a moment of democratization, but was also emphasized with a view to the possibility of regulating one’s own workload and thus balancing out workloads (e.g. Schumann and Gerst 1996). On the other hand, however, it was also worked out that in practice forms of teamwork can arise in which teams become a self-sanctioning organizational unit via “peer group pressure”. And it was objected that the scope of employee empowerment is in fact severely restricted by the framework of predetermined company goals and that instead of a really comprehensive breakdown of hierarchical levels , there is merely a situational disregard of hierarchical differences (Vormbusch 1999 ; Babson 1995 ; Wellins and Byham 1991). With a view to the possibilities of reducing the workload, empirical studies have also shown that sustainability is not a sure-fire success when introducing new lean concepts (e.g. Gerst 2010 , 2011 ), but that these can even be accompanied by new workloads, so that you Contribution to the humanization of work is always a question of the concrete implementation and design (e.g. Jürgens et al. 1989 ; Minssen et al. 1991 ; Berggren et al. 1991 ; Howaldt and Kopp 1992 ; Sauer 2011 ).

Overall, the implementation of forms of direct participation and participation-oriented management principles in the previous search processes for alternatives to the Fordist-bureaucratic company model could hardly go beyond the initial stage (e.g. Dörre et al. 1993 ; Dörre 1996 , 2002). Klaus Dörre, for example, cites various causes as reasons for this: from the introduction of capital market-oriented forms of control in the 1990s to the potential for conflict offered by the loss of power of middle management in the concepts to the lack of institutional safeguards for participation that is only “granted”. The bottom line was that it was not primarily efficiency and effectiveness reasons that were decisive for the inadequate implementation, but the risks were simply too great for companies to “persist in pursuing concepts that ultimately give employees more power” (Dörre 2015 , P. 103).

In the current digital upheaval, the entire construction plan of the Fordist-bureaucratic company is fundamentally up for grabs – from the isolation of functional pillars to the hierarchical understanding of leadership to the expert mode of highly qualified mental work (Boes et al. 2016 c). A reinvention process is gaining momentum in companies, which could open up a new space for more democracy in the world of work.

Companies are reinventing themselves: agility as a guiding principle in digital transformation

The starting point of the reinvention process in the company is a leap in productivity. This is marked by the rise of the Internet since the 1990s, on the basis of which a global “information space” has emerged. This information space has developed at enormous speed into a new global social level of action. Here people can not only save, edit and exchange information in a wide variety of ways, but also interact openly and lively and relate to one another in a wide variety of ways. At the same time, all activities that take place in this information space leave behind traces of data from which usable information can be obtained.2012 ).

In the course of the dissemination of a new guiding principle for the design of IT infrastructures, the cloud (Boes et al. 2017 a), the potential for the leap in productivity in companies is becoming increasingly evident: Platform-based business models use the cloud as a “marketplace” for Products and services. Companies use cloud platforms to tie partner companies as well as open source communities or freelancers or crowdworkers to themselves in order to include them in their value creation processes depending on the situation (Leimeister and Zogaj 2013 ; Boes et al. 2015 b; Vogl 2018). And finally, in the working world, vast amounts of different data are bundled and combined in the cloud so that people can gain information from it and make decisions in order to optimize processes – for example with the “Internet of Things” in the factory. At the same time, more and more parts of what people do at work and how they work with colleagues take place directly or indirectly in the information space. To the extent that the object and means of work can be digitized, a “new space of production” is created here (Boes 2004 ). This becomes the basis for new forms of cooperation – from mobile work to a new quality of globally networked cooperation (Boes and Kämpf 2011). But it also enables a new quality of transparency in work, which is becoming the basis of ever tighter controls (Boes and Bultemeier 2008 ).

Taken together, the development of the information space marks a historical turning point that is quite comparable to the beginning of the industrial revolution: Similar to the machine systems of the “big industry”, the information space today forms the foundation for a fundamental upheaval in the world of work – and in companies as a whole . In the course of the digital transformation, the certainties and organizational principles of the Fordist-bureaucratic company are completely called into question, because innovations can be delivered much more quickly via the information space and “the customer” can be dynamically integrated into the value creation process. At the same time, an increasingly seamless flow of information is made possible,

Against this background, the companies have intensified their search processes for a new, suitable construction plan for the digital working world in order to meet the new requirements and to be able to use the new possibilities. The concept of agility is increasingly beginning to establish itself as a new guiding principle – not only in IT companies, but also in traditional industrial companies (Boes et al. 2016 b, 2018 ; Gergs et al. 2018 ). Only agile work and organizational concepts seem to enable companies to implement new digital business models and, for example, to develop “executable” products at short-cycle intervals or to integrate the customer’s perspective into the value creation process (Boes et al.2017 a). The cooperation between previously largely isolated areas, such as between hardware and software development or between development and IT, also requires agile forms of cooperation in cross-functional teams, as is currently being promoted with the so-called “DevOps” approach ( e.g. Brandt and Jung 2018 ). In addition to “Pair Programming”, which aims to improve the exchange of knowledge in the work process, and “Test Driven Development” for early error identification in software development – above all “Scrum” has established itself as an agile method in practice (Beedle and Schwaber 2002 ).

The Scrum framework was developed by pioneers in software development and is inspired by the idea of ​​product development teams from lean production (Rigby et al. 2016 ). As an agile method of project organization, it represents an alternative to the long-standing bureaucratic waterfall projects with their long planning and sometimes multi-year project times.^Footnote4thThe central principle of Scrum are two to four-week “sprints”, which subdivide the development time and thus massively shorten it. Because: At the end of each sprint, each team has to present usable software, which is then integrated and expanded step by step from sprint to sprint. At the beginning, the central features of the software are determined with the customer and transferred to a kind of to-do list (the “backlog”), which is then continuously updated over the course of the project. The individual tasks are first described in detail from sprint to sprint, broken down into smaller work packages and implemented. This short-cycle procedure is ultimately also transferred to the team’s meeting routines: These should, for example, meet daily for the so-called “Daily Scrum”,

It is particularly interesting that the Scrum approach also combines a new (leadership) role concept: Because the team is considered to be of major importance, the social integration of the team has its own role, the so-called “Scrum Master”. The classic role of the project manager, on the other hand, is being dissolved. Instead, there is the so-called “Product Owner” who represents the customer’s perspective to the team. Unlike a project manager, however, the new role concept for the role of the product owner does not provide for the role of the product owner to determine or control the distribution of work as well as the time and capacity planning of the development team. These competencies are reserved for the team – and in this respect it is considered “empowered”: The employees should work together as a team to estimate their expected workload and the time required for this and retain control over their work planning. On this basis, they can regulate their own workload. Other dimensions of empowerment concern access to relevant data, the selection of work equipment (tools and methods) and the design of the platforms on which work is carried out. However, they can also include the employees’ time sovereignty and even include the election of managers. the selection of work equipment (tools and methods) and the design of the platforms on which work is carried out. However, they can also include the employees’ time sovereignty and even include the election of managers. the selection of work equipment (tools and methods) and the design of the platforms on which work is carried out. However, they can also include the employees’ time sovereignty and even include the election of managers.

New scope for more democracy in companies?

The agile work and organizational concepts provide answers in the search for alternatives to bureaucratic concepts of work organization and for possibilities to break up the previous “silo structures”, to establish flat hierarchies and to increase the flexibility for change and customer orientation overall. At the same time – and this can at least be observed in pioneering companies (Boes et al. 2016 b) – agile concepts also address a certain type of employee: The “agile employee” should act in a self-organized and first-person manner, assume responsibility to a particular extent, and can be used flexibly and sometimes think outside the box.

In order for the agile employees to be able to meet the new requirements, however, they need the corresponding freedom in their work – for example to network freely and across departments, to access all the data relevant to their work area, or just to be around themselves to be able to take the time to think through complex relationships in depth. In this sense, agility addresses the involvement and direct participation of employees in a new quality: Those who are supposed to take responsibility also need the appropriate power to make decisions. This insight is most clearly expressed in the empowerment of agile teams, which fundamentally calls into question the traditional leadership concept of the “princes” in the Fordist-bureaucratic organization (Boes et al.2016 b).

So while agility could become the basis of an emerging space for more democracy in companies, previous empirical findings paint a contrary picture of the digital world of work. Here can be rather the contours of a new Taylorism (eg Staab and Nachtwey 2016 ), increasing casualization (Ehrlich et al. 2017 and “digital lines”) (Boes et al. 2016 d, 2018 ) recognize that the employees no own decision leeway more and massively restrict their room for maneuver. The DGB index “Gute Arbeit” ( 2016) that 45% of the employees surveyed “very often” or “often” have the feeling that they are at the mercy of digital technology. And last but not least, a new “platform economy” is emerging, in which employees will be exempted from all labor protection norms and democratic participation options (Boes et al. 2016 c; Benner 2015 ; Risak and Lutz 2017 ; Vogl 2018 ). Overall, new forms of transparency and control, increasing work intensification and increasing pressure to perform can be observed, which for more and more employees a “system of permanent probation” (Boes and Bultemeier 2008 , 2010) seem to establish that leads less to a democratic and more to a “burned-out” world of work (Kämpf 2015 ).

In our opinion, however, it would be negligent, in view of these sobering findings, to ignore the democratization potential that arises on the basis of agility in the course of digital transformations. So far, hardly any research results are available on this. However, the few findings already show that the introduction of agility does not automatically lead to an expansion of direct participation and involvement of employees in the sense of their empowerment, but can even go hand in hand with opposing effects (Hodgson and Briand 2013 ; Boes et al. 2014 , 2018 ).^Footnote5 Against this background, the question arises as to whether the experiences of “lean production” and “new production concepts” are repeated and the introduction of agile work and organizational concepts also threatens new burdens and forms of “peer group pressure”. How far does the team’s empowerment go in practice and what are the potentials and challenges with regard to democratization? In the end, is the risk too great for companies to equip their employees with more power?

In the following, we want to pursue these questions and take a look at the use of agile methods in highly qualified mental work from a work-sociological perspective. The focus is on the employees’ perspective and their subjective experience of agile work and organizational concepts. Precisely because opposing effects are to be expected with a view to the concrete implementation of agile methods, the targeted reconstruction of the employee perspective is of central importance. Accordingly, the results presented below are based on a qualitative research design. The context is formed by the research projects “Lean in the Office – New Industrialization Concepts for Mind Work and the Consequences for Work and Employees” (funded by the Hans Böckler Foundation,

The empirical basis for this essay are two case studies in pioneering companies that show the changes in work in the course of the introduction of agile methods in various fields of application. The aim is to develop this new field holistically and to outline higher-level development tendencies based on the case-specific observations. With a view to generalizing these results, further research will be required in the future.

The subject of case study A is a large European software company in which a new production model was implemented on the basis of agile methods, which we were able to conduct empirical research in several waves over a period of five years. We were able to conduct 70 interviews with employees and 21 expert discussions with representatives of management and the works council. Case study B is about a research and development area of ​​a large, global industrial group in the metal and electrical industry that has introduced Scrum as an agile method of project organization in a limited project framework. A total of twelve intensive interviews with employees and seven expert interviews were included in this case study. The case selection is informative insofar as

The chosen industrial sociological case study approach (Pongratz and Trinczek 2010) combines expert discussions and document analyzes with in-depth interviews with the employees themselves. While the expert discussions serve in particular to reflect the strategic background of the introduction of participation-oriented forms of work, the central conceptual content, the associated interests and motives as well as the organizational framework, the employee interviews are primarily used for this purpose To look “under the surface” and analyze the concrete implementation and practice in everyday work, to systematically look at their consequences and to understand the subjective perspectives and experiences of the employees. The interviews with the employees are therefore methodically based on the concept of “graded reflection” (Boes and Trinks 2006, P. 73 ff.). As a further development of the “problem-centered interview” (Witzel 1996), this method aims to reflect on the subjective work experiences together in an iterative procedure and on the basis of the respective relevance of the respondents. In the sense of semi-structured interviews, guidelines were developed for all interviews, in which the theoretical preliminary considerations were incorporated. The expert interviews lasted 60 to 90 minutes, the interviews with the employees 90 to 120 minutes. All interviews were recorded and transcribed for the evaluation. The interviews were evaluated individually and in an iterative research process in which the various empirical perspectives were contrasted and related to one another, gradually condensed into empirically substantive and saturated case studies.

Agile methods in practice and the consequences for employees – two case studies

In the following, two case studies show how the use of agile methods based on the Scrum framework changes work and organization in highly qualified employee areas in the course of the digital transformation, how the employees experience this and what potentials and challenges arise with a view to democratization as part of the empowerment of the teams. While case company A is about realigning an entire development organization based on a combination of agile methods with the lean approach, case study B illustrates the use of agile methods within a limited project framework. In both cases, the focus is on working out the contradictions in the lived practice of agile methods.

Case study A: New production model in software development

Case company A is a European IT company. More than ten thousand employees work there in the field of software development, distributed across various development centers around the world. Driven by the development of digitization, the company has set itself the goal of converting its business model, which is based on the development of standard software for business applications that were previously sold as on-premise solutions, to the cloud and thereby transforming itself into a “cloud Company ”. In his reinvention process, he benefits from the fact that it switched its development organization to agile methods at the beginning of the millennium.

Realignment of the development organization

The first impulses for the introduction of new development methods came from the company’s developer community itself. As an alternative to the rigid logic of bureaucratic waterfall projects, individual groups took up the agile methods early on. In particular, the focus on the core work process of the actual programming as well as the importance of the “empowered” team were rated positively by the developers. Over time, the scattered pilot initiatives networked to form an “agile community” and promoted the acceptance of agile methods in the company. It played into their hands that with the acceleration of innovation cycles in the context of digitization and the increasing complexity of the organization, the model of classic waterfall projects in the development organization was increasingly reaching its limits.

In a realignment of the development organization that has been in operation since the end of the 2000s, the company joined the agile grassroots initiatives. The intention was to anchor a new production model for software development beyond the classic waterfall projects in practice across the board. However, the breakthrough of agile methods only occurred in combination with lean development, i.e. through the scaling of Scrum and the use of the semantics of an established rationalization concept, which made the new development methods connectable to the ideas and expectations of middle and upper management. Within two years, a new production model was rolled out to the entire development organization worldwide. From a sociological perspective, it succeeded2003 ) to incorporate into the grassroots initiatives of the employees and to open up software development with the lean concept towards industrialization (Boes and Kämpf 2012 ; Boes et al. 2014 ).

With a view to the importance of the new development model for today’s cloud strategy of the company, one of our interviewees reflects: “[…] what we did back then with lean and agile, if we hadn’t done that, we would need in the cloud today don’t play along at all ”(A-13). He thus refers to the connection between the cloud as the basis for delivering short-cycle innovations and integrating customer feedback into the development process via the information space in real time, and the importance of agile methods as a new form of work organization that supports the corresponding short-cycle and flexible working methods on the Office Floor is what makes it possible.

Basic structure of the new production model in software development

As a result, a fundamental paradigm shift in software development has taken place in the company. A new production model has emerged from the combination of agile methods and lean development. Its central pillars can be described as follows:

• First, the development work of the teams is now organized as part of a synchronized and timed value creation process. Instead of the previous long-term project cycles, the projects are now structured with Scrum in short-cycle development intervals of two or four-week sprints. While integration and testing of code used to take place very late in the development cycle, compatibility is now tested with modern development environments and highly automated test and integration processes at a very early stage of development. At the end of each sprint, all teams deliver synchronized usable software. On this basis, the company can reorganize the interfaces and handovers between the teams and in line with the flow principle of lean production (Ohno 1993) bring them into a systemic context. The work of many different software teams meshes like one cogwheel with another.
• Secondly, it is now possible to break down complex software on the basis of a so-called backlog in such a way that even larger development projects can be organized based on division of labor without separating the process of specification of the software systematically and temporally from the coding. On the basis of a description of the functionalities of the software, a list of backlog items is created, which is broken down into the various teams in a cascade. A so-called product owner is responsible for creating the backlog for each team. Since several teams usually work on a project in a company, a pyramid-shaped structure was established by product owners who organize the cooperation according to the principle of the “Scrum of Scrums” and calibrate the prioritization of individual items sprint by sprint. The new organizational structure ultimately also leads to a new type of transparency regarding the provision of services and opens up new possibilities for control by management. While development work used to be a “black box” for outsiders, it is now comparatively easy to see at the end of each sprint which items of the backlog were successfully completed and how the overall status of a project is to be assessed. Last but not least, this also restricts the previous “zones of uncertainty” in organized action (Crozier and Friedberg While development work used to be a “black box” for outsiders, it is now comparatively easy to see at the end of each sprint which items of the backlog were successfully completed and how the overall status of a project is to be assessed. Last but not least, this also restricts the previous “zones of uncertainty” in organized action (Crozier and Friedberg While development work used to be a “black box” for outsiders, it is now comparatively easy to see at the end of each sprint which items of the backlog were successfully completed and how the overall status of a project is to be assessed. Last but not least, this also restricts the previous “zones of uncertainty” in organized action (Crozier and Friedberg1979 ) that the traditional expert mode offered developers.
• Thirdly, the “empowered team” becomes the nucleus of the new production model. The basic building block of the organization is no longer the individual software developer, but a collective of software developers. The team organizes itself as an autonomous unit. Based on the Scrum principles, it can decide for itself how the applications are programmed and, above all, how many items from the backlog the team would like to tackle within a sprint. With the new meaning of the team, a paradigm shift is taking place away from the principle of individual expertise towards collective knowledge domains. Team structures and work processes are characterized by sharing knowledge within the team and, for example, creating transparency within the framework of daily scrums.

The basic infrastructure of the new production model is ultimately the information space: Here, in complex IT-based development environments, not only the work packages of all teams are broken down, planned and organized according to the division of labor; The work status in the teams is also made transparent for the entire organization via a digital backlog. The programmed codes of the developers are made openly accessible in IT systems that are consistently linked via the information space, are permanently (automatically) tested and continuously merged into “usable software”. For the systemic integration of entire development departments in a synchronized and uniformly clocked value creation process, the information space thus represents the actual backbone.

Empowerment in the field of tension between new design leeway and dependencies

The expansion of direct participation is directly laid out in the basic structure of the new production model. A first clue for this are the striking changes in the management structure. The role of the project manager is completely dissolved and replaced by agile roles such as the product owner. However, the latter has far fewer decision-making powers than a project manager before and can only decide on the “what”, but no longer on the “how” and “how much” in the work of the teams. This is accompanied by a massive increase in management spans in line management: from 10 to 30 employees.

In the work process itself, it is in particular the central role of the “empowered team” as the nucleus of the new production model that is intended to open up new scope for the developers. In order to be able to keep pace better in the face of accelerated innovation cycles, the collective teams should not only be able to jointly decide within the framework of Scrum how the functionalities assigned to them are to be broken down and implemented in code, but should also be able to independently determine the scope of their work packages in the respective sprints . This gain in power by the teams must not hide the loss of power of the individual developer.

At the same time, the work of the teams is embedded in the synchronous cycle of the entire development organization. In short-cycle intervals, a consolidated status must be submitted again and again, which can be integrated into the higher-level value creation process. This creates a very close-knit network of reciprocal dependencies that threatens to level out the new scope for design. Regardless of the complex development dynamics, the combination of agile methods with the principles of lean management makes consistent process orientation with the goal of systemic integration more important, which again restricts the development teams’ scope for design through the interdependencies and interfaces in their work.

The new production model in practice: Between empowerment and the digital assembly line

The perspective of the employees is an indicator of how this tension between new creative freedom with Scrum on the one hand and new dependencies through the synchronized clocking on the other hand affects the democratization in the work processes. In particular, the aspect of empowerment and, above all, the ability of the teams to independently control their workload must be taken into account. With their authority to commit or not to commit backlog items – without the involvement of management – the teams basically have very extensive decision-making and control options. However, if you ask how empowerment is experienced by employees in practice, you get a heterogeneous picture.

Yes, I think in the last few years we have had a very strong tendency for guidelines to be simply communicated from top to bottom. And I think that it is at least a small step to strengthen the independence of the teams a little in certain areas. In other words, where the teams also have core competencies. I am not saying at all that the teams have to decide which functionality should actually go on the market, because in development we are certainly often a long way from the industry or the customer. But in the area where the development teams have core competencies, they shouldn’t be. And that, I think, is simply strengthened again by the approach. (A-146)

This developer sees the introduction of the new production model as strengthening the independence of the teams, especially in the areas in which they have their core competencies. Elsewhere, he particularly emphasizes the ability to have a say in the architecture of the software to be developed, which he evaluates as a key way of influencing the work process.

While empowerment is lived comparatively stringently in some development areas, in our empirical research we can also identify other areas in which the empowerment of the teams is less pronounced. In these areas, the practice has established that 60% of the backlog is centrally specified by management; This package of tasks is non-negotiable for the employees, only the remaining 40% are subject to an independent commitment by the teams.

So sometimes the team feels too little involved in the overall planning […], and down on the team then, in principle, a chunk of virtually completely planned arrives. And there is already the danger that you will get a little out of context. […] You now have a specific package, but you often don’t know how it depends in the context. […] That was probably because you could [previously] turn the wheel even more, yes. Which is not always good, but you could individually, the individuals could control more. […] For the individual one naturally had some kind of freedom. That takes away a bit of this streamed concept. (A-66)

In this sequence it becomes clear that employees can also experience the new production model differently, less as empowerment and more as a restriction of freedom in work. These freedoms relate in particular to a holistically cut work item that can also be supervised end-to-end as a developer. Some of the employees experience the changes outlined here as a gradual deterioration in their work situation. The focus is on the feeling of only being able to “work through” ready-made tasks. This is exemplified in the following interview section:

In the previous projects, I actually always kept it that way: this was the process of creating the specification, creating the design, what does the software look like, thinking about what the user interface looks like and so on, that was actually also the case with the Projects were always topics where I was not only working on it now as a project manager or as a solution management team, but where the developers who were part of the team were also involved, yes? […] that they were there from the start. And at the moment it is the case that the role of the developer, I personally think, is more like that the ready-made backlog, where everything, where someone has already thought something up, is given to the people, and it actually only becomes processed, yes. But it’s not like that anymore or at least at the moment it is not the case that the developers are really working on these topics, who will later implement the whole thing. (A-52)

Interestingly, criticism of a lack of empowerment is repeatedly linked to the topic of industrialization in practice. It is criticized that, as a developer, for example, “is only processed”. Behind this is the fear of working “like an assembly line”. Another developer argues: “I have the feeling that with Scrum you are trying to introduce assembly line production. But we don’t do assembly line production. We do software development. ”And elsewhere he emphasizes:“ And so I personally see the teams as more of an executive body and not really empowered ”(A-50).

Overall, the selected case study offers a differentiated picture: On the one hand, it can be seen that the democratization potential created in agile methods comes into play in practice. They consist in the decision-making power of the teams about the scope of the work and also the type of implementation of the content determined and prioritized by the product owner in the work. The realization of empowerment in practice therefore depends on the teams being able to plan and design their work independently, without being restricted by management. On the other hand, there are areas in which the management does not allow the teams this freedom of design. In the teams in which more than half of the work tasks are specified by management and thus elude the active commitment of the team, Can’t really speak of empowerment. Even highly qualified developers feel like they’re working on an assembly line in these teams. Our empirical evidence also shows that it is these teams in particular who complain about a massive increase in workloads in the context of the introduction of agile methods. In our interviews, for example, there is talk of a “kind of permanent stress” (A-50) or “very high permanent pressure” (A-62).

Case study B: Scrum in an engineering project

Case company B is a global company in the metal and electronics industry. The case is an example of traditional industrial companies that are currently in the process of adjusting to the digital upheaval in the economy. In particular, the previous innovation processes are reaching the limits of bureaucratic forms of organization: Long planning lead times, rigid, bureaucratic procedures and decision-making processes, as well as innovation and development processes lasting several years make it difficult or impossible to react quickly to the rapid dynamics of change in markets and technologies. In order to meet the new requirements of digitization, the case company is trying to reposition itself as an “agile organization”, especially in knowledge work.

Agility as a new guiding principle

At the time of the survey, activities and initiatives can be observed everywhere in the company that amount to overcoming the boundaries of bureaucratic culture and organization – from the introduction of open room concepts and the establishment of a new home office culture to community-based forms of networking and Collaboration. In this context, attempts to establish agile teams can also be observed in a wide variety of company areas – from development to sales. The associated potential for expanding the direct participation of employees is illustrated below using the example of a group of engineers who have introduced Scrum as an agile method of project organization.

The approximately 30 engineers are divided into four teams and work on the advance development of a product innovation, in the course of which they are confronted with various digitization technologies and vast amounts of data. The concrete form in which the Scrum methodology is implemented in the teams includes all essential routines and roles. Here, too, the entire work organization – from the distribution of responsibilities and the description of the tasks to their breakdown into work packages and the status of their processing to the specific workload of the individual developers – is organized using an IT platform via the information room. In contrast to case study A, however, the teams are not integrated into a higher-level,

Empowerment as the answer to increasing complexity in product development

In this case, too, empowerment primarily means that the teams themselves determine their specific work plan for the next sprint. You can estimate the scope as well as the effort of the respective product functionalities to be developed and thus control your own workload.^{Footnote6 In} this way, the team retains control over how many tasks it processes in a sprint period, to what extent and with what resources. The teams make sure that no more than 70–80% of the working time in a sprint is “committed”, i.e. planned, so that a kind of “buffer” remains for the unforeseen.

However, the direct participation of the employees as part of the empowerment of the team goes one step further in this case and even enables the teams to determine the content of their work to a certain extent by also defining the actual description of the product functionalities (the definition of the so-called “user stories”). This is obviously related to the high complexity and innovative nature of the project, as the following interview passage shows:

What I see, and that’s really interesting, when you reach a level of complexity like the project we’re working on and a developer formulates “user stories”, for a product owner who already has an administrative role, it can ‘ I say very, very difficult to go into the depth of the subject to really understand whether it is actually something that makes sense or not. Because in principle the know-how is so incredibly in a very narrow area. There are no references. So, even from his own experience, he cannot judge whether the employee is actually offering the right solution or offering the right topic. It is very difficult for him to judge. He has to trust them one hundred percent. (B-5)

The interviewee describes here that the complexity and the degree of specialization in the project hardly make it possible for the manager to evaluate the content-related approach in the work from a technical point of view. Therefore the developers have to be empowered enough to be able to plan the content of their work themselves. A manager reflects the importance of empowered teams for the development project as follows:

[It] works very well the way of thinking and the spirit from Scrum, namely that of independent teams who basically understand in dialogue with the product owner where the whole thing should actually go, what we need there, and from there then think about how you can best achieve the whole thing. This of course leads to the fact that you get independent engineers who think through gaps that you had not thought through to the end themselves. And I think that is also such a key, because such a complex system is no longer understood by someone who does not think of everything. You have to have such a principle of subsidiarity there, too, it has to, someone has to have the big picture in mind, but thousands of details will slip through the air. How do I get the employees to fill these gaps? I need. In my opinion, a management mechanism works top-down – I’ll tell you exactly what you have to do, you do it – not at all. Because what you have forgotten is also forgotten in a model like this. You need something, where you say, watch out, I want to go here and there, yes, look how you get there. (B-13)

The manager also emphasizes: The complexity of the work requires a new level of involvement from the engineers and is no longer manageable for the individual manager. It is therefore dependent on the independent action of the teams (on the “principle of subsidiarity” of agile methods) and on the fact that the engineers penetrate the “gaps” and the “details” for their area of ​​responsibility in depth and think through them themselves. For this, the teams need their freedom – the traditional management approach based on the “top-down” principle is increasingly reaching its limits.

Contradictions in practice: transparency and leadership culture

The contradictions in the implementation in practice become visible if you look at the perspective of the employees. First of all, it is noticeable that it is mainly the younger employees who judge positively and emphasize the advantages of Scrum. Older employees, on the other hand, show a slightly different perspective in the interviews. In particular, the transparency that is created via IT systems and in the meeting routines is assessed more critically by them than, for example, by the younger colleagues, who see it as a favorable learning condition. Older people, on the other hand, often experience this “absolute transparency”, according to one interviewee, as “pressure to justify”. Against this background, certain forms of resistant practice can be observed in some teams: e.g.

The background to these behaviors is obviously a tense stressful situation – despite empowerment and self-control of the workload in the team. Even the manager stated that the developers were “exposed to enormous pressure across the board”. This is explained in more detail in the following interview passage:

Because the employee can no longer say about himself: “I know exactly what I’m no longer responsible for, if I don’t take care of it,” then it’s okay. “So we have a very, very high level of personal responsibility, we have one very, very high intrinsic motivation in the team. And because they see everything and know everything and know everything, they know exactly where we have construction sites everywhere. This is the responsible engineer, if you will, who really sees the full breadth of horror and feels responsible for it. Well, you no longer take the burden off his shoulders of not having to worry about certain things. (B-13)

The interviewed manager attributes the pressure at work to personal responsibility and the high intrinsic motivation of the employees. Against the background of the lack of separation of planning and execution, the employees are confronted with the “complete breadth of horror” and cannot evade responsibility. In a sense, this is the downside of the “mature engineer”, that he has to bear the whole burden of responsibility. This increases the risk of overwhelming themselves, which the manager then appears to be helpless to face.

This narrative of a supposedly “interested self-endangerment” (Peters 2011 ) is different from the perspective of the employees:

The name “Sprint” is justified in this case with us, yes, you really have to say […]. Well, I think it’s actually a more stressful work environment than without [agile methods], you just have to see it that way, for the individual. That means, I guess there are, as I said, very positive aspects, but the fact that this is sold as a relaxed working method, I don’t entirely agree with it because, I guess the pressure is higher than overall without, than before. So far everyone has been able to have their own rhythm. This is no longer available in the agile method. You have to say every day I’ve made progress. If not why. I had the problem. That means, this daily rhythm, so for me, I know very well that there are days when I can perhaps do 150% and others only 50. And then there are maybe three days where I, it just doesn’t come, where you can’t really make any progress, and then, then, there are two days where you make real progress. In these agile methods there is no possibility in principle to follow this personal rhythm, because a certain progress is always expected, and that is something that is relatively stressful in part. (B-5)

The employee describes his personal suffering very vividly with the agile methods: Through the transparency and control in the team, an unfamiliar work rhythm is forced on him, and he feels a permanent pressure to justify himself, which he experiences as stressful. There is high pressure to perform and the stress at work increases. His description is strongly reminiscent of a typical constellation of “peer group pressure” (Vormbusch 1999 ).

Elsewhere, the respondent points out that most developers actually work much longer on their tasks within the framework of Scrum than they previously estimated together, and then “bend” their hours in the IT system so that the overtime is not done becomes transparent. Another employee pointedly explains why this is so: “Well, we do the work, we do all the preparatory work, and we are terribly bad at implementation, and everything always worked in the review. Because there is also [the manager] in there. “(B-7) It becomes clear here that, in addition to agility, central elements of the previously strongly developed bureaucratic management culture persist – problems in the implementation of work planning are not simply communicated openly,

Overall, the case study illustrates how far the democratization potential of empowerment can reach in the context of agile methods. Based on the rapidly increasing complexity in a field of work that is disruptively changing as a result of digitization, it is almost a necessity to remove the separation of planning and execution and to transfer decision-making powers to the teams in a new quality – up to and including the determination of the content of one’s own work. However, the case study also shows the contradictions and challenges associated with empowering teams. For example, the individual now has to submit to the team’s work rhythm. Individual design leeway, which was characteristic of the work in the previous individualistic expert mode, is now provided by collective, Overlaid decisions made in the team and subordinated to a work process determined by short-cycle sprints. Above all, however, it shows that the bureaucratic framework conditions that still exist in the organization shape the development of the agile teams. In particular, the far-reaching transparency can quickly become the cause of increased group and justification pressure, for example, if the continued existence of a bureaucratic management culture prevents open and constructive handling of problems and there is no “agile error culture” based on mutual trust. that the bureaucratic framework that continues to exist in the organization shapes the development of the agile teams. In particular, the far-reaching transparency can quickly become the cause of increased group and justification pressure, for example, if the continued existence of a bureaucratic management culture prevents open and constructive handling of problems and there is no “agile error culture” based on mutual trust. that the bureaucratic framework that continues to exist in the organization shapes the development of the agile teams. In particular, the far-reaching transparency can quickly become the cause of increased group and justification pressure, for example, if the continued existence of a bureaucratic management culture prevents open and constructive handling of problems and there is no “agile error culture” based on mutual trust.

Merging and Outlook: Potentials and Challenges of the Democratic Company

Our considerations and empirical findings show that with the concept of agility in the course of the digital transformation, a new guiding orientation has emerged in companies. This aims to overcome the limits of the Fordist bureaucratic organization in order to increase productivity and cope with the increasing complexity of production processes. With agile concepts, the possibilities for overcoming isolated silo structures, bureaucratic decision-making cascades and the expert mode created on the basis of the information space should be made practically effective – by restructuring the work and organizational processes in the team and thinning the hierarchy levels or increasing the management spans.

In our case studies, we can see some far-reaching potential with regard to the employees’ power of disposal over their work processes. Corresponding dimensions here include the scope of work and the type of implementation of the projects (ie the “how” in the work) and can sometimes even extend to the possibility of determining the content of the work. However, our case studies also show that agility does not automatically mean empowerment. Different types of game can be identified – up to agile teams without real empowerment. The fact that different varieties can arise even within the same company shows the importance of the specific design of agile methods and the associated operational negotiation processes (also Boes et al.2014 ).

With a view to the difficulties and contradictions of empowering agile teams, various challenges can be highlighted in detail. One relates to the scaling of the Scrum approach itself: If a holistic production model is implemented for the entire development organization based on the Scrum framework, the design of the interfaces between the teams requires special attention. The growing interdependencies indicate that empowerment cannot be thought of by the individual team alone. Another challenge relates to the management and the continuation of a Fordist-bureaucratic leadership culture. If management is not ready to accept the autonomy of agile teams and, for example, specifies large parts of the work plan as non-negotiable, then the empowerment is effectively undermined in a core dimension. As a result, employees can get the impression that they only have to work through externally determined tasks on an assembly line. In this way, the salutogenic potential of agile methods is ultimately undermined, so that the workload increases (Kämpf2015 ). This also applies to the challenge of designing the general conditions of agile teams: Without solid and well-developed relationships of trust that enable a constructive approach to transparency, forms of group and pressure to justify can develop, which can ultimately lead to the emergence of new burdens – similar to in the 1990s in group work in the context of lean production.

The difficulties and challenges of empowerment result not least from the dual character of agility itself. As a strategy for the industrialization of mental work, agility aims to intensify the exploitation of human labor by mobilizing the subjective potential of employees (Boes and Kämpf 2012 ; Boes et al. 2014 , 2018). At the same time – as with earlier rationalization concepts – opportunities and possibilities for democratization arise in the concrete implementation. Both potentials are laid out in the agile methods and are even partially dependent on one another. But that does not mean that both potentials are automatically realized. In particular, humanization potentials such as the expansion of direct participation and participation are dependent on active design (e.g. Sauer 2011 ). The case studies make it clear that it is ultimately the social negotiation processes in companies that determine the extent to which more participation goes hand in hand with more democracy.

In this sense, the actors involved in institutional co-determination are becoming an important factor for a new attempt at a democratic company. While earlier approaches to overcoming Fordist-bureaucratic structures through participation-oriented organizational concepts often tended to play off the direct participation and self-determination of employees against the institutions of codetermination (cf.e.g. Dörre 1993 , 2002 , 2015 ), at the latest with the collapse of the “New Economy ”at the beginning of the 21st century, awareness grew that new forms of direct participation require institutional security (Boes and Baukrowitz 2002 ; Boes and Trinks2006). In order for the democratization potential of agility to be exhausted, the works council must make empowerment a central point of reference in modern labor policy. The institutional safeguarding of the new participation opportunities for agile teams can create an important basis here. This could prevent, for example, the dimensions of empowerment from being repeatedly put up for discussion and having to be renegotiated by the teams. Instead, the dimensions of empowerment could be perpetuated through agreements between the social partners and employees could be granted a guaranteed right to empowerment. It should not be overlooked that the teams themselves are now increasingly becoming a politically significant actor in the company.

In the digital transformation, with the rise of agility to a new guiding orientation in companies, not least institutional co-determination is faced with the challenge of reinventing itself. Initial approaches such as cooperative and process-flexible “experimental company agreements” (Schröter 2017 ) and the concept of “company practice laboratories” (Boes et al. 2017 b) show ways in which co-determination can come into play in this constellation.

Notes

1. 1.The concept of agility has its origins in software development. In the 1990s, a movement formed there that broke with the classic linear process models and developed new methods to make development processes more flexible and leaner. In the meantime it has risen to the new standard in software development, the concept of agility in the context of digital transformation is now being taken up in ever wider application contexts and areas of companies (see e.g. Häusling 2018 ).
2. 2.Scrum is an agile method of project organization and is based on the basic idea that software projects cannot be planned precisely a priori. Instead of long planning runs, Scrum divides the development time into short-cycle intervals of two to four-week sprints, at the end of which there should always be executable software increments. Software projects are thus gradually expanded, integrated and expanded from sprint to sprint.
3. 3.The concept of empowerment has a strong emancipatory reference from its origins in the US civil rights movement. In this sense, it found its way into social work and community psychology as a scientific term (as a control over one’s own living conditions; Rappaport 1981 ). The term Kanter ( 1977 ) introduced into the sociological study of the world of work (for an overview from the perspective of management research see Spreitzer 2008 ). The emancipatory content of the term was supplemented by the aspect of economic efficiency (by mobilizing employee potential) (Bröckling 2003 was critical of this ).
4. 4thAccording to the specification of the waterfall model, software systems are to be developed in a strictly sequential process. All functionalities are specified, planned and budgeted for with the customer in advance. Analysis, design and programming follow in a linear sequence. The software is only tested and integrated at the end of the development cycle. In parallel to this process, all processes are precisely documented (Palmquist et al. 2013 ). In practice, the waterfall model often turned out to be too rigid and inflexible to really do justice to the inevitable imponderables in the process of software development (cf. DeMarco 2001 ).
5. 5.This also seems to apply to other team-based variants of direct participation, which can sometimes provoke direct resistance from employees (cf. e.g. Thursfield 2015 ).
6. 6thTo do this, the team jointly estimates the effort in the context of a “planning poker” in which each developer evaluates the respective functionality based on story points. To this end, the team has defined equivalences, which it uses as a guide when making estimates. For example, a patent letter has the equivalent of eight story points, while a workshop has thirteen story points. In a subsequent joint discussion, the collective calibration of the individual estimates takes place.