Engineering Agility Newsletter #5: The case for mono or multi-competence teams

Let's talk about one of the main pain points of the use of Agile practices in hardware environments. At least, one that Marina, me, and many of our peers have been experiencing when trying to find a matching and effective implementation of Agile ways of working that benefit engineering teams, complex systems development, and product quality: the topic of mono or multi-competence teams. 

The matter might have been called differently in your organization (e.g. 'cross-functional teams', 'product teams', 'stream aligned teams', 'system teams', to name a few). But for the sake of easiness-to-read; we use 'mono' and 'multi competence teams'.

Anyone who has been in the trenches of applying Agile practices for the benefit of hardware engineering companies says the same: it is incredibly difficult. Let me elaborate... 

The challenge

24 years after the publication of the Agile Manifesto, and hence more than 24 years of experience in the use of what we call 'Agile' has taught us the effectiveness of small, stable teams who embody all necessary competencies and capabilities to develop products and functionality of value. For software teams that might require a composition of specific coding skills, testing skills, UI/UX skills, database querying skills, and specific contextual expertise such as API handling or certain machine learning algorithms. Obviously, the required skills and backgrounds are highly specific to the product, solution, system, or value each specific team develops and maintains. One would call a team like this to be a 'cross-functional' or 'multi-competence' team. Ask anyone from a hardware company, and they would call this team composition to be a mono-competence team, as it only contains 'software people'. 

Hardware teams might have a completely different composition. For instance, a hardware team can have a collective objective to develop a frame, or a complex module containing high-voltage components, safety shielding, motors and actuators, and control modules. This entails the need for skills and expertise from mechanical engineers (e.g. material use, frame development, precision mechanics, thermal engineering), electrical engineers (e.g. board designers, FPGA engineers, layouters, cabling and shielding), software engineers (e.g. control software, HMI, data handling), and industrialization (e.g. manufacturing engineering, technical authors, manufacturing protocol builders). Each of these engineers has an extensive background (education, experience) within their respective fields. On top of that, each field has a different language, protocols, and constraints to consider, for very good reasons. 

A simple statement such as "Each team needs all engineering competences represented" is too narrow, and simply illustrates the lack of understanding of the complexities involved in the matter. With this blog post & newsletter we hope to bring you into our circle of understanding and hope we can broaden the group of interested people to pick each others' brain. 

The case for mono-competence teams

There are circumstances where mono-competence teams are highly beneficial. Consider the following: 

1. A mono-competence team has a better ability to 'absorb' junior engineers who are not accustomed to competence-specific habits, processes, tools, and techniques. Hence, senior and junior engineers from the same engineering competence allow for more 'learning on the job'. 
2. A mono-competence team is often related to the same line manager who can (more easily) stay in touch w.r.t. competence development, employee wellbeing, and staffing. 
3. A mono-competence team can more easily have a single senior team leader who can act as a Product Owner, Kanban Coordinator, or Backlog manager for the team (trust me, all of these scenarios we've seen). And hence, it is a better 'business case' for reducing the overhead on an engineering team, rather than having a Scrum Master and a Product Owner, or Team Leader and a Team Architect. 
4. A mono-competence team communicates in the same 'language' and follows the same processes which in turn require less alignment and discussions to understand each others' domains.

The case for multi-competence teams

Multi-competence teams (i.e. engineering teams that contain people with different engineering backgrounds) can also be very valuable and effective. Consider the following: 

1. A multi-competence team can own a piece of 'system behavior' or a 'system function' which negates the notion of 'well, but my part worked when I tested it'. A multi-competence team develops and owns multiple components, tweaks system behavior towards the need of the system, and has broad 'debugging' ability. Generally, multi-competence teams have a better ability to adapt to changes compared to a setup in which a request ends up at a mechanical team, an electrical team, and a software team simultaneously. 
2. Teams with a mix of engineering competencies and a stable, stand-alone or self-contained scope are the closest realistic setup that facilitates the so-called 'T-shaping' of people. Collectively planning, working on, and evaluating products, systems, modules, or part of those, allow for learning on the job. As a matter of fact, these teams depend on learning on the job from other engineering competencies to avoid team members to 'waterfall within an iteration/sprint'. 
3. Engineering teams who can surround themselves around the same product, system behavior, or module have the best opportunity to maintain an overview of the products behavior and operation. Teams consisting of solely mechanical engineers building frames will reduce their scope to frames only, and hence build a barrier to the constraints and design decisions of other engineering competences. We have noticed the prevalence of statements such as "we cannot oversee the total project" or "we do not know what we are contributing to" more in mono-competence teams versus multi-competence teams.
4. Multi-competence teams optimize for risk reduction (design, integrate, learn) but might prioritize speed of integration over quality. Mono-competence might optimize for quality but might compromise the overall delivery speed of the system since their parts and components need to be integrated with modules or components of other teams to understand integration issues. While quality, risk reduction, and delivery speed are all important, the 'reduced distance towards identification of integration risks' allows for faster adaption. And hence, as we Agilists know, the shortest route towards inspection and adaption, benefits product design agility.

Sooo... now what?

The truth is not that black and white. Complex product development requires all of the skills and competencies of the involved experts. Hence, organizing in a stable team of stable agile teams, requires us to have a mix of mono-competence teams and multi-competence teams planning, working, integrating, and learning together. The composition is highly dependent on the stable scope of each agile team. In future publications (and in our book... hint-hint!) we will elaborate on approaches to design teams which, together, have the ability to develop quality products efficiently while remaining stable over a long period of time. But, in any case, let us know what you think and what your experiences are... 

As always, thanks for reading. Hope it brought you some thoughts.

Further reads and sources

• Podcast with Milad Maleki, Markus Thut from Hitachi Energy Ltd. on iterative development in semiconductor manufacturing 
• Remaining compliant with industry standards such as ASPICE3.0 by PEDCO while operating according to a SAFe way of working
• Software-defined hardware - a McKinsey & Company article
• Developing a processor using Agile, presented at the IEEE/ACM International Symposium on Microarchitecture 

Footnotes: 

• Header image generated by ChatGPT. The text is old-fashionedly self-written.
• The mentioned companies have not paid for the promotion.