팀윙크에 처음 온 날 혼란스러웠습니다. 스크럼 회의가 스크럼블을 먹는 회의인가 싶었습니다. 당황했지만 애써 태연한 척했습니다.(얼굴에 티는 다 났지만요) 스크럼과 애자일은 저에게 처음 듣는 단어였습니다. 스크럼 회의에서 그로스팀은 각자 오늘 할 일, 업무 특이사항 등 프로젝트 진척도에 관한 이야기를 하더군요. 비즈, 디자인, 개발팀도 같았습니다. 회의는 15분가량 진행했습니다. 저는 처음 하는 거라 묵묵히 지켜보기만 했죠. 이 회의가 무엇이고 무슨 대화를 하는지, 어떻게 하는지를 살펴봤습니다. 저는 문득 궁금했습니다. 회사에서 회의하는 건 당연한 일이지만, 스타트업에서 굳이 스크럼 회의라는 회의 방식을 선택한 걸까? 스크럼 회의는 왜 이런 방식으로 회의를 할까?

검색해서 찾아보니 스크럼 회의는 '애자일' 방법론 중 하나인 스크럼 방법론이라고 하더군요. 애자일 방법론이 상위 개념이고 스크럼 방법론이 하위 개념이어서 스크럼을 알려면 애자일을 알아야 했습니다.

스크럼 회의? 애자일 방법론? 먹는 건가?

애자일 방법론, 무엇일까?

애자일 방법론을 공부하면서 국내외 많은 스타트업이 옛날부터 애자일 방법론과 문화를 실천하고 있다는 걸 알게 되었습니다. 실리콘밸리 글로벌 기업들의 애자일 방법론 실천 사례와 성공 사례를 담은 국내 책도 있더라고요.

옛날부터 지금까지 스타트업들이 실천하는 이 애자일 방법론은 과연 무엇일까요?

제가 팀윙크에서 느낀 애자일은 예측하기 어려운 시장과 고객의 니즈를 재빠르게 반영하고 이를 반복하는 업무 방식이라고 느꼈습니다. 애자일(agile)은 '민첩한', '기민한'을 말하는 단어입니다. 애자일 방법론, 애자일 문화는 말 그대로 민첩하게 행동하는 업무 방식 혹은 민첩하게 행동하는 조직 문화입니다. 여기서 중요한 점은 애자일 프로세스는 반복해야 하고, 단순히 재빠르게 움직이는 게 아니라는 점입니다. 애자일은 고객과 시장의 니즈를 빠르게 반영하여 반복하여 나아가는 방식이지 빠르게 움직이고 일을 끝내는 방식이 아니었습니다.

우리 재빠르니까 애자일한 거 맞지?! 응, 아니야~

애자일 방법론, 팀윙크는 왜 하게 되었을까?

그렇다면 팀윙크는 왜 애자일 방법을 하게 되었을까요? 직접 바비(a.k.a 팀윙크 캡틴, 대표님)에게 물어보지는 않았지만 팀윙크도 여느 스타트업처럼 '사업 모델이 초기에 불확실'하고 '불확실한 사업 모델이 전통적인 업무 방식과 맞지 않기' 때문에 시작되었다고 생각합니다. 애자일 방법론 사용 배경을 알기 위해서는 기존 사업 모델과 업무 방식을 잠깐 언급해야 합니다.

기존 사업 모델은 안정적이고 검증된 사업 모델입니다. 이미 충분히 시장과 고객 니즈가 반영되어 있죠. 기존 사업 모델은 흔히 전통적인 업무 방식이라고 일컫는 *워터폴(Waterfall) 방식으로도 업무로 진행됩니다. 이미 검증된 사업이니 검증된 계획에 맞게 순차적으로 일을 진행해도 무방합니다. 업무 프로세스도 반복할 필요도 없이 일을 끝냅니다.

* 폭포수처럼 위에서 아래로 일이 떨어진다는 뜻으로, 업무가 계획되어 순차적으로 진행하는 방식입니다. 워터폴 방식은 한번 계획되면 변경 없이 실행한다는 특이사항이 있습니다.

하지만 스타트업은 다릅니다. 스타트업 사업 모델은 불확실합니다. 기존에 없었던 새로운 사업 모델이고 시장과 고객 니즈를 예측할 수 없기 때문입니다. 어느 정도 시장과 고객 조사를 하고 데이터를 분석하며 사업 모델을 구축하지만 여전히 불확실한 요소들이 너무 많습니다. 급변하는 시대 트렌드와 고객 욕구도 불확실성에 한몫합니다. 만약 워터폴 방식처럼 고객 니즈가 수시로 반영되지 않은 채 불확실한 사업 모델을 시장에 내놓는다면 큰일이 날 것입니다. 이렇듯 스타트업에서 기존 업무 방식은 사업 성장에서 한계가 있었습니다.(실제로 저는 팀윙크 오기 전에 1인 창업을 하고 혼자서 워터폴 방식으로 하다가 쫄딱 망했습니다.)

이 한계를 극복하기 위해 많은 스타트업은 애자일 방법론을 채택합니다. 애자일 방법론은 위에 말했던 것처럼 시장과 고객 니즈를 바로 혹은 주기별로 반영합니다. 짧은 기간에 시장과 고객 반응에 따라 수정하여 사업 모델 혹은 서비스 기능이 진화합니다. 사업 모델이 고객에게 향하고 넓게 열려 있어 고객과 소통하며 나아갑니다. 팀윙크에서 느낀 건 고객 커뮤니케이션이 애자일의 핵심이라고 느꼈지요.

애자일 방법론, 팀윙크는 어떻게 할까?

팀윙크 애자일 방법은 스크럼 방법론을 사용하고 있습니다. 애자일 방법론 중에서 가장 대표적인 방법론인데요.

사전에서 말하는 스크럼 방법론은 '프로젝트 관리를 위한 상호, 점진적 개발 방법론'입니다. 스크럼 방법론은 소프트웨어 개발을 위해 만들어졌지만 지금은 일반적인 프로젝트 관리에서도 사용합니다. 제가 느낀 팀윙크 스크럼 방법론으로 말하자면 잦고 빠른 소통과 피드백으로 프로젝트를 발전시키는 방식입니다. 실제 스크럼 방법론이 이러한 방식으로 진행이 될 거라고 생각합니다.

모든 스타트업이 그렇듯이 팀윙크도 스크럼 방법론 시행착오를 겪고 있어 완벽하게 하지는 못합니다. 어떤 커다란 문화가 정착되기까지 오랜 시간이 걸리기 때문이라고 생각하고 있습니다.

그럼 팀윙크가 스크럼 방법론을 실제로 어떻게 실천하는지 제가 바라본 풍경으로 이야기해볼게요. 팀윙크는 스크럼 방법론 핵심 요소인 '데일리 스크럼 회의 - 스프린트 - 회고'를 실천합니다. 이 세 가지를 실천하기 위해 컨플루언스(Confluence), 지라(Jira)라는 협업 툴을 사용하고 있습니다. 왜 팀윙크는 핵심 세 가지를 실천하고, 이 두 개 툴을 사용할까요?

제가 느끼기에 팀윙크에서 애자일 문화 핵심은 효율적인 소통과 빠른 피드백 때문이라고 생각합니다. 소통과 피드백을 위해 스크럼 핵심 요소 세 가지와 툴을 사용합니다. 소통과 피드백을 중요하게 생각하는 건 무엇 때문일까요?

예측할 수 없는 미래를 대비하며 올바른 프로젝트로 나아가기 위해서입니다. 위에서 얘기했던 것처럼 급변하는 트렌드, 알 수 없는 고객과 시장의 니즈, 구성원의 요청 등 프로젝트에 고려해야 할 중요한 변수가 많습니다. 변수들을 다 안다면 모두 고려하고 프로젝트를 진행하면 일이 수월해지겠지요. 하지만, 우리는 모두 다 예측할 수 없습니다. 어떤 변수가 갑자기 튀어나와 프로젝트에 영향을 주면 그 변수를 고려하고 프로젝트를 진행해야 합니다. 소통과 피드백이 되질 않아 변수가 생기기 이전 프로젝트 업무를 계속 진행하고 있다면 낭패입니다. 한 마디로 삽질하는 거죠. 소통과 피드백이 중요한 건 이 삽질을 하지 않고 올바른 방향으로 나아가기 위해서입니다.

실제 저희가 컨플루언스와 지라 활용을 토대로 스크럼 방법론 세 가지 핵심 요소로 소통과 피드백을 어떻게 하는지 이야기해보겠습니다.

팀윙크 애자일 문화는 소통과 피드백이 핵심!

데일리 스크럼 회의(Daily scrum meeting)

저를 처음에 당황하게 했던 데일리 스크럼 회의입니다. 데일리 스크럼 회의는 매일 하는 간단하고 짧은 회의입니다. 스크럼 회의는 매일 아침 출근해서 서로 마주 보고 앉아서 15분 정도 진행합니다.(정통 데일리 스크럼 회의는 스탠드업 회의로 서서 회의를 합니다. 저희는 문화에 맞게 바꿨습니다.) 15분을 넘기면 회의가 간단해지지 않기 때문입니다. 컨플루언스(Counflence)라는 문서 도구 협업 툴을 이용하여 각자 오늘 할 일을 적습니다. 적으면서 어제 마친 일, 오늘 할 일, 프로젝트 중 특이사항에 대해서 이야기합니다. 컨플루언스를 사용하는 이유는 서로 나눈 이야기와 각자 업무를 문서로 만들어 한번에 볼 수 있기 때문입니다. 이렇게 각자 현재 상황을 말과 글로 소통하며 올바르게 나아가고 있는지 파악합니다. 만약 아니라면 피드백하며 수정합니다. 여기서 중요한 점은 스크럼 회의가 단순히 정보 전달로 생각해서는 안된다는 점입니다. 스크럼 회의의 목적은 소통과 피드백, 이 두 요소를 바탕으로 한 협력심을 기르기 위해서입니다.(인턴 초기에는 잘 몰라 보고하듯이 했었습니다.)

스프린트(Sprint)

스프린트는 짧은 기간 내에 프로젝트를 진행하는 방식을 말합니다. 예를 들어, 앱 서비스에 새로운 기능을 넣는 프로젝트가 있다고 하죠. 서비스 기획자, 디자이너, 개발자, 마케터 등 다양한 사람이 모여 각자의 업무를 해야 합니다. 수많은 업무들이 있겠고 우선순위가 있을 겁니다. 저희 팀윙크는 지라(Jira)라는 협업 툴로 업무를 나열하고 우선순위를 매깁니다. (아래 이미지는 지라의 '칸반 보드'라는 화면입니다. 업무가 티켓처럼 나와있습니다.) 우선순위가 낮은 업무는 BACKLOG, 해야 할 일은 TO DO칸에 넣어 업무를 진행합니다. 각자 업무를 진행하고 마감 날에 다시 모여 서로 피드백합니다. 피드백 후에 다시 스프린트를 반복합니다.

지라를 사용하는 이유는 효율적인 소통과 피드백을 위해서입니다. 지라 칸반 보드는 모든 사람의 업무를 한눈에 파악할 수 있습니다. 이렇게 한눈에 보면 모든 업무 진행 상황을 알 수 있기 때문에 불필요한 미팅이 줄어듭니다. 프로젝트 과정 중 문제점과 문제 해결점을 찾는 데 빠른 대응이 가능합니다. 효율적인 소통 방식으로 프로젝트 관리가 편리하다는 거죠.

프로젝트가 끝나면 고객 커뮤니케이션 결과를 바탕으로 피드백을 해야 합니다. 각자 자기가 끝낸 업무들로 피드백하는 데, 지라처럼 업무가 시각화되어 있으면 피드백하기가 편하죠. 또한, 자기 업무가 티켓으로 세세히 기록되어 티켓 별로 피드백할 수 있기 때문에 다음 스프린트를 고도화할 수 있습니다.

협업 툴 지라(Jira) 칸반 보드입니다. 다른 업무들은 다 가렸습니다.

회고(Reflection)

한 주를 마무리하는 날에 그 주를 돌아보고 다음 주를 알아가는 작업을 합니다. 한 주동안 내가 했던 일과 다음 주에 할 일들을 적으면서 어떤 업무를 했고 해야 하는지, 업무를 하면서 숨겨왔던 나의 수줍은 이야기들을 적습니다. 수줍은 이야기를 할 때는 스크럼 방법론 회고에 자주 쓰이는 다섯 가지 질문으로 합니다.

① 잘한 것은 무엇인가?

② 잘못한 것은 무엇인가?

③ 무엇을 배웠는가?

④ 아직도 풀리지 않은 궁금증은 무엇인가?

⑤ 향후 어떻게 다르게 할 것인가?

실제 제 회고입니다. 무엇을 배웠을 텐데 안 적었던 것 같아요... 아직도 풀리지 않은 궁금증이 많았던 모양입니다...

제가 생각하기에 회고의 이유는 금주에 했던 일과 차주에 할 일을 적어 업무 진척도를 파악하고, 질문에 맞는 속 얘기를 쓰면서 스스로를 돌아보는 동시에 외부에게 알리고 피드백받기 위해서라고 생각합니다. 자기 성찰과 외부 피드백으로 내가 무엇을 놓쳤고, 부족한 점이 무엇이며, 보완이 필요한 점을 알게 됩니다. 이것이 나에게 자양분이 되어 개인 성장으로 이어지죠.

회고는 다른 사람들도 보는 내 사적인 일기장과 비슷합니다. 내 업무, 내 속마음을 쓰면서 나를 돌아보는 동시에 외부에게 이야기합니다. 외부인들(회사 모든 사람 혹은 그로쓰팀)은 내 일기장을 보면서 하고 싶은 말을 댓글로 건네줍니다. 스크럼 회의와 스프린트가 고객과 소통하는 외부 피드백이라면, 회고는 팀과 소통하는 내부 피드백입니다.

제가 느끼기에 저희 팀윙크 회고에서 좋은 점 중 하나는 바비(대표)와 소통할 수 있다는 점입니다. 바비가 자주 외부에 나가고 바쁠 때면 내부 구성원들에게 직접적인 격려가 줄어듭니다. 그런데, 회고를 작성하면 바비가 코멘트를 달아줍니다. 격려와 칭찬을 주로 달아주면서 구성원들 자신감과 유대감을 북돋아 줍니다.(바비 코멘트 보는 맛으로 회고하는 것도 있습니다.)

이 이야기는 바비가 넣으라고 해서 넣은 게 아닙니다. 제가 임의로 넣었습니다.

* 저희 그로스팀은 월간으로 KPT(Keep, Problem, Try)라는 회고 방법으로 즐거운 토론을 나누기도 합니다. KPT에 대한 이야기는 다음 기회에 풀어볼게요.

애자일 방법론, 스타트업이라면 꼭 해야 할까?

지금까지 애자일 방법론이 무엇인지, 팀윙크에서 어떻게 애자일 방법을 하는지를 제가 학습한 지식과 팀윙크 경험을 바탕으로 이야기했습니다. 그렇다면 애자일은 무조건 실천해야 할까요? 제 생각으로는 아니오입니다. 애자일 관련해서 조금 더 공부한 결과, 애자일 방법론은 스타트업들이 실천하는 업무 방법론 중 하나가 애자일 방법론이었습니다. 워터폴 방법론, 린 방법론, 최근에는 데브옵스 방법론도 사용하고 있었습니다. 애자일 방법론은 선택 사항이지, 필수 사항이 아니었습니다.

애자일 뿐만 아니라 다양한 방법론이 있는 이유는 무엇일까요? 아마도 각각의 방법론에 적합한 스타트업, 프로젝트가 있어서라고 생각합니다. 방법론은 다양한 상황에서 각각의 상황에 맞게 해결하는 도구이고 그 도구를 누가, 어디에, 어떻게, 왜 쓰느냐에 따라 달라집니다.

예를 들어, 팀 내부에서 해결하는 닫힌 프로젝트라면 위에서부터 아래로 업무가 떨어지는 워터폴 방법론이 적합하고, 고객의 피드백을 지속적으로 반영하여 개선해야 되는 열린 프로젝트라면 애자일 방법론이 적합합니다.

그리고 애자일 방법론의 시초는 소프트웨어 개발 방법입니다. 애자일 방법론에서 확대된 애자일 문화는 몰라도 애자일 방법론은 개발 부서에게만 적합할 수도 있습니다.

저희 팀윙크도 제가 오기 전까지 시행착오를 통해 애자일 방법론의 장단점을 파악하고 실천하고 있었습니다. 애자일 문화를 중심으로 업무 방식과 조직 문화에 적용하고 있지, 때로는 어떤 프로젝트에서는 워터폴 방식과 문화를 사용할 때도 있습니다. 애자일 방법론은 여러 방법론 중 하나 일뿐입니다. 모두가 써서 유행처럼 쓸 필요는 없다고 생각합니다.

다음 장에서는 인턴 타키가 팀윙크 문화로 공부한 '데이터 드리븐'을 이야기할 텐데요. 데이터 드리븐은 데이터를 갖고 노는(?) 사고 방식인데요. 팀윙크가 데이터를 어떻게 가지고 노는지 다음장에 설명해드릴게요. 그럼, 안녕!

그로스팀 회고 쿠키 사진.jpg(회고 압박)