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.

Read more



ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai