From fixed roles to evolving agreements

In many if not all Agile ways of working, team self organizes to take shared responsibility. This often means to transition from role-based working model to agreement-based working model. This transition doesn't happen automatically, and it needs to be nurtured.

Roles are gone

When a team takes shared responsibility, the fixed roles within the team are gone and everybody becomes a team member. As we want everybody to care about the common goal, we purposefully keep the boundary among team members vague, so as to discourage the silo mentality. However, we often mistaken vague boundary for vague agreements. In fact, we need more - not less - clear agreements when we work in shared responsibility. Shared responsibility combined with vague agreements is a recipe for low performance of a team.

In traditional role-based working model, part of the agreements come from fixed roles with special responsibilities. When we get rid of those specialized roles, and replace them with generic roles such as team member, it both empowers and excuses everybody - now anybody can do anything and anything can be done by anybody. Thus, if we are not careful - doing things without agreeing with each other, it soon becomes chaotic. Once roles are gone, something else is needed.

From roles to agreements

Agreements play an important role when team takes shared responsibility. In theory, as anybody may do anything, everything requires an agreement; this will be too much overhead. In reality, we rely much on tacit agreement. If the team is stable, they build tacit agreements over time. With tacit agreements in place, there is less overhead to keep the team functioning. How do we build tacit agreements? If we leave them completely ad-hoc, they may emerge eventually, but with lots of pain during the storming. It is not uncommon to see that teams ruin the relationships among members and never get out of the storming. So, we instead introduce working agreements to aid the process.

Working agreements are explicit, usually with 5-7 items. They are evolving - with new items added into the list, and old items taken off the list - they become part of tacit agreements. Indeed, when a team changes, the tacit agreements need to be re-built, often meaning that some items may be re-added to the explicit working agreements.

In addition to tacit agreements and working agreements, sometimes there is need for more transient agreements, for example, around specific tasks. While taking shared responsibility, we should be mindful for more clarity - always be clear about who will get what done by when.

Back to roles

Working agreements are defined by team itself, what if team defines roles as their working agreements? It seems not breaking team's self-organization, as long as it is decided by themselves and they can adapt when necessary. Can having roles inside a team co-exist with taking shared responsibility as a team?

Let's look at it from two dimensions - whether roles are fixed or changing, and whether people taking those roles are fixed or changing?

from fixed roles to evolving agreements.jpg
  • fixed roles/fixed people leads to the silo - everybody becomes only caring about their own role and responsibility over time, then the shared responsibility is in jeopardy.
  • fixed roles/changing people may still have shared responsibility, though the fixed roles implies its static working model, and possibly the lack of continuous improvement.
  • changing roles/fixed people looks like just renaming roles:-)
  • changing roles/changing people clearly indicates shared responsibility, and the changing roles implies its dynamic working model, and possibly continuous improvement.

Therefore, as long as not the same people stick with those roles, roles and shared responsibility may well co-exist.

Although it is possible that team transforms by itself, it is more common that ScrumMasters, coaches, or Team Leaders (see Leading Self-Directed Work Teams) coach teams to transition from fixed roles to evolving agreements. When the roles are gone, watch out for the agreements!

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