Different context, same resource thinking

Almost a year ago, I wrote about "Seeing the underlying resource thinking". It was in the context of large-scale product development. In my recent training and coaching, I face more holistic product development including not only software, but also hardware, mechanical, supplier chain, etc. It is a different context, but we see the same resource thinking underneath their common practices.

In my view, resource thinking can be illustrated by the below assumptions and practices.

1. People can only work on their speciality, i.e. they cannot learn or learning means inefficiency.
2. Due to point 1, it is common to have partial allocation, in order to fully utilize people's specialty.
3. Due to point 1, and work is dynamic, it is common to have temporary group, assuming that people are interchangeable parts, thus, no cost incurred by moving them around.

Putting these into the context of holistic product development, it adds more challenges than software product development.

• There are more specialities involved. It could even be 20+ functions involved for holistic product development. Many of them only have minor allocation as the need for their speciality is limited.
• Cross-learning is more difficult. Think about it is relatively easier for back-end developer to learn front-end development, while it is more difficult for mechanical engineer to learn software development.
• Temporary group is even more loosely organized, it is often not clear who are in the group.

Scrum provides an alternative approach based on different assumptions than resource thinking.

1. People can learn. The more learning, the better they learn. And the learning helps efficiency.
2. Due to point 1, every team member is fully dedicated. When there is mismatch between work and skill, people cross-learn and expand skills.
3. Due to point 1, and believe that team stability is necessary for team's high performance. Stable team is created and it continuously improves.

Considering the context of holistic product development, it is indeed more challenging to apply Scrum literally. We need to think about the principles and apply the art of the possible here. One possibility could be:

• Identify core specialities necessary for the holistic product development, build a core team around those specialities by having members fully dedicated. Treat the rest as external dependency and support.
• Keep the core team stable, so that they could continuously improve as a team.
• Create cross-learning among core team members, at least enable some members to develop themselves into generalizing specialists. I have indeed seen people who could work across hardware, software and mechanical engineering, even though it is rare. For many, it is possible to expand a bit, but that would already be helpful for the flexibility.

Once you learn to see resource thinking, start to apply different sets of assumptions and principles. With the art of the possible, you will find a way forward in whatever context.