3. 기민함에 투자하라
중요하고 촉박한 데드라인이 있다면 이를 만족시킨 후 애자일을 시도하라.
개인 간의 경쟁을 부추기는 모든 형태의 정책은 애자일을 더욱 어렵게 만든다.
작업을 개인이 아닌 팀에 할당하라
애자일에선 실수를 비난하기보다는 학습의 기회로 삼는다.
제품 및 포트폴리오 확장하기
- 수직적 확장: 병목 현상 없이 업무할 수 있는 팀을 늘리는 것
- 수평적 확장: 팀의 책임을 분리함으로써 병목 현상을 제거하는 것
수직으로 확장하기
제품 또는 포트폴리오 오너십을 공유하는 팀의 수를 늘리는 것
'오너십을 공유'한다는 것은 이들이 업무를 수행하는 정해진 영역이 없다는 것
이런 공유된 오너십은 장점이자 단점이 된다. 구성원들이 다양한 코드에 익숙해져야 하며, 가장 큰 문제는 오너십이 1/n로 나뉘는 만큼 책임도 1/n로 나뉘게 된다.
수평적으로 확장하기
대부분의 기업이 선택하는 확장 방식으로 팀이 격리돼 작업하도록 하는 것에 중점을 둔다. 팀마다 특정 부분에 대해 오너십과 책임을 가진다.
팀 토폴로지
- 스트림 정렬 팀: 제품의 고객 접점 또는 고객 그룹에 집중한다.
- 난해한 서브시스템 팀: 특정한 전문 지식이 필요한 시스템 일부를 구축하는데 집중한다.
- 조력자 팀: UX 운영, 보안 같은 특화된 전문 지식을 다른 팀에 제공하는데 집중한다.
- 플랫폼 팀: 조력자 팀과 유사하지만 직접적인 도움보다는 도구를 제공한다. 제공하는 도구를 통해 다른 팀은 스스로 문제를 해결한다.
팀의 책임은 팀이 만들려는 시스템의 아키텍처를 모방해야 하기 때문에, 이는 기본적으로 아키텍처의 문제다. - 역 콘웨이 전략
수평적 확장은 팀의 수가 적을 때 효과적이다. 팀의 수가 적으면 쉽게 모든 구성원의 조합을 이해하고 업무를 조율할 수 있다.
애드혹한 조정 방식은 5~10팀 규모에서 효과를 잃기 시작한다. 병목 현상이 발생하고, 일을 너무 많이 하는 팀과 너무 적게 하는 팀이 나타난다.
비 스트림 정렬 팀은 의존성으로부터의 독립을 첫 번째 우선순위로 삼아야한다.
팀워크
최고의 아키텍처, 요구사항 및 디자인은 자기 조직적인 팀에서 나온다. 비즈니스 부분의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
전체 팀
모던 소프트웨어 개발에서는 프로그래밍 스킬, 대인 스킬, 예술적인 스킬, 기술적인 스킬을 모두 갖춰야한다. 그렇지 못하면 팀의 성과는 저하되고 특정 피처 또는 해당 피처를 완료하는 것에 집중하는 일보다 팀원들은 이메일을 보내고, 응답을 기다리고, 오해를 다루는 등의 다양한 태스크를 처리하느라 동분서주하다.
애자일 팀에서는 역할이 아닌 스킬이 필요하다. 기업 역사를 잘 알고 있는 선임 프로그래머는 최고의 PM이 될 수 있다. 뿐만 아니라 애자일 팀은 시간이 지남에 따라 학습하고 성장한다.
고객 스킬
고객, 사용자 및 비즈니스 이익을 대표하는 능력을 가진 사람들을 팀의 현장 고객이라 부른다. 이들은 무엇을 만들어야 하는지 결정하는 책임이 있다.
애자일 팀을 만들 때 가장 어려운 측면은 고객 스킬을 가진 사람들을 찾는 일이고 이는 제품의 가치를 증가시키는 데 필수적이다.
프로덕트 매니지먼트(프로덕트 오너십)
프로덕트 매니지먼트 스킬을 보유한 팀원들은 이해관계자와 협업하면서 팀이 무엇을 만들어야 하는지, 왜 그것이 중요한지, 그리고 팀이 누구의 필요를 만족시켜야 하는지 찾아낸다. PM들은 제품에 포함해야 할 대상에 관한 어려운 트레이드 오프 결정을 내리기 위해 조직 차원의 권한을 가져야 한다.
많은 기업은 PM을 매우 적게 배치한다. 이는 예측 가능한 작업을 하는 느리게 움직이는 팀 체제에서는 작동하겠지만, 일반적으로 팀이 잘못된 것을 만드는 데 시간을 낭비하게 한다.
PM은 스킬이지 사람이 아니라는 것 역시 기억하라.
도메인 전문성
대부분의 소프트웨어는 특정 산업군에 속해 운영되며, 각 산업군은 비즈니스 수행을 위해 특별한 규칙을 가진다. 팀에서는 이를 잘 아는 사람이 필요하다. PM은 이해관계자와 많은 시간을 할애하지만 도메인 전문가는 팀과 더 많은 시간을 보낸다.
사용자 경험 디자인(인터랙션 디자인)
UI는 제품의 얼굴이다. 사용자들은 오로지 UI에 대한 인식으로만 제품을 평가한다.
UI 정의 업무는 UT, 사용자 페르소나 생성, 사용자와 프로토타입 검토 등을 포함한다.
개발 스킬
고객 스킬이 무엇을 할지 파악하는 것이라면, 개발 스킬은 어떻게 할지 파악하는 것이다.
프로그래밍, 디자인 아키텍처
운영 환경에서 소프트웨어를 쉽게 배포하고 관리할 수 있또록 계획하고, 결함을 예방하는 데 필요하다.
테스팅
비판적 사고 스킬을 통해 고객이 제품을 구상할 때 모든 가능성을 고려하도록 돕는다. 대부분의 팀과 달리 전달하기 팀에서의 테스팅은 버그를 찾기 위한 철저한 테스팅과 관련이 없다. 대신 팀의 나머지 구성원들이 버그가 거의 없는 코드를 자체적으로 만들 것으로 예상한다. 버그가 빠져나오면 팀은 습관을 바꿔 이런 유형의 코드가 이후에 다시 발생하지 않도록 돕는다.
코칭 스킬
애자일을 처음 접하는 팀은 많은 것을 학습해야 한다. 애자일 프랙티스를 적용하는 방법은 물론 효과적인 자기 조직화 팀으로써 함께 일하는 방법도 학습해야 한다. 코칭 스킬을 가진 사람들은 팀이 효과적인 애자일 팀이 되는 방법을 배울 수 있도록 돕는다.
일반화된 전문가
애자일 팀은 generalizing specialist라 불리는 T자형 인재로 구성돼 잇을 때 가장 잘 작동한다. 이들은 병목 현상을 방지할 수 있다. 비 애자일 조직은 필요한 시점에 필요한 전문가를 배치하기 위해 복잡한 방법을 사용하지만 이는 잘 동작하지 않고 예측이 맞기도 쉽지 않다.
비 애자일 조직에서는 FE와 BE가 있을 때 어떤 때는 FE의 작업만 많으면 BE는 아무것도 못하고 있을 수도 있다. 일반화된 전문가는 이런 병목 현상을 피할 수 있다. FE가 많을 때는 FE 전문가들이 주도하고 BE는 이를 돕는다. 이는 단순히 프로그래밍의 문제가 아니라 팀이 직면할 수 있는 병목 현상이 무엇이든 팀원들은 기꺼이 참여해 서로 돕는다.
팀을 처음 구성할 때는 구성원들이 모두 일반화된 전문가일 필요는 없다. 이는 능력보다는 태도의 문제다. 모든 전문가는 자신의 전문성과 가까운 영역에 기여하는 것을 배우는 것에는 문제가 없다. 팀원을 선택할 때 그들이 자신들의 전문 영역을 벗어난 태스크를 기꺼이 돕고자 하는 의지가 있는지 확인하라.
팀 구성하기
팀에 필요한 모든 스킬을 보유하는 한 팀에서의 정확한 역할이나 직책은 중요하지 않다. 팀에서의 직책은 조직의 전통에 관련된 것일 뿐이다.
완전한 전담 팀원들
높은 성과를 보이는 팀원든 팀에 온전히 헌신한다. 구성원들을 여러 팀에 동시에 할당하는 단편적인 할당은 끔찍한 결과를 낳는다. 단편적인 작업자들은 팀에 깊이 관여하지 않으며, 대화에 참여하지 않을 뿐만 아니라 질문에도 대답하지 않는다.
안정된 팀
팀이 효율적으로 협업하는 방법을 배우는 데는 몇 달이 걸릴 수도 있다. 프로젝트마다 팀을 생성하고 해체하는 것 보다 유지하는 편의 낭비가 훨씬 적다. 팀의 제품이 수명을 다하더라도 해체하지는 말라. 대신 팀에게 새로운 미션을 부여하라.
팀 규모
한 팀의 규모를 3~20명으로 권장한다. 대부분의 팀에서 프로그래밍이 첫 번째 병목 현상을 일으킨다. 그러므로 팀 규모를 생각할 때는 각 팀이 프로그래밍에 소요되는 시간을 고려하는 것부터 시작해야 한다.
- 고객스킬: 프로그래머 3명당 1
2명의 현장 고객을 지원한다. 시간의 1/41/2를 프로덕트 매니지먼트에 이용한다. - 테스팅 스킬: 팀이 전달하기 플루언시를 달성하지 못했다면 프로그래머 2
4명당 한 명의 테스터를 지원한다. 달성했다면 48명이 테스터 1명을 지원한다. - 운영 스킬: 제품 환경 특성에 따라 0~2명의 인력이 필요하다.
- 코칭 스킬: 1~2명의 코치들은 시간을 나눠서 다른 팀과 협업한다.
동료들의 팀
구성원들은 자신의 전문 분야에 대한 최종 결정권을 갖는다. 예를 들어 프로그래머는 제품 우선순위에 대한 고객의 의견을 무시할 수 없고, 고객은 기술적 필요성에 대한 프로그래머의 의견을 무시할 수 없다. 또한 중요한 결정을 주도하는 시니어 팀원이 있지만, 팀 안에는 보고 구조가 없다.
이것은 자기 조직화 팀이 되는 데 매우 중요하다. 자기 조직화 팀은 주어진 작업을 주도할 사람을 스스로 결정하는데, 이것은 어려운 결정이 아니다. 구성원 서로를 잘 아는 팀은 주도할 사람을 자동으로 결정한다.
고성과 애자일 팀에서 전달하기 어려운 점은 그들이 얼마나 즐거워하느냐다. 애자일 개발 선언문 작성자 중 한 명인 브라이너 매릭은 '즐거움'이 또 다른 애자일의 가치라고 말했다. 훌륭한 애자일 팀은 자신들이 어떤지 느낀다. 이들은 낙관적이고 열정적이며 진정으로 함께 일하는 것을 즐긴다. 탁월함을 추구하지만 지나치게 진지하지만은 않다.
팀 룸
팀 룸은 팀이 함께 작업하고 협업하는 물리적 또는 가상의 장소다. 한 연구에 따른 함꼐 앉아 있을 대 생산성이 두 배로 증가하고 시장 출시 시간 역시 회사에서 세운 기준의 거의 1/3 수준으로 단축된다는 사실을 발견했다.
팀 룸의 최대한 활용하려면 전체 팀이 있어야 한다. 팀 룸 밖으로 자주 이동하는 PM과 같은 인원들은 팀 내 다른 사람이 자신의 역할을 대신할 수 있도록 확인해야 한다.
항상 질문하고 항상 도우라
문제가 해결되지 않는다면 팀원에게 도움을 요청하라. 그리고 팀원을 도울 때 개인의 생산성이 좋지 않을 것이라고 걱정하지 마라. 개인의 생산성은 낮아질 수 있지만 애자일은 팀에 관한 것이다. 아낀 시간보다 더 많은 시간을 쓰게 되더라도, 팀의 전반적인 생산성은 더 높아질 것이다.
필요할 때마다 들르라
팀 룸을 사용하면 회의 시간을 훨씬 줄일 수 있다.
시각화하라
사람들은 의사소통할 때 자신만의 멘탈 모델이 있다. 이 모델이 너무 다를 때 오해가 발생한다.
이를 방지하기 위해서는 내부 모델을 외부 모델로 바꿔야 한다. 모든 사람들이 볼 수 있는 시각적 형태를 만들면 좋다.
동의를 구하라
일방적인 결정은 사람들을 차단한다. 다수결은 소수를 실망시킨다. 합의에는 너무 많은 시간이 걸린다.
대신 동의 투표를 사용하라.
- 동의한다: 1
- 그룹의 결정에 따른다: 0
- 동의하지 않고 그 이유를 설명하고 싶다: -1
실수로 사람들을 압박하는 것을 방지하기 위해 모든 사람이 셋을 센 뒤에 동시에 표를 공개하라.
물리적 팀 룸
비대면 기술의 발전에도 불구하고 대면 커뮤니케이션은 여전히 팀의 협업에 있어 가장 효과적인 방법이다.칵테일 파티 효과에 따르면 사람들로 붐벼 시끄러운 상황에서도 자기 이름이 들리면 알아들을 수 있다. 사람의 두되는 방에서 일어나는 모든 대화에 주의를 기울이고 있다.
안전감
구글에서 탁월한 팀과 그렇지 않은 팀은 어떤 특성을 갖는지 내부 조사를 했는데, 팀 구성, 업무 외 사교 활동, 외/내향성, 동일/원격 근무, 연공서열, 개인 성과 이들은 모두 효율성을 만드는 데 큰 차이가 없었다.
중요한 것은 심리적 안전감(Psychological Safety)이다. 이 느낌이 높은 팀이 퇴사율이 적고, 팀원의 다양한 아이디어를 활용할 가능성이 더 높고, 더 많은 수익을 가져오며, 경영진에게서도 효율성이 2배 더 높다고 자주 평가를 받았다.
심리적 안전감은 경력이나 직책, 자기 이미지와 관계없이 부정적인 결과를 두려워하지 않고 스스로를 지킬 수 있는 능력이다. 또한 아이디어를 제안하고 질문하고, 우려를 제기하고, 처벌이나 굴욕 없이 실수할 수 있는 능력이다.
안전감을 높히는 방법
- 체크인으로 회의를 시작하라
- 대규모 토론을 2~4인 소규모 그룹 토론으로 나눠라
- 실수에 대해 열린 마음을 가져라
- 호기심을 가져라
- 피드백을 주고 받는 방법을 학습하라
- 공감을 사용하라
목적
팀원들은 무엇을 해야되는지는 듣지만 왜 해야 하는지, 회사의 목표 달성에 어떻게 도움이 되는지 듣지 못한다.
- 비전을 만들라
- 목적을 식별하라
- 목적을 문서화하라
- 목적을 차터링하라
- 목적을 홍보하라
- 목적을 이터레이션하라
활력 넘치는 업무
활력 넘치는 업무란 전문가들이 비록 어려운 상황에서도 일을 해낼 수 있지만, 활력과 동기가 부여되면 가장 생산적인 일을 한다는 인식에 관한 것이다.
활력을 얻는 방법
- 매일 정시에 퇴근하고, 운동하고, 수면하라
- 페어 프로그래밍을 하라
- 건강에 좋은 음식을 먹어라
- 업무 중 실수가 많다면 휴식을 취할 때다