“애자일은 대형 프로젝트에서 안돼”
스크럼, XP, 린 S/W 개발 등은 7~9명 단위의 작은 팀을 기반으로 설명되어 있었고, 이 인원으로 최고의 생산성과 품질을 낼 수 있다 라고 언급하였다. 그나마 스크럼 프로세스 정도가 여러 스크럼 팀으로 확장 될 때 작은 팀들을 여러개 만들고 이를 스크럼의 스크럼이라는 형태의 회의로 이슈를 해결하면 된다라는 확장에 대한 고민을 담았다.
하지만 심지어 스크럼 조차도 개발 외에 요구사항을 받는 방법이라던지, 릴리즈의 구체적인 방법에 대한 언급은 없었기 때문에, 규모가 큰 프로젝트에서 적용하는데는 제약이 있다는 생각들이 많았다.
그 때문이었을까… 십년 이상동안 대형 프로젝트에서 애자일을 활용하는 극복의 과정은 꽤나 고통스러웠다.
작은 팀 위주에 초점을 맞추던 기존의 프랙티스에서 벗어나 대형 프로젝트에 맞게 일부 변경된 시도를 하던 사람들에게는 많은 비난이 쏟아졌다.이전의 오리진(Origin)을 버리는 것이라 비난하는 이도 많았고 조금이라도 문서화에 초점을 맞추면 “이건 애자일이 아냐” 라고 비난하는 사람들이 생겨났다. “무늬만 애자일”, “하이브리드”, “미니워터폴” 등 다양한 용어들로 변형된 프로세스에 대해 부정적이었다.
하지만,이에 대한 변화는 결국 시장이 주도하게 되는데, 기존 프로세스에 대한 불만과 클라우드로 전환하는 시장의 흐름에 따라, 애자일의 확산 니즈는 점점 커졌다. 이와 함께 애자일 또한 일반화/정형화/대중화 되기 위한 움직임들이 나타났다.
그리고 다양한 조직의 더 많은 사람들이 애자일 방식을 기반으로 한 나름대로의 프로세스를 만들어 나갔다. 기존의 한계를 극복하며 현실적인 접근을 시도했던 것이다.
이의 대표적인 프로세스가 DaD(Disciplined Agile development), SAFe(Scaled Agile framework), LeSS(Large Scaled Scrum) 등이다. 심지어 SAFe는 미국 정부를 비롯하여 애자일을 하는 회사의 50%이상이 활용할 정도로 큰 인기를 얻고 있는 애자일 프로세스이다.
<SAFe(Scaled Agile Framework):150명 이상의 Portfolio 관리가 필요한 대형 애자일 방식>
<LESS(Large Scaled Scrum): MAX 80명 애자일 조직을 대상으로 수행하는 대형 스크럼방식>
이러한 프로세스는 기존의 도그마(Dogma: 독단적인 학설, 이성적으로 증명되지 않은 가설)라고 이야기 되던 순수 애자일 추구에서 벗어나 현실속에서 기존 문화와 다양한 프랙티스들을 섞는 것을 시도하는 내용들이 담겨 있었다. 시장 상황, 이해관계자들의 일해오던 방식 등을 일부 존중하면서, 애자일 방식을 통해 가치를 얻을 수 있는 중간 단계의 무엇인가를 찾는 노력들이 있었다.
이에, 디지안 씽킹으로 대표되는 디자인 방식의 변화, 린스타트업으로 대표되는 스타트업 바람이 더해져 바탕으로 이제는 소프트웨어 회사의 94%이상이 본인들은 애자일을 하는 회사라 말하고 있다.
<버젼원의 리포트2016: 애자일을 수행하는 회사가 94%라는 설문 결과>
전체적으로 스펙트럼이 소/중/대형을 넘나드는 애자일 방식들이 생겨나게 된 내용은 지금까지 설명한 바와 같다.
그렇다면 과거의 소규모를 향한 애자일과 중/대형 사업의 애자일과의 구체적인 차이는 무엇일까? 현실과 맞물린 일하는 방법이란 과연 무엇일까?
이를 효과적으로 설명하려면 2001년의 애자일 선언을 가지고 이야기 하면 좋다.
과거 작은 팀을 중심으로 진행하는 애자일 방식은 오른쪽 노란색 부분은 마치 금기처럼 무시하려는 분위기가 강했다. 그래서 조금이라도 오른쪽에 접근하는 것을 경계했다.
하지만 현실과 맞물리며 대형 프로젝트 같은 경우, 왼쪽보다는 확실히 덜 중요하나 오른쪽 부분 또한 중요하다는 인식으로 발전되어 갔다.
이를 설명하면 다음과 같다.
1. 대규모 프로젝트(50명 이상)에서 개인과 상호작용만 강조하면, 두 개이상의 팀이 되었을 때 효과적인 커뮤니케이션을 하기 힘들다 때문에 툴을 사용하는 것이 좋다
2. 동작하는 소프트웨어에만 집중하면 팀 내에서는 진행상황에 대해 잘 이해할 수 있으나 두 개이상의 팀이 되었을 때 서로의 진행사항을 확인하기 어렵다. 애자일팀들이 아주 쉽게 말하는 “우리팀에 와서 언제든 제품을 보세요” 라는 말은 2팀 이상을 봐야 하는 관리자에게는 눈살을 찌푸리게 만드는 대화가 될 수도 있다. 때문에 적당한 문서화는 커뮤니케이션에 도움이 될 수 있다.
3. 고객과의 협업만 강조하면 다양한 이해관계자를 모두 포용하지 못할 수 있다. 때문에 계약과 협상 을 통해 전체 이해관계자와 동일한 비전/생각을 갖으며 일을 해야 한다.
4. 상황에 따라 변화를 하는 것은 중요하지만, 주변 팀에 이야기 하지 않으면 두 팀 이상이 될 경우 의존관계를 무시하게 되여 고객의 비즈니스 가치를 늦게 딜리버리하는 상황을 만날 수 있다.
혹시나 대형 프로젝트, 대규모 조직에서 애자일을 적용하다 현실의 벽에 부딪혀 고민하고 있는 독자가 있었다면 위 이야기를 듣고 반가운 생각이 들 수 있다.
하지만, 다시한번 강조하여 이야기 하고 싶다. 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 상황의 따른 변화가 여전히 더 중요하다. 그래야 애자일 방식이다.
...
