한다고 한것들(commitments)을 못했을 때(missing)의 것들을 어떻게 받아들여야 할지 애매해서 좀 찾아봤는데 재미있는 링크를 찾았다.

Agile team missing commitments regularly and complaining about no trust

어떻게 보면 개발자들이 똘똘 뭉쳐서 에자일이라는 것을 해석해버리면 이런 식도 될 수 있겠구나 하는 생각도 든다.

질문의 요지는 스프린트 4개를 하는 동안 개발자들이 40~60% 정도를 빵구를 내고 있다. 하지만 MVP를 만들어낼때까지 4개의 스프린트가 남았음에도 불구하고 개발자들은 현재 상황에 대해 안이하다.  개발자들은 스토리가 거의 완성됐고 좀만 더 하면 된다고 이야기를 한다. 하지만 스토리는 완성되지 않았기 때문에 결국 스토리 완성은 다음 스프린트로 연장됐다. 따라서 계속 MVP에서 보여줘야 할 내용들은 줄어들 수 밖에는 없다. 스펙을 짤라야 하기 때문에.

럼 가장 많은 Vote를 받은 답변의 요지를 정리해본다. 답변에서는 3개의 Noop을 이야기한다.

4개 스프린트에서 스토리는 어느 정도(40 ~ 60%) 진행이 된거다.

하다만 스토리는 완성되지 않은 스토리다. 따라서 진행율은 0%다.  

스토리를 임의대로 자르고 붙혀서 이만큼 했다라고 이야기하는 것 자체가 작위적이다.  스토리를 정할 때 우리는 완결성을 부여한다.  “주어진 조건 아레서 어떤어떤 방식으로 동작해야하고 그 기능은 이렇게 검증한다” 라고 스토리를 써내려간다. 그런데 조건을 맘대로 변경하고, 동작을 변경하고, 검증 방식을 임의대로 자르고 붙혀서 우리는 잘 하고 있어.. 라고 이야기하는건 옳지 않다.  특히 정직할 수 밖에 없는 기계를 대상으로 작업하는 개발자가 이런 기계적이지도 못한 자세를 보인다는건 극히 잘못된 거다.

일은 거의 다 되어간다.

완결되지 않은 일은 백로그에 있는 다른 일들과 동급이다.  다만 다음 스프린트에서 높은 우선 순위를 가질 뿐

에자일 개발에서 스프린트는 백로그에 있는 것들 가운데서 이번 스프린트에서 해야할 일들을 뽑아서 진행해야한다.  지난 스프린트에서 다 못한 일들을 스프린트에 스프린트를 걸치게 하면서 개발하는건 제대로 된 에자일 프로세스가 아니다.  따라서 완결하지 못했다면 해당 스프린트에서 한 일은 없는 것이다. 단정적인 표현이지만 이것이 맞는 이야기다.  만약 이 규칙을 지키지 않는다면 에자일을 하는게 아니다.

에자일 개발 프로세스에서 스프린트는 중요한 의미를 갖는다.  한 스프린트는 집중해서 처리할 일들을 집중해서 처리하자는 암묵적 규칙 아래서 운영된다.  따라서 이 스프린트에 진행할 일들을 선정했다면 개발팀은 온전히 그 일에 집중해야 한다.  스프린트를 진행중인데 다른 일들이 급하다고 치고 들어온다면?  원칙에 따르면 “이게 급해요!!” 라고 치고 들어온 일들은 당연히 하면 안된다. 온전히 백로그에 잘 모셔둬야 한다. 스프린트에 집중헤야 할 일에 집중하는 것.  그것이 에자일에서 강조하는 스프린트의 운영 규칙이다.

누구나 한번쯤 응급실에 가본 경험이 있을 것이다. 다른 사람의 아픔보다는 자신의 아픔을 의사가 간호사가 먼저 돌봐주어야 한다고 우긴다.  고함 소리도 들리고 왜 의사가 오지  않는지 깽판을 치기도 한다.  하지만 의사는 자신의 우선 순위에 따라 움직이고 또 그래야만 한다.  같은 공간에 있지만 이미 치료를 시작한 환자가 있다면 그 환자의 치료가 끝날때까지 기다려야 한다.  당신이 죽을 정도라면 아마 응급실에 들어오자마자 의사가 바로 당신에게 달려들 것이다.

스프린트의 운영 역시 이와 유사한 측면이 있다. 스프린트를 통해 진행하기로 결정된 사항들에 대해 개발팀(응급실의 의사)는 이해 관계자들의 이해를 바란다. 이해 관계자들 역시 자신의 고통을 백로그에 담아두면서 기다림의 시간을 갖는다.  따라서 스프린트를 진행하는 개발자들은 해야할 일을 스토리를 통해 명확하게 정의해야 한다. 그리고 그 일의 완성을 위해 최선을 노력을 해야한다. 시간을 가지고 장난질을 하면 안된다.

이유가 뭐냐고 물어보면 개발팀을 못믿는거냐고 되려 받아친다.

서로 니 잘못이니 내 잘못이니 따지면 폭망이다. 왜 이렇게 예측(Planning)이 개판인지 물어보는게 바람직하다.

서로 잘잘못을 따지는 전투 행위로 들어가면 남는 건 상처밖에 없다.  상호 신뢰는 모든 일의 근간이다. 맞던 틀리던 험단과 힐란이 난무하면 신뢰는 무너진다. 결국에는 폭망에 이른다. 일을 시작했다면 되게 해야한다. 비난보다는 건설적인 견지에서 현상을 살펴볼 필요가 있다.  이 문제의 건설적인 관점은 왜 스토리가 스프린트에 완성되지 않는지를 따져보는 것이다. 특히 한번이 아닌 4번이나 제대로 스토리를 완성시키지 못했다는 사실에 집중해야 한다.

반복적으로 스프린트의 스토리를 완결하지 못했다는 것은 백로그에 존재하는 스토리의 규모를 제대로 예상하지 못한다는 것이다. 전후 관계가 명확한 스토리가 이런 꼬라지를 보인다면 더욱 더 개발 기간의 예측이 올바르지 못하다는 것을 뜻한다.   이 사실에 개발팀 공감해야 한다. 이 공감을 바탕으로 제대로 된 플래닝을 하기 위해 필요한 것이 뭔지를 고민해야 한다. 예를 들어 새로운 데이터베이스를 사용하기 때문에 혹은 새로운 언어를 사용해야 하기 때문일 수도 있다.  그렇다면 해당 분야의 고수를 초빙해서 플래닝에 도움을 요청하는 것도 좋은 대안이 될 수 있다.  만약 조직의 프로세스 혹은 권한 등이 문제라면 이를 잘 아는 주요 인사를 플래닝에 함께 참석시켜 예측을 해보는 것도 다른 방편이 될 수 있다.

가장 중요한 점은 최선을 다한 결과임에도 불구하고 동일한 문제가 반복적으로 들어난다면 열린 마음으로 이를 직시해야 하는 것이다. “믿고 맡겨주세요”와 같은 허왕된 문구는 정치인들이나 하난 말장난이다.  프로페셔널의 세계에서 문제는 객곽적인 사실로 보고 판단해야 한다. 그리고 그 안에서 개선할 부분이 있다면 인정하고 고쳐나가면 된다.

누구도 실수를 할 수 있다. 하지만 두번 실수를 하지 않는 것이 바로 프로다.