애자일이 아니야

새로 들어온 팀장급 인원들은 애자일 방법론을 도입한다고 스토리 회의, 스크럼 미팅 등을 운영했다. 4개월 여 진행했다. 그 결과는?

"애자일이라 말하고 워터폴로 행동한다"

많은 팀에서 이런 결과를 맞이했으리라 생각한다. 우리 팀은 각자 해야 할 일을 명확히 알고 누군가 시키지 않아도 그 일을 뚜렷이 해내는 개발자 개인 개인이 있었음에도 불구하고 결국 프로젝트 운영진은 가장 애자일스럽기 좋은 인적자원을 두고 워터폴을 행했다.

'아,  '언행일치'란 얼마나 어려운 일인지'

만일 애자일을 제대로 이해하고 있었다면? 프로젝트를 시간적 의존성이 없을 가장 작은 유의미 단위로 쪼개고 그것들을 병렬로 진행했을 것이다. 개발자들이 git을 쓰는 것과 같은 방법으로 말이다. 우리가 나눌 수 있었던 '애자일'스러운 유의미한 단위는 다음과 같았다.

1. 로그인 시점 변경

2. 대행사 기반 서비스 개발

3. 기존 서비스 페이지 개선

4. 안내 페이지 신설

5. 입력 페이지 신설

백엔드와 프론트엔드, 디자인, 그리고 마케팅 시점을 모두 고려해도 최소 저 5개의 프로젝트로 나눴으면 각각의 프로젝트가 시간적 의존성이 없이 각각 진행될 수 있었다. 기획이 비어있는 요소로 인해 발생하는 인적, 서비스적 충돌을 최소화할 수 있었다. 각각의 프로젝트가 얼마나 큰지, 얼마나 깊은지, 얼마나 중요한지를 파악하며 진행할 수 있었다. 병합 기간을 따로 두어 최종적으로 원하는 그림으로의 발전도 이룰 수 있었다. 중간중간의 데이터 분석도 시행할 수 있었다. 하지만 우리 현명한 프로젝트 진행요원들은 저 모든 것을 샐러드 보울로 만들어버렸다. 바로 워터폴!

워터폴의 가장 큰 문제는 시간적 인과성이 깊어진 프로젝트 진행이 '원인' 부분에 충돌이 발생하면 '결과' 부분에 시간적, 기술적 영향을 미친다는 것이다. 충돌은 기획부터 시작된다. 비어있는, 혹은 기존과 상충되는 기획은 변경 즉시 디자인, 개발 전체에 영향을 미친다. 디자인에 미친 영향은 개발에 변화를 준다. 늘어나는 시간은?

* 늘어난 총 시간 = 기획 변경 + 디자인 변경 + 코드 변경

과 같다. 그런데 워터폴 방식에서는 마감일을 지정해둔다. 결국 늘어난 총시간은 프로그램의 마감에 있는 개발팀에게 가시면류관을 씌워준다.

'너희의 희생이 모두를 이롭게 하리라.'

프로젝트 안의 충돌은 개인 간의 충돌을 일으키고 상호 간 신뢰를 끊어지게 만든다. 그렇게 된 이유는? 모두 알고 있지만 또 모두 모르고 있다. 알고 있지만 프로젝트 운영진이 이를 인정하는 순간 문제를 인정하게 되는 것이고 그러면 워터폴 방식에서 절대 불가능한 마감일 변경이 발생해야 하는 것이다. 그러면 본인들의 과오로 남게 되고 회사에서 신뢰도가 떨어진다. 그렇기에 끝까지 그들은 모르는 사람이 된다.

"킥오프 때부터 회의하면서 합의된 기간 아닌가요?"

라는 식으로 항변한다. 이렇게 얘기하면? 오케이 너랑 우리의 신뢰는 무너진다. 신뢰가 무너진 집단은 대화가 없어진다. 결국 사라지는 집단이 되는 것이다.

"알지? 애자일 아니야”