This is the second blog post in the series about the first trembling steps towards our methods, with focus on product development, and in today’s blog post we will start to look into a categorisation of normal focus areas for our set of principles, in order make a better understanding of what kind of principles, that if violated, give organisational problems.
Here are the principles categorised in five different categories with some comments on each category and as stated before, the understanding of the reduction and integration categories are vital:
Respect
Principle: We need to respect our people.
This one is always valid in any context, and violation of it give us bottom line symptoms like; bad quality, bad organisational problem-solving, people sick of stress, wrong product, low flow efficiency, etc. This is what Deming stated as the biggest problem for American industry after World War II or probably earlier, when the management disrespectfully did not listen to their employees and treated them like machines, reducing them in the end to only salary slaves. This disrespect is also a problem nowadays with new methodologies and frameworks, especially those trying to scale agile. The reason that is that the transformation to scaled agile is many times done with a recipe, a One Size Fits All, which means that the recipe cannot be questioned, no matter all the problems seen by the employees already from start. But disrespect can also be seen when agile teams cannot decide their own HOW and instead must do Scrum (and absolutely not Kanban), must do 2 weeks iterations (and absolutely not 3 weeks iterations), must do Flow Efficiency and Cumulative Flow measurements (and not “no measurements”), etc., which actually is not very agile.
I-competence
Principle: We need to have the right I-competence and information to be able to make our system product and its deliverables.
As stated before; to keep track of the I-competence is not only valid in the short-term, but also long-term, and the organisation must keep track of the I-competence in order to be able to stay in business.
Note that the T-competence is normally developed during the work in the teams, but over time some T-competences may be seen as vital long-term for example end to end T-competence, and will then be added to the competence that the organisation need to keep track of. This can explicitly be seen in Lean Product Development at Toyota, which during the years has introduced some new roles and updated old roles, to especially keep track of the end to end flow, like the role Simultaneous Engineer, see this blog post for details.
Speed
Principle: We need to be able to work in parallel (if needed).
Principle: We need to be able to work incrementally (if possible).
If needed, we shall be able to work in parallel and also incremental, if possible. Note that in hardware product development, a platform with modules can be seen as incremental work when a module is updated; cheaper, smaller, more energy efficient, less heat dissipation, less cooling needed, less space needed, less EMC dissipation, less EMC sensitivity, etc.
Reduction (to reduce different complexity to achieve a structure)
Principle: We need to have end to end control** of our activities and their interdependencies, especially them on the critical line, when we are developing our system product and its deliverables, both short-term and long-term and timely updated, as well as on the different levels of our organisation.
Principle: We need to have timely* Integration Events** end to end – (to get just-in-time* feedback).
Reduction of complexity, means that we are structuring and planning our work by trying to break down the problem in smaller parts, but where we always need to think first, so we also have an idea that the parts can be integrated to a more and more cohesive whole. We also clearly need to have control of the Big Picture and the long-term planning of our business.
For parts that we cannot directly see the solution, which can also be the total problem to solve, we need to explore (preferably in parallel, but it is difficult to experiment with an organization’s way of working since it is a whole and only one as well) by doing experiments in order to gain knowledge iteratively so we finally can understand what to do, or in worst case we cannot solve it. To have as fast feedback as possible is key in the Complex domain in the Cynefin™ framework, so that new knowledge can be generated. Remember that the interactions in the Complex domain are more important than the activities, since we are looking for a transdisciplinary solution.
Planning in the ordered domains (Complicated and Obvious) in the Cynefin™ framework is something our ancestors have been able to do since ancient times. The trick in the ordered domains is to have timely Integration events and not to make too small parts when we are talking about product development, i.e., not repetitive work. Too small parts give us too much coordination which is waste, but also too much start-up/closedowns, other Project Administration etc. This also means that we are moving the reality, the Big Picture, longer away from the teams and that we also are losing their problem-solving abilities. We see the same phenomena of small activities both in traditional silo organisations and organisations doing agile, but of totally different reasons.
Remember that there is no whatsoever restriction about how the work is done in order to reach an Integration Event, which means that the teams themselves are responsible for the how, as long as they take care of the what and the when. The team can work in any setup as long as they reach the Integration Event, nothing is right or wrong, as long as we follow our organizational principles. It is when we are going into different team setups, that we are actually start to differ hardware and software or/and the organization implementing the way of working. This will be handled later when an actual method for big software systems and hardware/software hybrids are presented, and will not be handled in this series, which is focusing on domain independence within a Complex context. Hardware teams can work with their longer “sprints” due to their longer lead time and software teams can work the way they like. But, the more we know the longer our “sprints” can be, we can never ever just make the sprints short without reason.
Traditionally, big organisations with KPIs on the silos give us specialisation, which especially today gives small activities, since smaller projects are preferred to reach the market fast.
In Agile way of working on the other hand, the activities are broken down into small pieces in order to try to reduce complexity, as well as trying to get rid of the interdependencies between the teams and/or experts working in parallel in the ordered domains. With no thinking on the wholeness first, the parts are actually aggregated to a whole, and not iteratively integrated to a whole, which is the effect if we have been thinking first. We also risk to miss the long-term planning of the product.
Different root causes give the same symptoms in the ordered domains; too small activities. So, we need to watch out so we do not make too small activities, since that will give us unnecessarily too many interactions when doing non-repetitive work.
Regarding the actual plan, it shall be more detailed short-term and can be rougher long-term. Since parallel work with many involved x-shaped teams generates many interdependencies, these need to be tracked on a daily basis for the coming 2-3 weeks in order to also be proactive when problems with deliveries occur between the teams or when experts are becoming bottle necks due to time slippage.
Organisational structure and architecture (from the reduction)
Principle: We need to have an organizational structure and control and responsibility over the system product’s architecture and its parts.
To keep track of all people in a big organisation we need some sort of structure. Remember though, that the actual work in the organisation do not need to follow this structure, rather the working organisation must be flat.
Also, here we need structure in a form of an architecture to make it easier to keep track of the different parts and sub-parts of the product. And the earlier we understand that the parts and sub-parts fits together, the better, which requires a system skeleton and systems test as soon as possible.
As we can see the reduction of complexity/complicatedness/uncertainty is rather straightforward and it has not changed too much compared to how we traditionally have done, maybe more than that parallel work needs another setup than the waterfall way of working.
Integration (to get a whole again)
Principle: We need to nourish broad competence, when needed in the end-to-end flow, to achieve better flexibility short-term (spanning from the needed T-shape when solving different interdependent activities in product development, to the needed multi-I-shape in production when solving different independent activities).
Principle: We need to nourish as short chains of interactions as possible; within the silos, between the nearby silos and cross-functional over all silos (end to end), as well as at all different levels of the organisation (so the activities with interdependencies easily can be solved).
Principle: We need to have full-time members in our working teams, in an as flat hierarchy as possible, following the numbers 5, 15 and 150, also in the light of Conway’s law.
In this category, we can easily see that scaling will make it easy to violate these principles. Scaling in combination with KPIs per silo, will reduce the possibilities for a smooth integration even more, to more or less only aggregation possibilities between the silos, and even give integration problems within the silos. Scaling and KPIs will hamper the nourishing of full-time team members, T-shape and short chains of interactions, which will give us the engineering metaphor of reduction and aggregation, neither efficient, nor effective for product development, no matter software or hardware. And to that we can also add the flexibility required by today’s market, which results in smaller and shorter projects, which for big organisations will result in even more fragmentised resources.
This was all in today’s blog post, tomorrow we will continue how the principles effect the size of an organisation. It looks like a small organisation always has had A Walk in the Park to be able to fulfil the principles. But when the organisation grows, it will easily come in on the Walk in the Dark track, especially when also considering today’s market. Right?
C u then.
*According to context and the needed flexibility, which means that we need to understand, nourish and be able to do work in every domain of the Cynefin™ framework, and also recognize and promptly respond to context switches, deliberate or accidental.
**in manufacturing we have Aggregation Points, which is a special case of Integration Events taking zero time.