애자일의 핵심은 팀의 자기조직화

이 글은 여러 시행착오를 통해 배운 애자일을 위한 자기 조직화의 중요성과 점점 더 애자일스럽게 변해가는 조직에 대한 경험을 공유하기 위함입니다.
많은 현업에서 업무의 불확실성을 해결하기 위한 방법으로 요구사항을 지속적으로 효과적으로 제품에 반영하기 위한 개발 방법론으로 애자일을 도입하고자 합니다.

”폭포수 모델은 옛날거야! “ 라고 하면서,
폭포수가 고전적 모델이지만, 분명히 효과적인 산업 환경과 환경은 있습니다. 무엇보다 조직화가 되지 않은 조직에서는 오히려 폭포수 모델이 더 효과적일 수 있습니다.

폭포수 개발 방법(Waterfall Model)과의 차이점

폭포수 모델은 하나의 단계를 순차적으로 수행하며 진행하는 방법론으로 이해하기 쉽고 직관적이지만, 프로젝트의 크기가 커질수록 단계별로 시간이 오래 걸리고, 요구사항의 변화에 유연하게 대처하기 어려워지는 단점이 존재합니다.

바로 이러한 한계를 극복하기 위해 나온 개발 방법론이 애자일 방법론입니다.
그리고 무엇보다 애자일은 외부로부터의 질서보다는 팀원 스스로가 만들어나가는 자기 조직화(self-organizing)를 통해 스스로의 참여를 기반으로 함께 만들어 가는 것을 주요한 가치로 여기고 있습니다. 하지만, 때론 이러한 부분이 무질서해 보이기도하고 전통적인 프로세스 조직과는 마찰이 생기게 되는 주요 원인이 되기도 합니다.

애자일에 대한 이해 없이 수행하는 프로젝트는 ?

대부분의 경우 방법론을 유행처럼 선택하고 “우린 애자일로 개발해!” 라고 말합니다.
이러한 애자일과 자기 조직화의 이해 없이 애자일이라는 방법론의 형식적인 부분만 도입한 경우 어떤 문제가 발생할까요 ?

동상이몽(同床異夢)

애자일은 요구사항을 만들고 전달하는 고객과 기획팀에게는 여러 번 나눠서 시장 변화와 목적에 맞게 요구사항을 변화할 수 있어 좋습니다. 그리고 개발팀에게는 미리 많은 걸 시도하고 고려하기 보다는 현재 요구사항에 맞게 빠르게 개발함으로써 시행착오로 인한 리소스 낭비를 줄일 수 있습니다.
하지만 이 생각이 엇나가는 걸 느끼는 순간은 생각보다 빨리 찾아옵니다.
기획에서 전달하는 요구사항은 계속해서 빠르게 변경되고 변화의 폭도 커지며 심지어는 양도 늘어납니다. 개발은 계속해서 변경되는 기획으로 인한 잦은 설계 변경으로 언제나 처음부터 다시 시작하게 되며 개발 피로감도 급속도로 빠르게 증가하며 완성도도 마찬가지로 곤두박질 치게 됩니다.

“애자일은 주기적으로 고객의 요구사항을 지속적으로 반영하는 거 아냐 ? 이것도 추가로 개발해줘”

애자일의 폐해는 잘못된 이해와 몰상식에서 비롯됩니다.
애자일을 도입한 프로젝트가 실패하는 대부분의 모습은 아마도 이러한 불분명한 목표에서부터 잦은 요구사항의 변경으로 이어진 업무 과중과 일정 지연이 팀원의 불만과 이탈로 이어져 엉망이 되고 결국 제품의 완성도는 떨어진 채 실패하게 되는 것일 겁니다.

그러면서 “역시 애자일은 문제가 많아”라면서 자기 위안도 함께

무분별한 애자일은 자연스럽게 점점 더 업무 폭탄으로 이어지고 이렇게 수행한 애자일은 오히려 주어진 목표와 일정이 설계 단계에서 분명한 폭포수 모델보다 더 실패확률이 높을 것입니다.
하지만 우린 너무나 쉽게 그리고 자주 이러한 실패를 쉽게 경험합니다. 팀 리더는 회의를 하고 올때마다 요구사항 변경으로 인한 산더미같은 일을 안고 돌아옵니다.
그런데 말입니다. 일정과 목표는 왜 변하지 않는 걸까요 ?
결국 이러한 고정된 예산과 일정에서 수행하는 프로젝트에서 애자일은 오히려 득보다는 독이 될 수도 있을 것입니다.

그래서 애자일 ? 어떻게 하는건데 ?

고정된 예산과 일정속에 원하는 목표를 이뤄야 하는 조건은 대부분의 프로젝트에서 동일한 환경일 것입니다. 그런 환경속에서 애자일을 적용하기 위해 우린 어떻게 해야하는 것일까요 ?

전 이 지점에서 다시 이전의 문제로 다시 돌아가봤습니다.

고객(or 기획, 다른팀)의 요구사항은 왜 자꾸 바뀌고 개발은 왜 잦은 변경에 불만이 발생할까 ?
변화가 성공을 위해서라면 개발은 그 변화가 불만일까 ?
고객은 성공을 위한 방향이라면 개발의 불만에 귀를 기울이고 설득해야 하지 않을까 ?

결국 모두가 애자일이라는 방법론으로 개발을 한다고 했지만 기존의 폭포수 모델의 단방향성 업무 흐름 구조에서 벗어나지 못하고 있기 때문일 것입니다.

애자일(Agile)

Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer(s)/end user(s).

<출처> 위키피디아

애자일 소프트웨어 개발은 자기 조직화(self-organizing)된 다른 기능 팀(cross-functional)들과 그들의 고객과 사용자들의 공동 노력을 통해 요구사항과 해결책이 발전하는 소프트웨어 방법론입니다.

여기서 말하는 애자일은 핵심은 결국 이해 관계자들, 프로젝트를 성공시키기 위해 최선의 노력을 해야 하는 모든 사람들의 공동 노력을 기반으로 한다는 것입니다.

하지만 오해를 하면 안되는 지점이 있습니다.

바로 “공동 노력”에 대한 해석입니다.
제가 생각하는 “공동 노력”에서 공동은 따로 하는 노력이 아니라 같이 함께하는 노력이어야 한다는 것입니다.
업무 별로 분리된 기획과 개발의 각자의 노력이 아니라 모든 팀원들이 함께 목표를 이루기 위해 하나가 되어 움직여야 하는 공동의 노력이라고 생각합니다.

예를 들면, 기존의 방법론을 통한 프로젝트들이 바톤을 주고 받는 이어달리기 였다면, 애자일은 이인 삼각 경기와 같이 같은 호흡으로 함께 나아가야 하는 것이 아닐까 생각합니다.

자기 조직화(Self-Organizing)

저는 프로젝트의 성공을 위해서 애자일 방법론이 필요하다면 무엇보다 중요한건 개개인의 능력이 아닌 공동의 목표를 이루기 위한 공동의 노력을 기반으로 하는 자기 조직화라고 생각합니다.

하지만 여기서 여러가지 경우가 있을 수 있습니다.

모든 조직원들이 일정 수준 이상의 전문가 집단일 경우와 쥬니어들이 다수 포함되어 있는 경우가 있을 수 있습니다. 또한 모든 조직원이 비슷한 직무일 수도 있고 혹은 전혀 다른 업무를 하는 경우도 있을 수 있습니다.

이런 모든 경우에서도 자기 조직화는 가능할 것인가 ?

우린 줄기세포가 아닙니다. 모든 직무의 요구사항을 만족할 만큼 빠른 시간안에 진화할 수 없습니다.
그럴 경우를 생각했을 때, 무엇보다 중요한건 공동의 목표에 대한 욕구가 일치해야 한다는 것입니다. 원하는게 일치하고 그것을 이루기 위해 힘을 합쳐야 한다는 생각이 그리고 그것에 대한 신뢰가 형성되었을 때, 조직은 무엇보다 빠르고 단단하게 움직일 수 있습니다. 세포들의 자기 조직화처럼 일사분란하고 효율적이지는 못할지라도 팀 모두는 어쨌든 자신의 몫을 다하기 위해 자신이 할 수 있는 곳에서 최선의 노력을 다할 것이라는 것입니다.
그런 신뢰를 가진 조직이라면 우린 누가 슈퍼맨일지라도 상관없이 하나의 팀으로써 모두가 하나가 되어 지구평화를 지켜나갈 수 있을 것입니다.

자기 조직화된 조직과 아닌 조직은 무엇이 다를까요 ? 어떤 조직이든 슈퍼맨만 있다면 슈퍼맨이 지구를 지키는 건 똑같다고 느낄 수 있습니다.
하지만 현실에서는 슈퍼맨처럼 올바르고 정직하게 어떠한 실수도 없이 어떠한 어려움도 해결할 수 있는 주어진 목표를 달성하는 전지전능한 사람은 없을 것입니다. 결국 현실세계의 개개인은 더 큰 목표일 수록 조직의 도움이 필요하고 혼자 힘으로는 모든 것을 다할 수 없을 것입니다. 그때 신뢰하고 함께 목표를 이루는 조직과 그렇지 않은 조직은 전혀 다른 결과가 나올 수 밖에 없을 것입니다.

사실 이건 모든 경우에도 적용될 것입니다. 하지만 애자일에서는 왜 이러한 자기 조직화가 더 중요한 것일까요 ?
바로 고객의 요구사항을 만족하기 위해, 끊임없이 변화하고 적응하고 발전하기 위해서는 고정된 목표도 고정된 능력이 아닌 상황에 맞게 모두가 변하고 모두가 노력해야 하는 모두가 공동의 노력으로 공동의 목표를 향해 가는 조직이어야만 하기 때문입니다.
그런 조직이 아니라면 변화에 적응할 수도 없을 것이고 부족한 부분도 채울 수 없을 것이기 때문입니다. 공동의 목표를 향한 모두의 노력은 누구의 희생도 강요도 아닌 온전히 목표를 이루기 위한 그것을 온전히 동의한 신뢰를 가진 조직이어야만 가능한 것이기 때문입니다. 그렇게 해야만 모두의 노력은 혁신과 발전으로 이어질 것이고 목표를 이루기 위한 가능성은 더 높아질 것입니다.

애자일을 위한 준비

It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change

<출처> 위키피디아

애자일 방법론은 적응형 계획, 진화하는 개발, 조기 제공, 지속적 개선을 추구하며 신속하고 유연한 변화의 대응을 장려합니다.
그렇다면 팀은 프로젝트로 애자일 방법론을 채택한다면 무엇을 준비해야 할까요 ?

시작은 애자일에 대한 이해로부터

애자일 소프트웨어 프로젝트는 아래와 같은 개발 선언을 중심으로 수행합니다.

애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

<출처> 애자일 선언서

저는 이것을 아래와 같이 이해합니다.
애자일의 요구사항은 잦은 변경이 아닌 성공을 위한 진화이며,
애자일의 개발은 처음부터 완벽한 설계로 체크리스트를 지워가는 것이 아닌 체크 리스트를 채워가는 것이며,
애자일의 배포와 개선은 성공을 위한 작은 실패를 허용하기 위해 빠르고 반복적으로 수행가능한 것이어야 하며,
애자일은 그래서 모두가 함께 나아가야 한다는 것이다.
애자일에 대한 이러한 이해를 바탕으로 애자일을 수행한다면 우리는 어떠한 과정에서도 불평과 불만보다는 이해와 협력으로 문제를 해결해 나갈 수 있을 것입니다. (어려운 걸 말로 하니, 참 쉬워 보이네요.)

공동 목표

저는 이러한 애자일의 이해 이후 공동 목표 형성 작업을 합니다.

공동의 목표를 형성하기 위한 첫 걸음으로 공동의 목표를 설득하는 것이 아닌 먼저 개인의 목표를 이해합니다. 그리고 개인의 목표를 달성하는데 우리의 공동 목표가 정말 중요한 것인지 필요한 것인지를 논의합니다. 만약 이 과정에서 공동의 목표가 개인의 목표와 전혀 부합하지 않거나 방향이 맞지 않다면 그리고 프로젝트가 길고 어려운 것이라면 저는 아무리 프로젝트의 성공에 필요한 사람일지라도 팀의 일원으로 함께하지 않는 것이 좋습니다. (이것은 지극히 개인적인 의견입니다)
이런 경우 팀내에서 함께하기 보다는 분리된 프로젝트로 필요한 업무만 분리하여 수행함으로써 팀의 공동 목표 형성에 영향을 받지 않는 것을 저는 선호합니다.

하지만, 모두가 동의한 공동의 목표 일지라도 개인의 목표는 때론 희생될 수 밖에 없기 때문에 비록 동의한 희생일지라도 이를 주기적으로 확인하며 희생을 최소화하고 개인의 목표와 공동 목표를 동일시하는 작업을 이어가야 합니다. (저는 이러한 과정을 주기적인 면담을 통해 보완하려고 합니다.)

그리고 정기적으로 평가하고 개선을 위한 노력을 수행해야 합니다. (저는 스프린트 회고를 통해 이것을 수행합니다.)
우리가 프로젝트를 수행하며 얼마나 “애자일스러웠는지” 그리고 어떤 개선이 필요한지를 서로에게 묻고 답하며 끊임없이 진화하기 위한 노력을 합니다.

애자일 선언 이면의 원칙

우리는 다음 원칙을 따른다:
우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
비록 개발의 후반부일지라도 요구사항 변경을 환영하라.
애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
동기가 부여된 개인들 중심으로 프로젝트를 구성하라.
그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
작동하는 소프트웨어가 진척의 주된 척도이다.
애자일 프로세스들은 지속 가능한 개발을 장려한다.
스폰서, 개발자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.
기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
단순성이 – 안 하는 일의 양을 최대화하는 기술이 – 필수적이다.
최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

<출처> 애자일 소프트웨어의 12가지 원칙

애자일 시작 그 후

이렇게 애자일은 반복적으로 공동의 목표를 확인하고 과정을 점검하며 혁신과 발전을 위해 모두가 자기 노력을 기울였을 경우에 가능성이 더 높아지는 방법론입니다. 만약 이러한 자기 조직화의 과정없이 애자일을 수행한다면 프로젝트는 성공할지 몰라도 그 과정에서 많은 희생과 그에 따른 어려움이 발생할 것입니다.

저도 몇몇 프로젝트를 애자일로 개발하며 결과는 성공했을지라도 애자일의 실패는 경험하며, 많은 희생과 어려움을 겪었습니다. 그리고 점점 애자일에 대한 이해가 높아가며 위의 방법으로 애자일을 수행하였을 때, 결과의 성공뿐만 아니라 지속 가능한 혁신과 발전을 이룰 수 있다는 확신을 함께 가질 수 있었습니다. 더불어 팀 전체가 이러한 자기 조직화를 통해 프로젝트의 목표를 달성할 때 얼마나 시너지가 나고 그 과정이 아무리 힘들어도 즐거울 수 있는지를 경험했습니다.

저는 자기 조직화는 다른말로 진정한 동료들과 함께하는 것이 아닐까 생각합니다.

믿고 함께 고민하고 꿈을 이루기 위해 나아가는 사람들과 조직화된 팀에서 수행하는 프로젝트는 목표의 어려움을 뛰어넘는 성공의 기쁨뿐만 아니라 지속적인 혁신과 발전의 과정을 함께 경험하는 즐거운 성장의 과정이라고 말할 수 있습니다.

이어서

이러한 애자일을 위해 저는 스크럼 프로세스를 도입하여 이를 수행하였습니다.
다음은 스크럼 프로세스와 스프린트의에 대한 이야기와 도입 과정에서의 시행착오에 대한 이야기를 통해 실질적인 프로젝트의 진행 과정을 이야기 하도록 하겠습니다.

참고

• 애자일 소프트웨어 개발 선언
• 위키피디아: Agile software development
• 위키피디아: 스크럼 (애자일 개발 프로세스)

매드업은 지금 채용 중! 매드업 채용 바로가기