애자일 프로젝트에는 생산성과 효율성이 뛰어난 정예요원들이 대거 참여하기 마련이다. 하지만 프로젝트에 실패하지 않으려면 그런 사람들을 신중하
애자일 프로젝트에는 긴밀한 협업과 매우 빠른 피드백이 필요하다. 이 프로젝트가 잘 진행될 때에는 사용자의 기대치 프로젝트 결과물과 근접하게 부합되고, 비즈니스에 전혀 영향을 미치지 않아 완벽할 뿐 아니라 시간도 낭비하지 않게 된다. 애자일 프로젝트가 제대로 완성되면, 경제적인 이익까지도 얻을 수 있다.
하지만 애자일 프로젝트의 생산성은 보통 팀 구성원의 능력에 달려 있다. 여기에는 높은 IQ, 높은 EQ, 그리고 고도의 집중력이 필요하다. 전문성, 추진력, 의사결정 권한이 불충분한 누군가가 팀에 있으면 나머지 사람이 그의 뒤치다꺼리를 하게 된다. 게다가 애자일 프로젝트는 인력과 업무 사이의 정확한 매칭이 중요하다. 만약 팀 구성원이 신경 쓰지 않거나 다른 팀 구성원과 한 방에서 같이 일하지 못한다면 한 마디로 긴밀한 협업은 불가능하다.
애자일이 유연성과 빠른 반복 수행에 달려있는 만큼, 문제 있는 사람을 찾고 고치기 위해 최대한 일찍 그리고 자주 애자일 팀원들과 접촉해야 한다. 팀 할당에서 문제가 있으면 일찍 터뜨리는 게 최선의 방법이다.
젠(Zen) 마스터의 “하나를 하는 것을 보면 나머지를 어떻게 하는지 알 수 있다”는 말처럼, 첫 작업이 완료되기 앞서서 팀 멤버십을 파악해내야 한다. 이상적인 것은 첫 작업이 완료되기 이전에 할 수 있으면 더 좋긴 한다. 하지만 현실적으로는 어렵다.
사용자ㆍ개발자ㆍ컨설턴트ㆍ관리자의 문제
성격에 결함을 가진 사람에게 장점이 있다면 이들은 스스로 자신의 결함에 대해 잘 모른다는 것이다. 그리고 그런 점을 그대로 드러내곤 한다. 애자일 팀은 단지 어느 부분을 살펴봐야 하는 지만 파악하면 된다. 대부분의 애자일 팀에서 확인이 필요한 4가지 부분이 있는데 바로 사용자, 개발자, 컨설턴트, 관리자다. 다음은 애자일 팀의 입장에서 비상 상황이라고 할 수 있는 40가지 문제를 사용자, 개발자, 컨설턴트, 관리자를 기준으로 정리해놓은 것이다. (순서와 중요도는 무관하다)
사용자가…
• 참여도, 관심도, 동기 수준이 낮고, 깊이 관여해야 하는 일상적인 업무로 너무 바쁘다.
• 문제, 조치 항목, 데드라인을 맡기 꺼리고, 어느 무엇에도 (특히 요건, 확인, 테스트 스크립트) 자신들의 이름을 올리고 싶어하지 않는다.
• 위험, 변화, 학습을 요소가 아닌 문제로 인식한다.
• 조치 항목과 데드라인을 두기 싫어하고, 마무리도 질색한다.
• 남을 비난하고 책임을 전가하는 모습을 보인다.
• 자신들이 원하는 것은 노골적으로 이야기하지만 클라우드 컴퓨팅 현실에는 무지하고, 부가적인 요청을 가볍게 생각한다.
• 대부분의 결정에 지연과 애매모호함을 더하는 듯 보이고, 바로 본론으로 들어가기 싫어하며, 단순한 해답을 꺼린다.
• 결론이 없는 대화로 회의를 채우고, 명확히 제기된 문제를 부풀려 터무니 없이 큰 문제로 확대시켜 버린다.
• 완벽하지 않은 정보로 행동을 취하기 싫어하고, 언제나 위험을 회피한다.
• 주의력이 없거나 중요한 그 어떤 것도 읽고 쓰는 능력이 없다.
개발자가…
• 대충 맞는 솔루션을 제시하고 싶어하지 않는다.
• 완벽주의에 빠져있다.
• 아키텍처와 소프트웨어 존속성에 너무 집착한다.
• 무언가 일을 해내기보다는 책임을 피하는데 집중한다.
• 코딩 먼저 하고 질문을 나중에 하려고 한다.
• 커뮤니케이션 능력이 좋지 않은데 특히 스트레스 상황 시 그렇다.
• 사용자를 혐오하고 동정하지 않는다.
• 프로젝트 관리 능력이 없거나 무능한 관리자 밑에서 일한다.
• 겁이 많고 결단력이 없다.
• 경청하지 않는다.
컨설턴트가…
• 낙찰 받을 것 같은 입찰에만 참여하거나 계약을 성사시키는데 집착한다. (도움말: 입찰에 대해 CTO에 문의하라)
• 너무 유연하고, 너무 순응적이고, 실제로 들어줄 수 없는 약속을 하려 한다. (도움말: 문화적 차이에 주의하라)
• ‘나쁜 소식’을 빠르고 효과적으로 전해주지 못한다. (문화적 차이에 주의하라)
• 거절을 잘 못하고 약속을 잘 지키지 못한다. (문화적 차이에 주의하라)
• 불확실한 상황에 책임지기 싫어한다.
• 경청하지 않는다.
• 요청 당일에 바로 답변하기 싫어하거나 답변해 주지 못하다. (도움말: 서비스 수준 합의서를 작성하라)
• ‘예스맨’/무능하다.
• 코딩의 속도와 용량만 과도하게 강조하고 제대로 된 구축에는 신경 쓰지 않는다.
• 현장에 나가기 싫어한다(나머지 팀원과 같은 시간대에 있는 것조차).
관리자가…
• 프로젝트에 능동적으로 참여하고 지휘할 의지가 없다.
• 수직적인 관계에 과도하게 집착해 모든 핵심 결정사항을 위에 보고하라고 요청하고, 다른 이를 신뢰하거나 일을 나누고 싶어하지 않는다.
• 가치보다 예산에 더 초점을 맞추고, 편협하게 정의된 수치에만 과도하게 관심을 보이며, 폭넓은 주제에 대해서는 크게 관심 갖지 않는다.
• 집중력 저하와 기억력 저하 현상을 겪고 있다.
• 해당 분야를 잘 모르고 배울 의지도 없는 사람을 승진시키려 한다.
• 극심한 내부 경쟁을 보상으로 유도해 리더들이 적은 예산을 책정하고 과도하게 높은 수준의 제품을 약속하며 실적을 쌓아나간다.
• 팀원들에게 책임만 주고 권한을 주지 않는다.
• 관리의 방편으로 공포를 활용하고 실패하면 공개적으로 처벌한다.
• 명백한 우선순위 설정, 현실적인 데드라인을 설정, 득실 인정을 꺼리고, 잡음으로부터 신호를 걸러낼 의지가 없다.
• 계약 협상 과정에서 비현실적인 조항과 비대칭적인 위험 아이템을 추가한다.
결론
앞서 나열한 비상 상황에 대해 점수를 매길 필요는 없다. 하지만 여기서 나온 문제들 중 여러 가지가 팀원들에게 발견됐다면, 신중하게 그 팀원을 빠른 시일 내에 교체하는 것을 고려해야 할 것이다. 만약 관리 부문에서 이런 문제들을 많이 발견했다면 애자일 프로젝트의 성공을 기대하기란 쉽지 않을 것이다.
*David Taber는 ‘세일즈포스닷컴 성공의 비밀(Salesforce.com Secrets of Success)’의 저자며 세일즈포스닷컴의 공식 컨설팅 업체인 세일즈로직스 CEO다. dl-ciokorea@foundryco.com
