1. 컨설팅 개요

새로운 제품이나 서비스를 개발하는 것은 기존의 비즈니스 프로세스를 전산화하는 것과는 많이 다르다.  신제품 개발에 있어서 구체적으로 부딪치는 문제는 고객 니즈 도출에서부터 제품 개발범위 및 차별화, 혁신성, 기술, 마케팅 전략 등 매우 다양하다. Scrum은 이런 신제품 개발 이슈들을 해결하는 데 효과적인 방법들을 제공할 수가 있다.  예를 들어 고객 니즈만 하더라도 처음에는 나온 요구사항이 개발과정에서 변동되고 시간이 지남에 따라 그 효용성이 달라질 수 있다. 그렇기 때문에 주기적으로 사용자의 피드백을 받아 우선 순위화하는 것이 필요하며 제품의 차별화나 혁신도 Scrum이 갖는 사람들간의 소통과 토론을 통해서 창의적인 제품개발을 지원할 수 있다.

본 컨설팅은 글로벌 SW를 만들고자 하는 신제품 개발팀을 대상으로 적용한 사례이며 참여인원은 4~5개 팀으로 구성된 약 30명 정도이며 전체(2년) 과제기간 중에서 1년이 지난 시점에 Scrum 방법론으로 전환하였다. 처음에는 다소 부담을 가졌지만 지금 이대로는 문제가 있다는 위기의식에 따른 리더의 결단으로 전환하게 되었다.  아래는 컨설팅 목표이다.

 -  개발생산성 및 제품 품질 향상

 -  팀원들의 열정과 적극적인 마인드 고취

- 팀원간 협력 및 전체 팀워크 향상

2. 적용 전 상황

l  장단기 목표 및 일정관리가 불명확

- 장기간의 개발 목표는 있었으나 월별과 같은 단기 개발 목표 및 일정이 구체적이지 않아 개발 진척관리에 어려움이 발생함

- 단기 목표가 명확하지 않다 보니 못해도 팀원들 사이에는 못해도 그만이라는 인식이 만연함

l  구성원들간의 의사소통 부족으로 인한 비효율성 상존

- 회의는 많으나 실질적인 업무 해결 의사소통이 되지 않음

- 기획자와 개발팀간에 소통이 미흡하여 개발 대기시간이나 재 작업이 자주 발생

l  전체적인 품질 및 생산성 측면에서 관리자의 불만족

-수동적인 팀원들의 자세로 인하여 품질 및 성과가 안 좋은 상황이라 관리자와 개발자간에 신뢰가 저하되어 있음

- 품질점검 지적 사항이 많으며 해결이 안되고 있음

3. 수행내용

컨설팅 진행은 프로젝트 리더 및 팀원을 대상으로 Scrum과 Lean 방법론에 대한 교육과 함께 시작하였다.  처음에는 관리자와 팀원들 모두 애자일 사상을 충분히 이해하지 못했기 때문에 초기에는 컨설턴트가 직접 애자일을 리딩하고 멘토링을 진행하였으며 다행히 2달이 지난 시점부터는 프로젝트 구성원들이 애자일 방식에 어느 정도 적응하게 되었으며 자기 조직화된(Self-organizing)  팀 초기단계에 진입하게 되었다.

 l  장단기 개발 목표 및 전체 릴리즈 계획

기존에는 개발리더들이 모여서 개략적인 일정 정도만을 수립하였으나 이번에는 전체 팀원들이 참여하여 개발해야 할 구체적인 기능들을 도출하고 제품백로그를 작성하였다. 제품백로그에는 개발해야 할 기능들을 기존 3단계에서 최대 7단계까지 나누었으며 중요도에 따라 4단계 우선순위를 결정하였다.  또한 Planning Poker를 이용하여 개발 시 예상되는 리스크와 제약사항들을 도출하였다. 그리고 주요 기능들에 대하여 스프린트 단위의 목표일정을 설정하였다. 결과적으로 전체적인 주요기능과 개발단계가 포함된 마일스톤 계획과 제품백로그가 담긴 릴리즈 일정 계획이 완성되었다.

 l  2주 단위의 스프린트 계획

그동안 팀원들은 상세계획 없이 각자 나름대로 작업을 하다 보니 혼자 고민하는 시간이 많고 시행착오가 많이 발생하였다. 그래서 이번에는 팀원들이 모두 모여서 2주 단위로 개발 상세 계획을 수립하고 Planning Poker를 이용하여 작업공수를 추정하고 스스로 업무를 할당하였다.  이 과정에서 컨설턴트는 팀원들이 토론을 통해서 최적의 개발방법을 모색하고 스프린트 목표에 대하여   최선을 다하는 마음자세를 가지도록 코치 역할을 수행하였다. 또한 팀원들은 할당된 일이 개인이 아닌 팀의 일로 인식하게 함으로써 팀 중심의 업무자세를 갖게 되었다.

 l  Daily Scrum (Standup Meeting)

처음에 컨설턴트가 데일리 스크럼을 진행하자고 하였을 때 팀원들은 심한 거부감을 가졌었다. 왜냐면 기존 도구에 있는 스프린트 백로그를 굳이 포스트잍에 수기로 적는 것을 불필요한 일로 생각했기 때문이었다.  처음에는 어색함이 2~3주 동안 지속되었으나 서로가 팀에서 진행되는 업무를 자연스럽게 파악할 수 있게 되고 서로간에 필요한 도움을 받을 수 있는 좋은 미팅이라는 것을 인식한 이후부터는 팀원들이 적극적인 자세로 임하게 되었다. 나중에는 관리자가 참석하지 않더라도 팀원들이 자발적으로 미팅을 수행하게 되고 서로간에 업무를 조율하고 협력하는 모습으로 발전하였다. 

[데일리스크럼 수행 장면]

 l  Sprint Review

스프린트 리뷰 역시 팀원들이 처음에는 흔쾌히 받아들이지 못했다. 이유는 내가 한 업무에 대하여 감시 받는다는 느낌과 개발도 바쁜 상황인데 리뷰에 시간을 쓰는 것이 낭비라는 생각을 하였기 때문이다.  그래서 우선 스프린트 리뷰의 의미를 팀원들에게 제대로 이해시키는 필요하였다. 시간이 지날수록 팀원들은 자신들이 개발한 것에 대하여 경영진이나 사용자들에게 피드백을 받는 것이 자신의 발전에 도움이 된다는 것을 서서히 인지하게 되었으며 리뷰를 준비하는 과정 자체가   품질을 높이는 측면에서도 도움이 되었다.  리뷰는 경영자들을 대상으로 한 리뷰와 실제 사용자를 대상으로 한 리뷰, 내부 검토용 리뷰 등 다양하게 진행되었으며 이를 통해 고객의 니즈를 정제하고 개발 방향을 재 수립하는 중요한 이벤트로 자리매김 하였다.

 l  Development 회고

초기에는 시행착오를 줄이기 위하여 스프린트 종료 후 회고를 수행하였으나 나중에는 한달에 한번 정도로 수행하였다. 회고 시간은 약 1~2시간 정도로 진행하였으며 이를 통해서 많은 비효율적인 활동과 팀원들의 불만 사항들을 해소할 수 있었다. 그전에는 회사 생활에 대하여 솔직하게 팀원들이 얘기할 수 있는 기회가 거의 없었는데 회고를 통하여 서로간에 생각이 다를 수 있음을 이해할 수 있게 되었고 팀원들이 서로를 배려하는 공감의 장으로 발전될 수 있었다.  

4. 컨설팅 성과 

- 경영진은 높아진 개발팀의 생산성과 품질에 만족하게 되었으며 개발팀원 또한 업무에 열정적으로 임하면서 성취감과 보람을 느끼게 되었다.

-장단기 목표가 명확해짐으로써 팀원들의 몰입도가 향상되었다.

- 개발 진행 상황의 가시성이 향상되었다.

- 팀원들간의 협력 및 팀워크가 매우 높아졌다.

-팀원들의 동기부여 및 주인의식이 높아졌다.

-시장에 맞는 제품 품질 및 상품성 확보 할 수 있었다.

 -품질점검 지적사항 감소 되었다.

아래는 3개월이 지난 시점에서 팀원들을 대상으로 설문한 내용과 바뀐 성과입니다. (응답자 20명)

l 본 프로젝트를 수행하면서 느낀 장단점이나 소감은?

- 기존에는 전체일정을 산정하고 개발하는데 어려움이 있었지만 애자일 방법 적용 후에는 단기적으로 명확한 목표를 세우고 진행할 수 있었다.

-  계획적으로 업무를 하게 된다. 스프린트 백로그 목표 달성을 위해 업무 외 쉬는 시간이 줄어들었다.

  -  PM이 팀원들과 수직적 관계에서 업무를 지시하고 전달하는 방식에서 벗어나 팀원들의 역량을 발휘할 수 있도록 여건조성을 하고, 스스로 동기부여를 하여 업무를 진행하므로 업무수행 능력도 높아지는 장점을 경험하였다.

  -  팀원간의 활발한 소통이 개발에 도움이 되었다.

  - 스프린트 계획을 상세하게 짜서 모두 어떤 일을 하는지 알게 되어 좋았다.

 - 회고를 통해 문제가 됬었던 부분을 해결 할 수 있어서 좋았다.

 - 저마다 본인의 업무에 집중하고 서로가 서로를 배려하게 되었다.

l 경영진 의견

     애자일 방법론을 처음 접했을 때는 실제 내용이 없는 그저 컨셉츄얼한 방법론이라고 생각했다.  따라서 알멩이 없는 하나의 유행 같은 것이라고 생각했다.  그러나 Scrum 방식을 적용하면서,  방법론 이라는 용어보다는 Framework 이 더 적합한 용어라고 생각하게 되었고, 소프트웨어 개발에 있어서 가장 핵심적인 요소였으면서도 그동안 간과되었던, 팀원간의 소통증진을 기반으로,  빠르게 변화하는 개발환경에  신속히 대응할 수 있는 최적의 framework이라고 생각하게 되었다.  

 5. 주요 이슈 및 적용 후기

스크럼을 처음 적용하게 되면 초기 1~2달간은 팀의 퍼포먼스가 예상만큼 안 나올 수 있다. 여기에는 여러가지 원인이 있을 수 있는데 프랙티스가 제대로 적용되지 않을 수도 있고 팀원들이 애자일 사상과 프랙티스에 적절히 적응하지 못했기 때문일 수 있다.  이 프로젝트의 경우에도 처음 1~2달간은 팀의 성과가 별로 나아지지 않자 제품관리자나 경영진이 방법론의 효과성에 의문을 제기하기도 하였다.  하지만 팀원들의 자세가 적극적인 마인드로 바뀌면서 스프린트 리뷰 시에 나타나는 제품 완성도나 품질이 눈에 띄게 좋아졌다.  

다른 또 한가지 이슈는 프로젝트 리더의 관리 마인드 변화이다. 국내 대부분의 프로젝트 리더들은 팀원들의 일하는 활동을 꼼꼼히 점검하는 마이크로 매니징 스타일을 구사한다. 그렇게 하지 않으면 업무에 펑크가 나거나 사각지대가 생길 수 있다는 것을 너무나 잘 알고 있기 때문이다.  하지만 스크럼에서는 이런 방식과 멀리 할 것을 권장한다. 즉 팀원들에게 업무의 자율성을 주고 대부분의 개발활동은 위임하는 것이다. 이런 관리 방식의 변화는 전통적 프로젝트 리더에게 하나의 도전이며 극복하기 어려운 것임은 틀림없다.  이번 프로젝트를 하면서 느낀점 중의 하나는 애자일 적용이 사람을 변화시키는 것이기 때문에 세심하게 신경쓰고 고민해야 한다는 것과 전통적 방법론으로 관리되는 SW R&D 프로젝트의 비효율성에 대하여 다시금 깨달았던 것 같다.