애자일, 스크럼, 스프린트는 왜 잘 되지 않을까? 기획 분석

최근 프로젝트를 하면서 애자일, 스크럼, 스프린트라는 단어를 자주 듣게 되었습니다. 애자일은 이전에도 자주 들었지만 스크럼, 스프린트는 요즘 자주 듣게 된 듯합니다. 그리고 스크럼에는 익숙한 이름인 노나카와 다케우치가 있어 반가웠습니다. 수 십 년 전 대학 때 들은 이름이 나오니 반가움이 컸습니다.

 

노나카와 다케우치가 이야기한 불확실성이 높은 환경에 대응하기 위한 창조적 조직으로 프로젝트 조직과 학습조직에 대한 이론을 바탕으로 애자일과 스크럼, 스프린트에 대해 살펴본 후,

왜 실무 현장에서 애자일 방법론이 실패하는지를 정리해 보고자 합니다.

 

 

 

애자일, 스크럼, 스프린트 개념

 

이 개념은 위키백과의 내용을 바탕으로 간단히 정리하겠습니다. 요약, 정리하는 것이므로 전체 내용을 실지는 않겠습니다. 더 자세한 내용은 위키백과를 찾아보시기를 권유드립니다.

 

 

애자일

위키백과 내용에 따르면 애자일 방법론은 '아무런 계획이 없는 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론'이라 쓰여 있습니다.

 

다른 설명 내용으로 '소프트웨어 엔지니어링에 대한 개념적인 얼개로, 프로젝트의 생명주기동안 반복적인 개발을 촉진한다'라고 쓰여 있습니다.

 

이 내용으로는 애자일이 무엇인지 정확히 이해되지 않을 것입니다.

저는 애자일 선언문을 보면 조금은 더 이해가 쉬어질 것이라 생각합니다.

 

애자일 선언문을 보면, 애자일 작업을 통해 다음을 가치 있게 여긴다고 되어 있습니다.

• 공정과 도구보다 개인의 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따라기보다는 변화에 대응하기를

 

애자일의 등장 배경 추정과 가치에 대한 실무 의견

우리는 애자일 선언문에서 애자일이 어떻게 등장하게 되었는지 알 수 있습니다.

 

애자일은 선언문에서 알 수 있듯이 불확실성하에서 소프트웨어를 통한 문제 해결을 위한 방법론이라 할 수 있습니다.

 

그러기에 고객과 협력을, 변화에 대응하는 것을 그리고 작동하는 소프트웨어를 추구합니다. 이를 빠르게 실현하기 위해 개인의 상호작용을 중요시하는 것입니다. 

 

이는 개발을 통해 문제를 해결해야 하는 상황이 너무 불확실하기에 계획을 수립하는 것이 무의미하기 때문입니다. 계획을 하는 기간에 상황은 변해 있을 수도 있습니다.

 

문서 작업 또한 같은 의미입니다. 문서화하는 동안 상황이 문서의 내용과 달라져 있을 수 있습니다. 

 

그러기에 속도가 중요합니다. 이러한 개발(생산) 조직은 2000년 이후 다품종 소량생산이 효율적인 시대로 접어들고, 글로벌화된 시장이면서 문화별, 지역별 차이, 세계화에 따른 계층 분화, 개성과 개인에 대한 인식이 대두되면서 더욱 커지게 되었습니다.

 

이는 다시 SNS로 인한 유행이 확산이 급속도로, 세계적으로 진행되면서도 역설적이게 이런 유행의 주기가 짧아지면서 시장을 인지하는 순간 더욱 빠르게 제품을 시장에 내고, 다시 제품을 변경하는 작업이 성공의 핵심역량이 되면서 중요성이 더욱 강화되었습니다.

 

결국 협상하고 계획한다면 문서를 작성한 후 개발을 하면,

이미 유행이 지난 제품을 출시하게 되는 상황이 되는 시장 환경이 된 것입니다.

 

이런 빠른 변화는 계획에 있어 모호성을, 문서 내용의 오류를 형성합니다. 그러므로 무엇보다 상호작용이 중요하게 되는 것입니다.

 

이는 단순히 서로가 잘 지내는 수준의 것이 아닙니다. 문제 해결을 위한 소프트웨어 개발을 위한 상호작용을 의미합니다.

 

그리고 이러한 과정은 작동하는 소프트웨어의 개발 결과를 산출물로 내야 의미를 가질 수 있습니다. 

그다음 이 작동하는 소프트웨어가 문제 해결에 적절하냐의 질문에 설루션이 될 수 있어야 합니다.

 

바로 두 지점에서 

1) 소프트웨어의 개발 결과를 산출물로 내야 의미를 가질 수 있습니다. 

2) 작동하는 소프트웨어가 문제 해결에 적절하냐의 질문에 설루션이 될 수 있어야 합니다.

 

전통적인 방식에서의 개발 경직성과 애자일 방법론 형식 지나치게 수행하려 하는 데에서 오는 개발 경직성이라는 양 극단이 애자일이 경계한 바로 선언문 가치를 해하는 결과를 가져왔다는 점에서 부정적 의미를 가집니다.

 

지나친 애자일 추구는 그 자체가 애자일적이지 않다는 것입니다. 그리고 지나치게 애자일로 하려는 노력 자체가 고객(문제 해결을 요구하는)과 협력을, 변화에 대한 대응보다는 애자일 방법론 실행에, 개인 상호작용보다는 애자일 방법론 실행을 완료했는지 평가에 치우치게 되어 비애자일적이게 되는 것을 실무적으로 보게 되었습니다.

 

결국 빠르게 변화하는 불확실성에 대응하기 위한 개발 방법이 불확실한 상황 변수로 등장하는 아이러니가 일어나는 것입니다.

 

이는 조직 전략에서 자주 등장하는 현상이기도 합니다. 좋은 의도와 적절한 선택과 방법론이 지나치게 몰입되면서 그 자체가 장애물이 되는 일은 어떤 혁신 조직에서 자주 일어납니다.

 

    

 

스크럼, 스프린트

스크럼은 럭비 용어입니다. 위키백과에서도 럭비에서 나온 용어라고 설명합니다.

 

위키백과를 보면 애자일 개발 프로세스로서 '프로젝트 관리를 위한 상호, 점진적 개발방법론이면서, 애자일 소프트웨어 개발 중 하나라' 되어 있습니다.

 

스크럼 방법론은 '노나카 이쿠지로와 다케우치 히로타카가 1986년 1~2월 하버드 비즈니스 리뷰에 올린 글에서 시작'된다고 말합니다. 그러므로 제가 수십 년 전에 배운 대학 교재에서 나온 내용이 다른 것은 아니라는 점을 확인하였습니다.

 

그리고 위키백과는 스크럼의 기반을 '지식창조기업' 있다고 합니다. 이 또한 대학 때 배운 조직 학습, 학습 조직의 내용과 맥을 같이 합니다.

 

스프린트는 스크럼을 구성하는 '반복적인 개발 주기'를 의미합니다. '계획 회의부터 제품 리뷰가 진행되는 날짜까지의 기간이 1 스프린트'라고 위키백과는 말합니다.

 

경영학적으로 보면,

스크럼은 인식된 문제를 해결하기 위해 구축된 프로젝트(TFT) 팀이 조직 학습을 통해 몰랐던 문제를 해결하는 소프트웨어를 개발하는 프로세스라 정리할 수 있습니다.

 

이때 스크럼의 진행에 대해서는 위키백과 내용을 참고하면 좋습니다.

• 제품 백로그 : 개발할 제품에 대한 요구 사항 목록
• 스프린트 : 반복적 개발 주기 (계획 회의부터 제품 리뷰가 진행되는 날짜까지 1 스프린트)
• 스프린트 계획 회의 : 스프린트 목표와 스프린트 백로그를 계획하는 회의
• 스프린트 백로그 : 각 스프린트 목표에 도달하기 위해 필요한 작업 목록
• 일일 스크럼 회의 : 날마다 진행되는 미팅 (어제 한일, 오늘 할 일, 장애 현상 등을 공유)
• 실행 가능한 제품 개발 : 스프린트 결과로써 나오는 실행 가능한 제품

위 내용은 위키백과에 나오는 스크럼 중요 요소입니다.

또한 '30일 주기로 실제 동작하는 제품을 만들면서 개발을 진행시킨다.'라고 쓰여 있습니다.

 

애자일과 학습조직을 결합하여 일일 스크럼 회의를 보면, 이는 하는 것이 아닌 하게 되는 것입니다. 그러므로 일일 스크럼 회의를 잡아놓고 한다는 것은 전혀 애자일적이지도, 학습조직적이지도 않은 것이 됩니다.

 

불확실한 문제를 해결하기 위해 각각 프로젝트 팀원들이 연구한 내용을 공유하고, 이 공유 속에서 설루션을 찾아가는 것이 스크럼 회의가 되어야 합니다. 그러므로 스크럼 회의는 학습조직이 실행의 결과인 것입니다.

 

그런데 일일 스크럼 회의를 형식적 주간회의가 아닌 일일회의로 하는 경우가 있습니다. 일일 스크럼 회의를 누가 프로젝트 팀을 쪼기 위한 방법으로 이용하기도 합니다.

 

결국 이러한 것은 애자일 조직이 아닌 아주 전통직인 관료조직의 모습을 띠고 있는 것입니다. 단지 회의명만 애자일로 스크럼인 것입니다. 

 

 

달리지 못하는 스프린트, 회의만 늘리는 스크럼

실무 현장의 스프린트를 보면 목표가 없는 경우가 종종 있습니다. 이전과 지금 주간회의, 지금과 1주 후 주간회의 기간이 스프린트가 되기도 합니다. 이 경우 스프린트 목표는 주간회의 보고입니다.

 

이 경우 제품 백로그와 스프린트 백로그는 존재하지 않습니다. 단지 과거 잡아놓은 WBS를 달성했는지 확인할 뿐입니다. 문제는 WBS조차 무엇을 개발해야 하는지 정확히는 모르는 상태에서 레퍼런스 기반 작성된 것일 수도 있습니다.

 

결국 1 스프린트 결과 작동하는 애플리케이션이 나오지 않습니다. 스프린트는 달리자 못하는 것입니다.

 

애자일 스프린트와 전통적 개발 방식의 WBS는 다른 것이자만 그냥 WBS 진척을 확인하는데, 멋진 용어로 스프린트가 쓰일 뿐인 것입니다. 그러기에 당연히 스프린트가 잘 진행되지 못하게 됩니다.

 

스크럼을 회의에 방점을 두는 경우도 문제 해결을 위한 지식 확산을 위한 애자일에서 말하는 개인의 상호작용이 되지 않습니다. 회의가 진행될수록 다른 사람의 말은 그냥 듣고 흘리게 됩니다. 문제해결을 위하 이틀 고민하고 작업하면 일일 스크럼 시 아우 일 안 한 사람이 될 수도 있습니다. 

 

이렇게 스크럼은 점점 형식적 회의, 일할 시간을 매일 빼앗는 지루한 회의가 되는 것입니다.

 

실무에서 스크럼이 자기 지식을 자랑하는 시간으로 변질되는 것을 보기도 했습니다. 문제는 이렇게 자랑하는 내용을 지식화, 정확히는 형식지(문서화)로 정리해 달라고 하면 하지 못합니다. 전체 문서화가 아니라 공유/협의를 위한 간단한 규정, 절차, 정의 정도의 문서화조차 못하고, 이를 개발로 진행하지는 더욱 못합니다.

 

스크럼과 스프린트가 개발이 아니라 자기 자랑 시간이 되는 것입니다. 그리고 자기 자랑이므로 서로서로 말하느라 스크럼 3~4시간 진행되기도 하고, 아무도 제대로 기억하지 못합니다. 그래서 다음주가 되면 또 비슷한 말을 반복합니다. 회의에 모인 사람들은 비슷한 이야기를 매주 듣는데 개발은 진행이 되지 않는 일이 일어납니다. 그리고 수개월이 지나도 반복되는 이야기에서 기시감과 미시감을 왔다 갔다 하는 경험을 하게 됩니다.