애자일이 성공하기 위하여 적합한 조직 문화, 프로젝트 환경, 팀원의 능력, 개발 환경 등과 같은 관점에서의 논의들을 보아 왔었는데 아래는 애자일 도입에 실패하는 원인으로 조직이 소프트웨어 개발을 투자로 보는가 혹은 비용으로 보는가로 설명하고 있습니다.
 
X와 Y라는 2개의 회사가 있습니다. X는 소프트웨어 개발을 미래를 위한 투자로 인식하는 반면 Y는 시간에 묶어 관리되어야 하는 비용으로 인식합니다. X는 팀에, Y는 프로젝트에 돈을 제공합니다.
In company X the software development effort is viewed as an investment, indeed the primary investment, in the company's future. In company Y the development effort is a small application and is viewed as an expense to be time bound and tracked. In company X the team is funded. In company Y the project is funded.

결론은? X는 애자일에 성공하지만 Y는 애자일에 실패합니다.
In company X agile will succeed. In company Y agile will fail.

X는 지속적인 소프트웨어 개발을 해나가지만 Y는 정해진 기간과 예산에 따라 프로젝트를 평가합니다.  애자일은 짧은 반복 주기에 따라 해당 시점에 개발 주기만을 예측하여 비지니스 가치를 지속적으로 더해가야 하는데 한번에 모든 개발 비용과 기간을 산정하여 종료 시점을 정해놓고 더 이상 투자를 하지 않는 고정예산 방식으로 통제를 하면 실패한다는 것입니다. 특히 애자일은 프로젝트가 아닌 장기적 관점에서의 소프트웨어 개발 노력을 요구하기 때문에 경영자들이 애자일의 도입이 조직의 예산관리 시스템과는 전혀 무관하다고 생각하는 것이 문제라고 지적하고 있습니다. 이외에도 스토리 포인트, 스크럼 마스터와 PM, 일일 스탠드업 미팅, 반복 개발 리뷰, 반복 개발 수립, 번다운 차트에 대해서도 의견을 주고 있습니다. 원문을 클릭하면 아티클을 볼 수 있습니다.  

기업의 사업모델 변화라서 주제와는 거리가 있기는 하지만, Vijay Govindarajan은 "늙은 코끼리를 구하는 10가지 방법"에서 기업이 전략적 혁신을 성공하기 위해 필요한 3가지 조건을 "잊기", "빌려오기", "학습하기"라고 제시하고 있습니다. 잊기는 기존에 성공했던 방식과 방법, 관행, 시장을 잊어버리는 것입니다. 
애자일을 적용하는데 기존의 프로젝트 관리 방식으로 성과를 비교하고 단기간에 ROI를 따져보기 보다는, 애자일을 통해 변화된 긍정적인 측면이 무엇인지 살펴보고 이것들이 가져올 수 있는 효과와 성과를 좀더 장기적 관점에서 바라볼 필요가 있습니다.

조직의 계층이 복잡하고 많을수록 경영진의 비전과 전략이 아래까지 전달되기 못하고 실무자의 의견과 생각이 위로 잘 올라가지 못한다. 작은 규모에서 혁신적이던 기업도 점차 인원이 늘어나고 규모가 증가하면 조직내부의 이런 저런 문제점과 이를 해결하기 위한 조직변화에 어려움을 겪게된다. 
사실 생산성, 품질, 비용과 같은 표면적이고 결과적인 요인보다는 사람과 문화, 권력과 정치와 같은 내부적이고 근본원인이 되는 요인들이 조직변화에 가장 어려운 부문이다. 위에서 개선을 하려고 보니 정작 자신의 기득권을 포기해야 하는 즉, 자기가 자기 목을 쳐야 하는 변화의 패러독스가 발생한다. 관리자가 관심을 보이지 않아도 근무 시간을 쪼개고 야근도 마다않고 팀에서 자발적으로 개선을 하던 직원이 전사적으로 이를 목표로 잡아 숫자로 실적을 보고시키자 수동적으로 변해버리기도 하고, 품질관리자에서 경영진으로 승진하고 나서는 품질을 무시하고 결과만을 재촉하는 경우도 보았다.

코스닥에 상장된 임베디드 소프트웨어 개발업체에 프로세스 개선을 자문하면서 위에서는 부사장이 예비 미팅에 한번 참석하고는 이후 위에서는 전혀 참석이나 관여가 없어 개선 범위와 결과를 많이 줄여버렸다. 위에서 관심이 없다면 씨앗을 뿌리고 가능하다는 인식을 해주는 정도를 넘어가기 어렵다고 생각했기 때문이다. 그 반대로 경영진이 전폭적 지원을 하는 반면 조직원의 관심이 거의 없고 형식적으로 참여하는 경우 어떻게든 원하는 결과는 내놓게되지만 그 이상은 기대하지 않는다. 경영진이 바뀌거나 조직이 변경되면 그 개선 활동은 유지되지 못할 것이기 때문이다.

PDCA, Six Sigma, ISO 9001, ITIL, SPICE(ISO/IEC 15504), CMM(I), 등과 같이 소프트웨어 프로세스를 개선하기 위한 다양한 방법과 개선 모델들이 있다. 개선 모델들은 소프트웨어 개발 프로세스의 베스트 프랙티스로 이루어져 이를 기반으로 현재의 능력을 개선하거나 평가할 수 있는 잣대로 사용될 수 있다.

프로세스 개선 모델로 가장 폭 넓게 사용되는 CMM(조직의 능력 성숙도 모델)은 소프트웨어를 만들어내는 과정이 개인보다는 조직내 체계화된 프로세스와 규칙에 따라 만들어질 것을 강조한다. 이에 따라 CMM은 아래 Agile Manifesto와 반대되어 무거운 프로세스의 대명사처럼 인식되어진다.  

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

CMM은 메타 모델로 무엇을 해야 하는지에 대한 WHAT을 정의하지 어떻게 해야 하는지에 대한 HOW는 구체적으로 제시하지 않는다. 따라서 조직에서 WHAT을 달성하는 방법은 다양할 수 있다. 다만 필요 이상의 형식적이고 이상적인 요구사항을 조직에 기계적으로 적용을 하다보면 실제 개발과는 단절된 것처럼 느껴지게 된다.

WHAT을 어떻게든 달성해야 하는데 HOW를 모르니, 조직에 맞지 않는 선진 사례를 그대로 베겨버리거나 형식적으로 혹은 결과만 조작하는 경우도 있다. 이것이 개선 모델에만 있는 문제점일까? 실제 무엇과 어떻게를 따로 분리하는 경우, 즉 이론과 실천간에 연계가 없는 경우 지식(베스트 프랙티스)은 고립될 수 밖에 없다. 무엇을 "안다"는 것은 이것을 이해하고 경험하는 과정을 필요로 한다.

단순히 CMM 매뉴얼을 번역하여 전달하고 이를 달성하도록 명령하고 통제하고 점검을 하는 방식으로 프로세스 개선은 이루어지기 어렵다. 개인이나 팀의 독창성이 무시된다면 이들의 참여와 협력을 얻을 수 없다. 개인과 개인, 집단 내 조직 간의 상호작용 과정에서 나오는 협창성(協創性)을 충분히 활용할 수 있어야 한다. 새로운 모델에 따라 모든 것을 버리고 새로 시작하는 것이 아니라 기존의 경험과 지식에 새로운 모델을 융합해 이전의 조직에서 만들지 못했던 가치를 창출하는 활동이다. 

프로세스 개선 과정은 표준화와 개선이라는 지속적 개선(Continuous Improvement)을 활용한다. <Optimization paradox 내의 그림 참조> 개선에는 조직원들의 창의력이 필요하며 조직은 창의력이 발현될 수 있는 제도와 문화, 환경을 만들어 줄 필요가 있다. 많은 조직들이 프로세스 개선에 실패하는 원인이 이러한 협창적 환경이 구성되지 못하여 개선에 대한 조직원의 열정이 식어버리는 것이다. 프로세스 개선에는 기존의 것을 새롭게 볼 수 있는 창의력과 이를 달성하려고 하는 열정이 요구된다.

오픈 소스 커뮤니티인 이클립스(Eclipse)는 소프트웨어 개발 프로세스 프레임워크인 Eclipse Process Framework (EPF)을 제공하고 있습니다. EPF에는 지원 도구와 프로세스를 제공하는데, 프로세스 저작 및 관리 도구인 Composer, wiki, EPF practices와 개발 프로세스로 Open UP, Scrum, XP를 제공하고 개발 method를 묶어 library가 있습니다. 

EPF는 프로젝트를 수행하기 위한 Processes와 개발 기술에 달라지는 기법, 가이드라인, 템플릿, 베스트 프랙티스, 교재, 사례 등을 제공하는 Method contents로 나누어 접근하고 있습니다. 프로세스는 달라도 메소드 컨텐츠는 같을 수 있습니다. 즉, XP와 RUP는 다르지만 리팩토링 기법은 동일하게 사용될 수 있습니다.

 

이러한 method contents와 processes를 조정하고 저작할 수 있는 도구로써 composer를 제공하며 가장 최신 버전은 올 해 10/9일 릴리즈한 1.5.0.4입니다. 물론 무료입니다. RUP(Rational Unified Process)를 써보신 분이라면 Composer에 익숙하실 것입니다. 같은 도구로써 RUP에서도 프로세스와 라이브러리를 프레임워크로 제공하고 이를 저작/관리하는 도구로 Composer를 제공합니다. RUP의 composer는 유료이며 라이브러리가 휠씬 풍부합니다. trial version을 받아 볼 수 있습니다. 

개발 프로세스는 프로젝트, 조직, 사용 기술 등 환경에 따라 달라지고 조정될 뿐만 아니라 경험과 지식이 늘어남에 따라 이를 조직의 자산으로  관리하기 위하여 Composer를 사용합니다. Composer를 통해 프로세스를 publish하여 html로 만들 수 있는데 다운로드 받아 개인 PC에 두고 필요할 때마다 참조한다면 많은 도움이 됩니다. Published 되어 있는 Open UP, Scrum, XP를 다운로드 받아 보시면 개발 프로세스를 공부하고 활용하는데 도움이 될 것입니다.

한국소프트웨어기술진흥협회에서 Agile에 대한 교육이 있네요. 재직자를 위하여 근무시간 이후에 10일간 40시간의 교육과정입니다. 중소기업직원 훈련 컨소시엄에 회사가 가입하면 무료로 교육을 받을 수 있습니다. 교육 목적과 내역은 아래를 참조하시면 됩니다. 교육장소는 송파구 가락시장역의 정보통신산업진흥원 내 교육장입니다.  
국내에 애자일 교육 과정이 드문 현실에서 반가운 소식이네요.

http://edu.kosta.or.kr/modules/course/appl_incu2.html?ID=398