핏펫 개발조직의 방향성과 애자일 리더십

스포티파이 애자일 조직의 실패 사례

스포티파이의 애자일 조직은 현재 국내 스타트업에서 가장 광범위하게 알려진 사례라고 생각됩니다. 성취하고자 하는 목적을 중심으로 구성된 Squad와 기능 중심으로 구성된 Chapter는 크로스펑셔널한 매트릭스 조직의 근간을 이루어 줍니다. 혁신을 만들고 급성장시키는 것에 비전을 가지는 스타트업에서는 이런 애자일 조직을 명시화한 방법론을 빠르게 이해하고 받아들일 수 있어서 현재도 많은 조직이 채택을 하고 있고 또 이를 통해 애자일 조직으로 성장해 나갈 것을 기대하고 있습니다.

많이 알려진, 스포티파이의 애자일 조직 모델
  1. 챕터 중심의 매트릭스 관리는 실제로 잘 워킹하지 않았다
  • 스쿼드의 목적이 상당수 오래 지속되었기 때문에 크로스펑셔널하게 운영되기는 어려웠음. 챕터의 중심 역할을 하는 기술적 테크 리드는 스쿼드에 종속되지 않았기에 팀의 구성원 변경이나 새로운 스쿼드를 만드는 것은 사실 제한이 많았음
  • 스쿼드에 소속된 구성원들에게는 단순히 기술 역량을 높일 수 있는 가이드만 필요하지 않았음. 회사생활에 대한 적응과 온보딩, 그리고 적절하게 커뮤니케이션을 하는 것과 스쿼드 내부에서의 업무 일정 조정이 필요한 상황이 빈번하게 발생함에도 스쿼드 책임자인 PO가 테크 구성원의 그런 문제들을 모두 해결할 수 없었음
  • 위의 사례는 전적으로 각 스쿼드의 테크 구성원들을 담당하는 단일 관리자가 없었기 때문임. mini-CEO 역할을 하는 PO에게 mini-CTO 역할을 기대할 수 없었음. PO에게도 기술 및 일정에 대해 의논할 동등한 급의 테크리드가 필요했으나 챕터리더의 역할에는 그것이 빠져 있었음
  • 구성원에게 자율성을 주는 것은 팀 간 업무 프로세스가 서로 제각각이 되는 혼란함을 주었음. 이에 팀 간 협업이 어떻게 이루어져야 하는지에 대한 공통 프로세스를 만들기가 어려워졌고 결국 조직의 생산성을 떨어뜨리게 됨
  • 구성원 간, 팀 간 협업을 함에 있어 기존의 Waterfall이나 관료주의에서 강조하는 명시적인 프로세스가 있어야 함. 협업할 때의 방식이나 우선순위를 조율할 수 있는 기준이 있어야 함
  • 특히 우선순위는 경영진의 방향성에 의해 목표가 얼라인되어 내려와야 하며 그에 따라 스쿼드 내에서의 업무 분배를 우선 고려했어야 함
  • 애자일조직의 역할이 정의가 되었다는 것은 구성원들이 어떻게 주도성을 가지고 일에 대한 책임을 갖고 일하는지에 대한 동기부여를 주진 못했음
  • 구성원들은 입/퇴사로 인해 변경될 수 있고 그에 따른 교육비용이 추가되며 문화적으로 애자일 정신을 받아들이지 못하는 구성원이 항상 존재했음
  • 애자일이라기보다는 Not-Waterfall 적인 업무 진행은 이도저도 아니게 되었음

현재 핏펫 개발조직의 모습은?

저희는 스포티파이의 실폐사례를 먼저 접할 수 있었기에 급진적으로 애자일 조직으로 전환해야 한다기보다 현재 구조에서 점진적으로 필요에 의해 하나씩 바꾸어가는 방법을 취하고 있습니다.

핏펫의 개발조직이 나아갈 방향성 1. Role-driven with Rank-driven

핏펫은 Role-driven 기반으로 Rank-driven이 혼합된 방식으로 의사결정하는 체계를 갖추어 나가려고 합니다.

핏펫의 개발조직이 나아갈 방향성 2. 테크리더의 리더십과 R&R

스포티파이의 애자일 조직 모델은 수평적인 방향성에 과도하게 집중되어 있고 프로세스조차 명확한 가이드 없이 자율성에 의지한 과오가 있습니다. 그 중 협업 프로세스를 명시화하고 스쿼드 간 협업을 위한 프로세스, 그리고 챕터의 적절한 업무 분배를 위해 테크리더의 R&R을 정리해 보았습니다. 저희는 독창적으로 챕터 리더(이하 CL) 외 각 스쿼드마다 테크니컬 리더(TL)를 별도로 두기로 했습니다. CL과 TL의 역할은 아래에 요약해 보았습니다.

  1. 멘토 역할
  • 1:1 미팅을 통해 챕터 구성원의 기술적 커리어에 도움을 주고 기술 자문을 합니다
  • 스쿼드 내 엔지니어 구성원을 배치하는데 주도적인 의사결정을 가집니다. 이를 위해 코드 리뷰, 1:1 면담을 통해 챕터 구성원의 동기부여요소와 역량을 파악합니다.
  • 코드 리뷰 프로세스 설계 및 체계화에 대해 책임을 집니다.
  • 스쿼드 간 기술적 논의를 위한 미팅의 주체 역할을 하여 기술적 의견 불일치나 갈등을 해결합니다.
  • 아키텍처, 코드 퀄리티를 관리하고 엔지니어 구성원의 문서화를 장려합니다.
  • 구성원의 결과물에 대한 품질과 속도가 점진적으로 향상할 수 있도록 지원합니다.
  • 신규 기술의 도입을 검토하고 적용하는데 의사결정을 합니다. 이는 기술로써 장기적으로 더 빠르게, 더 정확하게 회사의 비전을 달성할 수 있도록 돕는다는 목표 아래 실행됩니다.
  • 아키텍처의 현황을 파악하고 개선점을 도출, 방향성을 제시합니다
  • 개발코드의 테스트 프로세스에 대한 정책을 수립하고 구성원에게 제시합니다
  • 빌드타임을 줄이거나 스쿼드 간 공통으로 쓸 수 있는 개발산출물 등 기술적 생산성을 기여할 수 있는 일을 위한 업무 방향을 제시하고 실행될 수 있도록 합니다. 이를 위해 합의 하에 기존 스쿼드의 인력차출을 요구할 수도 있습니다.
  1. 멘토 역할
  • 구성원들에게 스쿼드 내 소속감을 부여하고 회사의 방향과 얼라인된 스쿼드 내 미션을 인지시킵니다
  • 우선순위와 일정, 업무 역량을 고려하여 1: 1 면담을 통한 구성원의 업무를 조율합니다.
  • 구성원의 직무 역량 외 협업자로서 평가를 하며 구성원의 평가를 주관합니다.
  • 스쿼드 내 구성원의 업무를 조율해 적합한 사람에게 적합한 업무가 정해진 기간에 효과적으로 배분되도록 합니다.
  • 백로그의 업무도 필요 시 기술적으로 잘개 쪼개어 구성원에게 분배합니다.
  • 스쿼드 내 엔지니어 구성원의 분쟁을 조율하고 비프로덕트 조직과 기술적 업무에 관해 PO와 협조하여 일정을 조율합니다.
  • 스쿼드 간 업무의 일정을 조율하고 유관 미팅을 주체합니다.
  • 스쿼드 내 개발 산출물에 대한 일정을 개발공수 관점에서 PO와 협의 일정에 반영합니다.
  • 스쿼드 내 기술적 장애물을 규명하고 실행하여 점진적으로 기술부채가 일정에 반영되어 제거될 수 있도록 합니다.
  • CL의 요구사항을 적시에 구성원에게 배분하여 실행합니다.

Ongoing..

앞으로도 저희의 시도는 계속될 것이고 계속 변화할 것입니다. 그리고 그 변화는 구성원과 회사가 동반성장할 수 있는 목표를 위해 이루어질 것입니다. 구성원들이 혼란스럽지 않게 점진적으로 애자일의 본질적인 정신을 추구하기 위해 노력하려고 합니다. 또 한번 멋진 변화와 함께 저희 모습을 공유드리는 날이 오기를 기다리며 글을 마치겠습니다.

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store