Seven Sins of Agile 1/7: Poor Processes

by Jürgen Hemmer and Dirk Krafzig

You are not alone if you experience shortcomings and inefficiencies of processes in your work environment. For example, because the collaboration between departments is poor, co-workers lack the know-how, vendors are not appropriately managed, different stakeholders have diverging interests, or because of many other reasons. Interestingly, problems like that can persist over a very long time and even inherited from one generation of employees to the next. People tend to ignore poor processes if there is no simple way of fixing problems, and nobody is held responsible for the end-to-end process performance.

Situations like that have a severe, long-term impact on the health, morale, and efficiency of the workforce. Employees suffer from the high workload and unsatisfactory work results. In the perception of the employees, the company is not trying hard enough to solve the problems. They become frustrated and wearily.

Sin #1: Poor processes

Motivated by success stories like Spotify or Google first teams in enterprises start working agile. So, the way a company becomes agile often starts bottom up. The success of these first agile teams is based on agile frameworks like SCRUM, SAFE, or LeSS. These frameworks guaranty a smart start in the agile world and generate quick results, e.g. quality improvements, or better time to market. This success is visible to the top management, and soon business agility is identified as an enabler to becoming more flexible to meet new market requirements. The board members initiate an agile initiative to introduce an agile framework in the whole company. They act in this way with the hope that this initiative will change the way of working more or less in the existing organisational structure.

We see several issues with this approach:

If you are lacking or – even worse – ignoring knowledge about inefficiencies, workarounds, and political disputes, you probably find their agile cousins popping up in your agile organisation.

But even if your processes are in good shape, not every process serves a highly dynamic market and must be changed to an agile approach. Sometimes it is sufficient to review the existing process and launch a new version with improvements to achieve goals like cost reduction, flexibility, or speed. Furthermore, other processes better stay as they are because they are given by customers and regulators, or constraint by law or other standards.

Why is it so difficult to fix process problems?

What makes process improvements often so tricky is their impact on multiple stakeholders. A change that might satisfy one stakeholder upsets another. Changes may also have personal consequences, i.e. some individuals can lose power, control, or reputation.

In agile initiatives, there is another problem. The percipience of process management is very formal, often impeding creativity and pragmatic solutions. So, processes are not the priority when you start an initiative to introduce business agility. In addition, some agile coaches find it disturbing and cumbersome analysing the process landscape and their ugly details. They feel that it is their job to overcome the limitations of old-fashioned processes and therefore tend to avoid process analysis.

The blind spot of the agile textbook

The agile manifest describes properties of agility, gives orientation on what behaviour has a higher priority and which one a lower. But it does not explain how the agile way of working looks like in a day-to-day business. To some extent, agile frameworks like SCRUM, SAFE, LeSS, or others fill this gap. These frameworks describe the agile way of working for a team or enterprise and provide useful definitions of roles and responsibilities. For example, SCRUM is very lightweight – it focusses on how one team should work in an agile manner. SAFE is made for the enterprise level. It delivers an implementation roadmap and gives some abstract recommendations about the target picture of an agile enterprise.

But no framework defines critical preconditions or even support from other disciplines if the preconditions are not met. So, every enterprise which is aiming at becoming agile must individually identify what preconditions must be fulfilled before starting.

And this is a critical blind spot of existing frameworks.

Recommendations

We recommend defining a work package that analyses the process landscape and answers the following questions before or at the start of an agile initiative:

• Is there comprehensive process documentation, and does it match reality?
• Are there processes that are given by a third party, e.g. customer, partner, or regulator?
• What is the volatility of the processes?
• What are the external dependencies – e.g. interfaces to other organisations?
• Are there known shortcomings in these processes?
• Are there disciplines that must define the margin for an agile team that should be responsible for the considered process?

We recommend addressing potential issues right away. Otherwise, people will blame agile for poor processes.

Summary

Companies need to be agile because of rapidly changing market conditions. So most probably their processes change often and fast. Therefore, fixing a concrete issue of the company`s processes is desirable, but it does not increase the agility in the long run. The better way is to define what “properties and principles” the new agile company should fulfil. For example, when business units are weak in describing requirements accurately, one might want to formulate the principle that each significant step in a company process needs to have an agile team that is responsible for it. These properties and principles give guidance to every team member.

Another significant point in the process landscape is the block of governance processes. Agile teams should, and are strongly motivated to, work independently and take responsibility for their decisions. The question is whether or not an agile organisation needs governance processes. Some agile coaches say no. But is that really an option? Is an agile team able to terminate a contract with an important customer or their own mother company? Can an agile team ignore compliance requirements? Surely not! The need for governance in an agile organisation is as crucial as in organisations today. Cross-cutting teams like legal, compliance, enterprise architecture, and others have the responsibility to give agile teams a framework of guidelines and principles, consult them in all phases, and govern them if a team tries to deviate rules, guidelines, or principles.

About the "Seven Sins of Agile" series

Dirk Krafzig and Christoph Tonk initiated the "Seven Sins of Agile" article series #AgileSins in order to draw attention to the widespread misunderstandings in the implementation of agile practices at the company level, to recommend possible solutions, and start a discussion on this topic.

An overview of the entire series can be found here: Seven Sins of Agile

About the authors

Jürgen Hemmer is experienced as a requirements engineer and SCRUM Master in several project teams over different industries. He consults in Enterprise Architecture Management and supports project execution with a focus on business topics.

Dirk Krafzig took the role of the project lead, chief architect, and product owner in many projects. His passion is Enterprise Architecture Management, and he is a well-known author of "Enterprise SOA" or the "Digital Cookbook Series" ("Modelling for Digital", "Managing for Digital" and "Digital in Action").

SOAPARK is a consulting firm with outstanding competence in Service-Oriented Architecture, digital transformation, Enterprise Architecture and IT industrialisation. SOAPARK is specialised in accompanying critical change processes in enterprises – in particular, if strategy implementation and governance, business processes and IT support are relevant.