Seeing the system dynamic: feature team vs. feature group

Feature group is a temporary group of individuals to deliver specific feature. It is very common in traditional matrix organization, and also called feature project. Meanwhile, feature team is a stable team who takes shared responsibility to deliver feature after feature. The below table from feature team primer summarizes the main differences between them.

feature team

feature group/project

stable team that stays together for years and works on many features

temporary group of people created for one feature or project

shared team responsibility for all the work

individual responsibility for 'their' part based on specialization

self-managing team

controlled by a project manager

results in a simple single-line organization (no matrix!)

results in a matrix organization with resource pools

team members are dedicated - 100% allocated - to the team

members are part-time on many projects because of specialization

Why do organizations make different choices? The below CLD illustrates the system dynamic around it.

Organize people - feature team vs feature group.png

Individual efficiency

The main motivation behind looking for the "right" individual to do the work is to create the skill match for individual efficiency. This is reflected by B1-loop, which reads like this:

  • the lower individual efficiency
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the higher individual efficiency

However, it creates unintended consequences at individual level shown as R1-loop and R2-loop. Together with B1-loop, it forms typical "fixes that backfire" system archetype.

R1-loop shows the problem with multi-tasking, which reads like this:

  • the lower efficiency
  • the more consideration of individual skill in dividing work
  • the more multi-tasking
  • the lower efficiency

Because seeking for perfect work and skill match creates the situation where people are multi-tasking for different feature groups, while multi-tasking is a source of low efficiency, the fix backfires.

R2-loop shows the problem with reduced learning, which reads like this:

  • the lower efficiency
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the less learning
  • the lower efficiency (with delay)

As people always work on familiar tasks, the learning is reduced, while learning helps increase the efficiency in the long term, the fix backfires.

Team performance

Traditional thinking assumes that team performance is solely or at least mainly decided by individual efficiency, which forms B2-loop by extending B1-loop. It reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the higher individual efficiency
  • the better team performance

Again we see "fixes that backfire" system archetype, this time at team level. It is formed by B2-loop and R3/R4-loop.

R3-loop shows the problem with low interdependency, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the smaller skill gap
  • the less need for help
  • the weaker collaboration
  • the worse team performance

The task interdependency enables team collaboration. Once team members perceive little need to help each other, the motivation to collaborate is low. While the team performance is affected much by the level of collaboration, think about the time of integration. The fix backfires.

R4-loop shows the problem with temporary group, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less stable team
  • the weaker collaboration
  • the worse team performance

Because the work is dynamic, matching work with individual skill inevitably makes team unstable. While it takes time and effort to get a team into performing stage, any member change will bring the team back to storming stage (referring to Bruce Tuckman's model). The fix backfires.

Moreover, we see another "fixes that backfire" system archetype at team level, which is formed by B3-loop and R5-loop.

In traditional thinking, shared responsibility means no responsibility. Thus, it is believed that defining clear individual responsibility helps team performance, which is shown as B3-loop. It reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less shared responsibility
  • the better team performance

R5-loop shows the problem with lacking common goal, which reads like this:

  • the worse team performance
  • the more consideration of individual skill in dividing work
  • the less shared responsibility
  • the less aligned goal for different members
  • the worse team performance

Members in the feature group reporting to different managers make it even more difficult in having real common goal, while it is essential for team performance. The fix backfires.

Leverage

There is full of resource thinking in the above system dynamics, such as ignoring learning capability, aiming for efficiency and utilization, moving people around, etc. The old mental model plays the essential role in keeping the status quo. Seeing it is a powerful leverage in itself.

Considering to break vicious R-loop and/or introduce B-loop to balance, the below list offers some ideas about where to leverage:

  • keep stable team (through organization design)
  • ensure dedication (through organization design)
  • define shared responsibility (through organization design)
  • create task interdependency (through organization design)
  • support learning (through coaching)
  • align common goal (through coaching)
  • increase level of collaboration (through coaching)

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