애자일 도입에 있어서 큰 기업일수록 그 결정이 더욱더 신중해질 수 밖에 없는 것이 사실이다. 무엇보다도 큰 변화에 따른 회사의 리스크가 가장 큰 부담이기 때문이다. 하지만 철저한 동기부여와 준비가 뒷받침 하며 그 리스크를 최소화하는 것이 가능하다. 애자일은 팀 멤버들의 동기부여와 더불어 모두 애자일에 익숙하지 않으면 큰 성과를 당장 기대하는 것에는 한계가 있다. 만약 모든 팀이 애자일을 도입하면서 여러 팀들의 노하우를 서로 배울 수 있다면 어떠할까? 이번 사례에서는 대규모의 집단이었지만 애자일을 모든 팀이 한번에 도입하면서 변화를 시도한 사례를 살펴볼 것이다. 바로 세일즈포스라는 기업이다.
세일즈포스는 CRM(고객 관리 솔루션)을 클라우드 컴퓨팅 서비스 형태로 제공하는 기업이다. 비즈니스 응용프로그램 및 응용프로그램 플랫폼을 인터넷으로 제공하고 있다. 이 회사는 1999년 3월에 마크 베니오프가 설립하였고 현재 만명 이상의 직원들이 일하고 있다. 국내에서도 세일즈포스 제품은 큰 인기를 얻고 있으며 전세계적으로 굉장히 많은 고객을 두고 있다.
세일즈포스는 3개월에 거쳐서 약 200명 규모의 팀들에 애자일 방식을 도입하는데 성공했다. 이 사례는 애자일 도입에 있어서 가장 크고, 빠르게 도입된 사례들 중 하나로 손꼽힌다. 세일즈포스의 애자일 도입 사례가 처음 알려진 것은 2007년도에 프라이 그린(Fry Greene)이 애자일 커뮤니티에 자신의 회사에 대한 사례를 공유하면서 빠르게 퍼져나갔다. 만약 애자일 도입을 고려하고 있는데 어떻게 도입을 해야 할지 고민하고 있는 조직이라면 굉장히 좋은 참조 모델이 될 수 있을 것이다. 특히나, 대규모 조직을 교육하고 혁신을 이루기 위해 어떻게 준비하여 실행에 옮겼는지를 확인해 볼 수 있을 것이다. 뿐만 아니라 그들이 애자일 프로세스를 선택하게 된 이유와 어떻게 도입에 성공할 수 있었는지, 또 도입 후에 어떻게 확장해 나갔는지에 대해서 배울만한 내용을 공유해보도록 하겠다.
먼저 세일즈포스는 3개월이라는 짧은 기간 안에 30개의 팀들을 워터폴(Waterfall) 개발 방법론에서 애자일 방법론으로의 변화시키려고 했다. 무엇보다도 그들이 처음에 집중했던 것은 확실한 개발주기와 투명성 그리고 스스로 일을 진행할 수 있는 팀을 만드는 것이었다. 세일즈포스는 애자일을 도입하면서 6개월 동안 자체적인 기존 개발 프로세스를 벤치마크 했었고 두 개의 메인 릴리즈를 완성했으며 또, 매달 코드의 배포가 가능하게 진행했다.
그들은 애자일을 도입하기 전에 애자일의 원칙들을 먼저 리뷰했다. 애자일의 원칙 중에 보면 팀이 어떤 사람의 압력과 요구로 이루어지는 것이 아닌 팀은 스스로 움직여야 한다는 요구사항이 있었는데 그들은 신중한 결정을 내리기 위해서 스태프들을 대상으로 설문 조사를 했다고 한다. 그 설문조사의 결과 87% 가량의 개발 구성원들이 스크럼 팀이 스스로 알아서 움직일 수 있는 팀이라고 믿고 있었고, 80% 정도의 기술 스태프들이 새로운 개발 방법론이 자신들의 팀을 보다 효율적으로 만들 수 있다고 답했다.
그들은 지금도 지속적으로 개발 조직을 개선하기 위해서 노력하고 있을 뿐만 아니라 명확한 데이터와 자료를 기반으로 올바른 결정들을 내리고 있다. 여담이지만 많은 기업들이 자료조사는 진행하지만 확실히 내려야 하는 결정 앞에서는 확신이 없어서 망설이는 경우가 많이 있다. 하지만 세일즈 포스는 충분한 자료조사를 기반으로 과감한 결정을 실행해 옮길 수 있는 점을 보여주고 있다. 그럼 세일즈포스가 애자일을 도입하게 된 배경부터 살펴보도록 하자.
도입 배경
세일즈포스는 고객의 필요에 따라서 서비스를 확장하는 온디맨드 서비스에 있어서 시장 선도와 기술 리더로 발돋움 하였고 지금도 계속해서 정상의 자리를 지키고 있다. 세일즈포스에서는 매일 같이 8천5백만 결제가 이루어지고 있고, 약 65만명의 구독자들을 가지고 있다. 즉, Salesforce.com이라는 웹사이트는 CRM 솔루션을 제공하는데 사용자의 요구에 맞추어 개발된 플랫폼이다. 국내에서도 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 그룹의 중요성에 대해서 이미 인지가 되고 있었다는 것이다.
이 변화에 있어서 가장 중요한 부분은 어떻게 소프트웨어를 개발할지에 대한 계획이 아니라 이러한 개념들을 어떻게 기술 조직들에게 전달하느냐는 것이었다. 한명의 팀 구성원이 새로운 개발 프로세스를 설명하는 문서를 작성했는데 여기서 이 프로세스의 장점들과 왜 우리가 이 오래된 개발 프로세스에서 변화가 필요한지에 대한 이유를 기술하게 했다. 더불어 각 조직 별로 모든 레벨의 핵심 구성원들과 한 시간 정도의 미팅을 45번이나 가졌고, 이런 미팅에서 나왔던 피드백들을 모두 문서에 기록했을 뿐만 아니라 새로운 프로세스의 디자인의 모형들과 조직 별로 다르게 적용해야 되는 변화들도 기록했다. 이렇게 오픈 된 커뮤니케이션들의 피드백들의 반복들을 통해서 모두가 새로운 개발 프로세스를 정립하는데 목소리를 내게 하는데 결정적인 역할을 했다고 이야기 한다. 초기 문서에 포함되었던 두 가지 중요한 포인트는 먼저 사용 가능한 프로세스들의 디자인을 통합하기 위한 계획이었고 두 번째는 각각의 주요 릴리즈 별로 우리가 얼마만큼의 시간을 필요로 했는지에 대한 내용을 담았다.
이 문서를 정리하면서 두 가지 도입방법을 고려했다. 첫 번째는 시범적으로 도입해서 점진적으로 천천히 결과를 내보자는 것이고 또 다른 것은 한꺼번에 모든 팀들에게 적용해서 바꾸자는 것이었다. 이 큰 변화를 도입하는데 있어서 가장 중요한 요소는 바로 조직간의 불협화음을 피하는 것이고 이러한 변화에 대한 갈망이 팀에 있냐는 것이었는데 다행히도 대부분의 팀 원들이 같은 시간에 같이 도입하고 싶어 했다.
그래도 논쟁이 없었던 것은 아니었다. 주된 논쟁은 만약 모든 팀들이 한꺼번에 새로운 프로세스를 도입할 경우에 몇 개의 팀들이 시범적으로 도입하는 것에 비해서 같은 실수들을 하게 될 경우가 많다는 것이고 매일 모든 팀들을 지원할 코치 인력들이 부족하다는 것이다. 하지만 여기에 희망스러웠던 것은 한 팀이 스크럼(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주 단위로 진행하는 회사단위의 리뷰를 진행하는 것이 가능했다.
일찍 필요한 도구를 만드는 것
세일즈포스는 개발을 관리할 수 있는 애자일 툴을 직접 만들었다. 엑셀과 같은 시트는 쉽게 관리가 어려워지기 때문에 그들이 직접 만든 제품을 이용하는 것이 많은 이익을 가지고 왔다.
[그림1] 세일즈포스의 애자일 툴 (스크럼포스)
[그림1]은 세일즈포스가 처음 애자일을 도입할 때 자체적으로 만든 스크럼포스라는 툴이고 모든 팀 구성원들과 스크럼마스터 그리고 제품 책임자가 업무들을 관리할 때 사용한다. 기능 매니저들은 여기서 제공하는 레포트 기능을 이용해서 팀을 관리하고 또 릴리즈를 관리했다.
이 툴은 Salesforce.com 에서 제공하고 있는 플랫폼이기 때문에 모든 개발자가 매일 그들의 제품을 이용하는 이유를 주기도 할 것이다. 세일즈포스의 툴은 사용자 스토리의 우선순위를 드래그&드랍 하면서 수정할 수 있는 기능을 제공하고 있고, 업무를 관리하고 업무진행 과정을 볼 수 있는 차트도 지원하고 있다. 물론, 이 툴 외에도 굉장히 많은 애자일 프로젝트 관리 툴들이 있기 때문에 조사해보면 대등한 툴들을 쉽게 찾을 수 있을 것이다.
진행사항을 눈에 볼 수 있게 하는 것과 최대한 많은 커뮤니케이션을 만드는 것
진행사항을 눈으로 직접 볼 수 있게 하는 것은 구성원들이 가지고 있는 특정 정보를 넓게 공유하는 것에 대한 두려움을 극복하는데 도움을 준다. 변화라는 것 자체가 굉장히 어려운 부분이 있고, 또 모든 사람들이 이메일을 읽지 않는 부분이 있다. 그래서 커뮤니케이션에 대한 여러 채널을 가지는 것과 같은 메시지들을 그 채널들을 통해서 반복적으로 전달하는 것이 굉장히 도움이 되었다. 즉, 만약 자신의 팀들이 새로운 방법론과 진행 프로세스에 대해서 잘 이해하고 있는 만큼 더 자주 커뮤니케이션을 진행할 필요가 있다.
실수를 인정하고 그것에 관대해지는 것
애자일을 도입할 때 실험적인 문화 안에서 서로를 격려하는 것이 중요하다. 대부분의 사람들이 조직을 딱 맞는 애자일 방법론을 도입하는 것이 힘들 수 있기에 실수는 어떻게 보면 당연히 수반되는 결과일 수 있다. 팀 안에서의 사람들에게 보상을 하되 실수에 대한 어떤 불이익을 가지게 하는 것은 옳지 않다.
정리
지금까지 세일즈포스라는 큰 연구 조직을 기존 워터폴 개발방법론 방식에서 애자일을 도입하여 전환하기까지의 노하우들을 담아보았다. 세일즈포스가 이야기 하고자 했던 가장 중요한 포인트는 바로 애자일을 도입하고자 한다면 몇몇 팀이 아닌 모든 팀들이 한꺼번에 애자일을 실행한다면 큰 시너지를 얻을 수 있다는 것이다.
참고주소
Agile Methodology at Salesforce, an Inside Look
http://sforce.co/1tq6k1X
Salesforce.com Agile Transformation - Agile 2007 Conference
http://slidesha.re/1s2zxPU
