애자일 스쿼드 팀의 탄생 일지
우리는 어떻게 애자일 팀을 만들었는가
애자일, 애자일 하는데, 대체 그 실체는 무엇이며 어떻게 도입해야 하는지. 아니 실체는 있는지.
우리 팀이 성장한 이야기와 더불어 한 애자일 팀의 탄생기를 풀어 이야기해보려고 한다.
애자일을 몰랐던 우리 팀
1. 프로덕트팀이 생겼다.
나는 다섯 번째 멤버로 회사에 합류했다.
기획은 대표가 했으며, 정식 프로덕트팀은 디자이너인 나와 개발자-심지어 머신러닝 엔지니어-단 둘 뿐이었다. 초기 비즈니스 모델이 검증된 시점에 회사는 본격적인 프로덕트 개발을 위해 PO와 개발자 한 명을 더 채용했다. 그렇게 우리는 네 명의 프로덕트팀이 되었다.
2. QA 그렇게 하는 거 아니에요.
PO로 오신 분은 애자일 HR 출신의 프로덕트 매니징 경험이 있는 분이었다.
나를 포함해 애자일에 무지했던 기존 팀원들은 워터폴 방식으로 개발한 첫 번째 프로덕트의 QA를 엉망진창으로 하고 있었다. PO는 유저 시나리오에 따라 테스팅하고 버그를 잡는 법을 알려주었고, 버그를 우선순위에 따라 지정하고 우선순위 높은 버그부터 해결하는 프로세스를 만들었다.
3. 이러다 죽겠어요.
그럼에도 우리는 아직 비효율적으로 일하고 있었다.
워터폴 방식으로 빠르게 개발한 세 번째 프로덕트는 불안정했다. 개발자들은 간트 차트의 기간을 맞추기 위해 밤을 새워서 개발을 했다. 가장 일찍 출근하고 가장 늦게 퇴근했다. 그럼에도 버그는 끝없이 발생했고 개선하기 위해 또 끊임없이 야근을 하는 수밖에 없었다. 팀원들은 서서히 지치기 시작했고, 밤을 새웠지만 오히려 효율은 떨어졌다.
효율적인 업무 사이클을 만드는 법
4. 애자일의 유일한 맹점
애자일의 유일한 맹점은 애자일한 리더가 없을 때 그 팀은 절대 애자일 해질 수 없다는 것이라고 한다.
그러나 우리 팀은 애자일한 리더가 있었다. PO는 비효율적인 업무 프로세스를 개선하기 위해 각각의 비효율을 개선할 수 있는 애자일 개발 방식의 요소를 하나씩 가져오기 시작했다.
일정을 맞추기 위해 개발자들은 매일 야근해야만 했고, 정신적으로 또 육체적으로 많이 지쳐있었다. 또 이렇게 야근했음에도 정확히 추정되지 않은 일정 안에서 기획된 모든 기능을 개발해야 하다 보니 품질 높은 개발이 불가했다. 개발할 때마다 지속적으로 버그가 터졌고, 애석하게도 그렇게 완성된 프로덕트에서는 의도한 기능을 정확히 쓰기 어려웠다.
우리는 개발자들이 지속가능한 개발을 할 수 있게 하면서도, 보다 품질 높은 프로덕트를 만들 수 있는 방법이 필요했다. 우리는 포커싱과 우선순위 설정, 정확한 Outcome의 정의가 필요했다.
5. 스크럼을 세팅하다.
1차 론칭 이후 깨달은 것은, 우리 팀에 정확한 추정과 포커싱, 그리고 명확한 우선순위 설정이 필요하다는 것이었다. 추정이 정확하지 않으니 무리한 일정에 맞출 수밖에 없었고 그러니 지속되는 야근 속에서도 완성도 높은 개발이 불가했다. 또 큰 프로덕트의 모든 기능을 산발적으로 건드리며 개발하다 보니 고객에게 핵심적으로 전달해야 할 기능이 구현되지 않는 문제가 있었다. 또 이렇게 개발과 버그 개선이 지속되면서도 우선순위가 명확하지 않으니 먼저 해결되어야 할 이슈들을 처리하지 못해 남아있는 이슈들이 많았다.
우리는 먼저 고객에게 명확한 가치를 제공하기 위해 유저 시나리오에 따른 유저 스토리 단위 개발을 시작했다.
각 기능 구현에 초점이 맞추는 것이 아닌, 유저에게 전달될 가치에 따라 백로그를 쪼개고 개발하기 시작했다. 예를 들면, ’버튼이 클릭되게 만든다‘가 아닌 ’고객이 신청을 완료할 수 있게 한다‘와 같이 고객의 행동에 초점을 맞추어 개발하기 시작했다.
그렇게 우리는 기획안이 아닌, 인수조건과 시나리오에 따라 기획을 전달하고 개발자들과 함께 테스크를 수정해 나가며 효율적이고 효과적으로 개발과 QA를 하기 시작했다. 그렇게 기능이 아닌 유저 스토리에 따른 Outcome에 초점을 맞추어 기획과 개발 플로우를 수정했다.
우리는 지속 가능한 개발과 업무 포커싱에 따른 퍼포먼스 향상을 위해 스프린트를 세팅했다.
기존에 우리는 큰 프로덕트의 기능 전부를 개발하며 포커싱 할 수 없는 업무 환경 속에서 각 기능을 산발적으로 개발했다. 그러다 보니 목표 (혹은 지표에 따른) 팀원들 간의 컨센서스가 안 맞는 문제부터 산발적으로 진행되는 개발덕에 프로덕트의 품질을 챙기지 못하는 이슈까지 다양한 문제들이 발생했다.
우리는 2주 단위로 명확한 목표를 설정하여 개발할 수 있는 스프린트를 도입했고, 2주 동안 동일한 목표를 달성하기 위해 동일한 지점을 보고 달렸다. 2주간 진행할 업무들에 대해서는 스프린트 시작과 동시에 플래닝을 진행하여 각 테스크에 대한 리뷰와 추정을 진행했고, 각 테스크를 우선순위에 따라 정렬했다. 추정치를 기반으로 2주 안에 작업할 수 있는 양을 우선순위에 따라 잘라냈고, 우리는 기간 안에 작업이 가능한 수준으로 2주간의 백로그를 계획했다. 불필요한 야근은 줄었고, 배포와 관련하여 타 팀과의 커뮤니케이션도 원활해졌다.
2주간 우리는 매일 15분씩 데일리 스크럼을 진행하며 각자의 업무에 대해 빈틈없이 공유했고, 그 외에도 수시로 기획과 개발에 대해 논의하며 요구사항을 협의해 개발을 진행했다. 각 테스크는 칸반에서 관리하며 각 단계에서 병목이 생기지 않게 흐름을 관리했다. 2주의 스프린트가 종료되는 시점에 최종 배포를 마치고 회고를 진행했고, 회고에서는 다음 스프린트에 적용해 볼 만한 액션 아이템을 뽑았다. 우리는 뽑힌 액션 아이템들을 다음 회고에 적용하며 지속적으로 업무 프로세스를 개선했다. 우리는 그렇게 우리만의 일하는 방식, 우리만의 애자일팀을 만들어갔다.
6. 그래서 지금 우리는.
그렇게 우리는 끊임없이 우리만의 업무 사이클을 만들어갔다. 비즈니스 상황에 맞게, 또 우리 팀의 상황에 맞게, 회사의 상황에 맞게 지속적으로 프로세스를 디벨롭했다. 그렇기에 지금의 우리 팀은 또 다른 방식으로 일한다.
그 시기 프로덕트팀은 단 4명의 조직이었고, 지금은 13명의 두 스쿼드로 쪼개진 팀이다. 그때 전 직원은 10명 안쪽이었고, 지금은 여러 협업 지점이 있는 부서들이 잔뜩 있는 70여 명의 회사다. 우리는 그때가 아닌 지금의 우리 팀과 상황에 맞는 방식으로, 또 다른 방식으로 일한다.
그럼에도 지금의 우리 팀이 애자일하게 일할 수 있는 이유는 초기에 세팅되었던 팀의 문화와 가치에 모든 팀원이 공감하고 행동해 왔기 때문이다.
애자일은 업무 방식이나 프레임워크가 아니다.
스크럼을 한다고 모두 애자일 팀이 아니다.
그리고 꼭 애자일만이 옳은 것도 아니다.
어떤 방식으로든 효율적으로 성과를 내면 된다.
우리는 그 시기에 그 방식을 택했을 때 성과가 더 잘 날 수 있는, 효율적으로 업무를 할 수 있는 환경이었을 뿐이다.
우리는 앞으로도 계속 변화할 것이다.
그때 상황에 맞게, 최적의 최고의 성과를 낼 수 있는 팀으로.
