Originating from the purpose, it is important to most of all consider the following for the products that are developed; safety criticality, security level, organization size, product size (a big system is normally backend heavy), life cycle, modular platform or not, sure what to deliver or not and time to market, since they all effect the way of working. Even if every initiative is unique, we can from the purpose and the initiatives we have in the road map, understand what we need to require on our way of working. As we already stated before, if the system is big, it gets too complex for us humans to get it right, which means at least these things; we lose our ability to refactor the code for our system, we lose our ability to understand when tests on the parts and different flows are not any longer representing tests on the whole, we lose our ability to track the bugs to the requirements on higher levels, and we also lose our ability to keep all information about the system and its parts in our heads and present it to colleagues only orally. All put together means that we need documented information and requirements traceability, which in turn means that we need a proper systems design for big systems. If we have safety critical systems, that need security, or require a platform, then we always need structure and order, which means a systems design and requirements traceability also for smaller systems. Safety, security and platform, specifically requires system test specifications for the whole system, the subsystems, and even the sub-subsystems, all which are the results from the systems design(s), which make agile with emergent architecture/design more than inappropriate.
We can also add that big systems also have a tendency to have a long life-cycle, which makes the systems design even more important, so we not end up with a dead product, after some years of adding on new functionality, which always will happen. A dead product is a product that no one wants to touch, because no one knows what will happen we make changes to it; new functionality or bug fixing. The life-cycle must also be considered for small systems and organizations, meaning that agile development with emergent architecture/design can easily become a Walk in the Dark.
A lot about planning is pure common sense, which can be read about in this blog post series about common sense, especially in part 2, 5 and 6. Sometimes it is easy to forget that a lot of planning has already been done in an organization; to know how many people that is needed, their competence, tools, locations, etc. All this information is needed so we can plan the line hierarchy, which existence is easy to take for granted, since the line hierarchy normally always is in place when starting a transformation. The line hierarchy is needed in order to reduce the complexity when we have too many people with different competences, doing different activities to keep track of, and structures are something we humans can easily interpret. The same goes for how we structure the parts of our products in production, the architectures of our product in product development and activities in a plan in any context or domain. This of course is also valid for the virtual delivery structures in product development, which by the way, static or dynamic, never shall be a copy of the line hierarchy, see this blog post, for a deep-dive about what happens when an organization grows from a small to a bigger one.
As we understand, it is important to treat planning as one of the most important activities in any organization, no matter context or domain, in order to be systematic and structured. By reducing the complexity with planning, it will not only be easier to find the best logical order using our people at the best, but also to follow the plan, especially if it is visual to everyone. This is especially valid when the portfolio in a product developing organization, is a multi-initiative portfolio, which normally is the case in big organizations. The overall planning of the initiatives needs to be top-down with start in the portfolio, and the portfolio is also responsible for choosing, prioritizing and coordinating the initiatives. Moreover, the portfolio is strategical/tactical and is responsible for the road map, a rough middle- and long-term plan. Next level, the tactical/operational wholeness level takes care of the architecture, functional and non-functional requirements, the systems design, the systems test as well as the planning and coordination of respective initiatives and also sub-initiatives, if an initiative is very big. The team of team-level is operational, and implements the initiatives, as well as helping with the implementation of the code for the systems designed architectural skeleton and other wholeness level coding, if that capability is not completely available on the wholeness level. Here is a picture, planning – scaling down the WHAT, of how it can look like when we are planning our initiatives, our WHAT to do, where the different levels can be shown, and where further details of the picture is explained further on.
As with all planning, it needs to be done in advance, preparing the next level in any way of working, once again no matter context or domain. It is common sense, that we always need the best logical order of the initiatives (or activities inside the initiatives), since the number of our people is not endless, as well as the ability and competence of each individual or team, is not endless. We will automatically break the latter, if we are only using a short-term planning section for all teams at the same time, and omit the middle- or long-term planning. This because, since it will first of all lead to that we need all possible competence within the team due to the lack of middle- and long-term planning, which in the long-run leads to that our people will be half bad at everything. The risk is also high that also the wholeness level is incorporated within the teams, making us lose also the wholeness level understanding and capabilities as well. It is also a high risk that we lose the common sense that the wholeness level for big systems needs to be planned for first, as well as wholeness work need to some extent be done in advance before the work of the team of teams-level even can start. Because we do not want that to happen, we need to spread out the start of initiatives over time in order to, not overuse parts of the organization, not dilute the competence, or lose the wholeness. This means that this logical order of our initiatives always needs to be implemented using Overlapping Concurrent Sequences, which is used both in production and in product development, see this blog post, for a deep-dive in how and the theory behind. Overlapping Concurrent Sequences is actually the solution to the root cause of starting too many of the same activities at the same time, meaning running out of resources with the right competence, which is actually only bad planning.
For every level, the planning will consist of more and more details, rough in the portfolio and its road map and with more and more details and accuracy in time of delivery, via the wholeness level, down to the teams, which can give the best time estimate of when the work can be finalized. If the initiatives are new big systems or are enhancement of existing big systems, we always need to iteratively make or there is (or should) already be a proper systems design.
Follow-up of the plans are very important in order to have early recognition of problems, that can be due to variability, Murphy’s law, mistakes, inexactness, or problems with the way of working. Follow-up to understand the progress are always important, and is also an important part in order to be able to improve the way of working. And remember that it is always our way of working that we can improve, and it is not about blaming the employees.
We will now, without being too prescriptive, start with what is prerequisites in order to have a proper implementation of the line hierarchy, systems design, virtual delivery structures and the portfolio. This implementation is valid for all product development methods in any domain, and without these prerequisites, the actual product development method has high risk of failure. The top-down thinking is mandatory, since we are dealing with organizational systems design, to reduce the transdisciplinary complicatedness (not complex, since we do not need to find new (disciplinary) science). We will also use common sense and experience from the past way of working solutions, for achieving a fast, awesome and also understandable implementation of the organizational systems design for our new way of working. This is very much the same as needed for any other implementation of a way of working for product development, no matter if it is waterfall or Lean Product development.
As mentioned earlier, when making any way of working easier to understand in any context and domain, we always use structures in order to reduce the complexity. Here it is also important to mention that every structure that involves people, need to follow the organizational principles for humans of 5, 15, 150 etc., see this blog post. The numbers of 5, 15 and 150, give us some hint about some maximum size about just over 2000 persons in a rather flat virtual delivery hierarchy (flat is needed in order to decrease too many and too long chains of interactions making us lose information and trust, and probably also due to the fact that going over 200 persons doing things together, meant dividing into two parts, which also can be part of our DNA, so we can trust that our 150 persons leader, trust other 150 persons leaders), when doing really big delivery initiatives (not recommended). This is the biggest implementation that can be made, since the science is the (positive) constraint, see this blog post for more information and a picture. Regarding line hierarchies, which are like resource pools, the size has really no limits. For repetitive work that is truly aggregating parts, it is also possible that every manager will also act as a team leader and specialist on the process. This means that this virtual delivery structure, delivering aggregated parts repetitively, can be of any size, but where we will have other limitations for example infrastructural aspects, pointing more on other science, then our organizational principles for humans.
Next part of the SOSD method is the blog post about the line hierarchy.
C u soon 🙂