The SOSD method – Virtual delivery structures

As stated earlier in this series, every big organization needs a line hierarchy, no matter context and domain. But, for product development, which is in the Complex domain of the Cynefin framework, the line hierarchy by itself is not enough. This depends on the high probability for suboptimization within the silo-KPIs by the managers on different levels in the line hierarchy, as well as the fact that no one is really responsible for the delivery (every silo makes its respective sub-delivery), which includes also its systems design and test of it. These are the major reasons for the need of a cross-functional virtual delivery structure.

The domain will always decide the shape of the virtual delivery structures, i.e., the team structures, and will be discussed further down, without going into detail. Changes in the domain, the competence profile of the organization, the purpose of the organization among others will also change the different virtual structures within the organization, and this flexibility is very important. In product development, we do not only need virtual delivery structures and delivery responsibility to get rid of the sub-optimization from the silo organization, which is further dissected in this series of blog posts. The virtual delivery structure for an initiative can look in many different ways, depending on the prerequisites, but always need to be properly constructed top-down, in order to fulfil the top-down design of the product, as well as the organizational principles. Top-down means to consider how the components iteratively can be integrated, verified and validated to a cohesive and well-functioning novel whole. This in turn gives that predetermined parts, like value streams, do not give the needed flexibility to make something novel, a new product/system and definitely not a new platform. The reason is that functionality is divided into the predetermined value streams, before the new systems design is considered regarding the requirements, especially the non-functional ones, i.e., before we know what components we need in our systems design. The recognition of that value streams is an inflexible approach, will be painfully visible when the organization needs to do new customer solutions, that requires a completely new systems design, leading to a completely new architecture. But, since the functionality is divided down into the value streams as the first step, there is not even possible to re-evaluate the existing architecture. Due to the value streams thinking, the former positions for top-down thinking, systems design and wholeness have also since long been removed. This makes it even harder to fulfil new customer solutions, since it means that the skill, competence and experience has vanished as well. If there also are managers responsible for the teams within the value stream, this means a non-fruitful mix of the line hierarchy and the virtual delivery structure, making it even harder to fix the problem of this built-in inflexibility.

In product development, we do not only need virtual delivery structures and delivery responsibility in order to get rid of the sub-optimization from the silo organization, which is further dissected in this series of blog posts. Except for sub-optimization, other reasons for having virtual delivery structures, which has not been highlighted here, is the need of decreasing the number of intermediates, in order to be fast, not to lose too much information during transmissions and reduce Project Administration waste. This means that the lower the levels can be within the virtual delivery structure, the better. Of course, not bigger than teams of teams (< 150 persons) that deliver something together is of course the best, which is a very flat structure of only two levels, where the line hierarchy can need four levels or more. This means that no matter the size of an organization, three levels are appropriate; Portfolio level, Wholeness level and Team of teams-level. The Portfolio level is strategical/tactical, the Wholeness level is tactical/operational and the Team of teams-level is operational. This also means a flexible and adaptable solution, that can solve many different kinds of initiatives regarding both size and complexity.

The virtual delivery structure for an initiative can look in many different ways, depending on the prerequisites, but always need to be properly constructed top-down, in order to properly fulfil the organizational principles. Not only to get a proper organizational systems design et al, but also in order to get the total team feeling for the whole initiative. The plan of the whole initiative can consist of deliveries to IEs – Integration Events, where every team is delivering their important piece, to be integrated, verified and validated to the whole on the wholeness level for big initiatives, which is shown in the picture. Note that the term CI – Continuous Integration, is not synonymous with one or many IEs, not even the last IE before release. CI is about adding new tested code to the existing code, to avoid Big Bang Integration (and of course also a big bang for the verification and validation) at the end, but does not automatically include that the total code is verified and validated. This induce that huge problems still can be the case, especially for doing the big system right, see this blog post for a deep-dive.

The bigger system, the more levels, but normally the wholeness level and a team of teams-level should be the absolute maximum for any initiative, to not go over the limits for the people structures mentioned above. The best is that an initiative never is bigger than a team of teams-structure of 150 persons, but which also depends on other things like dependencies between the teams, as well as the size of the teams. The wholeness level has as the name tell us, responsible for the whole, the systems design of the non-functional requirements, that can be security, safety, jurisdiction including GDPR, fault handling, that give us the architecture, and of course systems test of the whole. The virtual delivery structure of any initiative, always start at the wholeness level, which is responsible for delivering the initiatives. The absolutely best is that a team of teams-structure can be responsible for the delivery of an initiative, as a complete system by their own, where they together with support from the wholeness level, which is still overall responsible for the delivery of the system within the total system.

Working close to the virtual delivery structures will also be supporting teams, that due to their context has another team setup, compared to the agile teams within a team of teams-setup for software development. The important part here is not how the teams work, but what they deliver and when. For example, an “in-house network and infrastructural operation” silo mentioned above can have their own virtual structure with many teams that sometimes deliver themselves, but many times together. This silo can then be seen as wholeness level of their own, with their own Kanban board and their own way of working, where every team probably only has a team leader and not a Scrum Master and a Product owner. They can also sometimes have individuals integrated in the team of teams-structures, which totally depends on the need and not prescription. Preferably they have as much similarities as there are need for, which can be morning meetings, retrospectives, etc. The most important is that the manager is not also the team leader, all to avoid micro-managing and sub-optimization, which KPIs on the silos on different levels, always lead to.

To clarify in which context we need virtual structures, we start with an example regarding the line hierarchy in production. For a clear context, like production, every unit, no matter abstraction level, know exactly what to deliver. This means that every unit themself and its manager, can deliver their purpose and over time they can improve its HOW they manufacture the WHAT. The unit shall be seen as a team which can be seen as a kind of virtual structure. With our principle of Respect of People, everybody in the team will grow in their learning by T-shaping within the team. To even further increase Respect of People, the team leader and the manager shall be different persons. The risk for suboptimization on the whole is low, since the WHAT on the whole is already set, they do not compete with other teams to deliver more WHAT, and do not need to interact for a new solution with other teams. The total virtual structure can be seen as one delivery team per group of people, and the result from each team are aggregated to the whole. The reason why this is possible is because the product development already has guaranteed that the parts are coherent and cohesive, when aggregated to the whole. The money needed for the organization, can also easily be retrieved and divided according to the line hierarchy and its units.
Having the manager responsible for also the team that is possible in production, will be counter-productive in product development, due to that there will be KPIs on the managers as well as sub-optimising measurements that will compare teams. We of course also have the increased risk of Respect for people problem when having different opinions within the team, when the manager and team leader are the same person. This risk is mostly due to the complexity in product development that the manager may not have any knowledge about at all.

Many organizations nowadays implementing agile at scale, have problems doing a proper implementation of the virtual structure. This means that they get problems with the deliveries to the customers, where the root causes are that the organizational or the product systems design, or both, are not done in a top-down manner. But instead, the belief is that these problems (symptoms) instead will be solved if the line hierarchy is changed to fit the different agile team structures, or changes of the line hierarchy, the virtual structures or responsibilities of the managers, or in combination. And it does not matter if the sub-optimizing solution is; the manager has the responsibility for one agile team and some other function (architecture, Scrum Master, Product Owner, etc.), or having the responsibility for three agile teams and no other function, etc., which in both cases leads to measurement of a part => comparing teams (indirectly manager) =>gaming (in order to look good) => master suppression techniques as the last station. Sub-optimizing solutions are only sub-optimizing and it can take long time before the new problems are seen. For example, the decrease of specialist competence when not having guilds anymore, can take years to understand. In the case with putting the manager as responsible for much more than 15 persons, we dramatically increase the risk for burn-out as well. This is because we violate another organizational principle and then sadly only give ourselves another built-in root cause in our way of working, instead of removing the ones we already had. The fact is that symptoms are impossible to solve, which leads to a sub-optimization that in this case make us go backwards in our attempts to get rid of the sub-optimization. Unfortunately, this leads to that risk that the organization will make multiple reorganizations of the line hierarchy, since every reorganization does not work on the whole, due to it is only sub-optimising. And this leads to an enormous waste of time and energy, which that the employees get extremely tired on reorganizations. The root causes always need to be solved, where the solution once again will be to introduce a virtual (cross-functional) delivery structure, which means that we need to stop the “agile at scale” reorganizations. Because, together with having one responsible for any initiative and to avoid the suboptimization when having only the line hierarchy, are the two main reasons why projects incorporated with a virtual cross-functional delivery structure, were introduced in the 1950s, see this blog post, for more information about when projects saw their first light.

Worth adding is also that in product development, the line hierarchy not only consists of capabilities for taking care of a predefined WHAT, but it also needs to consist of capabilities for HOW, to be able to make the systems design. As a result, we also must add additional silos taking care of this HOW, not only regarding systems design, but also regarding systems test. This is the top level of the initiative, and of course requires a top-level team that takes care about the wholeness of the initiative. This is especially missing on the top level when agile is scaled in a bottom-up transformation of big organizations, which also implies that if resources for HOW did exist, they will be removed before the organization even understands that they were still needed. The top-level can never be found inside the agile teams, more than in small organizations and small systems, since refactoring can be done gradually. We also need to be aware that the portfolio is another top-level requiring support functions, that never can be part of the teams and will be discussed further down.

When having virtual structures, these structures can be static or dynamic, which need to be considered, where normally hardware organizations have dynamic ones and software organizations tend to more and more go to the static ones, especially for agile software development. And as always there are pros and cons when having static or dynamic virtual structures. Dynamic virtual structures have built-in flexibility in setting up new initiatives, but will generate extra work in the portfolio to keep track of the initiatives and the money, and for management where we need to be vigilant with too much focus on resource allocation, which is sub-optimising per se. This is especially valid for big organizations doing waterfall development with waterfall for small initiatives, where the need of T-shaping is a necessity in order to be able to compete with smaller competitors. The administration waste, originating from having small percent of I-shaped employees participating in many different small projects is devastating for the efficiency and also to some degree for the effectiveness. This is also the reason for the difficulty to compete for big organizations making small projects (small systems), where an inefficiency of more than 50% is not unusual, see this blog post for examples and a deep-dive and into Project Administration waste and the theory behind.

From the purpose, we can also understand the domain of software or hardware, and these different domains, normally gives different virtual delivery structures regarding how the maintenance setup is handled. For hardware organizations, the maintenance is normally a separate organization that the development organization hands over to directly, or after a year or two after the customer release in order to correct the first faults in the hardware. The main reason is to free development resources, for next complex initiative to handle, leaving the only complicated released hardware with documented information to maintenance. With a high level of requirements traceability including baselines, the development can continue with next hardware variant any time, since it is separated from the current hardware release. Also, the customer connections are important, and they are also separate due to that every hardware shipped to the customer is unique, also combined with many other unique hardware at the different customers. For software organizations, we have normally only one software for multiple customers, and with some variants due to the continuation of next release, having development and maintenance in the same virtual structure, is the most suitable. The drawback with this setup is the risk of losing control over the maintenance cost, due that the stakeholders believe that they can choose more development and not listen to the teams. But high maintenance cost has always a tight connection to bad quality. This in combination with a superstition on refactoring from the teams also for big software systems, gives high risk for running maintenance costs. By pushing the problems in front of us, makes us to become too reactive instead of proactive, giving us more and more problems. The root cause to this is most probably a bad or non-existing systems design from start of the initiative.

It can be added that for smaller companies, there is normally not yet a line hierarchy due to the smallness, and the company itself can be considered as one whole virtual cross-functional delivery structure. The employees in a small company will work with many different functions, giving the right I-competence, T-competence and cross-functional broad competence needed for developing the product(s). Not only the organization itself gives less complexity, but the small products(s) also give less complexity. This means that there is a possibility to have less of documented information, less structure and order from start of an initiative. All this together means that more information can be in the head of the employees and that the architecture and design may be emergent, even though a lot of new functions then can dramatically reduce the life span of the product(s).

Note! Since we always need both a line hierarchy and a virtual structure for our way of working in product development, this also mean that we can skip the discussions about “the bad ” silos, or “is the silos good or bad”. But more important is that we can understand that if do not set up these two people structure deliberate, especially the virtual structure that is there for permeability, flexibility and adaptability, the risk is that we will hamper the interactions due to unnecessary boundaries and restrictions. Since our people always want to solve their tasks and deliver, the risk is high for sub-optimizing solutions when these two structures are intertwined, leading to selfish constellations (silos) unfit for purpose, will pop-up. Another risk to mention here, is when we let our teams be more autonomous than they really can be, which indirectly means that we on purpose are making each team to kind of a silo, and since they cannot deliver anything themselves, they can be seen as a silo (if they are deliver a whole, they are not a silo per se in an organizational point of view).

Reducing intermediates
The virtual delivery structure needs to be as flat as possible, in order to reduce intermediates and administrative staff, which means mainly to get rid of mirroring the line hierarchies when the organizations are big. Combined with the need of keeping track of the wholeness of our product/system, we need a wholeness level that is tactical/operational within the virtual delivery structure, keeping track of systems design, architecture, systems test etc. on the whole. Remember also that the work with the systems design and architecture to a great extent is domain independent and therefore very different from the work the teams do, that is almost totally domain dependent. In order to take care of virtual delivery structures of some thousand people, we have a team of teams-level as the only level to add, where of course a team as the wholeness level and only teams below as a virtual delivery structure, will be desirable. This structure is often enough, since it can consist of up to 150 people (Dunbar’s number) and therefore can deliver pretty big products/systems.

Next blog post in this series about the SOSD method, handles the need of a portfolio.

C u soon 🙂


*Prioritization method is needed for whole initiatives, before they are divided in to parts, which in turn gives the work order, where CD3 – Cost of Delay Divided with Duration, is possible.

Leave a Reply