brunch

매거진 기획자 다이어리

라이킷 17 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 박세호 Jun 06. 2020

Squad,Shape up, 그리고
스타트업의 조직문화

한 번에 나에게 딱! 하고 맞는 정답은 없어요. 지속적인 개선의 과정이죠

최근,

스타트업에서 프로덕트를 만드는 분들에게 "Spotify의 Squad 팀 모델은 실패였다 | GeekNews"라는 글과

이 스크린 샷이 동네방네 슬랙과 페이스북에 넘쳐났었죠. 저도 제가 같이 아이디어를 공유하는팀에 올렸었는데요,

여기서 파생되어 "Shape up"이란 베이스캠프에서 프로덕트 팀이 프로덕트를 만들어 내기 위해 작업하는 방식을 설명한 글들이 여기저기 온 프로덕트를 만드는 분들의 시장에 오르내리는 것들을 볼 수 있었습니다.

라이언 싱어의 Shape Up

그만큼 한국에서 스타트업, 그리고 IT 프로덕트를 만드는 팀들에게 "스포티파이 모델은 애자일 팀과 기능 조직이 목적 조직으로 변모하기 위한 유일한 해결책이야!"라는 말로 많은 관심을 끌었고, 이 방법을 도입하고지 많은 팀들이 해당 방식으로 조직개편을 진행했던 걸로 기억납니다(그 결과가 처참했던 것도 기억이 납니다).

그리고 결과적으로 많은 조직들이 해당 방법을 수행하고 시행착오를 겪으시며 "우리는 애자일한 방식과 맞지 않아." 또는 "이런 건 일어날 수 없는 일이야!"라는 생각을 하시거나, 위에 글을 보시며 "거봐 저런 방식은 맞지 않는 게 맞는 거야 우린 틀리지 않았어!"라는 생각을 하시는 분들이 많을 거라는 생각이 듭니다.

그리고 이글을 보며 가장 걱정스러웠던건 ,Shape up을 읽어보시고, 많은 프로덕트 팀이 해당 방식으로 팀을 재편하려는 움직임을 진행하시고, 모두와의 이야기 없이 새로운 업무 방식을 갑자기 도입을 시도하는 거죠.

그러나, 과연 저 Shape Up이라는 프로덕트를 만드는 방법이 정말로 우리가 프로덕트를 만드는 완전한 대안책이 될 수 있을까요? 전 아니라고 생각합니다.

일전에 이야기드렸듯, 개발 방법론과 애자일은 도구가 아니고, 프로덕트를 만드는 여정의 철학과 길잡이입니다. 그리고 이 방법론은 팀의 철학과 진행에 대한 강한 의지로 발현되고 스스로가 발전하고 개선되는 것이지, 어떤 방법으로 팀을 정형화시킬 수 없습니다. 결국 방법은 시도해 보고 우리가 개선해 나가는 거에요.

간단히 두가지 개발 방법에 대해서 설명을 기반으로 말씀드리자면, 초기 스포티파이가 주장한 스포티파이 모델이나, 새로운 대안이라고 나온 Shape up 구글 모두 사실은 굉장히 비슷한 코어 벨류를 기반으로 업무를 진행합니다.

- 한정된 시간 안에 좋은 프로덕트를 만들기 위해 이루고자 하는 것을 명확하게 정하고(스크럼에서는 Backlog Refinement 또는 Backlog Grooming이라 하고, Shape Up에서는 Shaping이라는 단어를 사용하더라고요.)

- 한정된 시간 안에 작은 팀으로 프로덕트를 만들고

- 이루고자 하는 명확한 주제와 기간 안에서 변화에 맞춰 기민하게 움직이고

- 프로덕트팀이 제품을 만드는 동안 제품을 만드는 동력을 완전히 제어할 수 있는

업무 방식을 강조합니다.

물론 다른 점도 존재합니다. Shape up은

- 앞으로도 하지 않을 가능성이 높은 일들에 시간과 관심을 쏟지 않기 위해 백로그를 관리하지 않고

- 처음 개발을 시작할 때 개발 팀원들의 생각보다는 시니어 그룹의 감과 촉(appetite, 오역이라면 죄송합니다)을 기반으로 작업을 요청해 시작하며

- 제품 개발 이후 회고하고 재확인하는 것보다는 바로 다음 작업(next betting)으로 넘어가는 것에 집중하는

형식으로 일을 진행하게 됩니다.

이렇듯 두 가지의 개발 방식은 사용자에게 가치 있는 제품을 빨리 만들어 낸다 라는 가장 큰 공통가치를 기반으로, 다른 수행 방법을 가지고 진행하는 겁니다(그리고 사실 이런 방법론은 스포티파이 모델뿐만이 아닌 다른 애자일 하게 일하는 방법인 XP, 스크럼, 크리스털 등등에서도 같은 코어 컨셉을 기반으로 일함을 강조합니다. 요건 다음에...). 그리고 적용 방법을 스스로 찾아보고 터득하고 자신들에 상황에 맞게끔 바뀐 것일 뿐 결국 결과적인 코어는 동일해요.

말이 좀 길어졌지만, 이 글들과 다양한 갑론을박 상황에서 가장 말씀드리고 싶은 건

우리 팀에 맞는 방법인지를 알기 위해선 방식을 정확하게 알고 적용하고, 적용 시에는 확실한 가설을 설정 후 검증하며 우리만의 방법을 만드는 게 중요합니다.

아무리 세상 좋은 개발 방법이 있다고 하더라도 지금 팀이 처한 상황과 방향에 맞지 않으면 전혀 소용이 없습니다. 그리고 그 실패는 팀이 못해서가 아니라, 우리가 알고 있는 방향이 잘하는 방향과 다를 수 있는 거예요.

우리의 캔트 백 형도 2018년에 스포티파이는 스포티파이 모델을 따라 하며 성장하지 않았는데 왜 느그들은 따라 하고 있니 라고 일침을 날렸죠

아직 우리가 일을 잘하는 방법을 찾지 못했다면,

어떤 방식을 도입해서 어떤 결과를 언제까지 우리가 하는 방식이 맞는지 확인한다.
어떤 결과를 얻게 되면 지속, 어떤 결과를 얻을 경우 과감하게 스탑을 진행한다.

라는 가설을 설정하고 가설에 대한 검증을 진행하는 것은 매우 중요합니다. 그리고 이런 빠른 시도와 성공 또는 실패가 팀과 비즈니스가 성장할 수 있는 큰 계기가 될 수 있을 거라 생각이 들어요.

우리가 더 가치 있는 프로덕트를 만들기 위해 성장하는 과정에 대해서 궁금하시거나 더 이야기해주시고 싶은 분들은 언제나 댓글로 남겨주시고, 조금 더 자세한 이야기를 나누고 싶은 분들은 "제안하기"나 "seho@feasible.kr"로 알려주시면 애자일과 업무 방식에 대한 디테일한 이야기를 나누실 수 있습니다.

keyword