This is the second blog post in the series about the first trembling steps towards Our Methods and in today’s blog post we will start to look into the categorisation of 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:
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. But, this disrespect is also a problem nowadays with new methodologies, not only when scaling agile where a methodology like SAFe cannot be questioned at the implementation at many companies, but also within the agile teams if they 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.
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.
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 sensivity, etc.
Reduction (to get a structure)
Planning – activity 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. 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 whole problem, we need to explore (preferably in parallel) 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 means 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 agile organisations, 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. 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. This is done instead of taking care of the real problem, understand how to do parallel explorations and do a better planning.
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
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.
As we can see the reduction of complexity/complicatedness/uncertainty is rather straightforward and it has not changed too much more than parallel work needs another setup than the waterfall way of working.
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.