Specialization vs. Responsibility

Specialization is about being good at something, while responsibility is about having a duty to deal with something. While they are related, it may not be good idea to couple them together.


Component specialization and Feature responsibility


Conway's law states, "organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"


Once you setup team with certain component responsibility, they specialize on the component naturally. Then, this becomes the source of inflexibility, when specialization is used to justify tying those teams with those components. Evolving architecture becomes harder when it is coupled with organizational structure.


The solution is feature teams with collective code ownership. The responsibility is on feature, while component responsibility is shared, do we still have component specialization? Most likely yes, at least at individual level. Some people are more knowledgable thus better at doing certain component work. Generalizing specialists starts with some speciality, then expands to other specialities. For example, you are the main developer on component A, and you expand to work on component B and develop specialty there over time. This may apply to team level too, since some features may touch certain part of system and the related components more often than other features. Specialization just happens. Since the responsibility is on feature, thus, the component specialization does not limit us from picking the most valuable feature items.


In short, have feature responsibility, and let feature guide component specialization.


Feature specialization and Product responsibility


The same dynamic happens with feature specialization. When the team has feature responsibility, e.g. it is a "Payment" team, the team specializes on the relevant domain. Then, this becomes the source of inflexibility, when specialization is used to justify tying those teams with those features. Evolving product becomes harder when it is coupled with organizational structure.


The solution is feature teams with common product backlog. Those teams have product responsibility, and they don't have special feature area responsibility such as "Payment". Do they still have feature specialization? Most likely yes. Given the team developed features in this area, when another high-value feature comes to same area, the team likely picks this one. Over time, they specialize on this feature area. This is even a good thing since it helps develop the deep knowledge and skills, but we don't want to label them as "payment" team and define their responsibility around this feature area. When that happens, we start to select features because we have suitable team available, rather than customer value driven. Therefore, every team is product team without having name tied to feature area. Instead of having "Payment" team, we have "Gryffindor" team. For specialization, we may even want to track and take advantage of it when possible.


In short, have product responsibility, and let product guide feature specialization.


Requirement area


If you work on large-scale development and adopt LeSS, you should have heard of Requirement area. Do we want to introduce areas with clear responsibility on product domains, or areas simply as groups of teams and let specialization on product domains happen and evolve? There is no simple answer. The bottom line is, Requirement area is dynamic. When you give Requirement area clear responsibility and associate it with meaningful area name (e.g. Security), it may help build the identity thus accelerate the specialization. On the other hand, this may also lead to Requirement areas standing still forever.


Conclusion


Specialization and Responsibility are two different things, and we shall not confuse them. Specialization happens, and you may want to track and take advantage of it, while narrow responsibility, defined around specialization and often labelled in name, decreases flexibility and leads to local optimization.

Read more

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

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

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

By Chokchai
Vocal archetypes

Vocal archetypes

ผมกำลังเรียนวิธีใช้เสียงในคอร์ส Stage Academy ของ Vinh Giang ในคอร์ส ผมได้เรียนเกี่ยวกับแม่แบบของเสียง 4 รูปแบบดังนี้ Motivator ผู้จูงใจ เป้าหมายของผู้จูงใจคือการจุดประกายแรงบันดาลใจ องค์ประกอบของการใช้เสียงรูปแบบนี้คือ * เพิ่มความเร็วในการพูด * เปล่งเสี

By Chokchai
เขียน runtests script ให้เป็น executable document กันเถอะ

เขียน runtests script ให้เป็น executable document กันเถอะ

ตอนนี้แล้วผมกล่าวถึงความสำคัญของเอกสารที่สามารถ execute เพื่อตรวจสอบดูว่ามันยังจริงอยู่ไหมได้ในรูปแบบของ unit tests ซึ่งเอาไว้เก็บบริบทของปัญหาที่เรากำลังแก้ หรือเรียกง่าย ๆ ว่า requirement ตอนนี้เราจะมาพูดถึงเอกสารที่ใช้ในการ build software เช่น build script หรือแม้

By Chokchai

Pair programming 4 แบบ

เวลาผมสอนเรื่อง pair programming ปรกติผมจะเล่าคร่าว ๆ ว่า pair programming มี 2 แบบที่ผมใช้บ่อย ๆ คือ ping pong ที่ใช้เวลาคู่ pair ชำนาญพอ ๆ กัน กับ driver-navigator ที่ใช้เวลาความชำนาญต่างกัน ช่วงนี้มีโอกาสได้ pair กับสมาชิกในทีมบ่อย

By Chokchai