DOI: JEL codes: M15, L84 /

Received 10 July 2019; Revised 1 September 2019; Accepted 12 November 2019

This is an open access article under the CC BY license (

Hubert Bogumił, master of economics, University of Warsaw; extramural Ph.D. student at the University of Warsaw, Krakowskie Przedmieście 26/28, 00-927 Warsaw, Poland, e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.


The aim of this paper is to explore the drivers of keeping the consistency within business processes that are highly supported by system configuration, while the system architecture is impacted by a technical change in the organization that uses both traditional and agile methods of change management. Two research questions were raised related to the most frequent road blocks in managing system and business non-regression in hybrid management of change and the respective methods used to limit the system and business regression in the conflicting approaches of business operation models. In the research, a tailored method of multiple case study was used based on primary and secondary data from accessible documentation of projects, experience from tests and production cut-overs performed in the mix-method of project management, and change management circumstances. Overall findings wrap up the conclusion which is, that in order to keep control using the rules of BPM in transforming an organization, it is an indispensable necessity to use open cooperation that addresses cross-organization business objectives and overall business sensitivity for threads related to an agnostic approach of change realization chained by methodological rules. The advantages of collected knowledge may lead to formed ways of securing business objectives from unexpected regression driven by internal and independent organizational enforcements.

Keywords: business hybrid organization, business and technical change, business regression, IT system regression


Organizational change is one constant value, driving life and business objectives and, hence, shaping the conditions of business processes, that were raised by numerous authors, e.g. Harmon (2007, p. 33). While unexpected occurrences influence business process governance on a daily basis and are perceived as natural inconveniences that require better planning and prediction for the future, the improper and independent implementation of intended change brings confusion on the legitimacy of adapted orderliness and aligned business processes that can be caused by natural deficiencies to manage the risks, as identified by Moran (2014, p. 36-37).

Business organizations, usually being well aware of the related risks and challenges, make efforts to consider, predict and identify any occurrence of change and try comprehensively to estimate its impact. Hillson (2017, p. 3) also underlines the role of increasing expectations related to this aspect. Some organizations, especially those that perform their business activities in highly regulated environments, are equipping their business processes with risk management tools that mitigate any deficiencies that may appear by materializing risks.

Nowadays, each organization is more and more aware of its subjectivity to different types of risks and increasingly this trend is strengthened by information technologies (IT). Information systems are demanded by every aspect of business architecture, constituting a constantly undying need and an inseparable compulsion that accompanies any business idea and its consequent change (Avila & Garces, 2017). Business Process Management, as a highly IT-soaked area, also influences IT changes that are strictly connected to innovative notions. This paper exemplifies the inter-dependencies between the ways changes are implemented and the possible aftermaths that can emerge.

In order to get clarity and comprehension of the used terms and definitions, it is important to explain the overall relations between them. Business Architecture is defined by The Open Group Architecture Framework (TOGAF) as the overall business organization, strategy, governance, which was adequately expressed in Harrison’s position (2011, p. 18). We believe it is valuable to supplement this definition with processes orderliness, which allows one to constitute business governance and entrepreneurial organism toward realizing set business goals and targets. To support business architecture, and also business initiatives, an organization uses Technical Architecture, which is defined as an embodied information system structure, adopted and implemented in a particular business organization to support business architecture and business initiatives; known also as technology architecture with its technical (software and hardware including middleware, networks, communications, processing, and standards) capabilities, as also stated according to TOGAF by Harrison (2011, p. 18).

Consequently, there is a need to define Business Change as a change in business process functioning in an organization, driven by people, which has been underlined by Stumpf (2015, p. 6). Business change in this paper is recognized as a single source for launching a chain of events through the obvious impact of technical architecture, and inducing related risks to bring regression in technical order and, subsequently, potentially impairing business architecture neighborhoods. On the other hand, it is necessary to underline that any other kind of business change that does not engender technical change is not a subject of this analysis. To picture this aspect, we may call two such examples as product parametrization, new plan of tariffs, etc.

As a usual successor to business change, in a highly technologized business organization, a Technical Change can be observed. It can be defined as a change in the technical architecture supporting business processes, requiring adequate analysis and technology, as also stated by Paton and McCalman (2008, p. 22). In this elaboration technical change is inducted by business change and strictly related to the change of version in configuration item (system, application, etc.). Consequently, any changes that do not directly entail a change in configuration item version are not a part of this analysis, for example, changes in parameter tables of database to bring new services or change existing ones.

To efficiently manage both business and technical changes it is important to introduce Change Management, which is a process embracing all the necessary activities to coordinate business and technical changes in an organization. Also called a “key skill” or even a “key survival skill,” as defined by Paton and McCalman (2008, p. XVI), the change management process is very often connected to a business readiness point of state that is a consequence of the implemented change; as such it may also refer to other dimensions as qualitative communication management, procedural readiness, staffing, etc. The change management process is well equipped with a portfolio of methods used to run it, for example, ITIL.

Further, Change Management is by best practices decomposed to other managerial sub-processes, with one of them being Project Management, named by Kerzner (2017, p. 2) as a coordinated set of tasks and activities aimed at realizing a project’s objectives. Project management is usually widely perceived as a large group of activities embracing: time management, risk management, schedule management, people management, scope management, test management, development and integration management, etc. The general approach presented in this paper, to all advanced terms and definitions on project management, is to express it as solely the management of unrepeatable work centered on achieving clearly specified aims. Project management is willingly taken as a subject of many methods and methodologies, both traditional, for example, PRINCE2, or agile, for example, AgilePM. At the same time, there is a clearly visible lack of a methodological approach to the use of mixed project management methods such as cascade and agile. This substantial gap is quite onerous, especially for those organizations that are in the middle of a transformation, or under pressure to use both of them at the same time.

The paper also analyzes Hybrid Organization, which we define as an organization where project management and superior change management processes are realized in both: traditional, cascade routine and a new, agile method creating teams and sub-organizations to proceed with a specific way of conduct, for example, DevOps, to support agile performance.

DevOps is identified as a business structure in an organization focused on realizing a particular set of business processes or value streams, usually highly independent within an organization and being equipped with technical support and adequately resourced, in order to realize business processes and related changes in an efficient and agile way, that was also intended by Kaiser (2018, pp. 2-4).

As the subject of the study is System Regression, it is important to provide a clear understanding of this term and define this as an unplanned change, resulting in an impairment of the business process and technical architecture that impacts the connected configuration or service. Such an approach is also provided by Kaiser (2018, p. 222). It is worth underlining that the risk of regression is one of the key aspects of the realization of the technical change within a system landscape, which results in the necessity to use advanced mitigation methods as non-regression tests; the occurrence of regression may result in unpredictable consequences and lead to a substantial impairment in the system and business architecture; in the hybrid organization, regression management is one of the key challenges that impacts the stakeholders of change implementation.

Nowadays, business organizations commonly use processes that are fully supported by information technology, as they are also connected to external dependencies such as regulatory reporting, external payment systems, intermediary vendors, outsourcers, etc. In the common perception, a well-performing business organization is very often bounded by the established rules and governance of Business Process Management.

Nevertheless, the market and the general surrounding business environments of a particular industry promote everlasting competition, which enforces mature business organizations to use more and more modern solutions. Many stakeholders within a particular business organization, and outside of it, perceive technological racing, and thus innovations and improvements, as key factors to keep up with market expectations. This endless searching is simultaneously full of side effects, risks, threats, and even dangers that may lead to disaster. In accordance with Teniente and Weidlich (2018, p. 614), in highly technologically-embraced business processes that are subject to BPM, there is a more frequently noticeable phenomenon of clear addiction which, even when a single business operation encounters severe issues, may be caused by one, and sometimes a non-pecuniary, technical change in information systems.

As a technical change process is an integral part of a change management process, there can be stated a homogeneous definition that technical change qualifies only changes in a system (software) component version, as also identified by Muller and Rumpe (2015). It is important to distinguish a technical change from a parameter change within an information system or application as long as parametrization does not impact the change in a technical component version. According to the currently used standards, many technical changes are realized in a prompt and agile approach, and keeping a close focus on configuration management and the appropriate version appliance has become an indispensable necessity and enormous challenge. The challenge increases in geometric progress to the scale of the technical changes and the number of their releases.

It is important to realize that every single attempt of change implementation may cause regression in the overall organizational order. Figure 1 displays the above-mentioned area, presenting the questionable flow that is a subject of the research.

Figure 1. Change Management in the business process of a Hybrid Organization - logic diagram

Bearing in mind that agility in a business organization influences every possible aspect of business governance and organism (Unhelkar (2013, p. 452), it also clearly impacts existing practices and methods of business change. As introduced by multiple IT service management approaches, for example, ITIL2 (Kaiser, 2018, p. 2), each component (configuration item: CI) has its own features and is versioned by the unique value, being a service asset. Kaiser (2018, p. 137) has endorsed such an approach, referring to the unique nature of each separate CI. All CIs configure a system landscape that is technical support for business processes. Many CIs do not function as independent elements but are in relation with other CIs. As mentioned by Avila and Garces (2017), this clearly and certainly leads to the conclusion that any technical change within the single CI (its version) may influence other related CIs and disclose unexpected consequences, which respectively may elicit the system regression in an overall system landscape. As Parsons (2014) identifies, following the occurrence of regression in a system landscape, it is obvious to notice the next step of the impairment of other business processes. The occurrence and matter of technical and, thus, business regression is very well known and is usually mitigated by multiple non-regression tests that can significantly decrease the project and system risk, as also described by Kaiser (2018, p. 288). In the hybrid change management performing organizations that face operational challenges related to independence and transparent governance, there are frequently repeating concerns of how to efficiently manage business processes that are impacted by business changes and, as Paton and McCalman (2008, p. 77) notice, it is connected to technical changes in order to keep business processes unimpaired.

The aim of the following research is to attempt to fill the gap in the methods and currently known practices allowing the smooth use of BPM, as was also identified by Teniente and Weidlich (2018, p. 614).

To display the universality of the regression problem caused by a technical change, we have chosen three organizations that represent in general: differential industries, maturity of IT adoption and openness for agility in the realization of business change. The research as such embraces reasons, challenges and answers of technical, and hence business, regression caused by diverse and incompatible practices related to project management and change management approaches. During the study, we attempted to interview key people who have a direct impact on all stages of creating a change and, at the same time, safeguard the risk of the negative consequences that changes may cause. All these elements have been described in the part of the paper related to Research Methods.

For strengthening the research business case, it is worth underlining that some fragmented researches have already identified issues of gapping areas between traditional methods and DevOps-oriented practices being a source of severe issues, which can be referred as well to Kaiser (2018, p. 73). Considering that either Project Management methodologies3 or ITIL do not provide answers and rules or help driving business practices for hybrid ways to manage the change, it is crucial to raise the following research question:

RQ1: What are the most frequent road blocks in managing system and business non-regression in a hybrid management of change?

And to supplement the analysis, it is crucial to refer to the consequent step that can be expressed by the following question:

RQ2: What methods are used by organizations to limit system and business regression in the conflicting approaches of business operation models such as traditional and agile?

The above questions try to address the shaping of the approaches and best practices that may be followed by defining reference models supporting those organizations, which wish to look for benefits and filling the gaps resulting from the use of such a hybrid style of change management. The following Figure 2 expresses the relations between the research questions.

Figure 2. Research questions – logic diagram

The emerging answers to the research questions will articulate the subject matter synthesis of the overall issues and ways of how to resolve them.

Nevertheless, the refined conclusions may also deliver honorable points to restart the discussion on how a business organization needs to perform to avoid easily predictable traps, as identified by Yazici (2009).

To present a comprehensive approach it is important to refer to the structure of the analysis and, hence, the paper as is. Thus, the elaboration has been compounded in the paragraphs stated below.

Firstly, there is a literature background of the raised theme, which also allows a better understanding of the root cause of the identified issues and subject matters of change in business processes powered by technology. The following paragraphs provide a description of the adopted research methods and their justification in the specific circumstances that were faced by the author. Next, there are the results and analysis obtained in the course of the research, which allow one to comprehensively understand how the raised issues and concerns may be addressed. The article concludes with further discussion and conclusive statements that summarize the matter of research, further discussion, consideration and, in consequence, future research options.


The business architecture of an organization is shaped and structured by business processes. A well-preforming set of business processes is always the subject of careful establishment and has been named as Business Process Engineering – BPE. Elzinga, Gulledge and Lee (1999) approach BPE as assessing ways in which companies’ productivity, product quality, and operations can be improved. A further step is another theory related to business process improvements that can be introduced, and that is specified as Business Process Reengineering – BPR. As noticed by Simon (1994, p. 29), it may embrace, among others, such criteria as the rearrangement of organizational structures, processes and tasks. According to Hammer (2001, p. 35), BPR is “the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical, contemporary measures of performance, such as cost, quality, service, and speed.” Thus, the necessity to look for improvements in business processes is natural from the perspective of innovations that are driven by technology, and also from the perspective of desiring to get higher business value that can be considerably supported by technology as well. It is also good to notice the overall place of a business model as a consequent set of processes efficiently or even effectively working.

While a business model can be related to an optimal state that such a set of business processes fell into, Białek-Jaworska and Gabryelczyk (2016) noticed that a business model can be extensively described by its components. Going further, they perceive a business model through its definition regarding the way a company delivers customer value. Another factor is the way the company makes customers pay for such value. However, the key point here seems to be refining the way a company transforms these payments into profits.

Changes in the business model usually enforce further reengineering of business processes. As business processes are highly equipped by information technologies, such changes can be perceived as sensitive for the overall business and technical architecture in the business organization. Simon (1994, pp. 59-61) describes IT as being disruptive for traditional processes that were mostly operated by humans, and indeed IT has been refining revolutionary changes that act at a highly speedy rate.

Nevertheless, it seems that the most unpredictable and thus devastating is the unplanned and unexpected failures in running business processes caused by the technology that supports it in a usual code of conduct. Śledziewska, Gabryelczyk, and Włoch (2017) link the Resource-Based Theory, which helps to understand competencies within organization, to the necessity to define digital competencies, which refer to the strategies for managing related assets and thus to the further development of specific skills within an organization. A lack of such digital competencies may drive unexpected occurrences in technical architecture. Dwivedi, Wade, and Schneberger (2012, p. 415) connect this phenomenon to the difference between working routines or systems and the information systems that are there to support, but in some circumstances may overwhelm, users. Moreover, it can even be worsened when intra-organization communication is not properly handled, as it is well noticed by Dwivedi et al. (2012, p. 100), who refers to this as the information distribution approach. It brings attention to the substantial role of intra-organizational communication in an Organizational Learning model, as pointed out by Dwivedi et al. (2012, p. 97).

Crashes that appear in the daily use of technology or its amortization can be somewhat considered and understood as natural occurrences. However, failures that are induced by changing technology can bring enormous and unbudgeted repercussions. In the following paragraphs, we will focus on the disruptions that are caused by regressive technologies during the implementation of technical changes, by change management processes running in traditional, cascade routines, and agile ones.

An impairment of the business process caused by a technical change

Although the definition of business impairment and the consequent impairment within BPM, which is caused by system regression and its management, is not a new appearance, as currently a basic emergence is observed of correlative problems triggered by a persistent approach to establish and use new, innovative tools and methods of agile managed organizations, as noticed by Mihalache (2017). This is very often applied to those organizations that are in the transformation from traditional operating models, as underlined by Unhelkar (2013, p. 146).

Pisano (2006) ascertains that “strategies adopted by firms that have successfully profited from their innovative activities cast into new light old questions about the impact of intellectual property protection on the rate and direction of innovation.” At the same time, it is necessary to underline that more and more accepted innovations in a limited time scale may create considerable issues connected to their efficient administration and management, and can result in the emergence of unexpected breaks in business processes.

McManus, Seville, Vargo, and Brunsdon (2008) notice that building and keeping more resilient organizations are considered to be able to create an adequate response to the crisis or emergency management issue that occurred. In consequence, resilience for organizations is found to have three principal attributes. McManus et al. (2008) list situation awareness, management of keystone vulnerabilities, and adaptive capacity. Also, it is indispensable to equip the organization with a facilitated process that can assist in enhancing its performance according to these attributes. This is directly touching such aspects as impairment of business processes and the ways organizations can manage them. By its nature, an impairment may have numerous different root causes related to differences in how the business is conducted and how the changes in technical and business architecture are performed. According to Kakar’s (2017) considerations, most of the enterprises which mainly use agile methods perform their operations within independent sub-organizations, named DevOps. Such an approach can efficiently realize business objectives, serving prompt change management routines to support them (Kakar, 2017).

Independence traps for business agility

In agile-oriented organizations, the independence of DevOps groups also shapes the new governance of system configuration by a clear division and separation of assigning a particular system CI (i.e., application) to the sub-org independent management, noticed also by Kaiser (2018, p. 122). Such a tight relation equally helps DevOps to realize changes in business processes and independent decision-making on the direction of change and future evolution, which was exposed by Mishra, Garbajosa, Wang, Bosch, and Abrahamson (2017).

Although an independent approach can substantially raise the efficiently prompt realization of business objectives for particular DevOps, it may also lead to an unpredicted impairment in the general system landscape of a horizontal organization and further cascade business impacts (Wells, 2012). Even more complicated and dispersed problems can be observed in hybrid organizations, where there are two approaches to realize business targets and cross-organization governance, as significantly gapped by independently functioning DevOps (Kakar, 2017).

In the large portfolio of unexpectedly emerging problems, they can be grouped and listed as the following: delays or stoppages of the business process and operations (Boehm & Turner, 2005), discontinuity of business performance (Prahalad, 1998), substantially impacting business reputation (Resnick, 2004), regulatory incompliance and litigation. Each of them can determine inconceivable effects for the further functioning of business organizations.

Mitigation challenges for technical change-related risks impacting business processes

The core ways on how to mitigate and manage the risk of business and BPM regression, impacted by system regression, in both an agile and hybrid organization is the subject of this analysis. Although the matter exists in many organizations, it is unexpectedly rare that business organizations raise it sufficiently to establish durable mechanisms to mitigate it. Although some research proposes patterns of algorithms on how to efficiently propagate changes to align business change with IT change, as elaborated by Avila & Garces (2017), they nevertheless seem to remain still in the exploration phase or, even more, only in theoretical considerations. Despite certain omits in this area, business organizations raise overall awareness and start to work out practices that may mitigate the risks of regression. The subject was raised by Kaiser (2018, p. 122), who dedicated conclusive findings to such mitigating practices.

To bring more comprehensiveness to regression in business processes impacted by regressive technology, it is natural to segment its dimensions and try to understand them from such perspectives as the right notice of regression, its severity and business impact, and exploring its root causes, as endorsed by Paton and McCalman (2008, p. 248).


The aim of selecting the right research method for this subject was to make the research widely based on people’s experience and findings. As the baseline items being examined were relatively new for other checked researches, the key acting stakeholding parties must have obviously been people. In this elaboration, a method of a multiple case study analysis focused on real-life organizations has been used, which was previously refined by Yin (2017, p. 91), and the issues they faced for the limitation of system regression The research is established on an exploratory qualitative study with the goal to develop a methodological road map to manage such occurrences in similar organizations. Three medium-size organizations were selected: a mid-size commercial bank, a trading company, and a software house. All of them had an understanding and use of BPM from independent industries and were in the transformation process to adapt an agile approached operational model, similar to Mihalache’s (2017) research. The refined choice of them was driven by general criteria based on two dimensions. The first of them is the observed extensive leadership to transform an organization from a traditional cascade-change driven one to an agile one. The second dimension is related to the variety of industries they represent, so as to get many general conclusions that can be relatively universal from a business perspective.

Based on the regulatory circumstances and legal environment, the above organizations work in, the transformation has a different rhythm and differs from one to the others. It makes the research much more interesting as the outcomes supplement each other and create a well-designed landscape of findings.

The case study focuses on the author’s own observations taken from daily work in close touch to the project environment and interviews with the CIO, business representatives or project managers, and the COO of each company. The supplemental material has been collected, based on particular change projects’ documentation, as business requirements, functional and technical specifications, risk registers, test scenarios, Configuration Management Database (CMDB) reporting, status dashboards, and others. These methods of gathering empirical data from primary and secondary sources are in line with the proposal for the case study research offered by Yin (2017, p. 91), who underlines the advantages of using multiple cases as more compelling and giving the effect of research as more robust. Such points in organizational change naturally allow one to explore the hybrid approach and, hence, the overall struggling and trade-off between time, delivery quality and the purity of used methods, as also underlined by Harrison and Lock (2017, p. 50). In order to collect so much comprehensive data, the research process was established in the following steps:

Step 1. Identification of issues related to the occurrence of business regression impacted by regressive technology and review the subject matter literature; the variety of identified issues determined the need to group them aggregated by similar features;

Step 2. Understanding the gaps in current research and the definition of research queries; the review of accessible literature helped to diagnose the research gaps and locate them in the two groups of used methods – agile and cascade; selection of the research method as the multiple case study analysis focused on real-life organizations as described by Yin (2017, p. 91);

Step 3. Observations and documentation studies; self-observations from realized projects supplemented by documented material were an additional input strengthening the interviews performed with key stakeholders;

Step 4. Interviews with selected stakeholders and driving for conclusions; interviews constituted the core valuable driver of research; in addition, it is good to underline that all the interviews were completed in a project environment; thus the openness and honesty of the collected information is very much aligned with its accuracy. There were also supplemental studies of additional material appointed by stakeholders.

The analysis is also based on the author’s own broader observations during the realization of system-related projects and additionally supported by secondary data – a review of project documentation. This approach has also been used and presented in Yazici’s (2009) elaboration. The raised questions have been adequately addressed and additionally supported by a broader explanation of the business and technical dimensions of occurred regression from the perspective of the notice of regression, its severity, and business impact, and conclusive exploration of its root causes, that was similarly exposed by Paton and McCalman (2008, p. 248).


Case studies

The basis for the analysis was established around three organizations: a mid-size commercial bank, a trading company and a software house; and the most important factor driving this choice was to observe the determined leadership required to promptly transform an organization into an agile one. All stakeholders clearly underlined that organizational readiness for an agile operating model was one of their targets and even as defined objectives obtained from supervisors. During the interviews, each stakeholder tried to point out several main features of agile-related business readiness. However, the platform and main goal were always targeted at efficient communication and cooperation between the business and IT toward delivering the expected change in business processes in prompt timeframes. Figure 3 displays the relations between grouped observation criteria and related system regression dimensions that were raised by the author’s respondents.

Figure 3. Observations criteria and regression dimensions

Figure 3 illustrates the following paragraphs, which summarize the current stage and review each one from the perspective of transformation advance. The description of the current situation has been divided by observation categories that attempt to display the selected wider picture of progressing to organization agility in a particular company. The refined categories were captured based on the Strategic Alignment Maturity model (SAM). The model touches descriptive and prescriptive aspects of alignment to attain higher levels of IT maturity and, consequently, effectiveness. This directly guides business organizations on how to improve business performance, as mentioned by Luftman, Tal, Dwivedi, and Rigoni (2010). As SAM relates to six business architecture dimensions to express its maturity: Communications, Value Measurements, IT Governance, Partnership, IT Scope, and Skills, we have exposed the following ones to visualize the paper’s targets: Maturity of IT processes, Business readiness, and have added Operational agility as a key performing factor. The chosen observation criteria reflect the logical transformation aspects that were raised many times during discussions and interviews with selected stakeholders. Almost everyone underlined that the starting point of a successful agile transformation needs to be a well-functioning IT organization. When an IT organization performs to expected levels and with matured processes and practices, the next success factor seems to be openness for change from the business functions and, thus, its readiness to get a new operating, agile model. Such declarations from business divisions could also be supported by the current agile practices used that can be valuable for resilient transformation. That is why operational agility is one of the core points that can be another important grip for handling agile transformation.

Maturity of IT processes

Business organizations utilize numerous tools that support business management and, respectively, also support IT governance. As IT-related problems extensively impact business processes, it is apparent to the leaders that it is indispensable to have a deeper view on IT-related aspects. Rogers (2009, p. 255) relates such needs to their embracement within the Capability Maturity Model (CMM). As per Rogers (2009, p. 255), many variations of the original model and, thus, frameworks, connect to the capability maturity model and other maturity models that are not part of any formal frameworks. The analysis embraced in Table 1 summarizes the overall view captured from the researched companies.

The above stated as-is quick facts on the maturity of IT processes consequently influence business readiness for applying new, agile-related ways of conduct.

Business readiness

Business readiness or substitutable, organizational readiness is quite a wide-ranging sense of terms. Among many of them, the most suitable for this paper is the one as presented by Weiner (2009) and constituting organizational readiness as a “shared psychological state in which organizational members feel committed to implementing an organizational change and are confident in their collective abilities to do so.” From the perspective of an overall approach and adaptive behaviors to accept organizational change and perform in a new atmosphere of agility, such a definition is comprehensive. Thus, respective observations have been collected and presented in Table 2. This adequately fits into the frame of the research.

Table 1. Maturity of IT processes


Maturity of IT processes

Commercial Bank

Business processes are fully covered by IT system support; any manual set of activities chased against possibility of automation.

Well performing horizontal IT service management model is strongly supported by ITIL and related system tools.

Change management process is centrally managed with minor exceptions. Constant aspirations to refine DEVOPS model of change management performance were observed.

There is a well adopted and used CMDB4. Any exceptions from using CMDB are persistently registered and audited.

Trading Company

Business processes are in the majority covered by IT system support. Nevertheless, there are gaps in coverage of processes by systems that are strongly defended by related staff.

IT service management processes are under construction and partly working. There are gaps in understanding the necessity for IT services and ways of their contracting and clearing.

Change management practices differ from department to department. The company is working on unification of change processes. For now, CM processes are not formalized nor described. Ways of performance based on best practices and verbal transmission are commonly used.

CMDB has been partly adopted for selected critical configuration items. The process of Configuration Management is based on an expert method. There is no routine to keep CMDB records actual. Any updates are executed usually only by clear requests from the CIO.

Software House

Business processes are fully covered by an IT system support. There are no manual activities, nor home-based solutions used for business processes. The office applications are only used for supporting the work of humans;

IT service management is efficiently repeatable and adopted in a particular company’s division. There is full coverage of the system’s development life cycle and maintenance by ITIL processes and best practices. Persistently seeking ways of improvement is adopted in the company’s culture.

Change management process is featured for each division and is independent. There is a full rollout to DevOps teams with a strong sense of efficient communication between teams as necessary.

CMS5 is widely dispersed among divisions and is locally adopted and managed. There is well-constructed communication on changes and the relationship between configuration items located in different DevOps teams.

Table 2. Business readiness


Business readiness

Commercial Bank

There is raised focus on business value and prompt response to market change. Favorable accents are put on profitability and refined business chase on any emerging business change.

There is a high willingness to close cooperation with IT and agile working methods. A culture of advanced understanding and importance of IT systems has been refined, and the way of their performance to very low level of granularity (e.g., Business very often possesses knowledge of tables in data base layer of system).

There is well-driven sense of reporting on business value. Reporting and status update seem natural and indispensable factor of peoples’ activities.

Trading Company

Business targets are quite steady and shaped within strict regulatory frames. Although the business innovation stream is well exposed to communication with the staff. New ideas are trying to get some daylight, however possible improvements and new ways of business performance are rather based on the routine to follow what competition does.

Clear separation from IT influence and gaps of understanding IT-driven business processes and getting additional value from closer cooperation. IT department is perceived as a focused magic center. The company staff receive IT solutions and partly are understood as business miracles with no clear understanding of their need and level of importance and moreover the ways they work.

Business value is unfocused for business departments. Profitability and business case are being built and reviewed at Management Board level. Lower levels of supervision are typical decision takers with low willingness to look for value or initiate further related ideas.

Software House

Business and IT are treated as one correlated mechanism with a high level of mutual understanding. Business lines are assigned to people who are very well oriented in IT capabilities and are involved in any discussion on IT aspects in an easy and unfettered way.

Business value is very well defined and focused on by all staff. There is currently an existing program of additional benefits and net fee revenue calculation for individuals that contribute their active involvement in achieving real value – e.g. new contracts or cost saving. The staff is highly committed and aware of the business and competitive edge of the company’s strategy and tactics.

Business value and profitability are frequently reported. The staff is very well aware of reporting routines and its importance for the overall functioning of business directions within the company.

The analysis of business readiness has clearly delivered an overall view of organizational preparation to introduce a transformation process toward an agile model of performance. The next-step researching point was to check the current status of those parts of the organization that declared agility as the currently used approach and code of operational conduct.

Operational agility

As with the definition of business readiness, there have been numerous attempts to describe operational agility. One of the most eligible, which sticks to the spirit of this research, is presented by Sajdak (2015), who defined it as the “ability to adapt a company’s business processes so that it can quickly, accurately, and effectively exploit market-driven innovation.” Additionally, it is worth including such a designation of operational agility as to “reconfigure existing processes quickly and create new ones to take advantage of dynamically changing market conditions” (Sajdak, 2015).

Operational agility determines the level of performance of business processes and thus the overall functioning and efficiency of BPM. Table 3 embraces the observations and declarations from respondents on this matter.

Table 3. Operational agility


Operational agility

Commercial Bank

Pilot DevOps Teams are performing in each business department. Several careful ways of adopting agile methods have emerged, although there is strong board commitment to respective transformation and constant enhancement of connected initiatives. As per the nature of business, adjusting operations to agile routines is critically dependent on a non-influential rule for client’s activities and functionality. From another perspective, agile practices are carefully adopted based on the review and potential appraisal of external supervisory bodies.

Trading Company

Selected IT change projects are practiced with the use of agile methodologies. Nevertheless, such practices are more related to new interest and desire for new experiments than a real need to delivering business and technical change quicker and more efficiently. Business and technical stakeholders declare openness for agile methods. There are related risks or threats unnoticeable as per business nature.

Software House

DevOps are efficiently working and organized for the entire company with a high independence and internal sense of competition. Nevertheless, there is a high sense of independence that causes an overall inkling of many small business organizations within one huge organizational body. Therefore, there is an existing overall question of keeping the consistency in business strategy applied to the entire enterprise as one running business organization.

Operational agility has indeed got a much broader sense and, again, can be expressed in multi-dimensional criteria. However, the paper has limited them to the above presented statements to target its research aims.

Conclusive findings

Toward getting a tolerably consistent and transparent overall view, there is an attempt to summarize conclusions on the as-is situation in a particular company. Clear observations can be refined, noticeable after the analysis of the current stage of agile transformation for the above-stated organizations. Software House is the most advanced company in getting to full agility. There are good awareness and understanding of the indispensability of mutual functioning, the axis of business-IT as performing machinery toward creating business value and a competitive market edge, and at the same time allowing people to develop their skills, competency, and interests in the innovative business organization.

Bank is fully aware of what steps to take toward getting to agility and is persistently realizing them. Nevertheless, due to keeping critical processes and business operations to high-standards and well-controlled, the transformation to agile reality is featured with evolutionary and careful steps. It is necessary to avoid any influence on the client’s wellness or comfort and thus, the bank’s impaired reputation. Another important point is to avoid the risk of exposing the bank to its regulatory bodies as a consequence of unexpected business impairment.

Trading company is in the stage of testing agile methods and the possibility of their further adoption, with no clear planned path to transform the operations into an agile formula. Nowadays, there are several initiatives launched to experiment and to collect a sort of experience toward preparing for any further planning of agility adoption. The company has got clear gaps related to staff awareness and overall understanding of why agility needs to be adopted and what benefits it may create for the company.

Despite the differences in the advance of a transformation to an agile functioning organization and understanding of its purpose, all three companies face high-level issues related to technical and further business regression that frequently occur during the realization of change projects, as was also noticed by Costantino, Di Gravio and Nonino (2015). Unexpectedly, a lower level of technical regression has been declared and observed in the trading company and the higher ones in the software house. The first impression of such a state is coming from the level of advanced technical support of business processes and the respective awareness by staff. Another explanation might be connected with the different technical regression tolerance in a particular industry and thus different exposure to risk occurrence and threats.

The roots, however, are diametrically different

With respect to the banking organization, although the phenomenon of technical and business regression is well managed and smartly limited, the business impact is the highest one in comparison to the other companies. This results from two general principles that put the bank out on more sensitive exposure than the remaining business organizations. These principles are:

  • reputation of bank as an institution of public trust and the connected client’s loyalty and security;
  • strictly regulated banking industry and strong requirements of the code of business conducts defined by external regulatory bodies.

Going further, it is necessary to summarize the risks and potential influence from the technical regression caused by technical change on the business organization and the level of business and value impairment they may result. The following paragraphs present the observed regression dimension and root-cause. They are based on considerably repetitive notifications from respondents that can be grouped into such categories as technical and business regression notice, severity of technical regression and business impact, root cause of regression and mitigation methods used or to be used. They comprehensively embrace those observations that are qualitatively connected to the subject of the research.

Technical and business regression notice

Our respondents underlined the importance of the moment when regression occurrence is noticeable. Although regressive tests are usually adopted for any technical change-related projects, it is rather unlikely to commit that all potential regression is to be mitigated. In conclusion to this fact, it is indispensable to emerge the ability to capture first symptoms of regression and promptly addressing potential business impact. As highlighted by the respondents and grouped in Table 4, such capabilities can be constructed and based on two engines: technical and cultural. Per the technical engine, it can be expressed as a set of tools, based on the statistical monitoring of technical and business processes. While technical regression predictive engines are providing early warning signals, the cultural engine can mobilize all human vitality to support it in parallel. It is achieved by the consequent building of people’s awareness and sensitivity for disquieting signals in daily work activities.

Table 4. Technical and Business regression notice


Technical and Business regression notice

Commercial Bank

There is carefully monitored and predicted potential influence of technical change of business processes thus there are quickly observed and identified gaps in particular business functions. Technical regression is most often assumed and observed for quick fix changes and unplanned releases. Thus, such regressive changes are accepted and, consequently, well managed by an emergency change management process or even business continuity planning. Within agile teams, the regression occurs more frequently than for the rest of the organization and sometimes is alarmingly ignored as non-material for particular DevOps.

Trading Company

There are mid-term identified gaps in business process functions. Surprisingly, there are no quick, adaptive processes run or the need to react promptly and efficiently. Technical regression is observed for newly implemented systems independently, a method that has been used for change management. There is a high tolerance of regression occurrence and hence fixing resulted dysfunctionalities are deferred in time.

Software House

There are immediate alerts of non-working elements in business or technical processes. High sensitivity level is displayed by staff as well as there is full awareness of the potential impairment to the business organization. Technical regression is constantly monitored for horizontal processes bulked by BPM and respective systems. Almost every release of a single technical change in such systems in one DevOps results in technical regression in other DevOps. Well-kept communication channels are working and there are established additional communication enhancements in crisis occurrence – i.e. frequent and multi-status meetings during the day or launching war-rooms, where the resolution is worked out until success.

Early regression notice may considerably increase further mitigation by the use of adequate counteraction. It is always accompanied by an appropriate qualification of the severity related to the occurred regression and circumscription of the potential impact on business processes.

Severity of technical regression and business impact

This dimension was evaluated as the biggest repercussion driver that requires promptness on analysis and consequent response. Our respondents endorsed such a sequence of steps as the critical chain on keeping the business process in a healthy condition with minimal impairment. As presented in Table 5, some respondents mentioned that a quick reaction may even retain the continuity of business processes, which is a key factor for business organization survival.

Table 5. Severity of technical regression and business impact


Severity of technical regression and business impact

Commercial Bank

System regression may have a high impact on business functions. It usually engages additional resources and war-room activities. In some cases, it even resulted in the launching of BCM6 and back-out plans. The most severe one resulted in inaccessible front-end services for the bank’s customers.

Trading Company

There is a medium impact on business functions, especially due to the fact that technical and business architecture by its nature are not in direct relations.

The highest risk can be caused by those configuration items that have an influence on metric and billing systems.

Software House

The severity of system regression is perceived as medium. It occurs frequently and hence best practices on how to manage with such situations have been worked out. Quick fix teams and post production cut-off incident management emerged. The most nagging issue is related to external delivery slippage and possible litigation.

As both regression notice and the identified severity are critical entry points to properly manage the occurrence of regression, it is important to attempt at concluding on the root cause that identifies the sources of the regression phenomenon.

Root cause of regression

As per business best practices, it is always valuable to conclude any issues or winning points after they have occurred or have been achieved. As listed in Table 6, our respondents in referring to such lessons learned, were focusing on the fundamental reasons that generate unexpected system regression and thus overall threads for the functioning of business processes.

Table 6. Root cause of regression


Root cause of regression

Commercial Bank

Quick fix changes are realized in the simplified procedures that omit some non-regression mitigation rules. For quick fix changes, the most important is the time to fix and sometimes it influences the necessary acceptance of a potential end, and even known regression upshots that may appear. The appetite for such acceptance is always contrary to comprehensive risk management rules.

Agile methods skip some configuration management practices and alarmingly also adopted rules in order to promptly address the project’s aims. Thus, the risk of non-regression is neglected especially for insular systems.

Trading Company

There is most often the lack of formal configuration management and extensive use of expert methods for possible regression identification. This approach causes the snowballing of technical regression. However, the risk of the existence of such regression is not connected to enormous business effects and is usually connected to the off-lining of one or two systems that in fact may well be around in such a size of enterprise and in this particular industry.

For cascade method-run projects, frequent delays are observed that influence on approaching with simplifications in the very end stages. In consequence, they generate unexpected technical and business regression.

Agile teams usually do not use any configuration management practices that seem only cumbersome as declared many times by agile teams.

Software House

A highly independent approach is used for frequent releases and individual styles and practices to implement changes within DevOps.

There are still gaps in efficiency of the communication methods used between DevOps on realized changes in horizontal systems. Although lessons learned are discussed after each release. Additionally, a persistent eagerness is observed to get improvements in communication ways. The reason for this is a frequently raised and maintained awareness and clearly exposed factor, that gaps and inefficiency in communication is one of the major roadblocks in managing non-regression and overall system configuration aspects.

Increasing numbers of releases that constitute KPI in overall competition between DevOps. This aspect is also supporting numbers of regressive issues. There is an observed and underlined challenge of realizing releases with no support from professional technology tools dedicated to change management in agile-performed software houses.

In conclusion of the noticed root causes, there were naturally raised ideas on how to exclude such reasons or at least try to shape any ways to make them calmer. Our respondents willingly proposed different mitigation ideas connected to the system regression reasons.

Mitigation methods used or to be used

Among the different ideas to mitigate system regression, there was a reasonable possibility to group them into the following bulks that are displayed in Table 7. Such groups can be a good starting point to create a flavor of the indispensable steps toward getting agreement between the supporters of traditional, cascade methods of the change management process and those who are persistent followers of agile-related methods and tools.

Table 7. Mitigation methods used or to be used


Mitigation methods used or to be used

Commercial Bank

There is an adopted ongoing learning curve that assures continuous awareness within the change team. Lessons learned workshops are used after each mid-size occurrence of system regression.

Despite using agile techniques, there is an indispensable need for respecting the configuration management guidelines, also for dedicated and seemingly isolated systems. The process of configuration management keeps relatively high standards and any omissions or apostasy from constituted rules are carefully reviewed and even, if necessary, audited.

Trading Company

Non-regression activities declaration is stated in the project’s documentation and status meetings. Nevertheless, all mitigation seems to remain rather as a declaration of necessary activities than a real plan that is to be realized. The project managers treat all tasks to avoid non-regression as a necessity in fulfillment methodologies and expected rules and as a kind of side-effect of their work.

Financial discipline, incurring staff’s discretionary compensation, has been adopted – i.e. yearly bonus. Thus, most disciplinary and motivation factors are potentially impacting people’s wages. The impact, however, is connected to additional benefits and not as a KPI on some ‘at risk’ parts of wages.

Software House

Introduction of one dispersed CMS and rules of use that clearly support all configuration management related needs and consequently to distinctly mitigate the risks of regression. Dispersed configuration management tools quickly and flexibly support all necessary activities to prevent any occurrence of potential regression, however specifically within a particular, single DevOps.

There is a need to flatten the independence and thus to lead the improvement of communication between DevOps for changes in horizontal systems. Still, there is a need for enormous efforts to be taken to handle the security of non-regression for horizontal projects and the need to enhance and refine communication channels.

Another idea is connected to the introduction of new KPIs – e.g.: percentage of occurred regression points counted in simple cases of impaired configuration items by changes called during project realization.

In the three examined companies, a huge bulk of differences has been observed among the overall approaches to handle non-regression related tasks and activities. Therefore, the interviews brought also deep and distinguished differences of attitudes among individuals regarding the overall perception of root-causes related to the above dimensions and their interesting behavioral expressions.

In discussions with people who are still strongly rooted in traditional cascade methods, a delicate skepticism and diplomatic curiosity were observed with respect to agile codes of conduct and reluctant reconciliation with upcoming changes. It is the usual behavior also observed in other researches that expose behavioral performance and the attitudes of people representing cascade-traditional approaches to project management. Supporters of traditional, cascade methods, being well aware of the level of regression launched by DevOps teams and issues related to this, were strongly underlining the need for an efficient and centrally controlled configuration and the management of non-regression, which was also endorsed by Pries and Quigley (2009, p. 179). Another very important factor that was usually re-called during discussion was the need for clear communication and, going one step forward, the necessity for giving the status of communication performance between DevOps and traditional teams.

Polar different attitudes were presented by people that have been using agile methods for at least several months. They excluded any need for central control of their practices and a somewhat hostile attitude to cascade and traditional methods of change management. Most often, DevOps teams perceive BPM as a driver of a particular value stream and do not connect it to its horizontal use across an entire organization. Nevertheless, they understand the phenomenon of system regression and thus, business regression caused by changes in systems when they are uncontrolled by central functions. Nevertheless, they displayed diametrically different approaches on the roots and possible resolution that is quite natural as observed by the others, as Mishra’s et al. (2017) considerations. At the same time, agile supporters also seemed to become supporters of keeping shortages or even the limitation of communication across business organization. They perceive the need for openness as a kind of danger that may incur their independence as an integral sub-organization within a large business organism. Another obstacle listed was the fact that open and frequent communication may be a challenging point to getting a competitive position and may impair their overall results and ranking of scores achieved among all DevOps.

The outcomes of the performed study have addressed the Research Questions in the following conclusions:

RQ1 – the perspective of the most frequent road blocks in managing system and business non-regression in agile and hybrid organizations is shaped by the following root-causes:

  1. Feeling of independence and limited or no need to inform about planned changes within an organization. The first impression is a very egocentric code of performance and putting all possible accents on the value and wellness of DevOps as a highly independent sub-organization. DevOps perceive agility as a principal (and very often as the only one) objective of change, and any occurrence of system and business regression connected to the change is rather occasional and usually insignificant or even found as part of the usual business code of conduct. This perception might be correct within the operations and also BPM rules, however solely limited to particular and single DevOps sub-organization. As naturally resulted, traditionalists notice hermetic barriers avoiding the controlling of configuration and change management inside DevOps. Feeling of independence also creates a crashing zone that impacts overall communication. This intractable aspect was most often raised by traditionalists and is the subject to the next paragraph.
  2. Poor communication and a highly competitive approach to the realization of changes in a business process among DevOps. While traditionalists are separated from getting a satisfactory awareness of activities and performance inside DevOps, there is another related regularity that isolates a single DevOps team from another by using strong, but natural, communication fire-walls. DevOps teams expound it as a strong factor influencing their competitiveness in relation to other DevOps teams. This comes from an even more general approach that is the result of agility and emphasizes the enhanced need for competition between DevOps. Traditionalists also noticed this rule and there were ongoing suggestions on the modification or even cancellation of any competitive KPIs that really hinder overall cooperation and efficiency. Traditionalists also raised the phenomenon of calamitous impact for functioning processes across the company, including indeed Business Process Management rules and practices.
  3. Use of different approaches and tools to manage the system configuration and regression. This is a key aspect when a business organization uses different project management and change management methods. While a particular DevOps is well aware of the practices, methods, and tools used toward performing an efficient agile change management process, there is a very limited or no exchange of information about changes in configuration among DevOps or other non-DevOps teams. This phenomenon has also been mentioned by other researchers, however, more from a pure business perspective, as also exposed by Mishra et al. (2017). The root cause of this, despite the above stated poor communication, is the persistent use of different approaches and tools for release management. The most aggravating driver of such a position is an effort to collate releases set in sprints to horizontal and periodic release plans in the overall business organization. Usually, such attempts run out, resulting in an even deeper dislike and assertiveness between traditionalists and supporters of agility. Nevertheless, both sides expressed that the use of different tools determines one key failure factor preventing the successful and non-regressive technical and, in consequence, business change. It is quite clear, and a certain fact, to observe that agile supporters do not wish any changes in such an approach making it hermetic and proof from outside inference.

As the substantial root-cause of appearance and subsistence of road blocks for successful and non-regressive change were expressed and commonly shared, the proposed solutions and mitigation drivers are often in opposition between supporters of traditional and agile methods.

Consequently, as per the discussion with representatives of DevOps teams, there is an increasing issue-phenomenon to perceive BPM as a local implementation only, with no need for reference to horizontal use within the entire enterprise organism. A similar notice is presented by Teniente and Weidlich (2018, p. 614).

In reference to literature, it is necessary to underline that agile enthusiasts perceive rather as roadblocks for agile methods such aspects as, for example, security, that was clearly underlined by Kaiser (2018, p. 97), than their impact on the overall consistency of change delivery. They tend rather look for getting the highest level of agility by using new methods, being faster and more efficient, as also noticed by Komai, Nakanishi, and Saidi (2017). Moreover, the cure to eliminate inconsistency is most often postulated to automate the release management process in the sole competence of DevOps, which has been considered also by Kaiser (2018, p. 286), which may increase DevOps results, strengthening further independence, but consequently increasing the risk level of regression occurrence in an overall hybrid organization. A similar approach has been presented in another elaboration where another common and important business aspect as enhanced business communication is recognized as one of the roadblocks of agility (Smite, Moe, & Agerfalk, 2010, p. 311).

RQ2 – the proposed and/or used methods by organizations to limit the system and business non-regression in the conflicting approaches of business operation models as traditional and agile are as following:

  1. Use of unified configuration management tools and information source. This solution, naturally consistent and non-collusive, however, became a bone of contention between supporters of traditional, cascade methods of project management and change management, and those who support agile reality. While traditionalists are opting for one, even central configuration management system and configuration planning, that is also noticed by Pries and Quigley (2009, p. 256), the agile supporters feel handcuffed by CMDB as external to a DevOps imposed tool that may incur their competitiveness and efficiency. Interestingly, agile supporters understand the traditional need to use such tools to keep overall awareness they nevertheless present an individual assertiveness in their particular cases. While targeting and, moreover, achieving the golden mean is extremely difficult, there is a necessity to underline that the use of one configuration management tool seems to be indispensable to keep overall consistency awareness and is one of the key mitigation methods for the risk of system regression and overall risk level within a managed project. It is worthy to consider if such a tool can have dispersed nature and technology that can still keep the sense of independence of a particular DevOps team.
  2. Overall notification on planned technical change, while business change may still remain uncovered out of the sub-org. The agile supporters perceive it as an unnecessary and time-consuming effort that encumbers their change management process and even influences efficient operations. They rather resist introducing such a hampering point to their well-performing processes even if it may significantly decrease the level of regression risk, on which Moran (2014, p. 28) raised the discussion. Nevertheless, agile supporters were keen to continue the discussion on how the planned change could be notified. Some respondents emphasized that the way of notification can be a key point of using or abandoning it, in the course of change management. Traditionalists are convinced that sharing information on system change is an important bridge in a hybrid functioning organization and is open to the method of its propagation. It shapes a very interesting conclusion that is based on the general rule to keep things as simple as possible in operations practices. The correctly shaped information structure, transparent and with short and comprehensive content and then a sharing flow, can be a key success factor in adopting it in hybrid methods of change management.
  3. Planning and realizing cross-organization non-regression activities (non-regression tests) whenever needed with horizontal coordination of a regression avoidance process. Such a proposed solution would display the wide picture of potential risks of non-regression and would be another natural denouement within intractable cooperation between traditionalists and agile supporters. However, this and the last conclusion again elicited polar attitudes. Although agile supporters generally understand such occurrences as horizontal releases, they connect them to regulatory conversions that may impact cross-organizational changes and still focus more on the need for the protection of their independence in operational activities. As such, they do not feel it addressees such subjectively wide initiatives, and the eventual changes necessary for them can still be performed in the agile regime and practices adopted in particular DevOps. This conclusion touches on a new phenomenon that can constitute a substance of hybrid performance – to embrace business horizontal needs in a traditional program that controls changes realized in DevOps using their own methods and tools. This may be really connected to the multi-level health condition of Business Process Management and, consequently, may critically impact it. What is surprisingly valuable is that both sides were keen to accept such a proposition. Moreover, the DevOps teams were open to support additional initiatives as cross-organization non-regression tests. Despite displaying a high awareness and understanding of the potential impacts on BPM, and thus on the governance of an entire business organization, there are extended stipulations that all required steps to be taken using practices and rules of particular DevOps.

Similarly, as in the roadblock section, agile enthusiasts rather perceive the above-proposed methods as more ceremonial, but somewhat valuable, and that require adequate sizing, which was also underlined by Moran (2014, pp. 77-78). There is an all-existing question, on how to efficiently locate the function of BPM across hybrid business organizations. Agile supporters most often raise the same sort of questions, which are more similar to questioning what value is provided by BPM as horizontal governance and how it can be beneficial to a particular and single DevOps team.


The above-stated findings indeed require further analysis, extended communication, and dialogue between traditionalists and agile supporters. As communication seems a very sensitive and gapped area, we truly believe that in particular situations, it requires to be remodeled and based on best practices that follow master models or theories, as stated by Dwivedi et al. (2012, p. 100). It seems critically significant to achieve the right level of mutual awareness as the first step and mutual understanding as to the second step. What is of key importance is the final step to get agreement on planned methods and ways of performance that can be compact, easy in use and, moreover, will not impair the sense of independence for a particular DevOps team, as Kakar (2017) noticed as well.

The dialogue and agreement require a transparent and open form with a clear intention of the aim as well as the use of consequent practices in change management, which is finding the mitigation methods and tools to prevent or decrease the occurrence of system and, thus, business regression in an organization, which was also raised by Galavan, Murray and Markides (2008, p. 119).

The general obstacles on the way of getting value from such a discussion have been stated in the preceding analysis. However, there is an additional point underlined by agile supporters – why consume time and efforts on getting agreement if on the horizon there is a clear aim – to get agile and DevOps oriented for an entire business organization. It brings a clear answer – as long as a business organization consists of more than just one DevOps team, getting horizontal agreement and cooperation is a kind of indispensable factor to keep a consistent and efficient operationalization governed by Business Process Management practices and thus defined business targets.

As presented above, there are numerous differences expressed by both sides, and objections or even open disagreement on the approach to managing the change. Nevertheless, we do hope, that based on open and continuous discussion, more efficient ways and tools will be established that can be accepted by both supporters. This is necessary to achieve the correct conditions for realizing technical change and thus achieving business targets and keeping the organization robust.

To comprehensively support the outcomes of the above-stated considerations, it would be beneficial to continue with the respective research and work in detail with the impacted parties. As such, we would underline the need to undertake exploratory work on the following aspects:

  • evolving BPM toward meeting the challenges of business process performance in a Hybrid organization during transformation to an agile operating model and a Hybrid Organization holding both operating models; such research would target the question of how to efficiently govern business processes in DevOps and outside DevOps, in the same business organization; another question that could be raised is how to handle the transformation process to an agile operating model, effectively manage business processes, and mitigate risks of their impairment;
  • enhancing communication methods, tools and practices between DevOps and the remaining parts of the organization; the exploratory works would target developing communication channels and practices to improve or even create the appropriate communication; it would need to take a leveraged survey approach that could then be supplemented by additional interviews;
  • automation of non-regression activities to simplify and empower mitigating the risk of business and system regression; based on the use of automatic tests and the currently known best practices for using RPA7, it could be valuable to work on refining the guidelines on how to automate and better address methods to prevent regression in a business organization; an extended review of the literature and the efficient organization of dedicated brainstorming sessions with subject matter experts would strengthen such efforts.

All attempts and openness toward getting a better functioning enterprise that efficiently manages its business processes and mitigates the risk of regression will outcome with mid-term and long-term results that strengthen the value of the whole organization.


The overall conclusion leads to the argument that a Hybrid Organization faces far-reaching challenges connected to the unexpected and sudden appearance of system and business regression that inclusively connects to traditional Business Process Management. Among numerous reasons, it is important to refine and group those that are natural regression drivers, mainly for Hybrid Organizations. Concluding the above-reviewed aspects, it emerged that subjective dimensions are the root-cause limbs for regressive occurrences and inaction of processes as such. All hitherto analyzed reasons, additionally attempted by refining mitigation methods, are focused and summarized in Table 8.

The above-stated reasons and mitigation propositions can also be concentrated and propagated as a general solution to keeping an inter-team attitude of open dialogue and persistently seeking improved cooperation. This can work out methods and practices such as the use of unified configuration management processes and tools, keeping communication on planned changes, and the willingness to participate in horizontal initiatives when called for and necessary as a multi-level verification of non-regression.

Such verification is another aspect of good cooperation, which is a ‘must criteria’ for the successful management of change. Usually, it takes the shape of non-regression and multi-platform tests that need enhanced cooperation between different teams. Such a need for the non-regression testing approach was exposed also by Parsons (2014) and seems to be the natural mitigation practice that may help in any doubtful situation.

Table 8. Dimensions of inaction in Change Management causing regression. Mitigation steps

Dimensions of inaction

Root-cause and mitigation

Lack or poor communication

Lack or poor communication between DevOps teams and traditionally running teams and parts of business organizations, highly impact underperformance or inaction of the change management process. This phenomenon is well known in almost all business organizations and, moreover, requires taking constant and persistent efforts to work on improvements and new communication channel solutions. Among many used expedients, it seems indispensable to keep open status communication supported by regular change management inter-departmental meetings. Another, more sensitive solution may be the emergence of human resources scoring against proper communication.

Internal independence

Oversized feelings of internal independence or even extended needs for keeping competitive and exceptional self-picture in the internal business racing landscape may be ruining appropriate change management and maintaining a non-regressive approach for change adoption. It is one of the most difficult factors as from a logical perspective it seems natural for DevOps organization and exceptive to the attempts of wider organizational dependency. This is a general issue for hybrid organizations and a specific trap of keeping dual routines of project and change management. Nevertheless, it seems intransigent to adopt acceptable breakthroughs toward ensuring proper communication and cooperation between single DevOps and the other parts of the business organization. Similarly to the approach that can be used in case of improving communication, it requires regular status meetings and a scoring approach.

Use of different technological stacks

Use of different technological stacks may cause significant impairment to the system and business architecture and processes controlled by BPM as well as finally business targets. This is particularly connected to the configuration management tools that are being used in parallel or supplementing each other, which lead to informational disorder and an increased direct risk of regression. The first and key solution seems to be unification and the use of one or integrated CMDB that can be a single referential point supporting project management and non-regressive approach of implementing a change.

Exertion of manual routines

Enhanced use of manual practices of performing configuration checks and change process. As adapted a long time ago, manual work will not hold up the increasing demands of release management in highly supported IT processes. Automation on change management and non-regression activities would reinforce the resilience of change implementation and mitigation of business and system risk regression.

Getting a mutual understanding and agreement on ways of proceeding can bring additional values and strengthen internal business routines and confidence.

It also supports the overall conclusion of the necessity to enhance the cross-organizational spirit of getting mutual value through open and honest internal cooperation. This creates such ensuing benefits as operational consistency, external competitiveness within industry, and many other business imperatives. These conclusions can also be observed in the group of findings among other researchers (Daniel & Daniel, 2018).


I would like to thank all the people involved in the study. The matters of research and interviews have sometimes been perceived as a trifle sensitive. This was expressed during the open discussion. That is why some of the respondents asked for anonymity. Therefore, the paper does not present the names of people or the names of the business organizations.


Avila, O., & Garces, K. (2017). Change management support to preserve business-information technology alignment. Journal of Computer Information Systems, 57(3), 218-228.

Białek-Jaworska, A., & Gabryelczyk, R. (2016). biotech spin-off business models for the internationalization strategy. Baltic Journal of Management, 11(4), 380-404.

Boehm, B., & Turner, R. (2005). Management challenges to implementing agile processes in traditional development organizations. IEEE Software, 22(5), 30-39.

Costantino, F., Di Gravio, G., & Nonino, F. (2015). Project selection in project portfolio management: An artificial neural network model based on critical success factors. International Journal of Project Management, 33(8), 1744-1754.

Daniel, P. A., & Daniel, C. (2018). Complexity, uncertainty and mental models: From a paradigm of regulation to a paradigm of emergence in project management. International Journal of Project Management, 36(1), 184-197.

Dwivedi, Y. K., Wade, M. R., & Schneberger, S. L. (Eds.). (2012). Information Systems Theory, Explaining and Predicting Our Digital Society (Vol. 2). Berlin/Heidelberg, Germany: Springer Science & Business Media.

Elzinga, D. J., Gulledge, T. R., & Lee, Ch-Y (1999). Business Process Engineering. Advancing the State of the Art. Berlin/Heidelberg, Germany: Springer Science & Business Media.

Galavan, R., Murray, J., & Markides, C. (2008). Strategy, Innovation and Change. Challenges for Management. New York, NY: Oxford University Press.

Hammer, M., & Champy, J. (2001). Reengineering the Corporation. A Manifesto for Business Revolution. New York, NY: HarperCollins Publishers Inc.

Harrison, F., & Lock, D. (2017). Advanced Project Management. A Structured Approach. London, England/New York, NY: Routledge.

Harrison, R. (2011). TOGAF 9 Foundation. Study Guide (2nd Edition). Zaltbommel, The Netherlands: Van Haren Publishing.

Hillson, D. (2009). Managing Risk in Projects. London, England/New York, NY: Routledge.

Kakar, A. K. (2017). Assessing self-organization in agile software development teams. Journal of Computer Information Systems, 57(3), 208-217.

Kaiser, A. K. (2018). Reinventing ITIL in the Age of DevOps. Berkeley, CA: Apress.

Kerzner, H. (2017). Project Management., A Systems Approach to Planning, Scheduling and Controlling. New York, NY: John Wiley and Sons.

Komai, S., Nakanishi H., & Saidi H. (2017). Guidelines for selecting agile development method in system requirements definition. In Proceedings of the 7th IEEE International Conference on Control System, Computing and Engineering (ICCSCE, 2017).

Luftman, J., Tal, B-Z., Dwivedi, R., & Rigoni, E. H. (2010). IT governance: An alignment maturity perspective. International Journal of IT/Business Alignment and Governance, 1(2), 13-25.

McManus, S., Seville, E., Vargo, J., & Brunsdon, D. (2008). Facilitated process for improving organizational resilience. Natural Hazards Review, 9(2), 81-90.

Mihalache, A. (2017). Project management tools for agile teams. Informatica Economică, 21(4), 85-93.

Mishra, A., Garbajosa, J., Wang, X., Bosch, J., & Abrahamson, P. (2017). Future directions in agile research: alignments and divergence between research and practice. Journal of Software: Evolution and Process, 29(6), 1-4.

Moran, A. (2014). Agile Risk Management. Cham, Switzerland: Springer.

Muller, K., & Rumpe, B. (2015). A methodology for impact analysis based on model differencing. In 17. Workshop Software-Reengineering and -Evolution, Vol. 4.

Parsons, D. (2014). Influences on regression testing strategies in agile software development environments. Software Quality Journal, 22(4), 717–739.

Paton, R., & McCalman J. (2008). Change Management. A Guide to Effective Implementation. London, Great Britain: Sage Publications.

Pisano, G. (2006). Profiting from innovation and the intellectual property revolution. Research Policy,35(8), 1122-1130.

Prahalad, C. K. (1998). Managing discontinuities: The emerging challenges. Research-Technology Management, 41(3), 14-22.

Pries, K. H., & Quigley, J. M. (2009). Project Management of Complex and Embedded Systems. Ensuring Product Integrity and Program Quality. Boca Raton, FL: CRC Press.

Resnick, J. T. (2004). Corporate reputation: Managing corporate reputation–applying rigorous measures to a key asset.Journal of Business Strategy,25(6), 30-38.

Rogers, G. P. (2009). The role of maturity models in IT Governance: A Comparison of the major models and their potential benefits to the enterprise. InInformation Technology Governance and Service Management: Frameworks and Adaptations(pp. 254-265). IGI Global.

Sajdak, M. (2015). Compilation of operational and strategic agility for ensuring the highest efficiency of company operations. Economics and Management, 7(2), 20-25.

Simon, K. A. (1994). Towards a theoretical framework for Business Process Reengineering. Retrieved from

Smite, D., Moe, N. B., & Agerfalk, P. J. (Eds.). (2010). Agility Across Time and Space. Implementing Agile Methods in Global Software Projects. Berlin/Heidelberg, Germany: Springer Science & Business Media.

Stumpf, K. (2015). Leading Business Change, A practical Guide to Transforming Your Organization. Boca Raton, FL: CRC Press.

Śledziewska, K., Gabryelczyk, R., & Włoch, R. (2017). The gap in the digital competence: The diagnosis for Poland. Roczniki Kolegium Analiz Ekonomicznych / Szkoła Główna Handlowa, 45, 159-175.

Teniente, E., & Weidlich, M. (Eds.). (2018).Business Process Management Workshops: BPM 2017 International Workshops, Barcelona, Spain, September 10-11, 2017, Revised Papers(Vol. 308). Cham: Springer.

Unhelkar, B. (2013). The Art of Agile Practice. A Composite Approach for Projects and Organizations. Boca Raton, FL: CRC Press.

Wells, H. (2012). How effective are project management methodologies? An explorative evaluation of their benefits in practice. Project Management Journal, 43(6), 43-58.

Weiner, B. J. (2009). A theory of organizational readiness for change. Implementation Science, 4(1), 67. http://dx.doi:10.1186/1748-5908-4-67

Yazici, H. J. (2009). The role of project management maturity and organizational culture in perceived performance. Project Management Journal,40(3), 14-33.

Yin, R. K. (2017). Case Study Research. Design and Methods. London, Great Britain: Sage Publications.


Celem tego artykułu jest zbadanie czynników zachowania spójności procesów biznesowych, silnie wspieranych przez technologie IT, podczas pojawiania się zmian w architekturze technicznej organizacji, która stosuje zarówno tradycyjne, jak i zwinne metody zarządzania zmianami. Postawiono dwa pytania badawcze dotyczące najczęstszych przeszkód w zarządzaniu regresją systemową i biznesową przy użyciu hybrydowych sposobów realizacji zmian oraz odpowiednich metod stosowanych w celu ograniczenia regresji systemowej i biznesowej w konfliktujących się podejściach reprezentowanych przez różne modele operacyjne. W badaniach zastosowano sprofilowaną metodę wielokrotnego studium przypadku w oparciu o dane pierwotne i wtórne pochodzące z dokumentacji projektowej, doświadczeń z testów i uruchomień produkcyjnych systemów, przeprowadzanych zróżnicowanymi metodami zarządzania projektami i zmianami. Ogólne wnioski koncentrują się na tym, że aby zachować kontrolę przy stosowaniu zasad BPM w przekształcaniu organizacji, niezbędna jest otwarta współpraca, która pozwoli osiągać cele biznesowe w ramach organizacji i zachować wrażliwość biznesową przy agnostycznym podejściu do realizacji zmian w myśl stosowanych metodyk. Zalety zgromadzonej wiedzy mogą prowadzić do zarysowania sposobów zabezpieczenia celów biznesowych przed nieoczekiwaną regresją wynikającą z wewnętrznych i niezależnych mechanizmów realizacji zmian organizacyjnych.

Słowa kluczowe: hybrydowa organizacja biznesowa, zmiany biznesowe i techniczne, regresja biznesowa, regresja systemowa

Biographical note

Hubert Bogumił graduated from the Faculty of Economic Sciences, University of Warsaw, in 1996. Since then, he has followed a professional career acting for large global corporations, the majority in the banking sector. Hubert is a Program and Project Manager with long experience in the delivery of IT-related projects. Hubert has participated in numerous initiatives, such as: establishing new banks, transformation of banking organizations, IT implementation projects, optimization of IT processes and decommissioning of banks. Hubert has been actively contributing to the project management and IT process management methods being adopted in organizations that he supported. Hubert is currently following Ph.D. studies at the University of Warsaw, focusing his exploratory work on the methodological aspects of IT change management in the hybrid, cascade, and agile-driven, environments.

2 ITIL – IT Infrastructure Library.

3 Both types of Project Management methodologies as waterfall, e.g. Prince2 or agile, e.g. AgilePM.

4 CMDB – Configuration Management Database.

5 CMS – Configuration Management System.

6 BCM – Business Continuity Management.

7 RPA – Robotics Process Automation.