scrum적용 중 발생한 'PL의 반발'에 대한 소고..

scrum을 sm에 적용중이신 몽둥발이님 블로그에
PL의 반발이란 재미있는 글이 올라왔는데 상황은 이렇다.

6개월 프로젝트 - 2개의 팀(기존조직체계 유지)에 scrum적용 중. 5번째 sprint돌입
1팀 : 무리한 planning 그러나 미션 컴플릿! 고객과 관리자는 나이스샷 외침.
       그러나, 품질저하 가시화 되었고 개발자분들 초과근무 발생으로 초췌모드.
2팀 : 글에는 적혀있지 않으나 아마도 1팀에 비해 구현율이 낮은 상태

여기서 2팀 PL이 다음과 같은 불만을 토로한 것.

"개발자들을 적절히 제어할 수 있는 권한이 없어 답답하다" by 불만PL
1) 내가 생각하기에 충분히 할 수 있는 업무의 양을 개발자들이 과대포장을 하고 있다.
2) 현재 상태로 번다우닝(burn downing)을 하다보면 프로젝트가 실패할 가능성이 매우 높다.
3) 협의가 필요한 어려운 업무의 우선순위를 뒤로 미뤘기 때문에 프로젝트 후반에 매우 힘이 들 가능성이 크다.

2팀 PL의 입장에서는 불만을 토로할 수 밖에 없는 상황이다.

- aggresive planning 권한을 포기하고 scrum가이드에 따라 계획을 수립하였으나
  현 상황/추세로 봤을 때 과거이력이나 경험에 비추어봐도 6개월 출시는 사실상 불가능.
- 협의 필요한 업무마저 죄다 뒤로 몰려있는 계획으로 더더욱 위험하고 힘든 상태
- planning 권한을 포기했으나 좋지않은 결과에 대해 self-organization 무한책임을 강요하는 분위기
  현 인사평가체제에서 권한을 포기했다고 해서 PL의 책임이 약해지는 것은 아니다. 오히려 방조죄 추가.
- 가이드를 무시하고 무리한 계획으로 팀원을 밤샘시킨 1팀이 좋게 평가되고 있다,
  실제로 버그는 있지만 테스트 가능한 프로덕트를 일정내 맞출 가능성이 우리팀에 비해서 높다.
- 본 회사나 1팀을 보았을 때 '완료'란 버그가 있어도 6개월 내에 테스트 가능한 프로덕트를 내놓는 것.
- planning이 무슨 컨셉이든 인사평가시 까이는 책임을 면하려면
  품질저하로 인해 향후 추가 발생하는 리소스가 상당하고 팀원 눈에 다크서클이 생길지라도
  팀원들과 같이 밤샘하는게 정답인 것을 1팀, 기획, 관리, 기타 팀들이 여실히 보여줌.
  따라서, 가이드와 맞지 않고 팀원이 고생스럽더라도 무리한 계획과 밤샘을 시작해야겠다.
- scrum이건 뭐건 결국 예전방식(무리한 계획, 밤샘, 허술한 제품 일정 맞춰주기)이 정답이다.

1팀은 왜 가이드와 상반되게 무리한 계획을 잡고 밤샘을 반복했을까?
1팀 PL입장에서는 나름 현실적인 판단을 한게 아닐까..

scrum가이드에 따라 원만한 계획을 수립하는 것은 
현실(버그있는 프로덕트를 무리한 일정 내에 내놓는 것이 인정받는 상황)과는 맞지 않다.
일정 내에 개발된 제품은 품질이 저하된 상태로 이후 리소스가 소요되는 것을 생각하면,
차라리 밤을 새지 않고 품질을 추구해가면서 차츰차츰 개발하는게 훨씬 좋은 방법이지만
조삼모사를 바라는 환경에서는 어쩔 수 없다. 
무엇보다도 인사, 관리팀의 성과측정 부분이 달라진게 없어 기존방법을 선택할 수 밖에 없다.

이와 같은 상황에서 현실을 개선하기 위해 무엇을 해야 할까..?
자기조직화를 기대하는 것도 한계가 있다. 
시스템의 굴레에 소속되어 해당 시스템을 조망하기도 어렵고
그 시스템을 바꾸기에는 자신이 연관되고 지배받는 것이 많기 때문이다.
그래서 권력이란 질서에 몸을 맡기고 근본적인 문제를 포기한채 순응을 선택하기 마련.
1팀이 scrum과 쾌적한 개발환경이 가이드로 다가왔음에도 밤샘을 선택한 것 처럼 말이다.

'방법론'이란 롤은 그러한 잘못된 시스템을 철저히 타파하기 위해 존재한다는 것을 기억하자.. 

어쨌든 본인이 방법론 롤을 수행하고 있다면 이렇게 해야겠다고 생각하는데..

0. 1,2팀 PL과 팀원, 기획자, 관리자들에게 사과하기
   - 무리한 계획이 수립되어 본의 아니게 밤샘이 되도록 방조한 것에 대해 사과
   - 실패와 가까워질 때 까지 방조한 것에 대해 사과
   - 근본적인 개선을 위해 노력할 것을 약속하고 현실타파를 위한 구체적인 안건 제시 후 의견 수렴
1. PL롤 명시
   - PL과 롤에 대해서 사전 협의하고 결과를 관련자들에게 이해시켜야 한다.
   - 가이드압박 프로젝트에서 PL이 당하는 상상을 초월한 불이익(권한없는 무한책임)을 해소시킨다.
2. 책임과 권한을 명확히 공지.
   - 권한과 책임을 직설적으로 모두에게 명확히 전달.
3. 위험요소 확인
   - 위험관리 전략,식별,완화,대처안 대로 2팀 PL이 어필한 위험요소 확인하고 대처.
   - 미협의내용이 후반부로 몰린 것은 계획당시 위험요소로 등록되고 모니터링 했어야 하는 내용
   - 1팀 품질저하 부분에 추가적인 리소스가 어느정도 소요될지 가늠해야 함.
4. 과거부터 현재까지 생산성 가시화. 오픈까지 리소스 소요 추이 추정 및 가시화
   - 품질저하로 인한 추가적으로 발생하는 리소스를 포함하여 생산성을 측정
   - 오픈가능한 수준에 이르기까지 소요되는 리소스와 시간을 가시화
5. 조삼모사를 알리고 프로젝트 목적과 계획 변경
   - 생산성과 소요 리소스 추이를 통해 조삼모사를 기획, 관리자가 요구하고 있음을 보이기
   - 이로 인해 품질저하가 발생하고 결과적으로 엄청난 리소스 소요가 발생하는 것을 보이기
   - 기간내 달성보다 목표품질의 프로덕트를 단계적으로 출시하는 것으로 방향선회
6. 생산성 향상 방법 고안
   - 생산성과 리소스추이, 개발된 소스를 아키텍트그룹에 전달하고 아키텍트그룹 리뷰수행
   - 코드리뷰를 통해 코드 품질을 지적하는 것이 아닌 '코드품질 향상, 생산성 향상'방법 고안
   - 품질향상을 위한 최저비용 소요기회는 이터레이션을 넘어간 시점에 이미 지나간 것.
7. 확실한 user acceptance test
   - 품질 문제를 가시화 하고 모두가 인식해야 한다.

어떻게 보면 1팀은 품질문제 2팀은 리스크가 있네.. 하고
대수롭지 않게 넘길 수도 있는 아주 작은 문제일 수도 있지만
회사와 팀이 가지고 있는 근본적인 문제가 드러나는 현상이기 때문에 
성과기준이나 근무형태를 개선할 수 있는 큰 기회이기도 하다

개인이 가진 권력과 정치력에는 한계가 있지만
적극적인 개선시도가 어쨌든 개선을 위한 시작점은 되지 않을려나..
이후 어떻게 진행될 지 흥미롭다. scrum적용에 관심있는 분은 링크도 읽어보시기 바람.


p.s 아래 그림 '품질기대치에 따르는 테스트팀의 리소스 소요 및 품질향상 기회' 을 보자.
















개발시점에 품질을 최대한 끌어 올리는 것이
테스트와 피드백에 들어가는 엄청난 리소스 소요와 신뢰저하를 축소시킨다는 것은 상식이다.
하지만, 불가능한 일정과 특정시점에 제품출시를 성과 판단기준으로 들고 나오면,
개발완료 이후 테스트와 버그수정에 훨씬 많은 리소스가 소요된다는 것을 알고 있어도
품질기대 허용한도내에서 가장 낮은 품질을 선택할 수 밖에 없게 된다. 모든 PL들의 딜레마다.
이것을 알고 있으면서 궁극적인 문제점을 해결치 않고 PL에 책임을 전가하는 것은 절대로 안된다.

개발팀원의 밤샘근무와 품질저하, '개발완료'탈을 뒤집어쓴 failure수준의 sw
개발후기 또는 테스트기간에 테스트와 버그에 소요되는 폭발적인 리소스 증가.
그리고 반복되는 밤샘근무와 신뢰저하.. 이건 PL과 개발자의 잘못도 아니다.
예산할당, 개발기한 설정, 측정형태를 결정한
기획,PM,사업관리,방법론,품질이 책임을 먹어 주셔야 하겠다.

현실은 PL과 개발자를 타박하는 환경이지만서도.. 아.. 또 현실을 회피하고 싶어진다; (먼산~)