2001년 애자일 선언문이 발표되고, 2000년 중후반 한국에서도 애자일 붐이 일었다. 나도 그때 맹신도처럼 XP, 사용자 스토리에 빠져있었지만 대학생인 내가 현실에서 협업을 해본적이 없기 때문에 애자일에 ‘애’자도 이해했을리가 없다. 그때 그게 무슨 말인지 알고, 협업의 중요성을 인지 했다면 아마 전공 수업중에 소프트웨어 공학도 수강 했겠지. 돌이켜보면 코딩만 할 줄 알았지 정말 애송이.. ㅎㅎ
애자일 개발방법론에서 회고는 매우 중요한 이벤트다. 회고 방식도 여러가지가 있다. 그중에서 누구나 한번쯤은 해봤음직한 방법은 이런 방식이다. 프로젝트가 끝나고 회의실에 모인다. 이번 기간에 잘했던 것, 힘들었던 것, 개선하고 싶은 것 등등 시간을 갖고 포스트잇에 쓴다. 벽에 붙은 메모를 읽고 공감가는 곳에 스티커를 붙이고, 적절히 그룹핑하고 이 중에서 더 논의할 녀석을 고르고 논의후에 액션아이템을 뽑아낸다. 그리고 마지막으로 마인드맵처럼 펼쳐진 화이트보드를 기념사진으로 찍고 끝!
이런 방식이 처음엔 신선했다. 하지만 반복되는 액션아이템과 내가 할 수 있는 일보다 누군가는 해줘야하는 일로 액션아이템이 귀결되는 순간부터 의심이 들기 시작했다. 나는 회고를 하고 있는 것인가? 감정을 소화하고 있는 것인가? 이런 회고 방식으로 뭘 바꾸고 싶은것인가? 도대체 회고는 왜하는 걸까? 점점 본질적인 질문을 하기 시작했다.
회고는 왜 하는 것인가?
회고가 개선의 시작이라고 생각했지만, 때때로 회고가 감정 소화의 장으로 변할 때마다 마음이 불편했다. 그래서 회고 방식을 바꾸고 싶었다. 2020년 어느 시점부터는 회고를 준비하며 설문을 만들기 시작했다. 프로젝트를 진행하면서 “이건 아니지” 싶은 것들을 기록해 두었다가 질문으로 변환했다.
질문을 만들 때는 고민이 좀더 필요했다. 실수나 잘못을 인정하는 것도 중요한데 이미 알고 있는 사실이 한번더 언급되면 마음이 편치 않은게 사람 마음이다. 그래서 불편한 감정을 줄이기 위해 사람을 지칭하기보다는 상황을 지칭하는 방식으로 질문을 만들었다. 예를 들면, “작은 팀에서 번아웃된 동료가 있으면 더 힘들다. 만약 우리 팀에 번아웃된 동료가 있다면 어떻게 하겠는가?”
이 질문은 당시 프로젝트 팀과 직접적인 관련이 있지는 않았고, 개인적인 고민에서 비롯된 것이었다. 하지만 이 질문을 통해 꽤 깊은 대화를 나눴던 기억이 있다. 오래된 기억이라 이제는 감정만 남아있지만, 그 때 어린 친구들이 정신적으로 나보다 더 성숙하다는 생각을 했던 것 같다.
질문을 만드는 과정에서는 다분히 주관적인 견해가 들어가기 마련이어서, 사람들의 감정선을 고려하며 균형을 잘 잡아야 한다. 때로는 이런 질문을 만드는 것이 어려울 때도 있지만, 의외로 많은 소득을 얻었던 것 같다. 질문을 통해 종종 팀의 심리적 안전을 확인할 수 있었다. 심리적 안전과 관련된 내용은 다른 글에서 더 자세히 다루기로 하고, 여기서는 이 정도만 언급하고 넘어가자.
아무튼, 회고를 위한 설문은 충분히 회고할 시간을 가질 수 있도록 최소 2시간 전, 길게는 하루 전에 발송했다. 생각할 시간이 충분히 주어져야 깊이 있는 다양한 의견이 수집된다. 처음엔 답변을 모아서 노션에 정리한 후에 회고를 시작했지만, 어느 순간부터 설문을 포기하고 바로 실시간으로 회고를 진행하기 시작했다. 팀원들이 회고방식에 익숙해지고 심리적 안전이 높아질수록 다양한 주제의 이야기가 쏟아진다. 이때부터는 주제가 삼천포로 빠지지 않도록 중심을 잡는 또다른 국면이 펼쳐진다. 개선에 방점이 찍힌 회고라는 것을 팀원들이 인식할수록 액션아이템도 자연스럽게 수집되고 그중에서 합의된 내용은 바로 프로세스에 반영됐다.
점진적 변화를 위한 전략
회고를 통한 프로세스 개선은 개인적으로 몇번의 시행착오를 거쳤다. 한번은 이전에 경험했던 성공적인 프로세스를 복제해 새로운 팀에 이식한 경우인데 대부분 잘 적응하지 못했다. 일반적인 반응은 “복잡하다” 였다. 두번째 방법은 다소 시간이 걸리더라도 일부러 불완전한 상태로 시작해서 함께 개선하는 경우인데, 이 경우엔 대부분 만족도가 높았다. 경우의 수를 두개로 압축 했지만 실제 사례는 더 다양하다. 예를 들면, 새로운 팀원이 합류하거나 아예 프로세스가 없던 팀에서 컨설팅을 요청한 경우도 있었다. 현실의 다양한 변주들도 결국 크게보면 프로세스를 함께 개선할 여지가 있는가? 없는가에 따라서 반응이 갈렸다. 결과적으로 프로세스를 함께 개선하면 팀의 적응력과 팀워크도 함께 좋아진다.
질문을 통한 회고방식도 반복되면 본질은 흐려지고 창작의 고통만 남는다. 경험상 이 방식은 지속하기 어려웠다. 그래서 팀원들이 회고에 익숙해질 무렵 회고 마스터를 순환하자고 제안했다. 그리고 나는 나만의 회고준비를 위해 통계를 들여다보기 시작했다. 보통 3번의 개선 사이클을 돌면 유의미한 적응 효과가 나타나기 시작한다. 이때가 바로 통계를 들여다볼 시점이다.
우리 팀이 얼마나 일을 잘 하고 있는가를 가늠해볼때는 생산성(Productivity), 효율성(Efficiency), 그리고 효과성(Effectiveness) 3가지 측면에서 바라본다. 이와 관련된 자세한 내용은 이글에서 확인하자.
누적흐름도표 이해하기
먼저 이 차트가 어떻게 그려지는지 이해해보자. 누적흐름도표는 칸반보드에 생성된 이슈들이 각 컬럼에 머문 순간들을 스냅샷해서 보여준다. 그래서 X축에 시간, Y축에 이슈의 갯수를 표현하는데 칸반의 왼쪽 열에서 생성된 이슈들이 시간이 흘러 모두 오른쪽에 쌓이기 때문에 누적흐름도표는 우상향으로 증가할수밖에 없는 특징을 가진다.
생산성 확인하기
단순한 그래프 같지만 차트는 아는 만큼 보인다. 먼저 완료된 일감이 누적되는 기울기를 살펴보자. 기울기가 가파를수록 완료된 일감의 수가 많은거고 기울기가 완만할수록 팀의 생산성은 떨어졌다고 말할수있다. 따라서 1번보다는 2번이 2번보다는 3번 시점에 팀의 생산성이 높다.
와! 우리팀은 시간이 갈수록 생산성이 높아지네! 잘했네! 박수~!! 짝짝짝! 하라고 이런 차트가 있는게 아니다. 생산성에 영향을 주는 요인을 알아야한다.
생산성에 영향을 주는 대표적인 요인
- 일감을 처리하는 사람의 수
- 일감의 크기
단순 비교하면 1번보다 3번 시점이 생산성이 높지만 얼마나 효율적으로 일 했는지는 알 수 없다. 팀이 얼마나 효율적인지 비교하려면 일감의 크기와 투입된 사람의 수도 고려해야한다.
병목구간 찾기
누적흐름도표에서 가장 큰 영역을 차지하고 있던 완료 항목을 보고서에서 제외하면 병목을 좀더 쉽게 찾을수있다.
위 예시는 백로그가 급증하고 있음을 보여준다. 백로그와 일감은 차이가 있다.
- 백로그 – 해결해야할 문제들. 백로그로는 일을 할 수 없다. 즉, 일감이 아니다!!
- 일감(할 일) – 실제 개발자가 일할수 있는 적당한 크기로 구체화된 일감
백로그나 일감이 증가하기 시작하면 이슈 관리가 필요해진다. 백로그가 많으면 팀에 일이 많은 것 같은 착각을 일으킨다.
백로그가 쌓이는 대표적인 이유
- 실제 일감으로 구체화 되지 않고 러프하게 만들어진 경우
- 백로그의 의존성이 파악되지 않은경우
- 파악된 의존성이 해결되지 않아 그대로 쌓이는 경우
- 시간이 지나 의미가 없어진 일감을 삭제하지 않은 경우
- 계획없이 만들어 두기만 한 경우
일감이 쌓이는 대표적인 이유
- (팀 케파,처리속도에 맞지 않은) 무리한 일정 계획
- 부족한 실무자 (PM, PD, SE, QA 모두 포함)
- 일감을 실무자가 작성하거나 검토하지 않은 경우
진행중 컬럼에 제약이 필요한 순간
누적흐름도표에서 다른 컬럼을 다 제외하고 개발 사이클 구간만 선택해서 살펴볼수도 있다. 개발팀에서 개발자가 실제 일하는 구간을 세분화하면 코드작성 > 코드리뷰 > 코드병합 세 단계를 거친다.
개발 사이클 타임을 줄이기 위해서는 빠르게 코드를 병합해야한다. 위 그림처럼 개발중인 코드가 많아지거나 리뷰할 이슈가 많아지기 시작하면 전체적인 생산성은 떨어진다. 보통 이런 상황에선 컬럼에 제약만 걸어도 병목이 해소된다.
리뷰가 쌓이는 대표적인 이유
- 여러 버전을 동시에 병렬로 개발하는 팀
- 일감을 적절하게 자르지 않은 팀
- 개발자가 너무 많아서 순식간에 리뷰수가 증가하는 팀
- 개발자가 너무 적어서 리뷰할 여력이 없는 팀
컨트롤 차트 이해하기
컨트롤 차트는 칸반보드에서 생성된 이슈 하나가 완료될때까지 걸리는 전체 산술 평균시간(빨간색)과 기간별로 산출되는 롤링 평균시간(파란색)을 제공한다.
따라서 파란색 롤링평균 시간이 빨간색 기준선보다 밑에 있으면 팀은 효율적으로 일하고 있음을 의미한다. 이런 기본적인 이해를 바탕으로 올해 5월 어느쯤부터 팀의 효율이 떨어지고 있네? 아.. 이 팀은 문제가 있네! 라고 평가를 끝냈다면 당신은 애자일의 “애”자도 모르는 사람임을 고백한것이다.
애자일 선언 이면에 숨겨진 12가지 원칙중에 “가치있는 소프트웨어를 고객에게 지속적으로 전달해서 고객을 만족시키고, 작동하는 소프트웨어를 자주 전달 하라는 내용이있다.” 이 원칙을 현실에서 어떻게 구현할까? 생각해보면 단순하다. 고객이 원하는 적합한 일(피처)을 잘 선별하는 작업이 우선 필요한데, 선별 과정은 이 글의 목적을 벗어나기 때문에 일단 논외로하자. 이제 선별된 일을 빠르게 릴리즈하는 방법만 남았다. 이 문제를 피자가게 메타포로 바꿔보자.
고객이 먹고 싶은 피자를 고르고 앱에서 주문을 했다. 그럼 피자 가게에서 주문을 확인하고 피자를 만들기 시작한다. 완성된 피자는 포장되어 배달원을 거쳐 고객에게 전달된다. 고객이 주문에서 피자를 받기까지 걸린 총 시간을 리드타임(Lead Time)이라고 부른다. 그리고 주문을 받고 실제 피자를 만드는 일을 프로세스 타임 혹은 사이클 타임(Cycle Time)이라고 부른다. 여기서 배달원이 배달하는 시간은 또 다른 사이클이다. 수식으로 표현하면 아래와 같다.
그런데, 주문이 폭주하기 시작했다. 여기에 비도 오면서 배달이 늦어지는 상황을 생각해보자. 화덕이 하나인 피자가게는 주문을 감당하지못해 생산하기위해서는 대기해야하는 시간이 존재한다. 배달도 마찬가지다. 생산된 피자를 배달원에게 전달하고 싶은데 배달원을 구하는 것도 시간이 걸리기 시작했다. 이 상황을 수식으로 표현하면 아래와 같다.
다시 제품개발로 돌아와서 빠르게 릴리즈하는 방법을 단순화하면 바로 리드타임을 줄이면 된다. 우리가 성능을 개선할때도 병목을 찾아서 해결하듯이 현실에서 리드타임을 줄이는 일도 병목을 찾아 대기시간을 없애는게 가장 효과적이다. 왜냐하면 현실에서 사이클 타임은 0으로 만들수없지만 대기시간은 0에 가깝게 만들수있기 때문이다. 피자가게의 사이클 타임을 줄이려면 숙련자를 채용하거나 화덕의 갯수와 함께 피자 만드는 사람을 더 늘려야한다. 하지만 사이클 타임 개선은 비용도 들고 주문 폭주가 이어지는 상황이 아니라면 되려 고정비 지출만 늘리는 셈이 된다. 그만큼 사이클 타임 개선은 쉽지 않다. 숙련공을 채용하는 것과 숙련공으로 성장시키는 일중에 무엇이 더 쉽고 장기적으로 이득인지도 잘 따져봐야한다.
리드타임과 사이클타임 구분하기
우리는 제품 개발 과정 안에서 다양한 직군과 협업하지만 통상적으로 가장 병목이 되는 자원은 개발자임을 부정하긴 어렵다. 따라서 개발자원은 특별히 더 신경써서 관리되어야한다. 가장 이상적인 상황은 개발팀이 일정한 속도를 지속하는 것이다. 개발자도 사람인지라 날이 좋아서 날이 좋지 않아서 들쭉날쭉할수있다. 좋은 팀이라면 개인의 변동은 팀 차원에서 어느정도 커버가 된다. 하지만 팀이 들쭉날쭉하면 위험신호다.
개발팀이 실제 일하는 사이클타임은 보통 코드작성-코드리뷰-코드병합 이기 때문에 이 단계에 해당하는 컬럼을 필터해서 보면 개발팀의 평균 이슈 해결 속도를 알수있다.
위 차트는 현재 내가 속한 팀(퇴사전)의 사이클 타임이다. 입사후 첫 6개월을 제외하고 나머지 기간동안 거의 같은 속도를 유지했다. 심지어 마지막 릴리즈는 불꽃을 태웠다. (빨간선 밑으로 롤링이 내려옴)
그동안 우리팀은 얼마나 생산적이고 효율적으로 일했나?
팀이 얼마나 생산적이고 효율적으로 일했는지 확인하기 위해 같은 기간동안 개발팀의 리드타임을 누적흐름도표와 함께 겹쳐서 확인해보자.
개발팀의 개발 사이클은 일정하기 때문에 올해 5월부터 급격한 리드타임의 증가는 해결해야할 피처의 크기에 비례했음을 알수있다. 따라서 회고할때 이곳에 숨겨진 맥락을 짚는게 중요하다.
회고에 데이터 활용하기
길게 설명했지만 내 결론은 데이터를 회고에 활용하면 좋다는 이야기를 계속하고 있다. 사실 나도 데이터를 처음부터 활용한건 아니다. 회고준비에 지쳐갈때쯤 회고마스터를 순환하기 시작했는데 이때부터 회고 준비에 대한 압박이 사라지고 천천히 데이터를 들여다볼 여유도 생겼다. 역시 사람은 여유가 있어야 새로운 시도도 해보게된다.
데이터를 해석하는 데에는 다분히 주관적인 견해가 들어가기 마련이다. “왜 이런 결과가 나왔을까?”라는 질문을 통해 혼자 가설을 세워보고, 회고를 통해 서로의 견해를 확인한다. 우리는 이 결과가 문제 상황인지, 아니면 어떤 원인으로 인해 당연히 발생한 것인지, 그리고 우리 팀이 감당할 수 있는 리스크인지 또는 개선할 수 있는 것인지에 대해 논의했다.
차트가 보여주듯이 우리 팀은 꽤 건강했고, 실제로도 팀워크가 매우 좋았다. 데이터 회고가 꼭 어떤 문제를 발견하기 위해 필요했던 것은 아니다. 우리가 여전히 잘하고 있음을 성적표로 확인받으면 왠지 더 잘하고 싶어지는 욕구가 생긴다. 그 이유는 나도 잘 모르겠다. 이런 팀은 나도 처음이라…
플래닝에 데이터 활용하기
개발팀이 일정한 속도를 내면 일정 계획을 세우고 예측하는데도 도움이 된다. 나는 스크럼도 좋아하지만 일정 산정에 대한 스트레스가 꾀나 커서 주로 칸반을 사용한다. 개발팀이 일정한 속도를 내거나 이슈의 크기가 일정하게 짤리면 큰 비용 들이지 않고 이슈 갯수를 기준으로 예측을 해보기도 한다. 재밌는건 이런 대강의 예측도 어느정도 데이터가 쌓이면 얼추 잘 맞아 떨어진다.
개발 사이클 타임
개발 리드 타임
우리팀은 기본 개발 사이클이 존재하기 때문에 앞뒤 짜르고 순수하게 20일정도 개발할 내용을 플래닝하곤했다. 그렇게 플래닝한 티켓을 보드에 올려놓고 누적흐름도표에서 개발 리드타임으로 필터해보면 대강 감이 온다. 아! 이번 릴리즈는 힘들겠다. 이번에는 무난하겠네. 한번은 스토리 갯수가 평소보다 7개 많아서 7일정도 더 걸릴꺼라고 예상했는데, 실제로 9일정도 더 걸렸다. 특별한 노력을 들이지 않고 예측한 오차가 2일정면 나쁘지않다.
애자일 회고의 본래 의미
내가 글을 쓰는 동안 여러 질문들을 GPT에게 던지면서 놀라운 사실을 하나 알게됐다. 바로 회고라는 단어가 한국어에선 자기성찰의 의미가 있어서 다소 감정적인 의미로 받아들여 질수있다는 사실이다. 그런데 더 놀라운건 Retrospective 라는 단어의 늬앙스다. 다음은 GPT 내게 준 답변이다.
“Retrospective”는 다음과 같은 의미를 가집니다:
- 과거를 돌아보는 것
- 특정 기간이나 사건을 되돌아보고 평가하는 행위.
- 회상과 평가
- 과거의 경험, 사건, 행동을 되짚어보고 그 의미와 결과를 분석하는 것.
영어에서 “retrospective”는 일반적으로 중립적이고 분석적인 뉘앙스를 가집니다. 이는 단순히 과거를 되돌아보고, 무엇이 잘 되었고 무엇이 개선될 수 있는지를 평가하는 것을 의미합니다. 따라서 “retrospective”에는 반드시 자기 반성이나 잘못을 탓하는 의미가 내포되어 있지 않습니다. 오히려, 경험을 통해 배우고 성장하기 위한 긍정적인 과정으로 여겨집니다.
회고는 그렇답니다. 끝!
