알라딘MGG와이드바


애자일/스크럼 프로젝트는 왜 실패하는가? Part 2 개발 이야기

제목은 '애자일/스크럼 프로젝트는 왜 실패하는가?' 이지만 이번에는 스크럼 실패사례의 이유를 주로 살펴보자. 아래 내용은 주변 분들이 스크럼을 프로젝트에 도입하면서 겪었던 어려움들을 정리한 것이다. 이런 사례들을 보면서 타산지석으로 삼으면 애자일/스크럼을 도입하면서 실수를 줄일 수 있을 것이다.

비전을 모르겠다.
1,2주 단위의 스프린트로 작업을 하다보니, 장기적으로 무엇을 할 것인가에 대한 비전을 신경쓰지 않아 개발의 방향성을 알기 어려웠다. 또한 유저스토리가 너무 세분화 되어 있다보니 임원들이 프로젝트 진행사항을 보러 와도 한 눈에 프로젝트의 진행사항을 알기 어려워 했다.

PO(Product Owner) 는 어디에 있는가?
외국 지사에는 개발팀만 있고, PO(Product Owner)는 본사에 있는 경우에는 의사소통이 어렵고 스크럼마스터가 책임감있는 결정을 내릴 수 없었다. 파일럿 프로젝트에서 스크럼이 잘 되더라도 이를 본사 규모로 전파하기가 어려웠다. 같은 공간에 PO 가 있더라도 회사의 다른 업무때문에 PO 가 바빠다거나 우유부단해서 팀의 중요한 의사결정을 신속하게 내려주지 않는다면 스크럼을 하기 어렵다.

수익이 되는 분야에만 개발 리소스를 집중했다.
수익이 나는 팀과 인프라팀이 같은 스크럼 조직에 있다보니 대부분의 개발가용자원이 수익이 나는 팀에 집중되었다. 인프라팀도 꼭 필요한 팀인데 스프린트 작업 우선순위에서 계속 밀리다보니 작업자들의 사기가 많이 떨어졌다. 수익을 내는 팀과 인프라팀은 스크럼을 따로 하면 어땠을까 싶다.

스크럼보다 툴을 먼저 도입했다.
스크럼을 도입하기 전에 먼저 GreenHopperHansoft 같은 툴을 도입했더니, 스크럼을 개발팀에 맞게 고치지 못하고 툴이 정한 방식대로만 하게 되었다. 먼저 스크럼을 한 후에 툴을 도입하는게 더 좋을 거 같다.

요구사항을 제거하거나 미룰 수 없다.
갑을병정무기... 까지 내려가는 하청일 경우에는 한 번 하기로 정한 요구사항은 어떻게든 들어줘야 한다. 그러다보니 스크럼에서 얘기하는 '전체 Backlog 중에서 가장 우선순위가 높은 일부터 순서대로, 정해진 시간(TimeBox) 안에 할 수 있는 양만큼 꺼내서 작업한다' 를 할 수 없다. 그냥 무조건 다 해 줘야 하는 거다. 이러다보니 품질을 떨어뜨리는 한이 있더라도 일단 돌아가게만 만들고, 유지보수가 필요하게 만들어 이를 통해 추가적인 수익을 얻으려는 경우까지 있다.

하청을 맡겼으니 본전을 뽑아야겠다.
반대로 갑의 입장에서도 스크럼을 하고 싶으나 어렵다는 분들이 있다. 프로젝트에 대한 애정 때문에 욕심이 계속 생겨서 업무를 줄이기가 어렵다고 한다. 아무래도 하청업체는 자기 팀이 아니다보니, 최대한 쥐어짜서 본전을 뽑아야 한다는 생각 때문에 애자일이나 스크럼을 도입할 수 있는 입장임에도 불구하고 선뜻 나서지 못하는 것으로 보인다. 이 점은 모 대기업에서 갑으로 오랫동안 애자일을 도입하려고 노력하신 민신현(글뻥님) 글을 참고해 보는 것도 좋겠다.

스크럼을 제대로 이해하지 않은 채 스크럼을 도입하려 했다.
스크럼이 쉽다 보니, 관련 책도 한 번 안 읽어보고 웹에서 대강 살펴본 다음에 도입하려다가 잘 안 된 경우가 많다. 스크럼 실천법은 참 간단하지만 왜 그렇게 하는가에 대한 철학이 없다면 상황이 긴박해질 때 원칙을 벗어나서 되는대로 일하기 쉽다.

스크럼마스터가 micro-management 만 하려고 했다.
스크럼마스터의 가장 중요한 역할은 장애물을 제거하는 거다. 개발자들이 업무를 하는데 있어서 어떤 불편함이 있는지, 협업에서 일정에 안 맞는 부분이 있는지 등을 챙기는 것이 스크럼마스터의 가장 중요한 일이다. 스크럼마스터가 장애를 제거하는데 도움을 주지 않는다는 걸 팀원들이 인식하게 되면 스크럼이 돌아가지 않는다. 어떤 회사에서는 한 명의 스크럼마스터에게 여러 개발팀의 일일 스탠드업 미팅을 일일이 참석하면서 개발자들의 일정만 관리시켰는데 아니나다를까 몇 달 후 그 회사에서는 더 이상 스크럼을 하지 않았다.

속도를 측정해 이를 근거로 야근을 강요했다.
측정하지 못하면 관리하지 못한다. 정말? 에서 언급한 내용과 비슷한 경우다. 이슈트래커로 Backlog 를 기록하고, Burndown Chart 를 통해서 현재 개발팀의 작업속도를 측정하는 것 자체는 나쁘지 않다. 하지만, 이를 통해서 작업PC 성능이 나쁘다던가 중요하지 않는 작업을 제거해 준다던가 하는 식으로 장애물을 제거하는 게 아니라 야근을 강요하게 되면, 팀원들이 배신게임을 시작한다. 작업이 있어도 이슈트래커에 일을 올리지 않고, 하루면 할 수 있는 일을 1주일 걸린다고 올려놓는 식이다. 개발자의 생산성은 어떻게 측정하더라도, 거기에 맞춰 사람들이 최적화되기 마련이다. 스크럼에서 팀원들은 self-managed 된다. 야근이 필요한 상황이라면 알아서 야근할 것이다.

스크럼은 은총알이 아니다.
애자일/스크럼 프로젝트는 왜 실패하는가? 에서 얘기한 것처럼 원래 소프트웨어 프로젝트 성공률은 낮다. 그런데 스크럼을 도입하면서 다른 사람들을 설득하기 위해 스크럼의 장점을 과대포장하는 수가 있다. 이러면 큰 기대를 갖고 스크럼을 해 보다가 조금만 잘못된 점이 나와도 팀원들이 실망해서 원래 방식으로 돌아가게 된다. 스크럼을 한다고 해서 갑자기 코드 품질이 좋아진다거나 엄청난 기획이 나오는 것이 아니다. 스크럼은 경험적인 접근법이다. 기본 실천법은 있지만, 팀의 특성에 맞춰서 try and error 를 반복해가면서 팀에 맞는 방법을 찾는 과정이다.

스크럼에 대해 더 아시고 싶으시면 제가 번역한 스크럼 책을 참고하세요 :)

사용자 삽입 이미지




핑백

덧글

  • 백미댕 2011/09/30 23:30 # 답글

    어제 모임하고나서 이 글이 올라오니깐 한번 더 기억하게되서 좋네요^^ 책은 읽으려고 사놓고 책상 위에 며칠째 있는데 주말동안 빠싹 읽어봐야겠어요!! 좋은글 감사합니다!
  • 박PD 2011/10/01 08:05 #

    xper 모임에 오셨었나요? 댓글 감사합니다.
  • 백미댕 2011/10/01 19:29 #

    넴. 저는 레지스트레이션을 하며 돈을 걷었어요ㅎㅎㅎㅎ
  • 박PD 2011/10/02 00:06 #

    오우.. 기억납니다. 반갑습니다 :)
댓글 입력 영역


Yes24위대한게임의탄생3

위대한 게임의 탄생 3
예스24 | 애드온2