최근에 (주)도칸웍스의 첫 서비스 기획을 시작하며 유저 스토리를 사용하다보니, 애자일 스크럼 도입을 고민하게 되었습니다. 예전의 성공과 실패 경험을 공유하고 애자일이 여전히 효과적인 개발 방법론이 될 수 있는 이유와 이를 어떻게 적용할 것인지에 대해 고찰해보겠습니다.이번 회사의 개발 방법론도 애자일 스크럼일까?
(주)도칸웍스를 창업한지 한달이 지났습니다. 이제 첫번째 서비스 기획을 시작하고 있습니다. 개인적으로 가장 편한 방법인 유저 스토리 형태로 요구사항 정리를 하고 있다보니 우리 회사의 개발 문화가 애자일 스크럼이 되어야하나 고민을 하게 됩니다.
예전 창업에서 애자일 스크럼의 성공 포인트
10년 전 JANDI 를 공동 창업했을 때, CTO로서 채택했던 개발 문화의 근간이 애자일이었습니다. 돌이켜보면 개인적 욕심이 많이 들어간 결정이었죠. 직장인 시절에 여러가지 이유로 도입조차 시도하지 못했던 ‘실리콘밸리에서 핫한 문화’에 대한 동경이랄까요? 그래도 도입의 결과는 상당히 만족스러웠습니다. 회고와 스프린트 결과 공유회는 지금도 좋은 기억으로 남아있는데, 특히 회고는 제가 회사를 나오기 전까지 단 한 번도 놓치지 않은 문화였습니다. 그 경험은 “경영자로서 피드백을 수집하는데 회고만큼 효과적인 것은 없다”라는 강한 믿음을 가지게 만들었습니다. 물론 회고를 하는 방법을 참여자 모두가 학습할 필요가 있다는 건 많은 시행착오 끝에 얻게 된 교훈이기도 합니다.
그리고 스프린트 결과 공유회가, 처음의 우려와 달리, 개발본부 구성원들에게 건설적인 동기가 된다는 것도 깨달았습니다. JANDI에는 스프린트가 끝날 때마다 그 결과로서 배포 가능한 기능을 비개발 본부와 공유하는 문화가 있었습니다. 이런 공유회가 아직도 기억에 남는다는 옛 동료들의 감상을 들을 때마다 그 때의 결정이 틀리지 않았다는 용기를 줍니다.
애자일 스크럼의 실패 요소
물론 모든 것이 완벽하지는 않았습니다. 가장 뼈아픈 경험은 추정에 대한 스크럼 구성원의 거부감인데요, 끝까지 이를 해소하지 못했습니다. 추정을 마감기한으로 받아들이지 않도록 사려깊은 해결책들이 필요합니다. 스토리 포인트나 티셔츠 사이즈 등의 방법을 좀 더 진지하고 꾸준하게 도입하려 노력하지 못했습니다. 또한 스크럼 내부보다 외부에서 이 추정 지표를 마감기한으로 잘 못 인식하지 못하도록 학습시켜야 하는데, 제가 매니지하는 개발 본부 밖의 사람들을 강하게 드라이브 하는 것이 현실적으로 쉽지 않았습니다.
애자일 스크럼, 옛날엔 핫했는데 요즘엔 왜?
도입을 위한 리서치를 다시 해보니 예전과는 달리 요즘엔 애자일 스크럼에 대한 인식이 영 좋지 못하더군요. 왜 그럴까요?
개나소나 애자일이었지
하긴 10년 전부터 ‘애자일 문화’라는 단어는 ‘수평적 문화’와 함께 스타트업계의 필수 단어인 것 마냥 모든 구인공고에 한자리를 차지하고 있었습니다. 요즘엔 되려 이 단어가 시대에 뒤쳐진 회사라는 이미지를 주기 때문에 빼버리는 추세라고 하니 정말 격세지감입니다. 그 당시엔 많은 회사들이 애자일과 거리가 먼 조직을 가지고 있는 걸 업계의 많은 사람들이 알고 있음에도 불구하고, 채용에 도움이 되기에 약팔이를 멈추지 않았던 기억이 있네요.
시장에 만연해진 가짜 스크럼 마스터들
그리고 뭔놈의 스크럼 마스터들이 그렇게도 많았나 싶습니다. 애자일 자체가 어느새 비즈니스가 돼버리자, 이로 인해 탄생한 강연을 몇 개 수강하고, 책 몇 권 읽은 후, 출처도 모를 사짜 자격증을 내걸고 활약하는 가짜 스크럼 마스터들이 잔뜩이었습니다. 전 그들이 바닥에 ‘다크 애자일’ 인식을 만들어냈다고 봅니다. 진지한 고찰과 헌신적인 실행을 해본 경험도 없이 메뉴얼에서 가져온 도구들만 잔뜩 발라 안 하느니만 못한 결과를 내놓고 빤쓰런한 사례를 무수히 듣고 보았죠. 물론 신기루 같은 유행이 지나감과 동시에 이들도 OKR 같은 다음 유행어로 바람처럼 행적을 옮겼습니다.
달은 관심 없고 손가락만 보는 경영진
저 역시 첫 번째 창업을 엑싯한 이후, 조직의 프로젝트 리드나 경영진으로 일할 때는 애자일 방법론을 성공적으로 안착시키기가 쉽지는 않았습니다. 이유는 의외로 간단한데, 의사 결정권자들이 애자일은 커녕 개발 방법론 자체의 필요성을 공감하지 못했기 때문입니다. (혹은 전혀 관심이 없다던가요.) 제가 프로젝트 리드일때는 경영진이, 경영진일때는 대표가… ‘나는 관심없고 니가 알아서 해’라는 자세를 취하면 고난의 행군이 시작됩니다. 진짜 알아서 하고 있으면 ‘그건 니 권한이 아니야’라고 말하기 일 수였어요.
개발 방법론은 개발본부에만 존재해서는 안됩니다. 특히 IT 기업에서는 개발 방법론이 결국 사내 문화의 뿌리가 될 수 밖에 없습니다. 도입 결과에 대한 전적인 책임을 피력하고 전권을 가져오지 못한다면 성공적인 안착은 쉽지 않습니다. 가장 쉬운 방법은 전적인 책임을 가지고 전권을 가질 수 있는 포지션에 있으면 됩니다. 제가 대표이기 때문에 이번엔 이런 고민을 하지 않아도 되더군요.
관짝에 못을 박아버린 스포티파이
결정적으로 스포티파이가 만들어낸 이 바닥에 전설적인 문서, Scaling Agile 백서가 “사실은 구라”로 밝혀지면서 이 유행의 마침표를 찍지 않았나 싶습니다. 그들이 만든 백서는 전설적인 평판을 가졌고 많은 스타트업에게 교과서같은 역할을 했습니다. 후에 폭로되길, 그들 자신도 백서의 내용이 실제로 동작하는 완성된 개념이라고 믿지 않았다고 합니다. 자신들이 광고하는 문화가 정작 스포티파이 내에서는 실패하고 있었던거죠. 하지만 채용에 도움이 되기 때문에 이를 숨겼습니다. 이 희대의 사기 행각이 애자일 스크럼 자체의 평판을 나락으로 보내버렸다고 봅니다.
“내가 스포티파이에서 딱 하나만 고치고 싶었던 걸 고르라면, 자율성을 너무 강조하지 않았어야 한다는 것.”
스포티파이의 Agile Coach, Joakim Sunden
그럼에도 한 물 간 유행을 다시 쓰려는 이유?
우리에겐 여전히 효과적일 것이다
그럼에도 불구하고 저는 자문합니다. ‘회사가 작을 때는 애자일 만한 방법론이 있을까?’ 애자일은 작은 조직이 견고하고 일관된 문화를 가질 수 있는 가장 쉬운 북극성일 수 있습니다. 위에서 언급한 스포티파이조차 작은 풀스택 조직일 때는 그들의 방법론이 아주 잘 동작했다고 전해집니다. 최소한 대표인 제가 프로덕트 오너이자 스크럼 마스터를 하는 동안에는 애자일 스크럼이 잘 동작할 수 있다고 믿습니다.
Steady agile
그러기 위해서는 “협업은 학습이 필요한 기술”이라는 기조를 유지하면서 ‘스프린트의 성공을 어떻게 정의할지’, ‘자율성과 책임의 관계를 어떻게 조율할지’를 개선해나가야 합니다. Basecamp의 Shape Up처럼 필요하다면 우리만의 방법론으로 대대적인 변경을 취해야할 수도 있겠습니다. 그렇게 되면 언젠가는 우리의 애자일 스크럼은 애자일 스크럼의 모습이 아닐지도 모르겠군요.
회사의 문화는 정원을 가꾸는 것과 같습니다. 아름다운 정원은 지속적으로 정원을 가꾸려는 정원사의 의지로 만들어집니다. 전 꾸준하게(steady) 기민한(agile) 문화를 위한 정원사가 될 것입니다.
