This series of blog post will handle the implications of the principles in our search for the ultimate way of working.
To make the actually way of working suitable for our organisation’s business, we need to conclude what has and has not been written in stone regarding our set of principles, so we do not draw any false conclusions. This is very important since false conclusions are nasty, and many times not easy to rumble, because they look really true.
We of course also need to further state some other important information about the principles, so they are clearly understood and nothing is omitted when we are making our organisation’s way of working. Important omissions are unfortunately often seen in some of the methods and frameworks that are a significant part of the transformation wave rolling around the world. But when understood, they can be fixed. We will look into this from three different aspects; organisational, alignment and contextual. Let us start with the organisational aspects.
Team size
The team size must only be the number of team members needed, up to the number 15, and same goes for team of teams, up to 150 as the limit (details here). The amount of team members can of course differ from team to team within a team of teams’ setup. If the organisation has very big projects, maybe a constellation of many team of teams are needed, and to reduce the risk, a smaller number than 15 should be used as the maximum number of team members for a higher-level team or the portfolio level team. Scaling is in this way possible in a flexible way, but of course very big setups are always risky, but sometimes necessary, since someone need to take responsibility for the total, the Big Picture, what to do and when.
Of course, experts or other support functions can help the teams at any level when needed, and do not necessarily need to sit full time in the teams. These experts and support functions have Mean queues (details here) to themselves, since many different teams put activities in their queues. So, except normal planning to achieve alignment, we also need to have over capacity to take care about the processing time variability, see this blog post for a deep dive into queues and variability.
The teams’ x-competence
Any team in a team of teams’ setup, can have either I-competence, or T-competence, or anything between. The important thing is that they can deliver their part; aggregated, integrated and tested and ready in time for the next Aggregation Point or Integration Event, i.e. the team is self-contained. See this blog post about Aggregation vs Integration vs False Integration for a further elaboration. That everybody is perfectly multi I-shaped or T-shaped within a team may be good, but often not necessary, and most of all, not realistic, especially not regarding product development.
And of course, if everybody is perfectly T-shaped, meaning having exact the same competence, social loafing [1] needs to be considered. This means that in a team where each individual has got exactly the same competence, but not got a specific planned task in time, social loafing has big risk to increase, due to the possibility to hide in the group.
Interesting to see is that hardware development in projects does not have that problem even though the teams are I-shaped, which indicates that social loafing would be possible with high risk. But, by giving each individual specific planned sub-tasks within the time box, instead of the group together solving the full task without time aspects on the sub-tasks, social loafing has been decreased to very low levels.
Another thing that can be stated is that the team of teams need to have a T-competence covering the different teams’ competence. And this will be the same until the portfolio level team is reached, which in turn need to have T-competence covering the whole organisation. Without this setup, the team of teams or higher, are too loosely coupled, making platform work over the entire organisation impossible and giving very bad prerequisites for innovative work on the whole.
Team location and Conway’s law
We need to consider Conway’s law when we are putting the teams together at a location and how that corresponds to the architecture, so we do not get a crappy systemisation. This can easily happen when having T-shaped product development teams that are doing features all over the architecture in parallel, which can generate an enormous technical debt. And if we move the teams around, we need to be vigilant.
Organisation
In the organisation we always need to respect our people, and if we fail with that, the organisations performance will suffer severely. This principle is the one that Deming refer to as the main problem to America’s quality problems after World war II, that became painfully visible in the 1980s when the quality of Japanese cars increased very fast.
A very important issue nowadays regarding respect, is the scaled agile frameworks introduced in many big companies. In these frameworks, agile coaches on higher levels and management only respect their people, when their people are taking care of the HOW within the team. Not when team members point out problems with the way of working between teams or value streams. This disrespect is exactly what Deming brought up. Deming only pointed out that management was responsible for the system, but he never claimed that the management themselves did know the best about what changes need to be done, rather the opposite.
Our set of principles tell us that regarding the actual work we need to organise the work following the numbers 15 and 150 with full-time resources as much as we can, meaning that project size needs to be maximum 150 people if possible, which also gives a flat hierarchy. A very big project can have a setup of sub-projects of the maximum size of 150 people per sub-project, but the bigger the harder to handle, so it should be avoided.
And when doing the actual work, the set of principle also tell us that broad competence needs to be nourished, not hampered. We need broad competence to be able to flourish inside every part of the organisation when needed, between the parts of the organisation and end to end over the whole organisation. We also need short interactions chains end to end, that neither can be hampered, we to a great deal is effectuated by that the working organisation is flat as stated above.
As stated before, today’s market requires flexibility, and it is not only about that teams can be any x-shape or any number of team members described above, but also on higher levels; team of teams, team of team of teams, etc. This is needed so the organisation can react fast to market changes, and change its working teams in order to change the products and services. All this together give us that the working organisation cannot be static, which in turn gives that it is difficult to solve without a virtual organisation like the traditional line organisation*.
But, apart from the actual work, there are still many administrative tasks that need to be considered as well:
- someone needs to have responsibility for the needed I-competence and T-competence in enough number of people, to secure the organisation’s business in a market in constant change, which includes building domain knowledge and secure that people get the right training. This is valid also in the wider organisation.
- someone needs to take care of the longer-term career development for the people
- taking care of people also needs someone that can contribute with an outside perspective
- someone needs to take care of the long-term performance discussion
- someone still needs to do the administrative work as lay-off, sickness, vacation, salary discussions, etc.
- if the line manager and project manager is the same person, it means that the employee has nowhere to bring up problems regarding the line/project manager
All the above administrative tasks are normally a manager’s work in the traditional line hierarchy and are mostly needed for a company’s long-term survival, which also shows that the traditional virtual line hierarchy actually is a good solution. The lack of a virtual organization, has also been recognised by companies in the Agile Community, but they do not emphasise the lack of flexibility. Rather the administrative tasks above have been recognised, where the solutions without a virtual organisation get awkward and the long-term ones seldom are handled at all.
The solution with a virtual line hierarchy is also acknowledged at Spotify some years ago, where the Chapters are the responsibility for a part-time line manager. Spotify also have Community of Practice, called Guilds, but also for the items above, a Community of Practice is not enough to secure a company’s long-term competence.
In almost every company, there also need to be responsibility for career systems, salary systems, marketing, sales, ordering, production, etc., which shows that some silo organisation structure is needed anyway where the virtual organisation can be added naturally.
One problem in the traditional silo organisations that is often highlighted, especially regarding the big organisations, is that the projects also get the same hierarchy as the line. The projects are mirroring the line organisation, which gives long chains of interactions and many coordinators in the intermediate levels actually not adding any value. But, our principles for working teams regarding nourishing T-shape and short chains of interactions show us our limitations, and that the solution is that the projects need to be a flat hierarchy following the magic numbers of 15 and 150.
The frameworks for scaled agile that today are implemented in many companies sometimes have a virtual organisation, and sometimes not, which depends on the lack of information of pros and cons. This most probably depends on that the framework consultants are not understanding the implications of not having a virtual organisation. Without a virtual organisation, these implementations are a mix of the non-flexible Functional organisation and the Projectized Organisation, where the former led to projects to take care of the cross-functional whole and where the latter has never been recommended as a solution for bigger companies, since it is not taking care of the whole.
The reason for the Projectized Organisation to be problematic in big organisations, is due to the inflexibility since a project is never constant in its need of resources. This means that a big Projectized Organisation is more or less doomed to fail, or at least the fighting of resources will be much worse than in a silo organisation with projects would ever be. But, beware that value streams are the new fashion, trying to cover an E2E initiative, which are exactly the same as projects in projectized organisations, which never become a success due to their rigidity. And to start a project or to start a value stream in product development is not any different, it is a start of an complex initiative for making a product. It is not a value stream in a simple production line, manufacturing the product.
Roles and responsibilities
The roles and responsibilities is another important aspect for a virtual organisation, where we already have discussed the need of long-term competence in a company that is vital for success. But, especially in product development a too high concentration on the roles and responsibilities for the working teams, indirectly means an absurd focus on the activities and not on the essential interactions. This is cumbersome already in the ordered domains with many interdependencies in parallel work, but will make it more or less impossible in the complex domain, where the interactions have the highest focus. In the working organisation the focus must always be on solving the task and not the roles and responsibilities; it is not important who solves a task, which is taken care of in the project, sometimes in a necessary informal way.
But, when only having a static organisation and no virtual, this means that roles and responsibilities automatically are getting a too high focus, with high risk of tasks falling between the chairs, especially the unknown interactions that led to some task that was no one’s responsibility according to the specified roles. This is obviously not only a big problem in the implementation of scaled agile frameworks, when the virtual organisation has been removed, but also when having a virtual organisation, since the emphasise on roles and responsibilities are higher than solving the actual task already in the work processes of the framework.
In tomorrow’s blog post we continue with other conclusions regarding our set of principles, with the alignment aspects. C u then.
*the virtual organisation and the working organisation combined is what is normally called a matrix organisation.
References:
[1] Ringlemann, Max. Link copied 2018-09-14.
https://en.wikibooks.org/wiki/Managing_Groups_and_Teams/Social_Loafing