This is the third 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, if an organisation’s size makes any difference when trying to fulfil the principles. Let us start with the small company.
The small company
When we think of a small company it can be seen as one and only one autonomous entity with only a few small teams, with maybe not more than ten people in every team. These people really respect each other in order to get the company going, since fail really means fail. Let us go through the other principles and see which of the principles that can be difficult to follow.
The organisational structure is not a problem, neither the architecture that can be handled and Conway’s law should be a problem at all, team members that need to work with each other, and with the other teams, will simply sit down almost next to each other.
There need to be responsibility for the total business and we always need a long-term perspective and strategic direction of the company that someone need to be responsible for. This should not either be a problem for a small company, and an engaged leader is needed more than a manager.
Planning (including timely Integration Events) can be a weak spot for a small company, since many of them lack processes and/or description of them, many times with the thinking “it takes the time it takes” to finish the task. But, with a few teams this is manageable, even though many information is in the people’s heads, if the planning is taken care of to some extent.
The prerequisites for doing innovations are normally not a problem for a small company, rather it is the other way, that they many times exist due to a new innovation that they need to implement.
A small company with a few teams can have teams that are T-shaped, for example agile software development teams, or the teams can be I-shaped as hardware development teams normally is. Anyway, they definitely, due to their low number of people, need to have both multi-I-shape competence and some transdisciplinary broad competence, in order to solve their problems on the wholeness as well.
There are frankly no other people to get help from and in order for its survival the team members will work close together to solve the problem and, in this way, they are “forced” to get all the competences needed. The necessary I- and T-shaping will therefore happen normally in the whole end to end flow, since the flow is only within the teams.
With a few teams, short chains of interactions will not be a problem either and if incremental work is needed it can also be understood, learnt and solved.
In the small company there is only one problem to solve, a product or a service, so the team members are already full-time members in the teams, even though some of them must have knowledge and T-competence of the wholeness. This means that hierarchy is flat, and due to the low number of team members, the magic numbers 15 and 150 are not violated either.
Also important is that the small company can only have one measurement, the one on the total company, on the wholeness, so there are no sub-optimising measures on the parts.
As we can see, a small company or a few teams does not have any problems to fulfil the principles and it is neither hindered by sub-optimising KPIs or measurements.
The company grows to medium-size
So, what happens when the small company grows over a few small teams, and up to Dunbar’s number of 150 people, 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 for the needed human science.
Respect for people should not be any problem when increasing the company size up to 150 people, but we need to be aware and 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 their flagged problems.
When our company grows, we to a higher degree need to consider how we can take care of the total business and its strategic direction as well as the long-term planning for the company, since it is no longer easy to get an overview of all competences, what everyone is doing, salary, career ladders, etc., so somehow, we need to structure our organisation. But, at the same time as we need structure, we still need to have the same flexibility as before. This means that regarding the organisational structure as stated before in the Implication series, we need to separate the line hierarchy from the actual work. This since we need to be flexible and able to change the work easily to meet a flexible and fast market as well as solving our activities that requires transdisciplinary competence and knowledge “between” the manager’s area of responsibility. This at the same time as we need responsibility for the I-competence, number of resources and other administrative parts regarding our working employees. The Chapters at Spotify is one way to do it, compared to the traditional line hierarchy, with Chapter managers working 50% with the administration and 50% in other teams then their own employees. Spotify also have Guilds (CoPs, Community of Practices), where people can be part of any Guild to learn from each other. But, important to understand is that for the CoPs there is no one responsible for the total I-competence (or T-competence) of the company, that must lay elsewhere, like in a traditional line hierarchy or as in Spotify within the Chapters.
Remember also that most companies need to have sales, ordering, marketing, production etc., so a line hierarchy is not an awkward solution even when transforming to an organisation doing agile.
At this company size we must have and continuously update a way of working description on a high level (not to detailed), so we have a unified way of working.
Planning of the work in the initiatives should not be a problem either, especially when having a documented way of working. But still a proper planning needs to be done, where queues of planned activities at the teams’ Kanban boards in organisations doing agile or bottle necks to Integration & Verification, Configuration Management or Release resources that is centralized by the silo organisation, even though projects are used, cannot be accepted. But, when working in parallel with teams in any x-shape, there will always be many interdependencies, where many of them cannot be planned in advance. To solve them we need interactions between the teams and/or experts, stakeholders etc., meaning there cannot be any rigid way of working since that will make the chains of interactions too long, or in worst case due to a bad system, take too long time to handle.
With many teams working together, they can work sequential, parallel or a mix which depends on the context. The same goes for the planned Integration Events that need to be timely to get feedback when needed from the solution or from the customer about the product or service, also depending on the context.
Too infrequent Integration Events sometimes were a problem also for hardware organisations in the ordered domains, but mostly the iteratively building of prototypes automatically induces the coming Integration Events. For software instead, untimely Integration Events become the major problem for traditional software organisations, where the Integration Events could be more often due to no lead times. Unfortunately, they seldom were, which made the greater degree of freedom when coding, to give too many bugs, due to unnecessarily long feedback loops. Even with shorter time to next Integration Event, we still need to have frequent follow-ups. But, thanks to Agile and Lean thinking, Daily Build and Continuous Everything, software is now for smaller organisations on the right track, compared to the big failures for software projects in the 1980s and 1990s.
Also, in a medium-sized company, the complexity should be possible to handle, when everyone knows each other, as well as innovations may still be important for success.
Note that we have complexity on different levels in the company, which means that each level need to be able to experiment in order to gain knowledge. This also goes for the level where they must be able to put together people from different disciplines, to at least have the possibility to reduce different kinds of complexity.
The architecture should neither now be a problem and Conway’s law should not be a problem either for an organisation where everybody still knows each other, meaning that teams that need to work with each other will simply sit close to each other, making asking easy.
So far, the principles have not caused too much trouble at scale to a medium-sized organization, more than the unnecessary queues in an organisation doing agile and KPIs in the traditional silo organisations with projects, which easily can be taken care of by some better planning.
But now we have come to the principles in the Integration category, and here we have some interesting aspects of our scaling.
Even though the company size is only up to 150 people, we now need to be vigilant since we are keeping the administrative line hierarchy, but for good reasons. Although there probably are no KPIs on the silos yet, we need to start to make the line managers realise the importance of nourishing full-time resources, broad competence and short chains of interactions. The reason is, as said before, that we do not want to end up with only aggregation, when short chains of interactions are hampered, which is a result of specialisation when the managers to every price, want to keep their area of responsibility also in the working teams. And this is an important distinction; we need the line hierarchy for long-term success, where of course the needed competence is important, but in the working teams we need to solve the initiative as simple and as fast as possible. This means that in the initiatives we need all possible flexibility to solve all kinds of activities and interdependencies, many of them unpredicted from start. This in turn means that the interactions needed, cannot be hampered by roles and responsibilities within the initiative, since then simply too many unsolved tasks will fall between the chairs.
Also, the lack of possibility to solve unplanned interdependencies (kind of small Integration Events) between the teams and/or experts when working in parallel, becomes apparent when the integrating principles are hampered and is valid for both hardware and software and no matter x-shape of the teams.
If full-time resources, broad competence and short chains of interactions are nourished, there will be few part-time resources in the initiatives within the company, which results in broader competence and even shorter chains of interactions over time. This will in turn result in even fewer part-time resources in the next initiative, etc.
Note also that with fewer part-time resources, the virtual structure can and should be flatter than the line hierarchy, which also means fewer intermediate coordinators and leaders, i.e., short chains of interactions.
Warning! There is an extremely big difference between scaling a small company or when scaling in a bigger organisation already having autonomous teams. On one side we have the small company that is scaling-up (become bigger by employing people) and still be one company, while on the other hand in the big organisation there will be many autonomous teams that will be put together to combine a wholeness, which means scale-out. The difference between scale-up and scale-out is that when scaling-up, the team members have learnt that they are interdependent to each other since they always have been solving their problem together, but where each autonomous team in scale-out have learnt how to be independent and efficient by themselves. Therefore scale-out easily leads to sub-optimisation, by not understanding the wholeness, the Big Picture.
Remember also that even when making a production line, we always start from the wholeness in order to understand the processes needed and we never start with the processes we have to make the wholeness.
A measurement on the total company should be kept and there should be no measurement on the teams, instead lowest level should be on the initiative, the virtual structure. Measure-up, that has been proposed by Mary Poppendieck, takes care of the problem with sub-optimisation in the line organisation, since every level within the company is measured on (and is therefore connected to) the level above. This means that you need to make your superior manager successful in order to be successful yourself, which can only be achieved trans-silo with your colleague managers on the same level.
Traditionally, measurements regarding projects have normally been done only on the whole project and never on team level within the project, and therefore sub-optimisation of the wholeness is avoided. Of course, regular follow-ups are done on all levels and within all teams, to be able to follow the critical line and achieve the project milestones together.
A Toyota plant is only measured on the whole plant, never on the processes within the plant’s production line, even though they are not interdependent to each other, only dependent, which means low risk for sub-optimisation. Interesting to see is that organisations doing agile, have not taken the same approach and instead have measurements on their interdependent teams, which means high risk for sub-optimisation. Measuring on lower levels than the whole initiative, like team level in agile development, is therefore treacherous, and we need to be vigilant that the figures are not abused by people outside the teams. A measure for a team is only for the team itself, never for outside people.
A role of thumb for work in progress is:
We must always follow up progress, but we should not set measures on interdependent parts, only on the whole problem we started with.
This was all for this blog post today, tomorrow we will scale up to the big organisations, and see what problems that we encounter.
C u then.