TDSD – Test-Driven Systems Design – portfolio backlog management

The unprioritized backlog is a backlog for all kind of initiatives, small or big ones, in order to fulfil the organizational purpose, both short-term and long-term. Since we always need a top-down thinking when we are making a new product or enhancements to an existing one, the unprioritized backlog is very important to pass for all initiatives. This is due to the fact that any initiative can reveal that proper pre-development may be needed to be able to be successful with the initiative. To by-pass the unprioritized backlog only leads to that the wrong initiatives, or wrong functions within an initiative are developed, which means that this centralized backlog in the portfolio is necessary.

This means we need to understand what balance we need between centralization and decentralization and keep that balance. To focus too hard on decentralization in product development, in worst case make decentralization to a mantra, means that we will sub-optimize the whole. When decentralization is possible, is always context dependent. The more complexity we have, the less it will be possible to decentralize, since we have not yet figured out how the all the parts together will become a united and unified whole. We frankly first need more knowledge about the systems design and systems architecture before we can decentralize. This goes hand in hand with the need of a systems designed architecture in all product development, no matter domain, see the introduction to System Collaboration deductions for the details.

Decentralization goes together with fragmentation, since after the fragmentation has been done, the fragments are said to be able to work autonomous, in a decentralized way. By doing fragmentation, no matter if it is regarding what to do, how to do it or who is going to do it, we are not only losing the overview, but we are also losing the understanding of that we first need to reduce transdisciplinary complexity/complicatedness in order to be able to achieve proper systems designed fragments. The former one, which will be denoted as the term “snuttification”*, means that we divide into too small pieces and by that are losing the overview. Snuttification is something we many times easily can solve with planning, normally also in retrospective. Fragmentation of the latter kind, only leads to chaos, we will therefore refer to as chaotic snuttification, since by ignoring the systems design, we have fully dismissed the ability to make a synthesis leading to a whole. This in fact means that we are only aggregating fragments to a whole, i.e., false integration (to instead denote it continuous integration will not help us), meaning it will not get a united, unified and well-functioning whole.

Big initiatives, like enhancements, new products or new platforms, first need to be analysed, also with the current architecture in focus. This means the involvement of the wholeness team, in order find out how to solve the initiative, and how long time it will take, which will be some rough estimates. This also includes the steps and iterations that are needed to reduce the complexity to a manageable level.

The wholeness team will also consider the possible need of a platform, which can be used by different parts of the organization. To be efficient, platform thinking with modules is an important part in order to be efficient, and to continually keep the structure of the systems designed architecture with proper interfaces and APIs. That different parts of the organization develop about the same functionality without consideration of the wholeness, will rapidly become an architecture that cannot be handled anymore, leading to a dead product no one dares to touch.

The higher complexity, which is common especially when doing new products or new platforms, the more knowledge needs to be gained, which directly means a higher unpredictability in when the initiative can be ready. This will of course have an effect on the actual time needed for the initiative, but it will also have an effect on the lead time considerably if the complexity is high.

Cost is always an important parameter, which of course also will be calculated, especially from how long time an initiative will take, where the actual time and the lead time need to be distinguished.

If the initiative is prioritized, it is put in the prioritized backlog, where the wholeness team later in the process, may continue to develop the needed overall architecture, before the team of teams will continue with the architecture and functionality within the parts.