오래된 SW 엔지니어의 평생 공부

자기조직화(Self-Organizing)은 자연 스러운 것이다. 옛말에도 삼인행이면 필유아서헌이라고 했다. 왜 2명도 4명도 아닌 3명이면 선생이 있을까? 2명이면 상호작용이 간단할 것이고 3명이 되면 상호작용이 복잡해 지면서, 자연스럽게 리더가 생긴다는 것으로 이해할 수 있다.

그런데, 애자일 방법론에서 왜 자기 조직화를 강조할까? 자연스럽고 효과적인 팀인데? 실재 조직에서는 이와는 다르게 인위적으로 Hierarchy를 만들기 때문에 Self-Organizing과는 괴리가 생길 수 있다. 그렇다면, 어떻게 운영하는 것이 좋을까?

마침, 인터넷에서 재미있는 글[1]을 찾아서 번역해 본다.

왜 자기 조직화 팀이 나은가?

많은 사람들이 자기조직화 팀의 개념에 대해 혼란스러워합니다. 그들은 무정부 상태와 동일시되거나 자기조직화를 자기 형성(self-forming), 자기주도(self-directed) 또는 자기관리(self-managing)와 혼동합니다. 자기 조직화란 무엇을 의미하며 다른 모든 용어와 어떻게 다른가요?

자기 조직화 팀이란 무엇입니까?

자기조직화 팀의 개념부터 시작하겠습니다. 이 용어는 2001년에 발표된 애자일 선언문 뒤에 있는 12 가지 애자일 원칙에 포함되었습니다.

"최고의 아키텍처, 요구 사항 및 디자인은 자기조직화 팀에서 나옵니다."

일부 사람들은 이를 다음과 같이 특성화합니다. 자기조직화  팀은 스스로 작업을 수행하고 프로세스를 관리하며 진행 상황을 모니터링하는 방법을 스스로 결정합니다. 저는 이것은 자기 관리 팀(Self-managed team)이 더 적절한 표현이라고 생각합니다. 저는 그것이 선언문의 저자들이 의미 한 것이라고 생각합니다. 팀의 문제는 "팀을 구성(Organize)하는 방법"이 아니라 "작업 방법(How)"을 파악하는 것이기 때문입니다. 

마찬가지로 가장 최신 Scrum Guide[2]는 "자기조직화 팀"을 6번 언급합니다(2019/01/04에 확인한 결과 2번, Self-Organizing은 4번 언급합니다.). 이 용어가 팀 구성 방법이 아니라 팀이 작업을 수행하는 방법을 의미하고 있음이 분명합니다.

애자일과 스크럼에서 자기 조직화의 근원

2001년 애자일 선언문과 스크럼 가이드에서 자기조직화가 언급되었지만 실제로는 두 가지보다 이 용어가 먼저 나왔습니다. "자체 조직화"가 가장 먼저 사용된 곳 Scrum에 영감을 준 1996 년 HBR 기사 인 "The New Product Development Game"[3]으로 거슬러 올라갑니다. 이 기사에서는 자기조직화가 세 가지 주요 특징을 갖는 것으로 설명했습니다.

“그룹은 자율성(Autonomy), 자기 초월성(Self-transcendence) 및 교차 수정(Cross-fertilization)의 세 가지 조건을 보일 때 자기 조직화 능력을 보유합니다. 다양한 신제품 개발 팀에 대한 연구에서 우리는 세 가지 조건을 모두 발견했습니다." 

자기조직화 팀의 수준

실제로, 자기 조직화는 온/오프와 같은 이진 개념이 아닙니다. 더 일반적인 구분 방법은 다른 수준의 자기조직화의 구성이 있다는 것입니다.

Richard Hackman은 자신의 저서 인 The Wisdom of Teams(아마도 [4]를 잘못 언급한 것으로 보임) 에서 자기 조직화를 살펴볼 수있는 유용한 프레임 워크를 제공합니다. Hackman은 누가 방향을 제시하는가, 누가 팀 구성원 구성을 디자인하는가, 누가 작업을 모니터링 및 관리하는가, 그리고 누가 실행하는가를 포함하여 팀 감독 및 관리를 위한 4 가지 요소를 살펴 봅니다. 아래 다이어그램에 표시된 것처럼 관리자(Manager) 또는 팀(Team)이 각 작업을 수행하는지에 따라 팀 이름이 다르게 지정됩니다.

Hackman의 프레임워크를 기반으로 작업하는 대부분의 Agile 및 Scrum 팀은 아래의 자체 관리 팀 범주에 속합니다.

자기조직화 팀과 자기형성(Self-forming)의 약간의 혼동

나는 최근에 자기 조직화라는 용어를 자기형성 팀을 의미하는 것으로 해석 한 고객이있었습니다. 그들은 새로운 문제가 생길 때마다 조직 내 팀이 구성 될 것이라고 생각했습니다. Richard Hackman은 이를 자기설계 팀(Self-designing Team)을 호출합니다.

새로운 문제가 생길 때마다 고객이 자기설계 팀을 구성 할 수는 있지만 어떤 팀이 존재할 것인지 한 번만 결정할 가능성이 높습니다. 일반적으로 경영진은 어떤 팀이 필요하고 누가 팀을 구성 할 것인지 결정합니다.

그러나 관리자가 팀에 할당하지 않고 팀 구성원이 작업 할 팀을 결정할 수 있도록하여 민첩한 전환을 시작하기로 선택한 일부 조직이 있습니다. 권한 부여 및 의사 결정 및 팀 구성원이 그러한 결정을 내릴 수 있도록하는 것입니다.

저는 두 개의 다른 조직에서 팀의 자기형성(Self-forming) 연습을 촉진하는 특권을 가졌습니다. 팀 자체 구성은 개별 팀 구성원이 작업 할 팀을 선택할 수 있는 시점입니다. 이는 일반적으로 필요한 팀 비전과 필요한 작업 로그 및 원하는 팀 수를 설명하고 개별 팀 구성원이 팀을 구성하는 방법을 결정할 수있게하여 수행됩니다.

Ahmad Fahmy는 Bank of America에서 이러한 유형의 운동에 관한 훌륭한 기사[5]를 썼습니다. 벤 코펠 (Ben Kopel)은 시카고 스타트 업 업 테크 (Chicago Startup Uptake)에서 자체 선택 팀화 (self-selection teamification)[6]라고하는 유사한 운동에 관한 기사를 썼습니다. 이것을 볼 대, 아직 혼돈란을 해결하지 못한 것 같습니다.

무정부 상태(Anarchy) 아닌가요? 누가 책임자인가요?

어떤 사람들은 자기조직화가 무정부 상태와 같다고 생각합니다. 그들은 사람들이 실제로 옳은 일을 할 것이라고 믿지 않으며, 상황이 맞다면 그들에게 기대되는 것을 믿지 않습니다.

보다 전통적인 리더는 팀 전체를 다루기보다는 목을 조를 사람(The single throat to choke)[7]을 가지기를 기대합니다. 

제 경험 상 이런 일이 결코 일어나지 않습니다. 팀에는 가이드 레일 위를 달립니다. 우선 순위는 프러덕트 오우너(Product Owner)가 설정합니다. 팀 구성원은 일반적으로 리더십(저는 경영층이나 중간 관리자라는 의미로 이해됩니다)에 의해 선택되며, 일반적으로 애자일 프레임워크 (예 : Scrum 또는 Kanban)도 설정합니다. 무정부 상태가 아닙니다.

참고문헌

[1] Why Self-Organizing Teams are Better, https://vitalitychicago.com/blog/why-self-organizing-team-are-better/  

[2] The Scrum Guide, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf#zoom=100

[3] The New Product Development Game, https://hbr.org/1986/01/the-new-new-product-development-game

[4] J. Richard Hackman, "Leading Teams", 2002

[5] How to Form Teams? A Story of Self-Designing Teams, http://www.ahmadfahmy.com/blog/2013/12/5/the-rise-of-the-team

[6] Teamification: Agile Team Self-Selection, https://www.linkedin.com/pulse/teamification-agile-team-self-selection-ben-kopel/

[7] https://vitalitychicago.com/blog/single-throat-choke-agile/