소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다. extreme programming. Kent Beck.

• 짧은 주기로, 작동하는 소프트웨어(MVP,Minimum Viable Product)를 만들어가면서 커뮤니케이션의 비용을 최소화 하고 이슈사항에 바로 대응하며 개발하는 방식이 애자일 소프트웨어 개발방식(↔폭포수 개발방식(water fall))

잘 이해한 사례

잘못 이해한 사례

• Spotify에서는 개발 기본 단위인 팀을 Squad라고 부른다.(8~12명)

• 스쿼드는 일종의 미니 스타트업으로 특정 기능, 서비스의 기획 개발 출시 등 그 시작과 끝을 책임진다..

• 각 Squad는 커다란 제품의 한 부분을 담당한다.

• Squad 내부에 기획, 개발, 테스트, 배포 등이 가능한 모든 기술과 자원을 갖추고 있다.(Full-stack)

• Squad는 업무 수행 방식 및 팀 구성에 대한 의사결정 권한을 부여받는다. 따라서 보고, 승인으로 인한 업무 지연이 발생하지 않는다.(일하는 방식을 스스로 결정)
  • 임명된 리더는 존재하지 않는다. 다만 Product Owner에게 팀 업무의 우선순위를 정하고, 로드맵을 사업 가치와 기술 관점에서 설정하는 책임이 있다.(의사결정은 모두가 함께)

• Tribe는 같은 관련분야에서 일하는 Squad의 집합이고 필요한 Squad를 키워내는 인큐베이터의 역할을 함.(음악플레이어/ 백엔드인프라 등)

• Tribe Lead에게는 Squad가 성공하기 위해 필요한 자원과 자율성을 충분히 지니고 있는지 확인하고 조치(한 명일수도, 그룹일 수도 있음)

• Tribe는 40여명(권장)~최대150명

• Squad 사이의 업무 종속성(의존성)을 해소하기 위해, 필요에 의해 ‘Scrum of scrum’을 진행한다.

• 규모가 커져서 속도가 느려지고 마찰이 증가하면, 밀접하게 연결된 임무를 가진 두 개 이상의 Tribe를 지원하는 동맹, 즉 Alliance가 형성

기능 중심 조직 구조에서 제품 중심 조직 구조로

1. 기획자와 디자이너 그리고 개발자가 페이스북이란 앱을 만든다고 할 때,

1. 이들은 각자 수행하는 기능 별 팀에 소속

1. 기획자는 기획 팀에서 기획을 하고

1. 디자이너는 디자인 팀에서 전달받은 기획을 기반으로 디자인

1. 그리고 개발자는 개발 팀에서 기획자와 디자이너가 전달한 정보를 기반으로 소프트웨어를 개발

• 뉴스피드 팀, 검색 팀, 채팅 팀 등이 페이스북이란 앱을 만듬

• 각 팀에 프로덕트 매니저와 프로덕트 디자이너 그리고 프로덕트 엔지니어가 속함

• 서로 다른 역할의 구성원이 페이스북 내 각기 다른 콘텍스트의 제품을 담당하여 함께 협업

• Chapter는 한 Tribe 내에 존재하는 같은 직군의 조직. (예를 들어, 웹 개발자 챕터, 테스터 챕터, 백엔드 챕터 등)

• 각 Chapter는 정기적으로 모여서 해당 분야의 전문적인 내용들을 다룬다.

• Chapter Lead는 자신의 Chapter 구성원을 관리한다. (임금, 인력 개발 등의 동적 자원 관리) 그러나 Chapter Lead도 한 Squad의 구성원(실무자)

• Guild는 Tribe를 넘나드는 공통의 관심 분야를 가진 사람들의 커뮤니티라고 할 수 있다. (예를 들어, 웹 기술 길드, 테스터 길드, 애자일 코치 길드 등)
  • 원래 목적은 Tribe간에 전문성 융합이었지만, 발전하여 공통관심사를 지닌 구성원들의 이해공동체가 됨(공예, 사진 길드 등)

• 해당 분야에 속한 구성원은 Guild에 무조건 소속되게 되지만, 그렇지 않더라도 관심이 있는 사람이라면 누구나 참여할 수 있다.

• Guild Coordinator는 Guild의 전반적인 리더 역할을 한다.

• 공개적으로 같은 관심 사항에 대해 토론하고 해결책을 모색한다.

매트릭스 조직과 차이점 구성원들을 가로/세로로 엮어주는 매트릭스 조직과 매우 유사하긴 하나 결정적인 차이가 있다. 일반적인 매트릭스 조직은 같은 직군을 한 곳에 모아서 일종의 Pool을 구성한 다음, 그 인원들을 프로젝트에 필요한 자원으로 할당하고, 같은 직군의 관리자에게 업무를 보고하고 관리받는 형태

폭발적인 성장은 혁신의 속도를 늦춘다. Working Backwards, Colin Bryar

스타트업에서 일하다보면 100명을 기준으로, 주도적이고 기민하던 조직이 눈에 띄게 느려지는 것을 경험할 수 있다. 여러가지 이유가 있겠지만, 의존성의 문제가 꽤 크다. 코드도 업무도 중첩되기 시작하면서 예전에는 독자적으로 넣던 기능 개발에 이제는 '조율'이란 의사소통이 필요해지기 때문이다. https://brunch.co.kr/@dongnyuk2000/27. 도니.

• 직원 규모가 선형적으로 증가 ➡ 의사소통의 수는 대부분 기하급수적으로 증가 ➡ 점점 조직의 속도가 지연
  • 조율하는 일에 많은 시간을 쏟게 되면, 무언가를 창조하는 일에는 시간을 덜 쓸 수밖에 없음

• 의사결정이 여러 조직의 영향을 받아야 하면 영향력을 발휘할 수 없는 직원들은 의욕을 잃어가고, 조직적인 저항으로 인해 혁신 아이디어를 추진할 의지도 사라지게 됨

아마존의 '싱글 스레드 리더십' 조직구조

• '한 사람에게 여러 가지 책임을 동시에 부여하지 않고 오직 하나의 목표에만 집중하도록 하는 것이다. 그리고 해당 목표를 달성하는 일만 전담하는 분리 가능한 자율팀을 이끌도록 한다'

• 오로지 그 프로젝트에만 매달린 관리자와 그 일 외에 아무 일도 하지 않는 싱글 스레드 팀
  • 싱글스레드팀은 자신이 맡은 기능에 명확한 오너십을 가지고 다른 팀에 최소한의 영향을 받으면서 혁신을 추진할 수 있음
  • 다른 팀에 승인 받지 않고 단독으로 변화를 추진할 수 있는지의 여부가 중요
  • 그것이 불가능하다면 더 작은 기능으로 쪼갬

비전은 고집하되, 세부 내용에는 유연성을 가져라 (Be stubborn on the vision but flexible on the details.) Amazon

공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

1. 원활하고 투명한 소통이 가능한 조직 크기로 한정한다.

2. End to End(전략 수립부터 실행까지) 의사결정이 단위조직에서 가능한 수준이 되도록 조직의 규모와 업무를 정한다.

3. 불필요한 관리의 단계를 줄이고 수평조직을 통해 상하 소통의 속도를 높인다.

4. 관리자형 리더뿐만 아니라 전문가 리더들이 조직에서 실무 감각을 잃지 않고 플레이 코치로 기능할 수 있도록 한다.

5. 조직의 학습이 자발적으로 일어나며 이를 비즈니스에 적용, 확산할 수 있는 프로세스가 가능하도록 한다.

6. 상위관리자만의 독단적 의사결정이 아니라 다양한 기능의 리더들이 함께 상호작용하도록 한다.

스포티파이의 조직 모델(Spotify Model)

스포티파이 조직 모델 애자일하는 사람이라면 누구나 알고 있는, 그리고 이제는 HR을 하는 분들도 그들의 조직모델의 용어를 자연스럽게 사용합니다. 2012년 스포티파이의 조직구조를 만들었던 헨릭 크니버그는 짧은 pdf에 그들의 이야기를 담아냈습니다. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf 불러오는 중입니다... 그리고 이 문서와 함께 여러 자료들을 공개하였습니다. 그리고 이제 스포티파이 조직 모델은 많은 기업들이 따라하고 싶어하는 그리고 컨설팅사들의 제안에 빠지지 않고 들어가는 내용이 되었습니다. 사실 저도 많이 떠들고 다녔는데요. 생각해보면 저 짧은 pdf 파일도 제대로 읽은 적이 없었네요. 익숙하지 않은 언어 탓을 해보며..

https://humbleagilecoach.tistory.com/15

아마존은 왜 싱글 스레드 리더십을 만들게 되었을까?

순서 파괴 - 콜린 브라이어 | 저번 시간에 블리츠 스케일링을 통해, 조직의 성장 단계에 따라 발생하는 문제들과 경영 관점 변화를 들여다봤는데, 좋은 책이지만 '상호 의존성으로 인한 속도 저하'라는 문제에 대해서는 다루지 않고 있었다. '순서 파괴'라는 아마존 전 임원 콜린 브라이어의 책을 보다가 아마존이 상호 의존성 문제를 풀어낸 방법을 자세히 적고 있어서 알아보려 한다. '싱글 스

https://brunch.co.kr/@dongnyuk2000/27

Spotify’s Failed #SquadGoals

“The Spotify model” got a bunch of companies talking like Taylor Swift about startup culture, but four former Spotify employees reveal the truth: its eponymous way of working failed before it scaled.

https://www.jeremiahlee.com/posts/failed-squad-goals/

애자일이 무엇인가요?

프로그래머가 되고자 하는 분들을 위한 이야기 | 필자의 지인 중에 잘 알려진 IT출판사에서 근무를 하는 분이 계신다. 출판사에서 일하다보니 출판 기획, 저자 섭외 및 관리(?), 편집이나 교정 작업, 출판 등을 비롯하여 책을 만드는 모든 일을 하고 있는 분이시고, 소프트웨어 개발자는 아니다. (그럴 필요도 없다.) 하지만 개발자들을 아끼고 조금이나마 그들을 이해하고자 프로그래밍을 배우고 있으며,  최근에

https://brunch.co.kr/@insuk/5

3장 조직화 : 싱글스레드 리더십

발명에 실패하기 위한 최고의 방법은 그 일을 누군가에게 파트타임 업무로 맡기는 것이다. 속력과 방향을 모두 측정하는 지표 '속도' > - 어떻게 신속한 혁신을 이뤄냈는지, 더불어 관료주의의 유혹은 어떻게 떨쳐냈는지 숱한 질문을 받는다. 비슷한 규모의 회사에서 공통적으로 발견되는 정체 현상을 이겨내고, 모두를 깜짝 놀래킨 민첩함을 유지할 수 있었을까? 답은...

https://velog.io/@wltn39/3%EC%9E%A5-%EC%A1%B0%EC%A7%81%ED%99%94-%EC%8B%B1%EA%B8%80%EC%8A%A4%EB%A0%88%EB%93%9C-%EB%A6%AC%EB%8D%94%EC%8B%AD