진정한 애자일 조직으로 거듭나기까지
1년 동안 단계적으로 진행한 조직/프로세스의 변화
지난 글에서 애자일의 철학에 대해 짚어보았는데요, 오늘은 구체적인 프로세스에 대해 이야기를 해보고자 합니다. 특정 프로세스를 도입했다는 것만으로 애자일을 실현했다고 단정짓기는 어렵지만, 분명 애자일 철학을 최대한 실천하는 데 도움이 되는 방법들은 존재합니다.
그 중 특히 조직 구조의 변화가 중요한데요. 저자의 동의를 받아 번역/편집하여 소개하는 아래의 글은 1년 동안 어떤 변화를 통해 진정한 애자일 조직으로 전환했는지에 대한 경험을 담고 있습니다.
기능 자체의 전달에만 집중하는 피쳐 팩토리(Feature Factory)에서 실험을 통해 솔루션을 지속적으로 발견하는 다기능(Cross-functional) 조직으로 전환하기까지, 어떤 과정을 거쳤고 그 결과는 어땠는지 구체적으로 서술되어 있는데요. 단계적으로 애자일 조직으로 전환할 계획이 있다면 참고할 부분이 많습니다.
Going from feature factory to continuous discovery in 1 year — Andrew Jordan Miller
2020.11.23 / 원문 (링크)
프로세스를 변화시키기는 것은 어려운 일입니다. 이미 프로세스가 존재하면, 오래되고 친숙한 방식으로 계속 돌아가고자 하는 관성이 있기 때문입니다. 따라서 변화는 점진적으로 시도해야 오래 지속될 수 있습니다.
변화에는 리스크가 따르지만 그만큼 큰 성과를 만들어낼 수 있습니다. 저희 팀은 1년 동안 분기별로 다음의 과정을 거쳐 지속적인 발견(Continuous Discovery)을 시도하는 애자일 조직으로 전환했습니다. 그리고 그 결과는 성공적이었습니다.
지금부터 각 단계별로 어떤 변화를 거쳤는지 설명하고자 합니다. 단, 이 내용은 애자일 조직 전환 튜토리얼이라기보다 저희 조직에 특정된 프로세스 변화를 다루고 있다는 점을 감안해주시기 바랍니다.
2019 Q4
2019년 말 우리 프로덕트 조직의 모습은 다음과 같았습니다. 협업과 애자일 비슷한것(Agile-things)을 하고 있기는 했었지만, 우리는 각자의 역할에 갇혀있었습니다.
아이디어는 리더십에서부터 엔지니어에게로 한 방향으로 흘러갔습니다. 리더십에서 나온 아이디어가 UX팀을 거쳐 피쳐화되고, 해당 피쳐를 할당 받은 PM은 엔지니어와 함께 개발 계획을 세웠습니다. 이 때 어느 정도 애자일스러운 일이 진행됩니다.
우리는 배포 결과에 따라 이터레이션했고, 아래 그림과 같이 피쳐를 어떻게(How) 설계할지에 대해 어느 정도 애자일하게 협업했습니다. 문제는 무엇(What)을 만들지가 이미 정해져 있었다는 점입니다. 이 프로세스가 무조건 나쁘다는 것은 아닙니다. 이렇게 일하는 방식에는 장단점이 존재합니다.
장점
피쳐를 설계하는 것을 매우 잘하게 되었습니다.
기능을 배포하는 것을 정말로... 매우 잘하게 되었습니다.
단점
엔지니어 리드가 받는 스트레스가 상당했습니다. 한 팀에서 2-3개의 피쳐 개발을 한번에 신경써야 했습니다.
애자일스러워지는 단계에 이르러서는 이미 피쳐가 정해진 상태였기 때문에 방향을 중간에 바꾸기 어려웠습니다.
목표는 생산량(Output)에 초점이 맞춰져 있었습니다. 목표 달성을 위해 이미 정해진 솔루션이 있었고, 솔루션을 얼마나 잘 전달했느냐가 성공의 척도가 되었습니다.
2020 Q1
2020년 시작에 우리는 다기능 프로덕팀(Cross-functional Product Teams)이라는 조직적 변화를 만들었습니다. 이 변화는 프로덕트, 테크 리더와 디렉터에 의해 진행되었는데, 당시 거의 2년 넘게 논의했던 주제였습니다. 그리고 드디어, 우리는 해냈습니다!
우리는 제품 관리자(PM), UX, 엔지니어, QA, 비즈니스 분석가, 고객 담당 매니저를 한 팀으로 구성했습니다. 이 변화를 통해 우리는 1) 팀에 자율성 부여하고, 2) 엔지니어 리드의 스트레스를 줄여준다는 두가지 목적을 달성하고자 했습니다.
이 시기에 우리는 팀 차터(Team Charters)라는 문서를 도입했습니다. 이 문서는 각 팀의 목적, 전략, 비전을 담고 있는데, 다음 세가지 역할을 합니다.
1. 팀이 한 방향으로 움직일 수 있도록 한다.
2. 팀 간의 협력을 강화한다.
3. 리더십에서 팀의 현황을 파악할 수 있도록 한다.
결과
각 팀은 여러 이해관계자의 인풋을 기반으로 팀만의 로드맵을 만들었습니다.
PM, UX, 엔지니어는 초기 전략적 단계에서부터 협력하기 시작했습니다.
더 많은 역할(분석가나 고객담당 매니저)로부터 프로덕트 아이디어가 나왔습니다.
2020 Q2
2분기에는 3가지 변화를 만들었습니다 : 이중 트랙 애자일(Dual Track Agile), 결과 중심의 목표(Outcome-focused goals), 팀 KPI와 지표(Team KPIs and Metrics)
1) 이중 트랙 애자일
지속적인 발견을 위해 제품 발견(Discovery)와 전달(Delivery)을 분리할 필요가 있었고, 이중 트랙(dual-track)은 이를 달성하기 위한 방법이었습니다. 즉, 아래 예시와 같이 제품 발견과 전달 각 트랙의 칸반보드를 따로 구축하고 두 트랙을 동시에 진행하는 것입니다.
유저 스토리는 발견 트랙 플로우를 거치면서 유효성이 검증되거나 우선순위가 조정됩니다. 검증된 유저 스토리는 전달 트랙의 백로그로 이동됩니다.
우리의 프로세스는 이전처럼 일직선으로 흘러가지 않고, 원형적으로 작동하기 시작하며 많은 협업과 아이디어, 데이터의 교류를 만들어냈습니다. 발견 트랙 안에서도 전달 트랙과 마찬가지로 여러 사이클을 거칠 수 있으며, 제품 발견과 전달 트랙 간의 피드백 루프 또한 존재하기 때문입니다.
2) 결과 중심의 목표
결과 중심의 목표는 솔루션 그 자체보다는 결과에 초점을 맞추는 것입니다. 무엇을 만들지가 아닌, 어떤 지표를 움직일지를 목표로 삼습니다. 예를 들면 다음과 같습니다.
- 생산물(Output) 중심의 목표 : 만족도 조사 기능 v1을 배포한다.
- 결과(Outcome) 중심의 목표 : 주간 설문 완료율을 25%로 올린다.
저희는 더 이상 팀에 솔루션을 던지지 않고, 결과 중심의 목표를 기반으로 어떻게 목표를 달성할 것인지는 팀이 알아서 결정할 수 있도록 하고자 했습니다.
3) 팀 KPI와 지표
이미 부서 수준에서 보는 KPI나 지표가 있기는 했지만, 결과 중심의 목표를 측정하기 위해서는 팀 단위의 달성 지표가 필요했습니다. 팀 KPI는 부서 단위 KPI의 선행지표로 설정하는 것이 이상적입니다. 이는 공통의 목표를 향한 팀 간의 협업에 도움이 됩니다. 저희 팀은 목표 지표를 정의하기 위해 북극성 지표(North Star Metric)를 찾는 워크샵을 진행했습니다.
결과
발견 트랙을 통해 많은 아이디어를 구현하기 전에 미리 분석해볼 수 있었습니다.
초기에 아이디어를 여러번 이터레이션해본 뒤에 피쳐를 설계하여 재작업을 줄일 수 있었습니다.
엔지니어들은 발견 단계에 참여해 테스트해볼 만한 프로토타입을 만들기 시작했습니다. 그 결과 디자이너 리소스가 없을 때도 아이디어를 빠르게 검증할 수 있었습니다.
2020 Q3
이 시점에서 우리는 지속적 발견을 빠른 속도로 할 수 있을 만큼 필요한 기반을 잘 닦았습니다. 자율적인 팀이 갖춰졌고, 발견 트랙이 형식화되었으며, 결과를 측정할 지표도 잘 설정되어 있었습니다.
이 분기에 우리는 두 가지 발견 단계를 추가로 도입했습니다 : 빠른 실험(Rapid experimentation)과 디자인 스프린트(Design Sprints)
1) 실험
실험의 목표는 아이디어 검증을 위한 양적 데이터를 얻는 것입니다. 우리는 몇가지 실험의 원칙을 세웠습니다.
1. Ownership : 빠르게 실행하는 것을 목표로 실험에 대한 오너십을 가집니다.
2. Communication : 팀 내부와 팀 간의 의견이 잘 일치될 수 있도록 커뮤니케이션에 공을 들입니다.
3. Iterate & Innovate : 기존 기능이나 실험을 지속적으로 반복 검증하여 혁신을 찾아냅니다.
4. Learn every week : 실험을 통해 매주 새로운 것을 배우기 위해 노력합니다.
5. Purposeful : 팀 KPI와 관련되어 있는 실험을 필요한 기간만 진행합니다.
6. Share results : 다른 팀에도 결과를 공유해 학습하는 문화를 만들고 실험의 가치를 전파합니다.
또한 실험을 성공적으로 진행하기 위해 필요한 역할에 대해서도 정의하였습니다.
- 테크니션(Technician) : 실험을 적용하고 올바르게 작동되는지 확인
- 실험 설계자(Experiment Designer) : 실험 내용, 변수, 타겟, 실험을 통해 기대하는 결과를 정의합니다.
- 분석가(Analyst) : 실험 결과를 측정하기 위한 필수적인 메트릭을 확인. 실험 후 결과를 분석한다.
- 카피라이터(Copywriter) : 실험에 쓰이는 문구를 작성한다.
- 코디네이터(Coordinator) : 다른 팀과 협업한다. 실험을 진행하기 전에 이해관계자에게 실험에 대해 알리고 우려사항이 있을지 확인한다.
2) 디자인 스프린트
디자인 스프린트에 대해서는 이미 책이 존재하기 때문에 자세히 쓰지는 않으려고 합니다. 한 가지 저희가 조금 다르게 적용한 것은 디자인 스프린트 동안 다른 업무가 동시에 진행되기 때문에 스프린트 기간을 1주에서 3주로 늘린 점입니다.
애자일하게 일하는 것은 어렵지만
그만큼의 가치가 있다.
저희 조직은 1년이라는 기간 동안 꽤나큰 변화를 겪었고, 그 결과는 굉장했습니다. 실험을 통해 우리는 기존 KPI를 260%나 높일 수 있었습니다. 정말 놀라웠죠!
지속적인 발견을 시도하는 것은 때로 피쳐 팩토리로 일하는 것보다 훨씬 어렵습니다. 모호함 속에서 일해야 하기 때문입니다. 우리는 다음 세 달 동안 무엇을 만들지 거의 알지 못했습니다. 어떤 방향으로 가야할지에 대한 대략적인 생각을 토대로 성공 지표를 모니터링하면서 빠르게 반복적인 실험을 했습니다.
또한 발견 단계가 포함된 애자일 조직은 더 많은 커뮤니케이션을 필요로 합니다. 장기적으로 무엇을 구현할지에 대한 명확성이 떨어지기 때문에 모든 멤버들과 지속적으로 소통해야 하기 때문입니다.
애자일 조직 안에서 일하는 것이 어렵긴 하지만, 더 재미있고 더 큰 성과를 만들 수 있습니다. 피쳐 팩토리로 일하면 무엇을 만들지 알고 있지만, 피쳐의 성공 여부에 대해서는 크게 신경쓰지 않을 수 있습니다. 하지만 지속적인 발견을 시도하는 조직에서 일하면, 내가 하는 일의 영향력을 지속적으로 측정하고 업무 전반에 대한 오너십을 크게 느낄 수 있습니다. 나아가 동기부여와 직업적인 성취감 또한 높일 수 있습니다.
위 글은 작성자인 Andrew Miller가 Dallas Product Camp에서 진행한 세션을 요약한 내용입니다. 세션 영상은 (링크)에서 보실 수 있습니다.
작성자는 부동산 관련 디지털 솔루션을 제공하는 RealPage에서 일하고 있습니다.
본문에서 이 글의 이야기가 특정 조직의 경험이라고는 했지만, 1) 결과 중심의 목표를 향해 2) 빠른 실험을 하며 3) 자율성을 가지고 4) 지속적인 발견을 하는 5) 다기능 조직은 많은 프로덕트팀에서 보편적으로 도입하고 있는 형태입니다. 국내에서도 쿠팡, 토스, 뱅크샐러드, 지그재그 등 많은 팀에서 다기능 목적 조직과 실험 문화를 도입해 프로덕트를 만들고 있습니다.
노션을 쓰신다면, 이중 트랙 애자일(Dual Track Agile)을 노션으로 진행하기 위한 구체적인 방법을 담은 작성자의 다른 글(링크)도 읽어보시면 좋을 것 같습니다.
