드러내어 경계를 인식하기 (feat. XP의 적용)

안녕하세요. yeTi입니다.
오늘은 드러내는 용기로 서로간에 경계를 인식하는 불편한 상황을 만들고 이를 기회로 전환할 수 있겠다는 생각이 들어 이를 기록하고자 합니다.

문제 인식

작년 12월부터 4명 규모의 백엔드 파트 리더를 맡게 되었습니다.

그런데 안타깝게도 판매할 수 있는 제품을 줘야하지 않느냐는 피드백과 개발 속도가 너무 느리다는 피드백을 CBT 상황부터 꾸준하게 들어왔습니다.

그래서 품질 이슈와 개발 속도 이슈를 XP의 단순성의 가치를 따르지 못했기 때문이라고 생각하여 기획의 범위를 줄여 개발 범위를 줄임으로써 해결해보고자 시도했습니다.

대실패

XP의 단순성에 기반한 개발 범위를 줄이려는 시도는 대실패하여 제품의 릴리즈 연기에 이르게 되었습니다.

이유는 기능적으로 부족함에 따라 판매할 수 있는 수준이 아니라는 것이었습니다.

드러내기

이후 부족한 기능을 보완하는 기획을 하고 개발일정을 추정했다니 터무니없는 릴리즈 일정이 나왔습니다.

하지만 이를 좋아보이기 위해 다듬지 않고 있는 그대로 팀 외적으로 공유하게 되었습니다.

경계 인식

역시나 터무니 없는 계획이라는 것을 공개하는 자리가 되었고 결국 영업팀에서 제품이 판매할 수 있는 준비가 될 때까지 영업 대상을 확장하지 않겠다는 피드백을 받았습니다.

이로써 대외적으로 기대하는 기능적 완전성 및 품질의 수준을 알 수 있는 기회가 되었습니다.

좌절이 아닌 기회

확실히 대외적으로 받는 부정적인 피드백은 제 자신에게 정신적으로나 심적으로 작지 않은 충격으로 다가왔고, 이는 앞으로의 막막함으로 이어졌습니다.

그러나 마침 지난 포스팅이 생각 났습니다.
경계란 위험을 경험해야 정해지는 것이다.

개발팀의 개발 수준을 드러냄으로써 대외적인 기대치와 격차가 크다는 것을 공식적으로 선포하게 되었고 이로써 우리가 무엇을 해나가야 하는지 알게된 계기가 된 것 같습니다.

방향성을 잡다

XP의 원칙에서 기회와 품질에 집중해야하는 상황으로 인식했습니다.

기회는 용기의 가치에 기반하여 일주일별 주기를 달성하도록 제안할 수 있어 보이고, 품질은 단순성과 피드백의 가치로 지속적 통합을 하도록 제안할 수 있어 보입니다.

스프린트 회의에 개발팀은 개발한 기능을 리뷰하면 될것같고, 데모 데이에 지속적으로 개발사항을 리뷰하면 될 것 같습니다.

결론

신기하게도 같은 지식으로 다른 상황을 마주해보니 다른 해결책이 효과적이라는 것을 알게되었습니다.

지난 회사에서 XP를 적용한 경험을 기록한 것이 있습니다. XP, 희한하게 나아지는 방법론

그러나 지금 팀에서 온전하게 적용할 수 있는 실천 방법이 없다는 것이 신기하게 느껴졌습니다.

현재 상황을 인식하고 현재 상황에 맞는 해결책을 찾아가는 과정에서 스스로 성장하고 있겠다는 느낌이 듭니다.