Seeing the system dynamic: component team vs. feature team

This is one article in a series that tries to see system dynamics behind various choices in organizing work, people and time.

Among many choices in organizing people, feature team vs. component team is an important one.

The below CLD (Causal Loop Diagram) illustrates the system dynamic around it.

Organize people - component team and feature team.png

The variable "product scope"

The difference between feature team and component team can be boiled down to the difference in product scope. Read the article "is team in Scrum feature team?" to understand that feature team is a continuum related to the product definition. Thus, I introduce the variable "Product scope" to illustrate the continuum.

  • "Product scope" bigger => more on feature team
  • "Product scope" smaller => more on component team

Driving forces for feature team

1. Speed for value delivery

The related causal links read like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the faster speed
  • the more value delivery

Once all dependencies are within the team, it is always in sync so that the value can be delivered in the same sprint. This is the most important benefit in adopting feature team.

2. Speed for learning

Extending the above causal links creates the R1-loop, which reads like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the faster speed (the faster feedback)
  • the more learning
  • the higher efficiency (with delay)
  • the bigger product scope (expanding feature team)

This is a virtuous cycle leading to feature team in broader product. However, as there is delay between learning and efficiency, the effect may be invisible in the short term.

3. Skill gap for learning

The related R2-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the more learning
  • the higher efficiency (with delay)
  • the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. However, the skill gap also causes less efficiency in the short term, which creates restraining force against feature team. See more details in B1-loop.

4. Self-organization capability

The related R3-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the less external dependency
  • the less coordination complexity
  • the fewer roles for coordination
  • the more capable team becomes in self-organization
  • the bigger product scope (expanding feature team)

This is also a virtuous cycle leading to feature team in broader product. The coordination roles here refer to project managers or feature coordinators responsible for coordinating work across teams.

Restraining forces against feature team

1. Efficiency

The related B1-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the lower efficiency
  • the smaller product scope (shrinking feature team)

Even though the learning triggered by skill gap can lead to higher efficiency in the long term (R2-loop), the challenge in the short term is real. In order to shift dominance to R2-loop, we need to think of ways to reduce efficiency loss and raise learning effectiveness. We shall introduce right amount of skill gap to support learning while not overly losing efficiency. It is necessary to gradually expand the scope of feature team. Meanwhile, we shall focus on how to speed up the learning.

Traditionally, one way to reduce skill gap for efficiency is to consider skill in prioritization. Sometimes, we select low-value items just because they match our skill. However, the value delivery is decided by both the value in those items and how efficient you deliver them.

  • the more consideration on skill match in prioritization
  • the less skill gap
  • the higher efficiency
  • the more value delivery

Skill consideration in prioritization can help value delivery.

  • the more consideration on skill match in prioritization
  • the less value in items
  • the less value delivery

Skill consideration in prioritization can also damage value delivery.

In a way, it is an economic choice, but doing so misses the possibility to remove the constraint.

2. Quality

The related B2-loop reads like this:

  • the bigger product scope (adopting feature team)
  • the bigger skill gap
  • the lower quality
  • the smaller product scope (shrinking feature team)

Another challenge is about quality. When skill gap is too big, the quality will suffer. One argument for component team is that it leads to better quality, as people are more specialized. Whether this holds true deserves further examination, because the narrow focus on component also limits learning, which is essential for good quality.

Lowering efficiency and quality are main concerns in adopting feature team. Therefore, the leverages lie at how to support learning and ensure quality. The following practices would help.

  • Continuous Integration
  • Collective Code Ownership
  • Component Guardian
  • Community of Practices
  • Slack

Consider those while adopting feature team, and learn more details from LeSS website and books.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai