This is the third blog post in the series about the first trembling steps towards Our Methods 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 team up to 15 people that is independent of other teams, where people respect each other in order to get the company going and where 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 will simply sit down next to each other.
There need to be responsibility for the total business and we always need a long-term perspective and direction of the company that someone need to be responsible for, which should not either be a problem for a small company.
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, only 15 persons should not be a problem if the planning is taken care of properly.
The prerequisites for doing innovations is normally not a problem for a small company, rather it is the other way, that they many times exist due to a new innovation.
A small company can be seen as a T-shaped team, or a team with many I-shaped competences which also have acquired broadness, many of them working in parallel. Anyway they definitely, due to their low number of people, need to have both multi-I-shape competence and some broad competence in order to solve their problems.
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 frankly only within the team.
With only one team, 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 they are already full-time members in working teams in only one team, so the hierarchy is already flat, and due to the low number of team members, the magic numbers 15 and 150 are not violated either.
And also important is that the small company can only have one measurement, the one on the total company, on the wholeness, so there is no measures on the parts that can be sub-optimising.
As we can see, a small company or one autonomous team 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 15 persons, the limit for trust and sympathy, but up to Dunbar’s number of 150 people, the number of people we can recognize and know the name on.
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.
When the company grows, we to a higher degree need to consider how we can take care of the total business and its 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 does, 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 in the projects. This since we need to be flexible and able to change the projects easily to meet a flexible and fast market, at the same time as we need responsibility for the I-competence 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. They 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 Agile organisation.
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 projects 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 Agile organisations or bottle necks to Integration & Verification, Configuration Management or Release resources in the traditional organisation 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 making 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 build of the prototypes were setting the time to next Integration Event. For software instead, untimely Integration Events become the major problem for 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. And thanks to Agile thinking, Daily Build and Continuous Everything, software is now on the right track compared to the big failures for software projects in the 1980s and 1990s.
Also here 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, even on portfolio level, or where they at least must be able to put together people from different disciplines to at least have the possibility to generate new transdisciplinary thinking.
The architecture should neither now be a problem and Conway’s law should not be a problem either for an organisation where everybody still know each other, meaning that teams that need to work with each other will simply sit down next to each other.
So far, the principles have not caused too much trouble at scale, more than the unnecessary queues in an Agile organisation and KPIs in the traditional organisations, 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 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 prize 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 project as simple and as fast as possible. This means that in the projects we need all possible flexibility to solve all kinds of activities and interdependencies, many of them unpredicted from start. This in turn means that our interactions needed cannot be hampered by roles and responsibilities within the project, 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 projects within the company, which results in broader competence and even shorter chains of interactions over time. Which in turn will result in even fewer part-time resources in the next project, etc.
Note also that with fewer part-time resources, the project 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 projects. 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 Agile organisations in turn, have not taken the same approach and instead have measurements on their interdependent teams, which means high risk for sub-optimisation.
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.