오래된 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/

개요

애자일 서적 등에서 많이 사용되는 설명 방법 중 비유(Metaphor)가 있다. 가치와 원칙 관련한 글에서도 빙하 비유(Iceburg Metaphor)를 소개하기도 했다. 여기서는 여러 서적에서 사용한 정원 가꾸기 비유 관련 내용을 정리해 보려 한다. 정원사, 정원 가꾸기와 같은 비유는 일상에서 접하기 쉬운 내용을 통해서 애자일 이론을 쉽게 이해할 수 있는 설명 방법이기도 하다. 이러한 비유가 좋은 점 중에 하나는 비유는 그곳에서 이어지는 생각의 타래, 즉 더 깊은 이해로 가는 입구이기 때문이다.

"XP Explained"에서의 비유

익스트림 프로그래밍(Extream Programming, XP)은 내가 가장 처음 접한 애자일 개발 방법이었다. 짝 프로그래밍(Paired Programming)에 탐복하고 지금도 정말 익스트림(Extream)하게 개발과 배포를 동시에하는 데브옵스(DevOps)와 같은 맥락의 지속 통합(Continous Integration)의 개념을 소개했던 방법론이었다. 무엇 보다도 프로젝트의 일정과 목표도 중요하지만, 개발자 중심으로 관점을 바꾸게 해준 중요한 방법론이었다.

XP Explained(한국에는 익스트림 프로그램으로 번역[1])은 Manifesto for agile software development의 초기 서명자 중 한명이면서 JUnit으로도 유명한 Ken Beck이 저자인 책이다. 이 책에서는 운전하는 방법에 대한 비유도 있지만, 내가 처음 보았던 정원 가꾸기 비유가 포함되어 있다. 원본의 일부를 잠시 살펴 보면 다음과 같다.

No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a gardener. So it is with XP. Reading the book won't make you an extreme programmer. That only comes with programming in the extreme style, participating in the community of people who share these values and at least some of your practices sharing what you know with others.

애자일 해지기(Being Agile) 위해서는 책에 있는 이론만 한다거나 읽어서만은 안된다는 것이다. 실재로 실행(Practice)도 하고, 다른 애자일 커뮤니티에 참석하고, 애자일 방법론에 대해서 가르치기도 해야 한다. 그래야, 애자일리스트(Agilist)가 될 수 있다.

소프트웨어 장인정신에서의 비유

소프트웨어 장인정신[2][3]은 애자일 접근방법 중 개발자들의 역량을 강조하면서 나오는 활동 중에 하나이다. 많은 애자일 방법론에서는 훌륭한 동료들과 일하는 것을 강조하지만, 어떻게 훌륭한 개발자가 되는지에 대해서는 이야기 하고 있지 않다. 소프트웨어 장인[3]에서도 정원가꾸기에 비유가 있다. 여기서는 코드 개발하는 것이 정원 가꾸기와 유사하다고 설명하고 있다.

Code is organic, not mechanical. Like a garden, code needs constant maintenance. Look after its soil, Remove weeds, Water it, Remove dead plants, plant new ones, and trim or rearrange existing to make healthy, looking nice and whole. With basic and regular maintenance, the garden will always look great if we neglect it, it will require much more effort to make it look good again. Code is no different. we don’t look after it constantly, the code starts to deteriorate as changes and new features are added. Bad design choices, lack of tests, and poor use of languages and tools will make the code rot faster. Gradually, other parts of the code will also be contaminated up to the point that the whole code base is extremely ill, making it painful and costly to maintain it.

소프트웨어 제품을 만들 때, 계속 새로운 기능만 추가 하는 것이 고객을 만족시키는 일이 아닐 것이다. 잡초도 제거하고 물도 주고, 죽은 화초들은 제거하고 새로운 화초를 심기도 해야 한다. 단순히 코드라고 했지만, 소프트웨어 제품으로 본다면 정말 크고 훌륭하게 관리되어 사람들이 돈을 지불하고 관람하는 식물원과 같은 수준을 고려한다면, 어떻게 관리하여야 할지 생각해 볼일이다.

맨먼스 미신에서의 비유

맨먼스 미신은 후배의 책장에 꼽혀 있던 책으로 처음 접했다. 어디선가 보았던 제목이지만, 잠시 펼쳐 보았을 때에는 저자의 내공이 느껴지는 오래된 책이었다. 역시 다시 검색해 보니, 1975년의 책이다. 한글판은 번역이 된지는 얼마 되지 않았다. 이 책에 포함된 점진적 개발(Incremental Development)에서는 소프트웨어를 살아있는 생물에 비유 했다. 그래서, 구축(Build)하는 것이 아니고 키우는(Grow)한다고 이야기 하고 있다. 오래된 책이지만, 현재에도 통용될만한 지혜를 전달하고 있다고 할 수 있다.

So it must be with our software systems (In other words, software system is similar to complex system such as living things). Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit it is fleshed out, with the subprograms in turn being developed into actions. 

피플웨어에서의 비유

피플웨어[5]에서는 팀 빌딩을을 농업(Argiculture)로 비유 한다.

We stopped talking about building teams, and talked instead of growing them. The agricultural image seemed right. Agriculture isn’t entirely controllable. You enrich the soil, you plant seeds, you water according to the latest theory, and you hold your breath. You just might get a crop; you might not. If it all comes up roses, you’ll feel fine, but next year you’ll be sweating it out again. That’s pretty close to how team formation works. 

농업에서 전체를 통제하지 못한다. 대신, 근간이 되는 토양을 푸엉하게 하고, 씨를 뿌리고, 이론에 따라 물도 주고 가꾼다. 하지만, 어떻게 될지는 숨죽이고 기다리는 수 밖에 없다. 수확이 있을 때도 있지만, 그렇지 않을 때도 있다. 안되었다고, 실망하고 있을수만은 없다. 왜 그랬는지 고민도 해야 하지만, 결국 다시 시도해 보는 것이 정답일 것이다.

매니지먼트 3.0에서의 비유

매니지먼트 3.0[6]에서도 조직관련해서 정원에 비유를 제공하고 있다.

. Living systems grow fast in the beginning and then reach a level of maturity. Mature systems don’t need to be looked after as often as the young systems.
. When a garden is not managed, it will simply keep growing but in another direction than what was intended. It’s the same with software systems and teams.
. Many growing systems have a certain life expectancy. They have a tendency to wither away and die.

생명체가 가지는 특징을 소프트웨어 혹은 조직이 유사하게 가진다는 것이다. 처음 태어났을 때, 급격히 성장하고 성숙하게 된다는 것이다. 또한, 관리하지 않으면 원하는 방향으로 발전하지 못한다는 것이다. 생명체와 같이 마지막에는 죽음을 맞이한다는 경향을 설명한다.

또한, 개발자와 관리자가 정원사와 같이 해야 하는 활동도 설명하고 있다.

. Seed, feed, and nurture the systems
. Young systems need more care than mature ones.
. Weed out everything that draws energy away from our healthy growing systems
. When the time has come, we recognize when to replace the old with the new.

정원에 있는 식물의 생명 주기를 알고 시기에 맞는 관리를 해주고, 필요한 교체 시점 또한 파악해야 한다는 것을 이야기 한다.

정리하면서...

정원의 비유는 소프트웨어 제품, 소프트웨어 개발 조직에 대해서 이해하기 쉬우면서도 명료하게 특징을 잘 설명해 준다. 하지만, 이 비유만으로 모든 것이 설명되지는 않는다. 기본적으로 애자일 이론들과 더 나아가서는 소프트웨어와 개발 조직이 복잡 시스템(Complex System)임을 이해 해야 한다는 것을 한번 더 깨닫게 한다.

참고 문헌

[1] 익스트림 프로그래밍 (Extreme Programming) - 변화를 포용하라 2판, 켄트 벡,신시아 안드레스 저/ 정지호, 김창준 역, 2006년 7월

[2] Manifesto for Software Craftsmanship, http://manifesto.softwarecraftsmanship.org/#/en

[3] 소프트웨어 장인 프로페셔널리즘, 실용주의, 자부심, 산드로 만쿠소 저 / 권오인 역, 길벗, 2015년 09월 25일

[4] 맨먼스 미신, 프레더릭 브룩스 저 / 강중빈 역, 인사이트(insight), 2015년 03월 23일

[5] 피플웨어 3판, 톰 드마르코, 티모시 리스터 공저 / 박재호, 이해영 공역, 인사이트(insight), 2014년 07월 15일

[6] 매니지먼트 3.0 - 새로운 시대, 애자일 조직을 위한 새로운 리더십, 위르헌 아펄로/조승빈 역, 에이콘출판, 2018년12월 27일