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 “D3BTOR” team.
Let’s start by explaining what “D3BTOR” actually stands for. First, it is a list of “specialist skills” needed in every successful vertically integrated, cross-functional team: Definition, Design, Development, Build Pipeline, Test, Operational Readiness, and Release Coordination.
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 “product & 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 Agile” methodology as governance framework (and it’s “bigger brother” MSP for the overarching program structure) for all our projects. PRINCE2 Agile provides a lot of things to make sure that there is 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 “product & 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”. We will explore these things in more detail in a later post.