This is the fourth 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 look into scaling up to big companies to see what we more need to think of in order to still fulfil the principles compared to small and medium-size companies.
Big companies
So what happens when the medium-size company grows over 150 persons, Dunbar’s number, the number of people we can recognize and know the name on, and how they relate to all other persons, see this blog post series for the details. Here are what we more need to think about compared to a medium-size company.
Respect for people is now something we need to be vigilant for, so we still listen to our people and not let any KPI on departments or groups, or measurements on smaller parts of the company make us start to indirectly disrespecting our people by listening to the numbers instead of our employees. And as stated before, it is not enough to quell people’s opinions and proposals for improvements to only be within the team. This disrespect will make the system no better and since the system cannot become better, the teams are forced to only do improvements within themselves, which most of the times are ok within production, but never ok within product development where we have interdependence between the teams. And when things do not go as well as expected, more control and measurements are the answer instead of solving the root causes to the problems, where the exhaustive measurements in Agile organisations are good examples. See this deep-digging series about problem-solving, or explicitly this blog post about queue problems caused by ourselves, in organisations doing agile.
For a big company we need to take care of the total business and its direction as well as the long-term planning for the company. Without an administrative structure we cannot have an overview of all competences, what everyone does, salary, career ladders, etc., so it is actually no add-on compared to what has been discussed already regarding the medium-size company.
Since the principles are scalable, the planning of work should not be a problem now either, since we only add another level for the really big projects. But we need to be aware that we always start from the whole problem, which means a top-down approach when we are planning, so we are not falling into the trap of the Engineering metaphor*. Especially, this can easily happen when we already have fixed teams in place, like in organisations doing agile, or even easier if the organisation is rigid like a production line, making us just try to divide the problem into small parts for the teams and then aggregate the team’s output back to a wholeness. By doing so, we have the big risks of:
- ignoring or not understanding the complexity of the problem to solve and
- that we all and especially our teams are losing the Big Picture and
- at the same time, we are throwing away the teams’ excellent problem-solving abilities and
- that our ability to make common platform solutions on higher levels, or the whole company will be strongly reduced, with effects on the long-term business.
A warning here about banks that wants a platform for use over many different banking areas (and sometimes also over insurance areas) and at the same time need to understand the users in the different areas about their need of different applications. This is both a Technology Push problem and a Consumer Pull problem at the same time. If we add on to this a transformation to frameworks for scaled agile, the bank will have severe problems if all the complexity cannot be handled, which will be the case if the brittle solution is to just make smaller parts of the complex problem, i.e., for example splitting the organization into value streams for the old (monolith) architecture.
For new innovations we need a warning here not only regarding the mentioned Engineering metaphor, but also regarding KPIs, control and measurements, which apart from their strong sub-optimising impact, also can create a culture that is disrespecting people; where you are not allowed or do not dare to do faults, or make your voice heard regarding problems. This makes different thinking and experimentation more or less impossible, severely hampering both the organisation’s adaptivity and prerequisites for new innovations.
The actual architecture for more complicated and bigger products requires more work to make and keep updated. Regarding Conway’s law we need to be vigilant since now everybody does not know each other, making it easier to make some re-position of the teams without legitimate reasons, making us not only violating Conway’s law, but also the principle for respect.
Still so far, the principles have not caused too much trouble at scale and apart from the unnecessary queues in an organisation doing agile and the sub-optimising KPIs in the traditional organisations, we need to be vigilant to upcoming requirements on more control and measurement. This is always valid regardless size and kind of organisation and is only a sign that something is wrong in the system, i.e., our set of principles is not followed.
But now we have come to the principles in the Integration category, and here we already have seen some interesting aspects of our scaling, so we need to carefully take care also of the consequences for big organisations.
With a big company, KPIs on the silos will really hamper the work in the initiatives regarding integration possibilities, so our KPIs need as stated before be measured on the next level. This in order to get a natural collaboration on the level below and in the end to achieve system collaboration on the whole.
Full-time resources, broad competence and short chains of interactions now more than ever need to be nourished, to achieve as many full-time resources as possible in the initiatives. This is the Achilles’ heel for big companies having small companies as competitors, since with too many part-time resources, the project administration waste will increase dramatically. This increase of waste can make the big company need 2-3 times more full-time equivalents as small companies, which of course will make the product much more expensive due to low resource efficiency and also late to the market, the latter since too many people digging in the same hole will make Flow Efficiency slow. See this blog post for an elaboration on the tight connection between Resource and Flow Efficiency.
Especially in hardware the Integration Events for the evolution of the prototypes into the full product are very depicting, where we are in the Complicated domain, and our experts can show us, what changes needed to be done in order to make the next prototype. For integration in the Complicated domain, we really talk about Events that take time with unknown, but knowable results. For aggregation on the other hand, we talk about a point in time, since we know already from start that the aggregation will work. See this blog post for a more detailed exploration about Aggregation vs Integration vs False Integration. But, as we understand, Integration Events are also valid for any other domain in a Complex context, so for software we will need it to, which will be clearer when we present our pictures, in the next and final blog post in this series.
This was all in today’s blog post, and tomorrow the summary is presented in the last blog post of this series.
C u then.
*A common worry today is that our organisations are viewed with the eyes of the engineering metaphor. This means that first the problem to be solved, is reduced into smaller parts to be solved and then the result is aggregated together to a whole, see this blog post by Dave Snowden for more details about this problematic thinking. The worry is at least twofold. One is that the reduction goes into too small parts because of wrong reasons a) to try to reduce complexity and b) “less is more”, making too small activities in the ordered domains, that results in both low flow efficiency and bad resource efficiency, which is both inefficient and ineffective, where b) also making us lose the Big Picture. The other is that aggregation is only possible when we know that the parts fit together, for example in production. Aggregation can only be used by production, which means the Obvious domain, and aggregation is a subset of integration. Even though we have done a proper systems design for our product development initiative, we do not know if the parts will fit together at our integration event, which is the reason for using prototypes. If we have not done a systems design in product development, we are actually doing a false integration, and not a proper integration, since we have not even tried to reduce the complexity.