As time goes by, existing root causes will generate a gigantic waste since the symptoms* and consequences* then continuously will increase, leading to that we will get more and more of everything, and not in a good sense, for example:
- meetings (status, discussions, problems discussions, crisis, etc.)
- meetings (because the problems are never dissolved)
- meetings than the suggested ones in the method or framework
- fiery discussions
- unobjective arguments
- master suppression techniques
- functionality moved to future releases
- (agile) coaches
- change managers
- other people
The list above will generate many rabbit holes (symptoms). If we try to solve the symptoms, we will only get more symptoms, one example is trying to solve slow top-down decisions in a complex context, by decentralising the decision-taking. This will generate a high amount of uncoordinated anti-systemic decisions, which only will sub-optimise on the whole, and generate plenty more new symptoms to the list above.
When an organisation has come this far on the list above, the organisation is definitely risking its own existence, since an internal meltdown and self-destruction is now approaching fast, the sooner the more items that can be ticked off in the list.
It is easy to see that the items in the list together generate inefficiency and extra cost, since a summary of the items points at “less done with more people”. As stated in another blog post about meetings, many organisations have the problem with too many meetings. This means less time for doing the actual work that generates value to the customer, and in worst case the product is not made correctly. Too many meetings are not only an old phenomenon in traditional organisations, but happens also organisations transforming to an agile way of working, especially for agile at scale that if not handled properly, can be a real Walk in the Dark.
Some meetings are of course necessary, but when the calendars of the managers and employees start to get completely full, we need to be vigilant. The risk is high that many of these meetings originate from organisational problems within the organisation. A common (and bad) thing with especially these problems is that they reproduce themselves over time, even if we do not do anything about them. This means that we will get an increasing number of problems, or symptoms and consequences, if we did not dissolve them and the root causes to them in the first place.
The symptoms and consequences normally also have multiple pop-ups, meaning the same symptom and consequence in worst case are in all parts of the organisation. This generates a tremendous meeting waste in the different parts of the organisation, not to mention all waste of time trying to do the impossible, solve symptoms or consequences. And if we try to solve the symptoms directly (impossible), the “solution” will instead generate new symptoms, that will definitely pop-up somewhere or at many parts of the organisation, but we cannot state what, when or where in advance (only a root cause analysis can tell us the needed why). This pop-up effect will add a topping of reactiveness in the organisation.
More symptoms and consequences, will result in more (more meetings than specified in the method or framework**) and longer meetings about; discussing the problems seen, trying to solve the problems, status meetings reporting why there are so many problems and not least, trying to get the status about the coming release, will we make it, and not to forget, crisis meetings when we get nearer to a release, or it did not work as expected.
All the above generates a waste of time, and a waste of time always means that to generate the same result as planned, more people are needed. And with an example from a non-complex context, how many people can dig a hole, there is a limit for how many people we can add. In a complicated and complex context, adding more people when having problems, means we have already passed that limit. That means that even more of the good money will be put on the bad money, and we become even more inefficient and costly.
As we now can understand, and that also is shown in earlier blog posts and above all in this series about problem-solving, the root causes to organisational problems must be dissolved, there is no escape. If we not dissolve them or trying to directly solve the symptoms or consequences, the number of symptoms and consequences will increase over time, generating more and more of bad things. We have started our own death spiral.
Our ignorance to dissolving our organisational root causes, will be especially noticeable when the release drawing closer, the testing starts and the tricky bugs are found, all due to our malfunctioning way of working. In worst case our way of working has focused on built-in quality (testing only the parts of the system) and hence omitted that the total product is a system. This means a high risk also for a lack of a proper system test environment, system data, system test cases and of course system test personnel. This therefore need to be reactively taken care of, which means bad flow and slowness to market, since we have not been taking care of the system verification feedback loop properly.
And more and more testing and more bugs found, means time loss, which in turn means that more and more functionality is moved to future releases. And to understand which functionality that can/must be withdrawn from an already planned release, will of course also waste more time, which means that even more resources are needed.
And since the way of working has not got any better, due to our constant omission of dissolving the root causes, for example ignoring to reduce the complexity from start, we cannot reduce the administrative people as originally planned. This means that personnel like agile coaches, scrum masters, product owners, team leaders, etc., cannot be reduced, which is the normal case in a learning organisation, especially when having agile thinking***. They simply have too much problems to take care of, and with a hypothesis-driven everything thinking, with for example PDCA cycles in the different parts of the organisation, we won’t dissolve the root causes.
Instead, more and more of this administrative hands-on people are directly needed, not to mention the increased indirectly need of managers and other administrative staff. And when a new way of working is malfunctioning and all evidence showing that, are ignored, that means adding more consultants to protect the method or framework. This protection and the already malfunctioning way of working require not only more change managers, but more worrying is that the change managers get a very exposed position. The change managers are under attack from within the transformation to broadcast the way of working faster, and from outside the transformation from people that understand that the new way of working is malfunctioning, making the acceptance very slow or not at all. This exposure will be dig into in another rabbit hole blog post.
A great deal of all this, more and more of everything, is originating from bad planning and a poorly done or totally ignored systems design earlier on, which are the biggest root causes, especially with malfunctioning scaling agile frameworks. Without a proper systems design made on the product or the organisation’s way of working, the risks are very high that the parts are not integrating to a unified whole, i.e. which can be called a false integration. This also means a clear sub-optimisation when we are only trying to solve the symptoms in the parts, due to that a unified whole was not considered from start.
All this more and more of everything can end up with a real crisis for an organisation, in worst case a self-destruction that has been completely self-induced due to ignorance.
This was all for today folks, c u soon again, in another rabbit hole.
*In the introduction blog post for this series, symptoms were referred to as originating from a malfunctioning way of working, and the consequences as originating from our human behaviour trying to compensate for this. Remember that with existing root causes, the symptoms will always increase over time. The consequences on the other hand will not start until someone, within the transformation or external, understands that this way of working is malfunctioning, in combination with weak leadership.
**vigilance, vigilance, vigilance! What is usually stated by consultants of the method or framework, is that if more meetings are needed than specified in the method or framework, the transformation has been made wrong. But, with a root cause analysis method especially designed for organisational problems, it is easy to find out if the consultants’ declarative is correct or not. It can be added that; if the method or framework does not cover problem-solving of itself down to the root causes, which is extremely uncommon, the declarative is most probably false. The real reason for adding more meetings is then instead because the method or framework is actually not working in our context, even though universality is claimed.
***if the recipe is not working and we continue to ignore the root causes, the risk is high that the recipe will be dogmatically followed, especially when transforming to a scaled agile framework****. This will result in that the different roles also will be as exactly specified, which means that the administrative personnel in fact never will be reduced, even when it is possible.
****the ratio between administrative (non-value adding) and value-adding personnel is unfortunately, but normally very high in a scaled agile framework, compared to traditional way of working, which means that we need to be vigilant and challenge also new methods and frameworks.