‘세일즈포스’ 큰 조직에서의 애자일 도입과정

애자일 사례 분석

‘세일즈포스’ 큰 조직에서의 애자일 도입과정

애자일을 도입할 때 큰 기업일수록 신중하게 결정해야 한다. 회사의 리스크가 가장 큰 부담이되기 때문이다. 하지만 철저하게 동기를 부여하고 준비하면, 리스크를 최소화할 수 있다. 만약 모든 팀이 애자일을 도입하면서 여러 팀들의 노하우를 서로 배울 수 있다면 어떠할까. 이번 글에서는 애자일을 모든 팀에 도입하면서 변화를 시도한 큰 조직 사례를 살펴볼 것이다. 바로 세일즈포스라는 기업이다.

세일즈포스는 클라우드 컴퓨팅 서비스 형태로 고객 관리 솔루션(CRM)을 제공하는 기업이다. 비즈니스 응용프로그램과 응용프로그램 플랫폼을 인터넷으로 제공하고 있다. 1999년 3월에 마크 베니오프가 설립했고, 현재 만 명 이상 직원들이 여기서 일하고 있다. 국내에서도 세일즈포스 제품은 큰 인기를 얻고 있으며 많은 글로벌 고객을 두고 있다. 세일즈포스는 3개월에 거쳐 약 200명 규모의 팀 30곳에 애자일을 도입했다. 애자일 도입에 있어서 가장 크고, 빠르게 도입된 사례 중 하나로 손꼽힌다. 세일즈포스의 사례가 처음 알려진 것은 2007년 프라이 그린(Fry Greene)이 애자일 커뮤니티에 자신의 회사에 대한 사례를 공유하면서다. 만약 애자일 도입을 고려하고 있는데 방법을 고민하고 있는 조직이라면 좋은 참조 모델이 될 수 있을 것이다. 특히, 대규모 조직을 교육하고 혁신을 이루기 위해 어떻게 준비해 실행에 옮겼는지도 확인할 수 있다. 뿐만 아니라 이들이 애자일 프로세스를 선택하게 된 이유와 어떻게 도입에 성공할 수 있었는지, 도입 후에는 어떻게 확장했는지에 대해서 배울 만한 내용이 많다.

세일즈포스는 3개월이라는 짧은 기간 안에 각 팀들이 워터폴(Waterfall) 개발 방법론에서 애자일 방법론으로 변화했다. 처음에 집중했던 것은 확실한 개발주기와 투명성 그리고 스스로 일을 진행할 수 있는 팀을 만드는 것이었다. 세일즈포스는 애자일을 도입하면서 6개월 동안 자체적인 기존 개발 프로세스를 벤치마크했고, 두 개의 메인 릴리즈를 완성했으며, 매달 코드를 배포할 수 있게 했다. 

그들은 애자일을 도입하기 전 원칙들을 먼저 살펴봤다. 애자일 원칙 중 어떤 사람의 압력과 요구로 팀을 이루지 말고, 팀 스스로 움직여야 한다는 요구사항이 있었는데 그들은 신중한 결정을 내리기 위해서 스태프들을 대상으로 설문 조사를 했다고 한다. 그 설문조사의 결과 87% 가량의 개발 구성원들이 스크럼 팀이 스스로 알아서 움직일 수 있는 팀이라고 믿고 있었고, 80% 정도의 기술 스태프들이 새로운 개발 방법론이 자신들의 팀을 보다 효율적으로 만들 수 있다고 답했다. 그들은 지금도 지속적으로 개발 조직을 개선하기 위해서 노력하고 있을 뿐만 아니라 명확한 데이터와 자료를 기반으로 올바른 결정들을 내리고 있다. 여담이지만 많은 기업들이 자료조사는 진행하지만 확실히 내려야 하는 결정 앞에서는 확신이 없어서 망설이는 경우가 많이 있다. 하지만 세일즈 포스는 충분한 자료조사를 기반으로 과감한 결정을 실행해 옮길 수 있는 점을 보여주고 있다. 세일즈포스가 애자일을 도입하게 된 배경부터 살펴보도록 한다.

도입 배경

세일즈포스는 고객의 필요에 따라서 서비스를 확장하는 온디맨드 서비스에 있어서 시장 선도, 기술 리더로 발돋움했다. 그리고 지금도 계속해서 정상의 자리를 지키고 있다. 세일즈포스에서는 매일 같이 8천5백만 결제가 이루어지고 있고, 약 65만명의 구독자들을 가지고 있다. Salesforce.com이라는 웹사이트는 CRM 솔루션을 제공하는데, 이는 사용자의 요구에 맞춰 개발된 플랫폼이다. 세일즈포스의 서비스 기술 조직은 Salesforce.com 이라는 서비스를 운영하고 개발하고 있다. 더 놀라운 것은 회사가 처음 설립되고 약 8년 동안 매년 50%씩 꾸준한 성장을 가지고 있는 부분이 고무적이다. 그들은 매년 평균 4개 정도의 주요 업데이트를 진행하고 있다고 발표했었지만 그들이 애자일을 도입하기 전에는 일년에 한 개의 주요 업데이트만 진행이 가능했다고 밝히고 있다. 그렇다면 애자일을 도입하기 전에 어떤 문제들이 있었을까? 그들은 다음과 같은 다섯 가지의 문제를 가지고 있었다고 말했다.

- 정확하지 않은 전체 개발기간(일찍 산정하고 평가하는 것은 결국 각 기능별 정학한 완성 일자와 완전한 테스팅 스케줄을 제공할 수 없었다.)

- 실제 릴리즈의 모든 단계별로 눈에 보여지는 결과물의 부재

- 거의 릴리즈 끝에 이루어지는 기능들의 늦은 피드백

- 길고 예측이 어려운 릴리즈 스케줄

- 팀이 확장될수록 줄어드는 생산성

R&D 그룹에서는 애자일을 도입하기 전에는 워터폴(Waterfall) 개발 방법론 기반으로 프로젝트를 진행했다. 기획이 끝난 다음 디자인하고, 그 다음 개발이 진행되며 마치 폭포수 같이 쏟아지는 것 같은 차트를 만들어내기 때문에 워터폴 개발 방법론이라고 이야기 한다. 당시 R&D 그룹은 모두 기능별 팀으로 조직화돼 있었다. 예를 들면, 사용자경험팀, 제품개발팀, 제품관리팀, QA팀 그리고 문서화팀 등과 같이 기능에 따라 팀이 구성됐다. 비록 그 팀들은 프로젝트에 따라서 팀의 구조가 조금 유연하게 바뀔 수 있었다고는 하지만, 결국 전체적으로 기능별로 진행되는 워터폴 개발 방법론을 따르고 있었다. 

세일즈포스의 워터폴 방법론을 예를 들면 다음과 같다. 제품관리팀은 제품 각각 기능들만 정의했다. 사용자경험팀은 각 기능의 프로토타입과 인터페이스만 생산했고, 개발자들은 그저 기술명세서와 코드들만 작성했다. QA팀은 각각의 기능을 테스트하고 검증하는 역할을 진행했고, 문서화팀은 각 기능을 문서화했다. 

워터폴 개발방법론 기반 프로세스는 팀이 규모가 작았던 초창기에는 성공적이었지만 회사가 갑자기 커지면서 대규모 조직을 관리하기는 쉽지 않았다. 비록 개별적인 기능과 패치는 성공적으로 배포할 수 있었지만 메인 업데이트를 할 때는 짧게는 3개월, 길게는 12개월까지였다. 회사가 빠르게 성장하고, 릴리즈 기간이 늘어났기 때문에 R&D 소속의 많은 사람들은 주요 제품의 릴리즈에 참여하지 않았다. 그 결과 조직은 학습기회를 잃었으며, 실제 시장에 고품질 제품을 전달하는 데 있어서 사기가 저하됐다.

애자일 도입 방법

악순환이 계속되면서 세일즈포스의 기술 책임자는 결단을 내렸다. 세일즈포스의 초기 창업자이자 R&D의 기술 연구센터장은 조직 변화 프로그램을 발표했다. 그는 앞서 설명한 기능별로 이루어진 팀들이 가진 느린 업무속도와 낮은 예측력, 제품의 안정성과 같은 문제를 지적했다. 그리고 기존 팀들을 바닥에서부터 다시 재구성하고 개발 프로세스를 다시 만들기로 했다.

이 과정에서 가치있는 개발 원칙들을 찾을 수 있었다. 일명 KISS(Keep it Simple Stupid)라는 원칙이다. 이는 간단한 것이 제일 좋다는 개념과 빠른 반복주기 그리고 고객들의 의견에 귀 기울이는 것을 의미한다. 새로운 개념들은 애자일 개발 방법론과 거의 일치가 됐다. 변화에 도움을 주는 주요 세 영역도 있었다. 첫째는 바로 온디맨드 소프트웨어 모델자체가 애자일 방법론에 잘 맞았고 두 번째는 잘 개발된 자동화 된 테스트 시스템이 새로운 개발 방법론에 잘 맞게 틀이 잡혀있다는 것이다. 마지막으로 R&D 그룹의 중요성에 대해서 이미 인지가 되고 있었다는 점이다. 가장 중요한 점은 어떻게 소프트웨어를 개발할지에 대한 계획이 아니라 이러한 개념들을 어떻게 기술 조직들에게 전달하느냐는 것이었다. 한명의 팀 구성원이 새로운 개발 프로세스를 설명하는 문서를 작성했다. 여기서 이 프로세스의 장점들과 오래된 개발 프로세스를 변화해야 하는지 이유를 기술했다. 더불어 각 조직 별로 모든 레벨의 핵가졌고, 이런 미팅에서 나왔던 피드백들을 모두 문서에 기록했다. 새로운 프로세스의 디자인 모형들과 조직 별로 다르게 적용해야 되는 변화들도 기록했다. 이렇게 열린 커뮤니케이션을 통해 피드백을 반복해 모두가 새로운 개발 프로세스를 정립하는 데 목소리를 내게 했다. 초기 문서에 포함된 두 가지 중요한 포인트는 먼저 사용 가능한 프로세스들의 디자인을 통합하기 위한 계획과, 각각의 주요 릴리즈 별로 우리가 얼마만큼의 시간을 필요로 했는지에 대한 점이었다. 이를 통해 두 가지 도입방법을 고려했다. 시범적으로 도입해서 점진적으로 천천히 결과를 내보자는 것이고, 또 다른 것은 한꺼번에 모든 팀들에게 적용해 바꾸자는 것이었다. 변화를 도입하는 데 있어 가장 중요한 요소는 조직간 불협화음을 피하는 것이고 이러한 변화에 대한 갈망이 팀에 있냐는 것이었다. 다행히도 대부분의 팀원들은 도입을 원했다.

논쟁이 없었던 것은 아니었다. 주된 논쟁은 만약 모든 팀들이 한꺼번에 새로운 프로세스를 도입할 경우에 몇 개의 팀들이 시범적으로 도입하는 것에 비해 같은 실수를 할 경우가 많다는 것이고 매일 모든 팀들을 지원할 코치 인력들이 부족하다는 것이다. 한 가지 희망이 있었다. 조직 내 한 팀이 스크럼(Scrum)을 이용한 결과 위주의 프로젝트를 이미 성공한 경험이 있었다는 것이다. 세일즈포스는 이 부분의 경험을 높게 사서 전체 팀이 이동하는 대규모의 변화를 적용하기로 결정했다. 우선, 기능 관리자나 프로그램 매니저와 같은 많은 그룹의 사람들을 교육했다. 스크럼마스터 자격증을 취득할 수 있게 교육을 지원했고, 애자일 도서들을 구입해 사무실에 배치했다. 스크럼 마스터 자격증을 취득하기 위해 2일 동안 스크럼 교육을 진행하고 시험을 보게 했다. 이 시험은 결과에 따라 스크럼 마스터(Scrum Master)나 스크럼 개발자(Scrum Developer)와 같은 자격증을 수여한다. 약 200만원의 교육비를 내서 이틀 정도의 교육을 수료하면 자격증 시험에 응시할 수 있는 자격을 부여한다. 한국에는 아직 담당 기관이 없다. 세일즈포스에서는 세 명의 주요 구성원이 있었는데 이 구성원들이 통합된 교육자료를 만들었고 사내 스태프들을 위한 교육을 진행했다. 교육 내용은 스크럼과 XP(eXtreme Programming) 그리고 린(Lean) 방법론 등이었다. 그들은 각 팀마다 2시간 정도 애자일 교육을 진행했다. 추가로 스크럼 제품 책임자(Product Owner) 교육을 제공했고, 또한 현장에서 업무량을 산정 (Estimation)하는 방법과 계획하는 방법에 대한 교육도 했다. 

산정이란, 기존에 정해진 업무의 복잡도를 평가하면서 한 단위의 사용자 스토리가 얼마만큼 걸리게 될지를 산정하게 되는데 이 미팅으로 팀원 모두가 참여해서 각 업무별로 복잡도와 걸릴 시간들을 측정하는 것을 이야기 한다. 그들은 또한 내부적으로 위키 기반의 웹사이트를 만들어서 애자일을 도입하는데 필요한 모든 지식들을 공유했고 새로운 개발방법론에 대한 중요한 추가적인 자료들을 공유했다.

애자일 도입 팀은 스크럼을 사용해 하루 단위의 결과를 만들어 공유하는데 초점을 맞추었다. 그리고 모두가 보고 공유할 수 있는 제품의 전체 스케줄을 만들었고 전체 조직들에 거쳐서 애자일의 비전을 전달하고 성공도를 모니터 했다. 그리고 애자일을 도입하는 데 있어서 시스템적인 장애들을 제공하려고 노력했고, 전문적 자료들을 전달함과 동시에 가이드와 교육을 진행했다. 공개된 몇몇의 성공 요인들을 정리해 보자면 다음과 같다.

- 개인의 생산성 보다는 팀의 처리량에 초점을 맞추는 것

- 각 기술 별로 나뉘어진 팀들은 매일 만나서 진행하는 미팅

- 공통으로 사용하는 언어의 정의와 간단한 애자일 프로세스

- 모든 팀 별로 일들의 명확한 우선 순위 리스트

- 사용자 스토리와 새로운 업무 측정방법의 정의

- 빌드 속도와 유연성에 초점이 맞추어진 자동화 팀

- 제품과 릴리즈의 완성도를 하루 단위로 확인할 수 있는 도표

- 스크럼을 이용한 제품 라인과 주별로 모든 팀이 볼 수 있는 어떤 결과물

- 넓은 분야의 스프린트 리뷰와 매달 진행하는 회고

- 제품 책임자(Product Owner)와 스크럼 마스터(ScrumMaster)들의 주기적 미팅

- 큰 릴리즈를 앞두고 정확한 시간 단위로 정확하게 만들어지는 작은 릴리즈

- 약 1500개 이상의 버그의 감소

- 매달 진행되는 잠재적인 제품들의 릴리즈

물론, 지금도 세일즈포스 조직은 계속해서 애자일을 연구하고 있다고 밝혔다.

세일즈포스만의 성공전략

세일즈포스와 같은 대규모의 조직이 어떻게 애자일을 자연스럽게 도입하고 또 성공할 수 있었을까? 무엇보다도 먼저 높은 직위의 사람들의 적극적인 지원이 있었다는 것이고, 이런 변화를 주도하는 팀을 만든 것을 가장 큰 이유로 꼽고 있다. 단순한 기법을 넘어 기본 원칙에 집중했고, 일찍이 자동화와 지속적인 통합(Continuous Integration)에 집중했다는 것이 중요하다. 이들은 애자일을 도입하는데 있어서 필요한 의사 결정을 철저히 투명하게 진행했고, 외부의 애자일 트레이닝과 교육을 적재적소에 잘 이용했다. 먼저 높은 사람들의 변화에 대한 지원에 대한 부분을 살펴보자. 이것은 큰 조직이 변화를 추진하는 데 있어 가장 필수적인 조건이기도 하다. 만약 임원 레벨에서의 변화에 대한 지원이 없었다면 아마 애자일 프로세스는 실패하고 말았을 것이다. 예를 들어 세일즈포스의 임원들은 각 릴리즈의 내용에 상관없이 굉장히 터프한 일정을 꽂아 넣었다. 비록 많은 팀들이 개발 주기에 대해서 불평했지만 관리팀들은 그 릴리즈 날짜를 지키고 새로운 개발 방법론으로 옮겨 갈 수 있게 독려했다. 완벽하지는 않더라도 일찍 결과물을 전달할 수 있었고, 필요 없는 것을 만드는 것을 어느 정도 막을 수 있었다. 두번째 성공 요소는 실행 팀의 헌신이 존재했다는 것이다. 실행 팀들은 모든 조직들을 통합할 수 있는 권한이 있었다. 팀 구성원들은 각 영역별로 다양한 사람들을 추천해 구성했다. 예를 들어 QA팀, 개발조직, 개발 관리팀, 제품 관리팀, UX팀 그리고 임원의 구성원들로 구성했다. 이 팀은 무엇보다도 어떤 결정을 만들고 새로운 방법론을 적용할 수 있는 권한이 있었고 공공장소에서 미팅을 실행하였다. 이 팀은 항상 투명하게 미팅 내용들을 투명하게 공유했고 누구나 쉽게 의견을 전할 수 있게 오픈했다. 뿐만 아니라 이들은 업계의 전문가들과 연결되었고, 비슷한 기술 회사들의 전문가들과 의견을 주고 받을 수 있었다.

세번째는 단순한 기술을 넘어 원칙에 집중하는 것이다. 어떤 기업이 애자일을 맹목적으로 도입해서는 성공하기 힘들다. 그것보다 왜 그 기업이 애자일 프로세스를 진행해야 되는지에 대한 이유를 이해하는 것이 가장 중요한 일이다. 기존 문제를 해결하기 위한 어떤 해결방안으로 접근하기 어려워질 경우에 그 팀들은 애자일이 전혀 도움이 되지 않는다고 불평의 목소리를 낼 수도 있고 또 이전 패턴과 비교하면서 새로운 패턴을 거부하게 될 것이다. 

하지만 세일즈포스의 실행 팀들은 애자일의 기본 원칙인 커뮤니케이션, 지속적인 통합, 고객들에게 빠른 전달과 피드백과 같은 원칙들을 제공하려고 노력했다. 이들은 기술 팀들에게 애자일의 목표들과 원칙들의 인쇄물들을 만들어서 공유했다. 네번째는 자동화다. 대규모의 자동화 도구와 빌드 시스템은 일찍이 존재했고 변화에 큰 도움을 줬다. 그들은 CI(Continuous Integration) 시스템, ‘지속적인 통합’이라는 툴을 가지고 있었고, 개발 조직 전체적으로 기능과 단위별 테스트를 자동으로 할 수 있었기 때문이다. 기존에 가지고 있는 시스템을 다시 만들기 보다는 개선하면서 지원하고자 노력했다. 그 결과 보다 철저한 코드 라인을 생성하는 데 집중할 수 있었다. 실제 통합 테스팅 시간을 줄일 수 있었으며 코드를 하나로 통합할 수 있었다. 그들은 높은 효율을 만들기 위해 자동화된 빌드시스템을 이용하기보다는 자주 체크인 하고 자주 테스트 할 수 있도록 하는 시스템이 필요했다. 이러한 짧은 프로세스들은 짧은 개발과 짧은 테스트 주기를 가능하게 했다.

다음은 철저한 투명도이다. 그들이 애자일을 도입하는 동안에 모든 것을 투명하게 한 것이 성공의 키였다. 무엇보다도 그들은 매일 공공 장소에서 미팅을 진행했고, 모든 사람들이 진행과정을 지켜 볼 수 있었다. 그리고 그들의 카페 같은 곳에 업무보드를 비주얼적으로 볼 수 있게 제공하였기에 누구나 그 정보들을 쉽게 볼 수 있었다. 

항상 모두의 계획과 정보 그리고 비전들을 과할 정도로 나눴다. 그들은 일자별 진행도를 만들어서 R&D 전체 팀이 실제 릴리즈를 위한 진행과정(실행 결과, 테스트 결과, 버그 수, 개발활동)을 체크할 수 있게 하였다. 이렇게 일자 별로 제공되는 오픈된 정보들은 모두에게 그들의 능력과 모든 팀들의 역량을 확인할 수 있는 중요한 정보였다. 

마지막으로 애자일 교육에 대한 부분이다. 애자일 도입에 큰 기여를 한 부분이다. R&D의 약 25%나 되는 인원을 애자일 교육에 투자했다. 전문가 교육을 지원했을 뿐만 아니라 팀 내 스크럼 마스터와 제품 책임자 들을 지원할 외부의 컨설턴트들을 고용했다. 아마 국내에서는 교육비용 때문에 선뜻 이 변화를 받아드리기 어려웠을 수도 있다. 하지만 이런 교육들을 통해 애자일 원칙들을 잘 자리잡았고 모든 팀들을 지원하면서 확장했다. 외부 교육뿐만 아니라 조직내의 모든 구성원들에게 애자일 성공 스토리와 다른 회사들이 진행했던 노하우 등을 공유했다. 이러한 활동들을 통해서 몇몇 팀들은 스스로 2주 기반의 주기를 만들고, 보다 나은 결과물을 전달하는 데 초점을 맞추었다. 즉 애자일이 단, 소수의 리더만으로 성공하기 어렵다는 것을 잘 보여주고 있는 것이다.

일찍 알았으면 좋았던 것들

세일스포스가 애자일을 도입하면서 초기에 목표했던 보다 주기적인 제품의 배포, 스스로 일하게 되는 팀들, 자동화, 눈에 보이는 결과물과 같은 것들을 달성했다. 여기에 더해 그들 스스로 일찍 시도했으면 더 큰 도움이 되었을 것이라고 밝힌 것들이 있다. 진행하고 나니 왜 그때 몰랐을까 했던 것들이다. 다음 여섯 가지를 살펴본다.

1. 일찍 애자일 도입 피드백에 귀 기울이는 것

2. 제품 책임자를 일찍 교육 시키는 것

3. 외부의 코치들을 일찍 섭외하는 것

4. 자동화 부분을 보다 일찍 시작하는 것

5. 경영진들에게 애자일 도입에 대한 구체적인 업무들을 요청하는 것

6. 조금 더 클리어하게 애자일의 역할이 무엇인지를 전달하는 것

세일즈포스는 초기에 애자일 도입에 필요한 주요 스태프들로부터 피드백을 많이 받지 못했다고 말한다. 모든 구성원들을 참여시킬 수 있는 하나의 좋은 방법은 열린 공간에서 미팅을 진행하는 것이다. 여러 방법들 중 하나를 소개하면 먼저 모두에게 쪽지나 포스트잇을 나누어주고 하나의 토픽 안에서 자기가 생각하는 세가지 문제들을 적게 하는 것이다. 그 문제들의 테마 별로 그룹을 만들게 하고 거기서 제시한 해결 내용들을 애자일 진행 팀에서 수집하여 반영하는 방법이다. 세일즈포스는 이러한 처리 과정들을 애자일 도입 뒤에 시작했지만 일찍 도입할 수 있으면 충분히 좋았을 것이다.

두 번째는 제품 책임자들의 교육 시기를 앞당기는 부분이다. 보통 애자일 도입에 있어서 가장 중요한 성공의 열쇠는 바로 제품 책임자에게 달려있다고 많이 이야기한다. 하지만 초창기 세일즈포스도 이 말의 진정한 뜻을 처음에는 이해하지 못했다고 했다. 제품 책임자는 모든 계획에 우선순위를 부여해야 하고 릴리즈를 어떻게 가져갈지를 결정해야 한다. 뿐만 아니라 그렇게 계획한 스케줄에서 매일 팀들과 커뮤니케이션 해야 하면서 기능들을 점검해야 하는 것이다. 또한, 모든 애자일의 시작은 제품 책임자로부터 시작된다. 예를 들어, 제품 책임자는 제품 백로그(유저스토리들과 처리해야 할 일들의 리스트)를 만들어야 하고 사용자 스토리를 디자인 하고 또 복잡도를 평가하고 계획해야 하는데 이 모든 것이 제품 책임자에게 있다는 것이다. 제품 책임자의 초기 교육을 넘어서 새로운 프로세스와 문화를 도입하기 위해서 지속적으로 제품 교육자를 애자일 도입에서 교육을 진행하는 것이 필수적이다.

세번째는 일찍이 외부의 컨설팅 인력을 섭외하는 것이다. 몇몇의 외부 전문가들은 그들을 더 빠르게 갈 수 있는 방법들을 인지할 수 있었다. 그들은 또한 이미 다른 회사에서 애자일을 시도하면서 쉽게 실수하는 부분들을 알고 있었기에 그런 것들을 쉽게 고쳐줄 수 있었다. 무엇보다도 내부적으로도 외부의 조언과 의견들을 더 쉽게 귀담아 들으려고 하기도 했다. 

네번째는 자동 빌드와 테스트 시스템을 일찍 셋업하는 것이다. 자동화가 애자일 기법에 있어서 가장 핵심적인 부분이 자동화 부분이고 전체 조직들에게 눈으로 확인할 수 있는 제품을 자동화를 통해서 전달하는 것이다. Salesforce.com은 JUnit 기반의 기능에 많은 투자를 가졌고 또한 통합에 실패한 리스트를 유닛 테스트들 기반으로 가져갈 수 있었다.

다섯 번째는 회사 임원들에게 애자일 도입에 대한 구체적인 업무들을 요청하는 것이다. 세일즈포스 임원들은 성공의 주요 요소였다. 임원들에게 애자일 도입에 필요한 작은 혹은 큰 업무들을 전달하는 것을 통하여 조직적인 변화를 가속화 시킬 수 있었다. 마지막은 애자일의 역할을 모다 명백하게 정의하는 것이다. 팀들을 스스로 일할 수 있도록 하는 것은 굉장히 중요한 부분이고 실제로 팀 구성원들에게도 열정을 전달할 수 있는 방법이기도 하다. 세일즈포스 또한 스스로 일하는 문화의 정립을 인식하고 있었다. 그 결과 어떤 일을 할당하고, 일을 완료한 뒤 보고하고, 또 할당하는 작업을 진행하려 하지 않았다. 이미 완료한 일을 확실히 정의하고 팀들의 이해범위 안에서 이미 처리된 것과 처리되지 않은 것을 스스로 결정하게 했다. 이러한 작업을 통해 팀에게 보다 유연하게 스프린트 목표들을 수행할 수 있을지를 이해하는 데 도움을 주게 되는 것이다. 또한 다른 중요한 점은 주요 임원들과 각 기능별 매니저들이 스프린트 경계 안이 아닌 밖의 경계에서 수정사항들을 제시해야 된다는 것이다.

세일즈포스를 통해서 얻을 수 있는 교훈들

세일즈포스의 애자일 사례를 통해서 우리는 많은 교훈들을 얻을 수 있다. 무엇보다도 새로운 팀으로 애자일의 도입을 고려하고 있다면 다음의 교훈들을 참고하면 좋다.

- 애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것

- 전문가의 도움을 얻는 것

- P2P처럼 개개인이 서로 코치할 수 있게 하는 것

- 여러 개의 팀을 뛰어나게 만드는 것

- 회사 레벨의 스프린트를 만드는 것

- 일찍 필요한 도구를 만드는 것

- 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것

- 실수를 인정하고 그것에 관대해지는 것

하나의 요소 별로 살펴본다. 

● 애자일을 도입을 진행할 헌신적이고 모든 권한을 가지고 있는 팀을 만드는 것

중앙에서 변화를 관리하는 조직이다. 이 조직 내에서 모든 조직들과 커뮤니케이션이 가능해야 하고, 만약 어떤 조직에서 문제가 생겼거나 했을 때 쉽게 접근할 수 있어야 한다. 더 중요한 것은 변화들에 대해서 충분히 커뮤니케이션을 해야 한다는 것이다. 회사 전체가 한번에 모두 변화를 진행한다고 두려워할 필요는 없다. 많은 사람들이 먼저 한 팀에서 시범 운영을 진행하고 그 다음에 천천히 다른 팀들에게 전달해 나가도 된다고 말할 것이 분명하다. 하지만 회사 전체가 모두 한번에 변화를 진행하는 것도 가능하고 이 방법이 더 큰 이익들을 가지고 온다. 먼저 한 팀만 진행할 경우 이미 다른 조직들과의 커뮤니케이션이 필요한 경우에 커뮤니케이션을 원활하게 해주는 애자일 효과를 누리기 힘들다는 문제가 있다. 하지만 회사 전체적으로 애자일을 도입할 경우에 전체 조직이 같이 참여하여 원활한 커뮤니케이션과 각 조직별 도움을 제공할 수 있다.

● 전문가의 도움을 얻는 것

외부 전문가들은 이미 우리가 경험할 장애물들을 전에 경험했을 뿐만 아니라 다른 회사들로부터 비슷한 사례의? 있다. 그들은 지금 회사에서 사용자 스토리들이나 업무산정과 계획 등과 같은 새로운 영역의 프로세스를 도입할 때 도움을 줄 수 있다.

● P2P처럼 개개인이 서로 코치할 수 있게 하는 것

먼저 각자 팀에서 이미 일찍 애자일 방법론을 경험했거나 다른 조직과 팀에서 성공을 경험한 구성원들을 찾을 수 있을 것이다. 이러한 구성원들은 개인적인 경험들을 나눌 수 있고 또한 우리가 보지 못한 실수들을 보는 것이 가능할 것이다. 

● 여러 개의 팀을 뛰어나게 만드는 것

때로는 우리의 시선이 고군분투하는 팀들에 초점이 맞추어지는 경우가 많이 있다. 하지만 그 초점을 성공적인 여러 팀들에게 맞추어지다 보면 탄력을 만들 수 있고 새로운 프로세스들을 잘 정착한 팀들의 본보기를 찾아낼 수 있을 것이다. 때문에 주변에 성공한 팀들이 생겨나다 보면 많은 팀들이 조언을 얻어서 잘못된 부분들이 자연스럽게 개선되는 것을 볼 수 있다.

● 회사 레벨의 스프린트를 만드는 것

세일즈포스는 한 달에 한번 스프린트 주기를 만들었고 모든 팀들이 같으 주기를 가지고 있었다. 이것은 세일즈포스의 스프린트 리뷰들이 한달 이라는 경계 안에서 같이 진행될 수 있게 해주었고 임원들과 팀들이 모두 어떤 것들을 진행했는지 발표하는 것을 가능하게 해주었다. 또한 모든 제품 라인이 매 달 탄력을 받을 수 있었다. 많은 팀들이 2주라는 내부 스프린터 주기를 가지고 있었기 때문에 4주 단위로 진행하는 회사단위의 리뷰를 진행하는 것이 가능했다.

●일찍 필요한 도구를 만드는 것

세일즈포스는 개발을 관리할 수 있는 애자일 툴을 직접 만들었다. 엑셀과 같은 시트는 쉽게 관리가 어려워지기 때문에 그들이 직접 만든 제품을 이용하는 것이 많은 이익을 가지고 왔다. 

<그림 2>는 세일즈포스가 처음 애자일을 도입할 때 자체적으로 만든 스크럼포스라는 툴이고 모든 팀 구성원들과 스크럼마스터 그리고 제품 책임자가 업무들을 관리할 때 사용한다. 기능 매니저들은 여기서 제공하는 레포트 기능을 이용해서 팀을 관리하고 또 릴리즈를 관리했다. 이 툴은 Salesforce.com 에서 제공하고 있는 플랫폼이기 때문에 모든 개발자가 매일 그들의 제품을 이용하는 이유를 주기도 할 것이다. 세일즈포스의 툴은 사용자 스토리의 우선순위를 드래그&드랍 하면서 수정할 수 있는 기능을 제공하고 있고, 업무를 관리하고 업무진행 과정을 볼 수 있는 차트도 지원하고 있다. 물론, 이 툴 외에도 굉장히 많은 애자일 프로젝트 관리 툴들이 있기 때문에 조사하면 대등한 툴들을 쉽게 찾을 수 있을 것이다.

● 진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것

진행사항을 눈으로 직접 볼 수 있게 하는 것은 구성원들이 가지고 있는 특정 정보를 넓게 공유하는 것에 대한 두려움을 극복하는데 도움을 준다. 변화라는 것 자체가 굉장히 어려운 부분이 있고, 또 모든 사람들이 이메일을 읽지 않는 부분이 있다. 그래서 커뮤니케이션에 대한 여러 채널을 가지는 것과 같은 메시지들을 그 채널들을 통해서 반복적으로 전달하는 것이 굉장히 도움이 되었다. 즉, 만약 자신의 팀들이 새로운 방법론과 진행 프로세스에 대해서 잘 이해하고 있는 만큼 더 자주 커뮤니케이션을 진행할 필요가 있다. 

● 실수를 인정하고 그것에 관대해지는 것

애자일을 도입할 때 실험적인 문화 안에서 서로를 격려하는 것이 중요하다. 대부분의 사람들이 조직을 딱 맞는 애자일 방법론을 도입하는 것이 힘들 수 있기에 실수는 어떻게 보면 당연히 수반되는 결과일 수 있다. 팀 안에서의 사람들에게 보상을 하되 실수에 대한 어떤 불이익을 가지게 하는 것은 옳지 않다.

정리

지금까지 세일즈포스라는 큰 연구 조직을 기존 워터폴 개발방법론에서 애자일을 도입해 전환하기까지의 노하우들을 담았다. 세일즈포스가 이야기 하고자 했던 가장 중요한 포인트는 바로 애자일을 도입하고자 한다면 몇몇 팀이 아닌 모든 팀들이 한꺼번에 애자일을 실행한다면 큰 시너지를 얻을 수 있다는 것이다.

출처 : 마이크로소프트웨어 11월호

제공 : 데이터전문가 지식포털 DBguide.net