왜 레트로스펙티브가 시간 낭비처럼 느껴질까?

Source: Dev.to

“우리는 $300‑$400를 잡다한 얘기만 하는 데 썼어요.”
— 2시간 세션을 진행한 뒤의 회고 컨설턴트

패턴

스프린트 1: “우리 CI 파이프라인이 느려요.”
스프린트 2: “CI 파이프라인은 여전히 느려요. 아무것도 변하지 않았어요.”
스프린트 3: “에스컬레이션 할 수 있을까요?”
스프린트 4: 아무도 CI 파이프라인을 언급하지 않아요.

다양한 기업, 산업, 팀 규모에서 이 패턴을 수십 번 보았습니다. 구체적인 이슈는 달라지지만 흐름은 동일합니다.

조직 면역

팀이 문제를 식별하면 보통 두 가지 카테고리 중 하나에 속합니다:

• 카테고리 1 – 팀이 해결 가능: 커뮤니케이션 패턴, 코드 리뷰 관행, 내부 프로세스.
• 카테고리 2 – 조직에 의존: 예산, 인원, 인프라, 팀 간 프로세스.

불편한 수치: **70‑80 %**의 의미 있는 문제는 카테고리 2에 해당합니다. 이는 기존 권력 구조에 대한 위협을 무력화하는 조직 면역을 촉발합니다.

진행 오류

애자일 업계는 종종 회고가 제대로 진행되지 않는 이유를 진행( facilitation) 부족 탓으로 돌립니다: 세일보트 포맷, 장점·단점, 심지어 해적 테마 세션까지 시도합니다. 진행 기법은 참여도를 약간 높일 수는 있지만, 팀에게 통제할 수 없는 문제를 해결할 권한을 부여하지는 못합니다.

진행을 비난하는 것은 제안함을 만든 뒤 경영진이 제안을 읽지 않는다고 탓하는 것과 같습니다.

실제로 효과적인 방법

• 통제 범위에 따라 분류

  • 녹색 – 팀이 해결 가능
  • 노란색 – 팀이 영향 미칠 수 있음
  • 빨간색 – 통제 불가

• 녹색 이슈에 시간 집중 – 행동 항목이 현실적인 성공 가능성을 가진 유일한 항목입니다.

• 빨간 이슈는 문서화하고 재논의하지 않기 – 조직 장애 로그를 유지합니다. 인식하고, 로그를 가리키며, 넘어갑니다.

• 전략적으로 에스컬레이션 – 영향을 수치화하고, 비용이 포함된 해결책을 제안하며, 마감일을 설정합니다.

• 해결되지 않을 문제를 받아들이기 – 일부 조직 문제는 리더십에 의해 버그가 아니라 기능으로 여겨집니다.

불편한 진실

회고는 팀이 통제할 수 있는 영역에서 팀 수준의 개선을 위해 설계되었습니다. 조직 차원의 변화를 위한 메커니즘이 아니라는 것이죠. 우리는 개발자에게 애자일이 그들을 권한 있게 만들 것이라고 말했고, 문제를 드러내는 의식을 제공했으며, 그 “권한을 부여받은” 팀을 예산·인력·전략이 세 단계 위에서 결정되는 전통적인 위계 구조에 끼워 넣었습니다.

회고는 압력 밸브가 되었습니다: 권한 없는 목소리의 외형만을 제공한 것이죠. 시니어 개발자들이 조용히 있는 이유는 무관심 때문이 아니라 제한된 영향력이라는 현실에 적응했기 때문입니다.

원문은 agilelie.com에서 처음 공개되었습니다.