스크럼이 낡은 방식이긴 하다
애자일을 습관으로 11
요즘에 좋은 글이 많아 구독하고 있는데, 어그로(?) 제목에 이끌려 두 개의 글을 봤다. 하나는 <스크럼이 개발자를 괴롭히는 9가지 이유> 이고, 다른 하나는 <최소 기능 제품 MVP, 이제 구시대적 발상인가요?>이다.
스크럼이 개발자를 괴롭힐 가능성은 높지
<스크럼이 개발자를 괴롭히는 9가지 이유>를 읽기도 전에 제목으로 던지는 메시지에는 이미 동의했다. 그런데 9가지나 있어서 훑어보았다. 외국 배경으로 쓰인 글이라 SAFe와 같이 국내에는 생소한 개념을 다루는 부분이 있기는 하지만, 꽤 잘 쓰인 글로 대부분 동의하지 않을 수 없다.
그의 말에 동의합니다로 글을 끝내기 아쉬워 내 의견을 조금 덧붙여본다. 개발자 입장에서는 가장 먼저 고려된 요인은 크런치 타임인 듯하다. 크런치 타임은 무슨 뜻일까? 구글링을 해보았다.
소프트웨어 결과물을 내보낼 때 들어가는 압박(stress)과 부가 시간 등을 뜻하는 듯하다. 짧은 출시를 빈번하게 가져가면 이런 압박이 쌓이면 생산성 저하를 가져온다. 예전에 CTO님이 (우리회사 말고 조금 더 규모가 있는 회사를 위해) 도움을 청하는 외부 조직에 제시할 애자일 방법을 고민하면서 이런 부작용을 피하기 위해 Shape Up을 찾았다고 공유해준 일이 있는데, 당장 써먹을 곳이 없어 듣고 말았던 기억이 떠올랐다.
개발자 입장에서는 뚜렷하게 느껴지는 가치가 없는데 빈번하게 압박이 이어지면 피로함을 느낀다. 바로 그 피로감이 경영자들 표현으로는 생산성 저하다.
독불장군이나 꽉 막힌 계획 피하기
또 눈에 띄는 항목은 독불장군 같은 PO와 일정, 릴리즈 트레인(SAFe 용어) 등이 보였다. 나는 이 부분을 업무 공간에서의 정치 문제로 본다. 기획자는 누구나 자기가 정의한 내용이 중요하다. 영업은 자신들이 만난 고객의 요구가 가장 중요하다. 개발자도 하고 싶은 일이 있다. 이것을 어떤 기준으로 해소해가느냐는 인간 사회에 필요한 정치를 개발팀 내에 구현하는 문제다.
나는 현대 축구팀의 유기적인 움직임에서 많은 힌트를 얻는다. <협업 조직에서 함께 앉기 구현하기>에서 자리 배치를 바꿔가며 조직력을 만들어가는 일을 축구에 비유한 일이 기억난다. 고정된 규칙만으로 합의를 이끌 수가 없다.
민주주의 정치제도를 보면 입법부와 사법부만으로 돌아가지 않는다. 행정부와 그 수장의 역할이 매우 중요한데, 그것을 어떻게 할 것이냐가 리더의 몫이다.
경합이 넘쳐 여유가 없으면
낭비가 없게 일하는 것은 좋지만, 긴 시간과 많은 기능이 생산성을 의미하지 않는다. 기획 결과를 보면 안 쓰는 기능이 항상 존재한다. 결정은 사용자(소비자)가 하기 때문이다. 그래서 반드시 여유를 갖는 어떤 장치가 필요하다. 생산성을 추구하고 개발자에게 여유를 주지 않으면 기술 부채가 따라온다.
Chris Richardson이 인용한 논문에 따르면 조직이 기술 부채로 낭비하는 시간이 무려 42%라고 한다.
MVP는 구시대적 발상인가?
두 번째 기사는 <최소 기능 제품 MVP, 이제 구시대적 발상인가요?>이다. 이 글은 제대로 어그로란 생각이다. 내용이 없다. MVP의 약점에 대해 제대로 알고자 한다면 기사를 보는 대신에 <아이디어 불패의 법칙>에서 소개한 ‘될 놈' 개념을 먼저 알아보라고 해주고 싶은 빈약한 기사다.
마무리
우리회사에서 중국 역직구 서비스를 키우느라 계획 없던 스타트업 모드로 일해왔다. 그러면서 20년간 내가 있어온 소프트웨어 업계와 조금 다르게 모험 자금이 IT업계에 들어오는 맥락도 조금 익혔다. 그렇게 보니 MVP의 한발 나아간 버전인 '될 놈'도 배웠다. 그래서 <최소 기능 제품 MVP, 이제 구시대적 발상인가요?>라는 어그로 기사를 혹시나 하고 봤는데 역시나 맹탕이다.
반면에 <스크럼이 개발자를 괴롭히는 9가지 이유>는 지난 10여 년 형식 위주의 애자일 도입에 대한 진지한 성찰이 잘 요약된 좋은 글이다. 나는 사업적 가치를 확인하는 릴리즈 이외의 문제는 인간 공동체엣서 정치가 알려주는 교훈이나 갈등 중재 등의 분야에서 이러한 사회적 기술을 배울 수 있다고 본다.
