E2E DEBTOR – An approach to managing complexity in large software programs

Large software initiatives are among the most complex constructs to handle in many areas: Project management, architecture, team culture, release coordination, system integration, and many other aspects that lead to constant friction. This article introduces an approach to handle these kinds of challenges, by matching the complexity level of the solution to the complexity level of the problem.

Before we begin, however, I would like to point out that the thoughts and approaches in this article are not new – in fact, they were invented by companies like Spotify, elaborated as part of large-scale agile frameworks (such as SAFe and DAD), and many capable consultants teach variances of these processes all over the world every day.

That being said, each organization has to find its own approach to handling complexity – by selectively using, tailoring, integrating, and constantly evolving their way of delivery digital results. This is our approach: The “E2E DEBTOR” team.

Let’s start by explaining what “DEBTOR” actually stands for. First, it is a list of “specialist skills” needed in every successful vertically integrated, cross-functional team: Design, Engineering (or Development), Build Management, Testing, Operations, and Release Coordination. Second, there is the meaning of the word itself: DEBTOR – “One who owes a debt” – and in our case, that “someone” owes it “end-to-end” (that’s the “E2E” part).

But what does that mean? And how does it work? Before we explain that in greater detail, we take a look at the big picture:


Of course, there are many concepts in this picture that need explanation.

We start at the upper right corner, right where it says “P2”. The angle we are looking at here, going from the upper right side to the lower left side, is called the “project perspective”. Projects are temporary initiatives (meaning, with a defined start and end-date) that deliver a specific outcome or product within defined tolerances. In our context, we are using the “PRINCE2” methodology as governance framework (and it’s “bigger brother” MSP for the overarching program structure) for all our projects. PRINCE2 provides a lot of things to make sure that there is at least a chance to deliver a successful project. Among these things, the most important one is the business justification – without it, there should not be a project. But more about that later.

On the next level of the “project perspective”, going further from the upper right side to the lower left side, we find two examples for something called an “Epic”. Epics are actually well understood and clearly defined in many iterative, incremental, and agile methodologies (see the SAFe explanation), so we will not spend a great deal defining them here. Briefly described, Epics are high-level initiatives, outlining goals to be reached by the project that is responsible for their implementation.

The third level on the “project perspective” is composed of several plus signs (“+”), as well as some triangles (“Δ”). The “+” signs symbol so called “Feature Teams”, while the “Δ” is labeled “Foundation Teams”. In order to understand how these concepts work, consider the following situation:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.