Scrum is unsuitable for large, complex and for infrastructure projects. There are better approaches to safely implement such projects with standard tools.

Theses

• Unsuitability of Scrum for large and for infrastructure projects.
• Admission conditions and infrastructure requirements as non-functional requirements
• FDD and DA as alternatives
• Tools for the management of complex projects

Backlog Secrets & bad projects

The resounding success of Scrum is not least explained by the easy-to-use process model, which enables efficient and coordinated action through clarity and the establishment of a common focus, and timely resource and goal management through the time boxes.

However, for very large projects and projects in highly regulated contexts, as well as for infrastructure projects, the procedure quickly reaches its limits.

Such projects are referred to here as wicked projects in reference to the term wicked problems (https://en.wikipedia.org/wiki/Wicked_problem).

In this paper, I explore causes of problems and show proven alternatives for project management and how these can be implemented operationally.

A starting point is the concept of the “backlog” and its use in the Scrum context.

The Scrum Backlog as Product Backlog

Projects and technologies aim at the optimal orchestration of resources and methods to achieve goals. A key tool Scrum provides for this is mixed functional teams, timely communication and the so-called “Backlog”.

According to the Scrum Guide, the Scrum Backlog is a “product backlog” that lists all components of the desired end product according to their value to the customer. These are packaged in stages into individual Sprint Backlogs and added in iterations to the continuously evolving work item.

So, contrary to the somewhat misleading name - backlog, a Scrum product backlog is a modular goal definition, a set of requirements that defines the design of the product.

A Scrum backlog also contains, contrary to the usual deposit in typical requirements management systems such as Jira and Confluence, per se no tasks. Rather, the tasks are to be derived from the requirements by the mixed-functional team. A Scrum team should be able to act autonomously and decide for itself how it wants to develop the desired product. This works excellently when the product has relative autonomy and can be developed on its own. In particular, user experience and ergonomics can be optimally developed in this way.

The high efficiency, the target and product focus that Scrum brings about in this way is, however, bought by the exclusion of framework conditions. If the product is part of a larger infrastructure or must meet certain external requirements with regard to security, robustness or durability, the product developed in this way will not be able to reach the necessary market maturity, or only with difficulty.

Such framework conditions generally include information security and data protection, in regulated industries such as finance, medicine or mechanical engineering industry-specific technical standards, up to very strict regulations for critical infrastructures (CRITIS).

Regulatory as non-functional requirements / infrastructure prerequisites.

At first glance, non-functional requirements do not appear to add value. However, if they are necessary, for example, to obtain approval for a medical device or to be able to use a device in a larger infrastructure in the first place, they are match-decisive and, without their implementation, only money is burned (“sunk costs”).

The sooner they are considered as non-functional requirements, the more value can be added.

Such requirements are generally stable over time and are not directly dependent on potentially volatile customer requirements. They can therefore be recorded in concrete terms right at the start and prepared for the project.

This usually requires relevant expert knowledge (for information architecture, information security, data protection, industry-specific standards, etc.), whereby the expert does not have to remain a fixed member of the team for the entire duration of the project, but can follow up on the topic on call or at predefined intervals.

Anchoring in the project

Limitations of Scrum

Scrum is not the appropriate method to set up a project like this for several reasons:

1. non-functional regulatory requirements are too complex and therefore cannot be included, observed and implemented in each individual sprint. This must be done in advance.
2. it does not make sense to fully and continuously integrate the necessary subject matter experts into the mixed-functional teams envisaged by Scrum. It is sufficient if they support at the beginning and afterwards selectively.

Alternative approaches for the implementation of large projects and projects in regulated contexts

Feature Driven Development

Feature Driven Development (FDD) was developed in the early 2000s by Jeff de Luca. It is very suitable for large software projects. It provides for the definition of component-related features under the leadership of a software architect at the beginning of a project, then organizing them into feature sets and finally implementing the individual features.

FDD thus combines a chordal, step-by-step procedure, which critics see as a waterfall approach, with agile elements. This ensures both cross-project coherence and goal-oriented implementation and testability.

FDD is very well suited for very large projects and for projects that have an infrastructure reference. FDD can also be easily used in the context of DA, which we will look at in more detail next.

Disciplined Agile

Disciplined Agile (DA, originally Disciplined Agile Delivery) was developed by two IBM employees, Scott Ambler and Mark Lines.

DA provides for the search for and definition of the appropriate framework for the project context at the start of the project. For this purpose, subject matter experts and/or solution experts can also be consulted. The framework conditions to be defined include both internal company expectations, regulatory framework conditions, as well as specifications on the part of a predefined infrastructure and the preferred working method of the team.

This way of working is referred to as the “Way of Work” (WoW), which each DA team can adopt. In this way, DA allows the well-known methods Scrum, Kanban, Waterfall, etc. to be embedded, making DA both a concrete project management method and a meta-management method that is more suitable for scaling (like Safe or Less) agile ways of working in large projects and in corporations than any other model known so far, due to its inherent scalability and flexible combinability.

At the end of a project, DA also provides for implementation and deployment in everyday life. Only the anchoring in the real (corporate) world ensures the sustainable value creation of a project.

Undercomplexity of Scrum

According to Ashby’s law, a complex problem cannot be solved with an undercomplex approach. The problem-solving capability must be greater than the problem complexity, or the problem will remain unsolved.

If the problem complexity is too large to be solved by a single team within a limited period of time due to the size of the project, large regulatory or technical constraints, Scrum proves to be too undercomplex and thus unsuitable to solve the problem.

Scrum itself implies this limitation because it leaves it to the team, or rather leaves the team to itself, when it comes to deriving the type of solution and the tasks required for it from the product-related requirements in the “product backlog”. Scrum thus increases the focus of attention of the specific team for a certain period of time without (exceptionally) granting it the preparatory consideration of important framework conditions, the addition of specific competencies or the time span for a sustainable solution finding that goes beyond a sprint.

Scrum mixes the product target definition and the product-related requirements in the product backlog and leaves the elaboration of meaningful implementation measures to the team during the sprints.

Non-product-related and non-functional requirements are not taken into account by Scrum, nor is the fact that the earlier they are taken into account in the course of the project, the more value can be created.

There are already enough orphaned and not connectable pilot projects or proof of concepts.

Recommendation for concrete implementation

In the case of more complex projects, the problem-solving competence of a single Scrum team, which according to the Scrum Guide should not contain more than nine team members, and which should independently work out the requirements and the measures for their fulfillment (tasks) in limited time windows from the goal definition, is no longer sufficient.

In these cases, a more powerful problem-solving methodology is needed. This will need to carefully distinguish between requirement types and granulation (e.g., business vs. functional vs. technical vs. non-functional), related use cases and test criteria, and the tasks to safely achieve the goals.

While sophisticated and highly specialized requirements management systems used to be in use (such as Doors or MKS), generic tools such as Jira or Confluence are predominant today. These, too, can be set up in such a way that a sustainable and efficient workflow can be established that can handle more complexity than a simple Scrum project. In addition to a deep knowledge of the tools, appropriate plug-ins are also helpful for this.