1.4

View in English

1.4 일하는 방식

개요와 동기

“일하는 방식”은 팀이 매일 실제로 어떻게 조율하고, 계획하고, 소통하고, 전달하는지를 말합니다. 일은 어떻게 쪼개집니까? 누가 누구와 언제 이야기합니까? 진행 상황은 어떻게 추적되고, 결정과 지식은 어떻게 흐릅니까?

대부분의 조직은 스크럼, 칸반, 어떤 확장 프레임워크 같은 이름 붙은 방법론을 채택하고, 의식(ceremony)이 그 아래에 있는 가치와 같다고 가정합니다. 그렇지 않습니다. 소프트웨어 전달을 바꾼 방법론들은 무겁고 인수인계에 의존하는 프로세스에 대한 반작용이었습니다. 그 목표는 빠른 피드백, 작은 배치, 권한을 가진 팀이었습니다. 원칙 없이 스탠드업, 스프린트, 스토리 포인트 같은 의식만 채택하면 프로세스의 비용만 치르고 이득은 얻지 못합니다. 화물 숭배(cargo cult) 애자일입니다.

큰 팀에서는 여기서 좋은 의도가 성공하거나 실패합니다. 천 명의 엔지니어가 한 방에 있을 수도, 같은 회의에 참석할 수도, 같은 암묵적 맥락을 공유할 수도 없습니다. 커질수록 회의와 복도 대화보다 글로 하는 소통, 비동기 협업, 가벼운 조율에 더 의존해야 합니다. 규모는 물리 법칙을 바꿉니다. 같은 공간의 여덟 명에게 아름답게 작동하는 관행이 흩어진 여든 명에게는 무너질 수 있습니다. 그리고 이를 고쳐 주겠다고 약속하는 확장 프레임워크는 애자일이 없애려던 바로 그 인수인계와 중앙 집중을 다시 들여오는 경우가 많습니다.

기업과 정부는 이 모든 압력을 최대 강도로 느낍니다. 여러 시간대에 걸쳐 있고, 정규 직원과 계약자와 벤더가 섞여 있으며, 의무화된 단계 관문(stage gate)과 보고를 지니는 경우가 많습니다. 여기서 문서를 먼저 쓰고 비동기적이며 성과에 초점을 맞춘 일하는 방식은 있으면 좋은 것이 아닙니다. 확장되는 유일한 방식입니다. 아래의 권장 사항은 프레임워크를 통째로 들여오기보다 원칙을 맥락에 맞게 조정하는 쪽을, 그리고 크고 분산되고 혼합된 인력이 진정으로 협업할 수 있게 하는 글로 쓰고 비동기적이며 투명한 관행을 선호합니다.

핵심 원칙

  • 의식이 아니라 원칙을 채택하십시오. 관행을 따라 하기 전에 그것이 왜 존재하는지 이해하십시오.
  • 작은 배치와 빠른 피드백이 큰 계획과 긴 주기를 이깁니다.
  • 어울리는 곳에서는 경직된 타임박스보다 흐름(진행 중 작업 제한)을 선호하십시오.
  • 추정은 대화와 계획을 가능하게 하려는 것이지, 거짓 정밀도를 만들어 내려는 것이 아닙니다.
  • 비동기적이고 글로 쓰는 소통을 기본으로 삼고, 동기 시간은 정말 필요한 일에 남겨 두십시오.
  • 누구든 회의 없이 따라잡을 수 있도록 일과 결정을 보이게 하고 문서화하십시오.
  • 수행한 활동이나 활용한 역량이 아니라 전달한 성과에 최적화하십시오.

권장 사항

애자일, 스크럼, 칸반, 린을 맥락에 맞게 조정한다

이것들을 종교가 아니라 도구 상자로 다루십시오. 스크럼의 타임박스 스프린트는 정기적인 계획과 리뷰 주기의 덕을 보는 탐색 작업이 있는 팀에 맞습니다. 칸반의 연속 흐름과 명시적인 진행 중 작업(WIP) 제한은 플랫폼과 운영처럼 예측할 수 없고 끼어들기가 잦은 작업이 있는 팀에 맞습니다. 낭비를 없애고 리드 타임을 줄이는 데 초점을 맞춘 린이 둘을 떠받칩니다. 의도적으로 선택하십시오. 도움이 되는 곳에서는 섞으십시오. 많은 팀이 ”스크럼반“을 운영합니다. 가치를 만드는 관행은 유지하고, 빈 의례가 된 의식은 버리십시오. 어떤 관행이든 시험은 단순합니다. 피드백을 짧게 합니까, 배치 크기를 줄입니까, 명확성을 높입니까? 아니라면 의문을 제기하십시오.

화물 숭배가 아니라 신중하게 확장한다

확장 프레임워크인 SAFe(Scaled Agile Framework), LeSS(Large-Scale Scrum), 대중화된 “스포티파이 모델”은 여러 팀을 조율하겠다고 약속합니다. 회의적인 눈으로 접근하십시오. SAFe는 구조를 가져오며, 포괄성과 교육 생태계 때문에 큰 기업과 정부가 자주 선택하지만, 민첩성을 해치는 무거운 계획, 위계, 인수인계를 다시 들여올 수 있습니다. LeSS는 린 원칙에 더 가깝게 머물지만 실질적인 조직 변화를 요구합니다. 스포티파이 “모델”은 한 회사의 진화하는 문화를 찍은 스냅숏이었을 뿐 템플릿이었던 적이 없으며, 스포티파이조차 사람들이 상상하는 방식으로 운영하지 않았습니다. 조각난 구조에 조율 프레임워크를 덧붙이기보다, 이전 장의 팀 토폴로지를 통해 조율의 필요 자체를 줄이는 방식으로 확장하는 쪽을 선호하십시오.

정직하고 가볍게 추정한다

스토리 포인트와 속도(velocity)는 팀이 자기 단기 작업을 계획하고 상대적 복잡도를 이야기하는 데 도움이 됩니다. 생산성 지표도, 팀 간 통화도, 약속도 아닙니다. 속도를 목표로 삼지 마십시오. 포인트 부풀리기로 악용될 것입니다. 장기 예측에는 처리량을 세고 과거의 사이클 타임 데이터를 쓰는 편이 낫고, 이는 추정치를 합산하는 것보다 더 정확한 경우가 많습니다. 많은 성숙한 팀이 일을 비슷하게 작은 조각으로 나누고 단순히 개수를 세어 추정 오버헤드를 줄입니다. 방법이 무엇이든, 추정은 불확실성 아래의 예측이지 약속이 아님을 기억하십시오. 범위로 전달하십시오.

비동기적이고 문서를 먼저 쓰는 소통을 기본으로 삼는다

크고 분산된 조직에서는 동기 회의가 확장되지 않고, 다른 시간대의 사람들을 배제합니다. 글쓰기를 기본으로 삼으십시오. 설계 문서, 결정 기록, 서면 현황 업데이트, 실시간 대화 없이도 행동할 만큼 맥락을 담은 충실한 티켓입니다. 피할 수 없는 회의는 녹화하고 요약하십시오. 문서를 먼저 쓰는 문화는 다른 시간대의 사람이 온전히 기여하게 하고, 신규 입사자와 계약자가 읽는 것으로 온보딩하게 하며, 오래 남는 기록을 남깁니다. 동기 시간은 진짜 협업, 관계 형성, 모호함을 빠르게 걷어 내는 일에 남겨 두십시오. 회의로 조각나지 않도록 큰 집중 시간 블록을 보호하십시오.

시간대, 계약자, 벤더에 걸쳐 잘 일한다

분산되고 혼합된 인력은 규모에서 표준입니다. 인수인계가 구두가 아니라 글로 쓰이고 완전한 ”팔로우 더 선(follow-the-sun)“을 염두에 두고 설계하십시오. 필요한 동기 접촉을 위해 겹치는 핵심 시간을 몇 개 정하고, 불편한 회의 시간의 고통을 항상 같은 지역에 지우지 말고 공정하게 나누십시오. 계약자와 벤더에게는 글로 된 맥락, 분명한 인터페이스, 공유 도구에 추가로 투자하십시오. 그들에게는 정규 직원이 쌓은 암묵지가 없기 때문입니다. 벤더를 별도의 불투명한 채널로 관리하지 말고 같은 가시적인 보드와 문서에 참여시키십시오. 가능하면 계약을 시간이 아닌 성과를 중심으로 구성하십시오.

장단점

접근 방식장점단점
애자일 (이해관계자와의 상호작용)높은 협업과 가장 빠른 가치신뢰와 유연성이 필요
스크럼 (타임박스 스프린트)규칙적인 주기, 예측 가능한 리듬, 내장된 성찰의식 오버헤드. 끼어들기가 잦은 작업에는 부적합
칸반 (연속 흐름, WIP 제한)유연함. 병목을 드러냄. 운영에 적합리듬이 약함. WIP를 제한하는 규율 필요
SAFe / 무거운 확장 프레임워크구조, 교육, 큰 조직과 정부에 익숙함위계와 인수인계를 다시 들여옴. 민첩성을 질식시킬 수 있음
LeSS / 가벼운 확장린 원칙에 가깝게 머묾깊은 조직 변화를 요구
비동기 / 문서 우선시간대를 넘어 확장됨. 오래 남음. 포용적모호한 주제에는 더 느림. 글쓰기 규율 필요

포괄적인 트레이드오프는 조율 대 자율, 구조 대 적응성입니다. 프레임워크와 동기 조율이 많을수록 속도, 오버헤드, 팀의 권한 부여를 대가로 예측 가능성과 정렬을 삽니다. 프레임워크가 적을수록 많은 팀 사이의 잠재적 불일치를 대가로 속도와 소유 의식을 삽니다. 대부분의 큰 조직에게 최선의 답은 최소한의 공유 주기에 강력한 서면 관행을 더하는 것입니다. 그러면 더 무거운 프로세스로 조율 부담을 관리하는 대신 그 부담을 원천에서 줄일 수 있습니다.

팀과 논의할 질문

  1. 리더십이 확장 프레임워크가 약속하는 예측 가능성을 원한다면, 애자일이 없애려던 인수인계를 다시 들여오지 않고 어떻게 그것을 줄 것입니까? 큰 기업과 정부 프로그램은 감독 기관이 볼 수 있는 예측과 조율을 요구하기 때문에 SAFe 방식의 빅룸 계획과 단계 관문 보고를 의무화하는 경우가 많습니다. 상충하는 고려는 진짜입니다. 리더십은 많은 팀에 걸친 예측 가능성과 정렬이 필요하고, 무거운 프레임워크는 속도, 오버헤드, 그리고 전달을 늦추는 바로 그 인수인계를 대가로 이를 줍니다. 계획 행사와 팀 간 의존성 조율에 업무 주간의 얼마가 사라지는지, 그 행사가 의존성을 제거하는지 단지 드러내는지 같은 증거를 논의에 가져오십시오. 더 강한 수는 팀 토폴로지로 조율의 필요를 줄여 확장하고, 보고는 계획 마라톤이 아니라 살아 있는 보드와 서면 인터페이스에서 충족하는 것입니다. 어떤 조율이 진짜이고 어떤 것이 의식인지 결정하고, 프레임워크의 오버헤드가 아니라 처리량과 사이클 타임 데이터에서 리더십이 필요한 예측을 제공하십시오.

  2. 속도(velocity)가 팀 간 생산성 지표로 바뀌는 것을 막기 위해 실제로 무엇을 하겠습니까? 스토리 포인트는 한 팀이 자기 단기 작업을 계획하는 데 도움이 되지만, 팀 간에 비교되거나 목표로 설정되는 순간 쓸모가 없어집니다. 포인트 부풀리기가 합리적인 반응이기 때문입니다. 큰 조직에서는 속도를 경영진이 비교하는 대시보드로 올리려는 끌림이 강하며, 이는 팀이 의존하는 추정치를 조용히 오염시킵니다. 표류의 증거를 가져오십시오. 시간이 지나며 포인트가 부풀고 있습니까, 팀이 추정을 부풀립니까, 누군가 속도로 순위가 매겨집니까? 팀 밖으로 나가는 어떤 예측에도 처리량을 세고 과거 사이클 타임 데이터를 쓰는 쪽을 선호하고, 추정치는 약속이 아니라 불확실성 아래의 범위로 전달하십시오. 답은 속도가 팀을 떠나지 않으며 팀 간 예측에는 흐름 지표를 쓴다는 명시적 합의를 낳아야 합니다.

  3. “글로 적었다”의 구체적 기준은 무엇이며, 어떤 결정은 여전히 동기 대화가 필요합니까? 문서 우선 기본값은 시간대, 계약자, 벤더를 넘어 확장되는 방법이지만, 아직 모두가 갖추지 못한 글쓰기 규율이라는 실제 비용이 듭니다. 기준을 구체적으로 정하십시오. 티켓에 실시간 통화 없이 행동할 만한 맥락이 담겨 있는가, 결정이 오래 남는 기록에 남는가, 피할 수 없는 회의가 녹화되고 요약되는가? 암묵지가 없는 계약자와 정규 직원이 섞인 기업과 정부 프로그램에서, 서면 맥락은 혼합되고 분산된 인력이 온전히 기여하게 하는 것입니다. 트레이드오프는, 모호하거나 논쟁적인 주제는 동기적으로 푸는 편이 더 빠른 경우가 많다는 점이므로, 그런 주제를 명시적으로 지목해 희소한 동기 시간을 그것에 남겨 두십시오. 글쓰기 습관을 만드는 비용과 불편한 회의 시간의 비용을 누가 지는지 정하고, 항상 같은 지역에 지우지 말고 공정하게 나누십시오.

  4. 각 의식을 오직 피드백을 짧게 하는지, 배치 크기를 줄이는지, 명확성을 높이는지로만 판단한다면, 현재 의식 중 무엇이 살아남겠습니까? 의식은 조용히 쌓입니다. 여기에 스탠드업, 저기에 리파인먼트 세션, 리뷰와 회고와 계획 행사가 더해져, 큰 팀이 그 회의가 뒷받침하려는 일보다 정기 회의에 한 주를 더 많이 쓰게 됩니다. 상충하는 고려는 실제입니다. 한 사람에게는 순수한 오버헤드로 느껴지는 의례가 분산된 팀이 공유 맥락을 쌓거나 막힘을 드러내는 유일한 자리일 수 있기 때문입니다. 증거를 논의에 가져오십시오. 1인당 주간 반복 회의 총 시간, 각 의식의 참석과 참여, 서면 업데이트로는 나올 수 없는 결정이나 신호를 각각이 실제로 무엇을 만드는지입니다. 모든 팀이 부과된 같은 주기를 운영하는 기업이나 정부 프로그램에서는 누적 비용이 막대하므로, 각 의식이 자리를 유지하기 위해 통과해야 하는 명시적 시험에 합의하고, 습관으로만 이어지는 것은 줄이거나 합칠 의지를 가지십시오.

  5. 일이 정체될 때, 실제로 어디에서 기다리는지 알고 있으며, 우리는 흐름을 관리하고 있습니까 아니면 인력만 배치하고 있습니까? 대부분의 지식 노동에서 작업은 실제로 작업되는 시간보다 대기열, 인수인계, 리뷰에서 기다리는 시간이 훨씬 길지만, 팀은 느린 전달에 직관적으로 인원을 늘리거나 더 높은 가동률을 밀어붙여 대응하며, 이는 대기열을 줄이지 않고 늘립니다. 긴장은 진행 중 작업을 제한하는 일이 역량을 놀리는 것처럼 느껴지고, 놀고 있는 것처럼 보이는 사람들이 관리자와 감독 기관을 불안하게 한다는 점입니다. 진실을 드러내는 증거를 가져오십시오. 사이클 타임 분포, 능동 시간 대 전체 리드 타임의 비율, 보드에서 항목이 막혀 있는 곳, 진행 중 작업 제한(동시에 진행 중인 항목 수의 상한)을 시행하면 처리량이 어떻게 바뀌는지입니다. 인력 가동률로 평가받는 큰 조직이나 정부 기관에서 이것은 목표를 모두를 바쁘게 하는 것에서 완료된 일이 계속 흐르게 하는 것으로 재정의하며, 그 전환이 전달 속도의 단일 최대 지렛대인 경우가 많습니다.

  6. 핵심 시간대에 앉아 있지 않은 비정규직, 즉 계약자, 벤더, 본사와 몇 시간씩 어긋난 지역의 사람들을 우리의 일하는 방식은 어떻게 흡수합니까? 규모에서 혼합되고 분산된 인력은 표준이며, 같은 공간의 핵심 팀에 맞춰진 관행은 나머지 모두를 조용히 배제합니다. 비공개 채널로 관리되는 벤더, 암묵적 맥락이 없는 계약자, 근무일이 결정 회의와 전혀 겹치지 않는 지역입니다. 고려 사항들은 서로 당깁니다. 더 촘촘한 서면 인터페이스와 완전한 서면 인수인계는 실제 규율이 들고, 같은 공간의 그룹이 누리는 빠른 비공식 조율을 늦추기 때문입니다. 결정이 내려지는 회의에 일상적으로 누가 빠져 있는지, 시차가 있는 지역이 인수인계를 기다리며 얼마나 자주 막히는지, 벤더가 직원과 같은 가시적 보드에서 일하는지 별도의 불투명한 트랙에서 일하는지 같은 증거를 가져오십시오. 정규 직원, 계약자, 벤더가 많은 시간대에 걸쳐 의무화된 보고 아래 섞여 있는 기업과 정부 프로그램에서는, 글로 쓰고 투명하며 팔로우 더 선 방식의 관행을 전체 인력이 기여하게 하는 기준선으로 다루고, 불편한 시간의 부담을 항상 같은 지역에 부과하지 말고 나누십시오.

분야별 관점

스타트업. 몇 사람과 짧은 런웨이라면 의식 목록을 건너뛰고 가장 가벼운 흐름으로 운영하십시오. 공유 보드, 짧은 서면 일일 업데이트, 동료가 깨어나길 기다리며 막히는 사람이 없도록 문서에 담긴 결정입니다. 첫날부터 글쓰기를 기본으로 삼으십시오. 비동기 습관은 5명일 때 만드는 것이 50명일 때 뒤늦게 이식하는 것보다 훨씬 쌉니다. 몇 년 동안 필요 없을 확장 프레임워크를 채택하지 마십시오. 여러분의 장점은 조율할 것이 거의 없다는 것이니, 그것을 지키십시오.

소기업. 애자일 코치도 전달 관리자도 없고 예산이 빠듯하다면, 정당화할 수 없는 교육과 인증 비용이 드는 구입형 프레임워크보다 기성 관행을 선호하십시오. 일에 맞는 방법론을 하나 고르십시오. 끼어들기가 잦은 서비스 업무에는 칸반, 프로젝트 업무에는 가벼운 스크럼 주기입니다. 단순한 보드와 분명한 티켓으로 충분한데 무거운 도구를 사려는 유혹에 저항하십시오. 희소한 조율 노력을 글로 적는 데 쓰십시오. 그래야 작은 팀이 한 사람의 기억에 인질로 잡히지 않습니다.

대기업. 많은 팀에 걸쳐서는 조율 비용과 일관성이 문제입니다. 최소한의 공유 주기, “글로 적었다”의 공통 정의, 속도를 팀 간 목표로 바꾸지 않고 집계되는 흐름 지표입니다. 인수인계를 다시 들여오는 프레임워크를 덧붙이기보다 팀 토폴로지로 조율의 필요를 줄여 확장하고, 일하는 방식을 일회성 롤아웃이 아니라 증거로 조정하는 것으로 다스리십시오. 감독이 계획 마라톤이 아니라 살아 있는 보드로 충족되도록 인터페이스와 보고를 표준화하십시오.

정부. 조달 규칙, 의무화된 단계 관문, 공적 책임성이 모든 선택을 형성하며, 정규 직원, 계약자, 벤더의 혼합 인력이 요구되는 진행 보고 아래 여러 시간대에 걸쳐 있습니다. 모든 작업이 직원과 벤더 모두에게 보이는 보드에 완전한 서면 맥락을 담고 있는, 문서 우선의 투명한 일하는 방식을 선호해, 현황 보고가 별도의 회의가 아니라 기록에서 곧바로 나오게 하십시오. 벤더 계약을 불투명한 시간 청구가 아니라 성과와 공유된 가시성을 중심으로 구성하고, 서면의 감사 가능한 흔적을 오버헤드가 아니라 컴플라이언스 자산으로 다루십시오.

사례

스타트업. 분산된 여덟 명 규모의 스타트업은 전체 스크럼 의식 목록을 건너뛰고 공유 칸반 보드와 Slack의 짧은 서면 일일 업데이트로 운영합니다. 두 창업자가 서로 다른 시간대에 있기 때문에 첫날부터 글쓰기를 기본으로 삼습니다. 모든 결정이 문서에 남으므로 상대가 깨어나길 기다리며 막히는 사람이 없습니다. 나중에 세 번째 시간대에서 채용했을 때 온보딩은 대부분 읽기이고, 비동기 습관은 변화 없이 확장됩니다. 한 번도 채택하지 않은 관행인 동기 현황 회의는 한 번도 아쉽지 않은 것입니다.

대기업. 한 다국적 은행이 수백 개 팀에 분기별 빅룸 계획을 포함한 확장 프레임워크를 도입했습니다. 서류상으로는 정렬이 개선되었지만 전달은 느려졌습니다. 팀은 프레임워크가 드러냈지만 없애지는 못한 팀 간 의존성을 계획 행사와 조율에 며칠씩 썼습니다. 은행은 방향을 바로잡았습니다. 진짜 필요한 가벼운 팀 간 정렬만 남기고, 팀이 자신의 가치 흐름을 처음부터 끝까지 소유하도록 재구성하고, 대부분의 조율을 서면 인터페이스와 비동기 업데이트로 옮겼습니다. 전달 리드 타임이 줄었고 진을 빼던 계획 마라톤은 집중된 가끔의 동기화로 줄었습니다.

정부. 시민 서비스를 제공하는 한 정부 기관은 한 지역의 정규 직원과 다른 두 지역의 계약자 팀에 걸쳐, 의무화된 진행 보고 아래 여러 시간대에서 일했습니다. 문서 우선의 칸반 기반 일하는 방식을 채택했습니다. 모든 작업이 직원과 벤더 모두에게 보이는 공유 보드에 완전한 서면 맥락을 담았습니다. 지역 간 인수인계는 글로 쓰이고 완전했습니다. 필요한 현황 보고는 별도의 회의가 아니라 보드에서 곧바로 나왔습니다. 이로써 분산되고 혼합된 인력이 지속적으로 협업할 수 있었고, 감독 보고는 부산물로 충족되었으며, 일정을 잡기 어려운 시간대 간 회의에 대한 기관의 의존이 줄었습니다.

비즈니스 사례: 동기, ROI, TCO

경제적 논거는 흐름 효율에 있습니다. 대부분의 지식 노동에서 한 단위의 일이 실제로 작업되는 시간은 전체 리드 타임의 작은 일부입니다. 나머지는 대기열, 회의, 인수인계, 시간대의 틈에서 기다리는 시간입니다. 배치 크기를 줄이고, 진행 중 작업을 제한하고, 동기적 병목을 글로 쓰는 비동기 흐름으로 대체하는 일하는 방식은 그 기다림을 직접 공략합니다. 사람을 늘리지 않고도 더 짧은 리드 타임과 더 높은 처리량을 얻고, 맥락이 신선할 때 피드백이 더 빨리 도착하므로 결함도 줄어듭니다.

도입 비용과 현상 유지 비용을 견주어 보십시오. 문서 우선, 비동기, 린 흐름은 주로 습관의 변화와 글쓰기와 도구에 대한 약간의 선행 투자가 듭니다. 값비싼 라이선스는 필요 없습니다. 반면 무거운 확장 프레임워크에는 교육, 인증, 전담 역할, 대규모 계획 행사의 지속적 오버헤드라는 실제 비용이 따릅니다. 오직 진짜 조율 필요만이 그것을 정당화합니다. 아무것도 하지 않는 비용은 회의로 포화된 캘린더, 배제된 원격 기여자, 결과를 개선하지 않고 시간만 먹는 화물 숭배 의식, 느린 전달로 나타납니다. 리더십을 설득하려면 전달 리드 타임, 배포 빈도, 가치가 낮은 회의로 잃는 업무 주간의 비율을 측정하십시오. 큰 인력에 걸친 흐름의 작은 개선은 큰 역량 이득으로 쌓입니다.

안티패턴과 함정

  • 화물 숭배 애자일: 근본 원칙 없이 의식만 수행하는 것.
  • 목표로서의 속도: 포인트 부풀리기를 부르고 지표의 쓸모를 파괴합니다.
  • 프레임워크 숭배: 맞는지 여부와 상관없이 SAFe나 “스포티파이 모델” 템플릿을 강요하는 것.
  • 약속으로서의 추정: 불확실성 아래의 예측을 구속력 있는 약속으로 다루는 것.
  • 회의 중심 문화: 다른 시간대를 배제하는 동기 통화를 기본으로 삼는 것.
  • 문서화되지 않은 결정: 사람들의 머릿속과 지나간 대화에 갇힌 지식.
  • 벤더 블랙박스: 공유된 가시성 대신 불투명한 사이드 채널로 계약자를 관리하는 것.
  • 가동률 집착: 완료된 일의 흐름이 아니라 모두의 바쁨을 극대화하는 것.

성숙도 모델

  • 1단계, 시작. 프로세스가 그때그때 이루어지거나 화물 숭배입니다. 팀이 원칙 없이 빌려 온 의식을 수행하거나, 공유된 방법 없이 즉흥으로 합니다. 소통은 회의 중심이고 문서화되지 않으며, 결정은 사람들의 머릿속에 있고, 추정은 약속으로 취급됩니다. 분산된 기여자, 계약자, 어긋난 시간대는 구두로 조율되고, 적절한 사람이 자고 있을 때마다 막힌 채로 남습니다.
  • 2단계, 발전. 개별 팀이 스크럼이나 칸반 같은 이름 붙은 방법론을 채택하고 어느 정도 일관되게 따르지만, 관행은 팀마다 다르고 의식은 기계적인 경우가 많습니다. 일부 팀은 설계 문서와 결정 기록을 쓰고 다른 팀은 여전히 회의에 의존합니다. 추정과 조율은 이루어지지만 “글로 적었다”의 공유 기준이 없어 맥락이 여전히 새고 팀 간 인수인계가 무겁습니다.
  • 3단계, 표준화. 관행이 일에 맞게 의도적으로 선택되고 조직 전체의 기대로 문서화됩니다. 최소한의 공유 주기, 티켓과 결정 기록의 서면 맥락에 대한 정의된 기준, 기본값으로서의 비동기 문서 우선 소통, 통제가 아닌 대화를 위한 추정의 사용입니다. 표준이 일관되게 시행되어, 어느 팀의 계약자나 신규 입사자도 읽는 것으로 온보딩하고, 벤더는 직원과 같은 가시적 보드에서 일합니다.
  • 4단계, 관리. 일하는 방식이 가정되는 대신 기준선에 대해 측정됩니다. 팀은 전달 리드 타임, 사이클 타임 분포, 배포 빈도, 처리량, 가치가 낮은 회의로 잃는 업무 주간 비율을 추적하고, 포인트 부풀리기로 속도가 악용되는지 지켜봅니다. 진행 중 작업 제한은 증거에 따라 시행되고, 가동률 대신 흐름이 관리되며, 어떤 의식이 자리를 유지하고 어디에서 대기열이 길어지는지는 의견이 아니라 데이터가 결정합니다. 리더십과 감독 기관에 대한 보고는 이 살아 있는 지표에서 곧바로 나옵니다.
  • 5단계, 오케스트레이션. 조직은 흐름 지표와 회고의 증거로 일하는 방식을 지속적으로 조정하고, 더 무거운 프로세스로 관리하는 대신 팀 토폴로지로 조율의 필요를 원천에서 최소화합니다. 일하는 방식, 전달 지표, 조직 설계가 통합되어 인력, 시장, 규제 환경이 바뀜에 따라 적응합니다. 많은 시간대에 걸친 직원, 계약자, 벤더의 분산되고 혼합된 팀이 매끄럽게 협업하고, 비용에 값하지 못하게 된 관행은 의례 없이 폐기됩니다.

논의를 위한 아이디어

  • 우리의 의식 중 오직 그것이 만드는 가치로만 판단한다면 어느 것을 유지하겠습니까?
  • 우리는 프레임워크를 더해 확장하고 있습니까, 아니면 조율의 필요를 줄여 확장하고 있습니까?
  • 우리의 속도는 계획을 돕는 도구입니까, 아니면 우리가 조용히 악용하는 목표입니까?
  • 회의와 사람들의 기억에만 있는 결정과 현황은 무엇이며, 글로 써야 하지 않습니까?
  • 우리의 동기 회의 비용은 누구의 시간대가 부담하며, 그것이 공정합니까?
  • 계약자와 벤더는 직원과 같은 가시적 흐름 안에서 일하고 있습니까?

핵심 요점

  • 방법론의 의식만이 아니라 그 뒤의 원칙을 채택하십시오.
  • 일에 맞게 애자일, 칸반, 또는 혼합을 고르고, 작은 배치와 빠른 피드백을 선호하십시오.
  • 확장 프레임워크에는 회의적으로 접근하십시오. 프로세스를 더하지 말고 조율을 줄여 확장하십시오.
  • 추정은 대화와 예측에 쓰고, 생산성 목표나 약속으로는 절대 쓰지 마십시오.
  • 크고 분산되고 혼합된 팀이 협업할 수 있도록 비동기적이고 문서를 먼저 쓰는 소통을 기본으로 삼으십시오.
  • 활동이나 가동률이 아니라 성과와 흐름에 최적화하십시오.

참고 문헌과 더 읽을거리

  • David J. Anderson, “Kanban: Successful Evolutionary Change for Your Technology Business”
  • Donald Reinertsen, “The Principles of Product Development Flow”
  • Mary and Tom Poppendieck, “Lean Software Development: An Agile Toolkit”
  • Craig Larman and Bas Vodde, “Large-Scale Scrum (LeSS)”
  • Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate” (delivery metrics)
  • The Agile Manifesto and its twelve principles
  • Henrik Kniberg, “Scaling Agile @ Spotify” (with the caution that it is a snapshot, not a model)
  • GitLab’s public Handbook on asynchronous, remote-first working