기업들이 소프트웨어 솔루션을 자체 서버에서 클라우드 환경으로 옮기면서, ‘더욱 민첩한’ 운영 방식을 추구하는 경우가 많습니다. 이는 기업 전체의 모든 측면에 이상적으로 적용되어야 하며, 동시에 모든 곳에서 구현되어야 한다는 것을 의미합니다.
이론상으로는 프로세스 변경이 간단해 보일 수 있습니다. 스크럼 이벤트들을 정의하고, 팀원들을 스크럼 마스터, 제품 책임자, 배송 관리자, 스크럼 팀 등 새로운 역할에 재배치할 수 있습니다.
Jira, Azure ADO, Miro 보드와 같은 도구들을 도입하여 필수적으로 사용할 수도 있습니다. 하지만 이러한 도구들을 연결하는 프로세스는 어떻게 할까요? 사람들의 생각, 행동, 일하는 방식을 바꾸는 것은 어떨까요? 분명한 것은 이러한 변화가 쉽게 이루어지거나 빠르게 완료되지 않는다는 것입니다. 이제 그 이유를 살펴보겠습니다.
배송 혁신 이니셔티브란 무엇이며, 기업들이 이를 추진하는 이유는 무엇일까요?
오늘날 많은 기업들이 여전히 폭포수 방식의 배송 모델을 따르고 있습니다. 이는 다음 과정을 포함합니다:
- 먼저 최종 결과물 또는 제품이 무엇인지, 대략적인 비용이 얼마인지를 계획합니다.
- 최종 제품의 모든 세부 사항에 대해 철저하게 논의하고, 반박하고, 질문하고, 합의하고, 다시 논의하며 최종적으로 확인하는 요구사항 수집 과정을 시작합니다.
- 전체적인 프로젝트를 추정하고 예상 예산을 확정합니다.
- 솔루션을 디자인합니다. 이해관계자들과 여러 차례 회의를 진행하고, 다양한 문서를 작성하여 이해관계자들에게 검토를 요청합니다. 최종 기능 및 기술 디자인을 확인하고 승인받습니다.
- 디자인을 기반으로 솔루션을 구현합니다. 여기서 완벽한 최종 제품을 개발합니다.
- 테스트 단계에 돌입하여 단위 테스트, 시스템 테스트, 기능 테스트, 통합 테스트, 성능 테스트, 회귀 테스트, 사용자 수용 테스트 등 다양한 유형의 테스트를 수행합니다 (이는 회사 문화에 따라 다릅니다). 모든 것을 문서화하고 이해관계자들에게 검토 및 승인을 받습니다.
- 솔루션을 실제 운영 환경에 배포합니다. 이곳에서 최종 사용자들이 완전한 제품을 사용하기 시작합니다.
- 개발팀이 솔루션의 잠재적인 버그를 수정하는 지원 단계를 예약합니다.
이 전체 과정은 몇 달에서 몇 년까지 걸릴 수 있으며, 보시다시피 사용자들은 프로세스가 완료된 후에야 결과물을 볼 수 있습니다. 오랜 기다림 끝에 마침내 성공(또는 실패)의 순간이 찾아오는 것입니다.
만약 오랜 기간 동안 무언가가 변경되어 최종 제품이 약간 달라 보인다면, 이는 변경 요청으로 간주됩니다. 디자인을 다시 검토하고 재작업하며 재승인을 받아야 합니다. 이로 인해 전체 일정이 지연됩니다.
분명히 이것은 민첩한 방식과는 거리가 멉니다. 모든 변경 사항은 이전의 전체 과정을 다시 시작해야 함을 의미합니다.
애자일 방식으로의 전환
그렇다면 어떻게 이러한 상황에서 벗어나 더욱 민첩하게 변화할 수 있을까요? 사람들은 수년 혹은 수세기 동안 폭포수 방식에 익숙해져 왔습니다. 그들은 자신에게 편안한 역할과 책임을 가지고 있으며, 현 상태를 바꾸고 싶어하지 않습니다. 주된 이유는 이러한 변화가 궁극적으로 지금까지 가지고 있던 권한의 일부를 잃는 것을 의미하기 때문입니다.
이것이 이러한 변화가 가장 강력한 수준의 저항을 유발하는 주된 이유입니다.
#1. 팀 재구성
첫 번째이자 비교적 간단한 방법은 팀원들을 스크럼 팀으로 재구성하는 것입니다. 이는 기능 영역이나 그 외 합리적인 논리적 구분을 기준으로 이루어집니다.
일반적으로 팀 분할은 순조롭게 진행됩니다. 문제는 팀원들이 여전히 이전 구조에 얽매여 있다는 사실을 깨달으면서 시작됩니다. 새로운 스크럼 팀의 일원이 되었음에도 불구하고, 실제로는 그렇지 않습니다. 그들은 여전히 이전 설정에서 벗어나지 못하고, 팀 구조 조정 프로세스와 함께 끝나지 않은 책임들을 여전히 가지고 있습니다 (이는 리더십이 완료해야 할 작업에는 크게 관심이 없지만, 시작해야 할 작업에는 관심이 많기 때문입니다).
따라서 실제로는 완전히 헌신적인 스크럼 팀이 아닌, 스크럼 팀이라고 불리는 집단이 됩니다. 이제 해야 할 일이 더 많아진 사람들의 그룹일 뿐입니다. 경영진이 기대하는 만큼 스크럼 팀 내부에서 일할 시간이 충분하지 않습니다.
동시에 팀원들은 스크럼 팀 내부의 새로운 기대치와 함께 이전의 업무도 마무리해야 한다는 압박을 받습니다. 이는 처음부터 실패하도록 설정된 상황입니다.
#2. 스크럼 이벤트 일정 조정
정기적인 회의 (스프린트 이벤트) 일정을 팀에 명령하는 것은 쉽게 정의하고 시작할 수 있습니다. 최소한 스크럼 팀이 세 개 이상의 시간대에 걸쳐 있지 않다는 가정 하에서 가능합니다 (하지만 종종 이러한 상황이 발생합니다).
문제는 팀원들이 정기적으로 이벤트에 참여하지 않기 시작할 때 발생합니다. 누가 얼마나 자주 참석하지 않는지에 따라 다양한 문제가 발생할 수 있습니다. 예를 들어:
- 제품 책임자가 계획 및 개선 이벤트에 참석하지 않으면 팀은 작업할 새로운 스토리를 얻지 못합니다. 혹은 스토리 설명이 너무 불분명하여 팀원들이 작업을 시작할 수 없는 경우도 있습니다.
- 스크럼 마스터가 회의에 불참하면 팀은 기본적인 스크럼 진행을 놓치게 되어 시간이 지남에 따라 길을 잃을 수 있습니다.
- 개발팀 팀원들이 자주 결석하면 팀원 간의 동기화가 이루어지지 않고, 팀 내부의 의사소통도 훨씬 어려워집니다. 또한 뒤쳐진 부분을 따라잡기 위해 추가 회의가 필요하게 되어 팀의 시간을 더 소모하게 됩니다.
결국, 사람들이 회의를 놓치는 것은 반드시 개인의 잘못만은 아닙니다. 이전의 할당된 업무 때문에 회의에 참여할 수 없는 상황일 수도 있습니다.
#3. 팀 안정성
스크럼 팀이 제대로 구성되고 이벤트 일정이 잡혀 있을 수 있지만, 팀이 장기간 안정적이지 않으면 (이상적으로는 최소 6개월, 개인적으로는 1년의 안정성이 최소 요구 조건이 되어야 함) 실제로 발전하고 개선될 수 없습니다.
결과적으로, 스프린트를 원활하게 진행하는 완전히 독립적인 스크럼 팀에 도달하지 못할 수 있습니다. 마지막으로, 스크럼 사고방식과 프로세스를 이해하기 위해서는 팀 내부 구성원들을 지속적으로 교육하고 배워나가야 합니다. 이것은 지치고 힘든 일입니다.
이는 특히 회사의 리더십이나 경영진이 간과하는 문제입니다. 팀 구성원을 단순히 ‘자원’이라고 부르고 분기별로 ‘활용’ 계획을 세우는 것은 곧바로 실패로 향하는 길입니다.
#4. 동일한 사람들에게 새로운 역할 부여
또 다른 극복해야 할 과제는 기존 인력을 다른 새로운 역할로 재배치하는 것입니다. 예를 들어, 이전에는 최고 권한을 가지고 팀을 관리했던 사람이 이제 제품 책임자가 될 수 있습니다. 스크럼 팀에서는 강력한 위치이지만, 이전 설정에 비해서는 상대적으로 약한 역할로 인식될 수 있습니다.
갑자기 제품 책임자는 스크럼 마스터 또는 프로그램 관리자와 협력해야 합니다. 여전히 콘텐츠에 대한 책임은 있지만, 전달 프로세스에 대한 책임은 이전만큼 크지 않습니다. 이러한 상황은 팀원들이 이전의 일부 책임을 포기해야 하므로 받아들이기 어려울 수 있습니다.
#5. 일하는 방식
이는 흥미로우면서도 종종 듣게 되는 이야기입니다. 민첩성이 필수로 여겨지는 변화하는 시장에 적응하기 위해서는 새로운 업무 방식을 배워야 합니다. 하지만 이러한 업무 방식은 정확히 무엇을 의미할까요?
제 생각에는, 경영진이 더 짧은 시간 안에 (훨씬) 더 많은 것을 달성한다는 의미가 명확합니다. 스크럼 팀이 구성된 후에는 모든 팀원이 갑자기 매일 기록되는 증분 결과를 달성할 것으로 기대됩니다. 만약 그렇지 못하다면, 경영진은 왜 애자일 프로세스가 제대로 작동하지 않는지 의문을 제기하기 시작할 것입니다.
경영진은 갑자기 모든 시간이 중요하다고 생각하고, 스크럼 팀이 기본적으로 쉬는 시간 없이 일해야 한다고 생각합니다. 왜냐하면 모든 스크럼 프로세스가 제대로 작동할 여유가 없기 때문입니다. 이것이 리더십 관점에서 바라보는 ‘새로운 업무 방식’의 정의입니다.
물론 이러한 기대는 현실에 기반하지 않은 것입니다. 일상적인 프로세스가 일부 변경되었다고 해서 회사 직원들이 같은 시간 내에 더 많은 일을 해낼 것이라고 기대하는 것은 환상입니다. 물론 일부는 그럴 수 있습니다. 하지만 이 그룹조차도 동시에 더 많은 작업을 수행하게 되므로 그 규모는 더욱 줄어들 것입니다.
목표와 현실의 차이
최종 목표에 대한 설명은 훌륭하고 많은 의미를 담고 있다는 점은 의심의 여지가 없습니다. 이는 다음 원칙을 따릅니다:
- 명확한 KPI와 OKR을 가지고 독립적인 백로그를 운영하는 안정적인 스크럼 팀
- 제품 책임자는 탄탄한 로드맵을 구축하고 구체적인 일정에 맞춰 제공할 우선순위 콘텐츠를 계획
- 작업 시작 전에 이미 상세하게 설명된 관련 기능을 포함하는 정의된 백로그 콘텐츠
- 정기적인 스프린트 개발 작업과 함께 실행되는 안정적인 테스트 프로세스
- 정기적인 프로덕션 릴리스 – 최소 한 달에 한 번, 이상적으로는 매 스프린트 완료 후
- 종속성이 있는 경우, 다양한 스크럼 팀 간의 위험과 문제를 추적하고 소통
그러나 현실에서는 위의 모든 사항을 달성하기 쉽지 않다는 것을 알 수 있습니다.
- 스크럼 팀을 구성하지만 팀원들은 끊임없이 변경됩니다 (분기마다). 팀에 스크럼 프로세스를 가르치고, 마침내 팀이 이를 이해하고 작업 방식을 바꾸기 시작하면, 다음 기간을 위해 팀이 재구성됩니다. 로드맵은 수정, 변경 또는 취소됩니다.
- 제품 책임자는 로드맵 세부 사항에 대한 실제적인 정보가 부족하고 (이전 습관 때문에) 백로그 콘텐츠 구축 작업을 팀에 직접 할당합니다. 결과적으로 팀은 무엇을 먼저 개발해야 할지 파악하는 데 시간을 소모하느라 콘텐츠를 개발할 시간이 부족합니다.
- 테스트 프로세스는 수동으로만 이루어지며, 따라야 할 많은 하위 단계와 승인 절차 및 복잡한 프로세스가 필요합니다. 즉, 개발과 동일한 스프린트 내에 테스트를 완료할 방법이 없습니다.
- 결과적으로 프로덕션 릴리스가 여러 단계 뒤쳐집니다.
- 모든 팀이 스프린트마다 많은 작업을 수행해야 하기 때문에, 다른 스크럼 팀 간의 의사소통은 혼란스럽고 비효율적입니다. 실제로 제품 책임자는 각 스프린트마다 팀에 너무 많은 콘텐츠를 할당하는 경향이 있습니다. 팀은 모든 것을 완료할 가능성이 없기 때문에 끊임없는 마감 압박에 시달립니다.
실수 수정
몇 가지 애자일 전환 프로젝트를 진행하면서 겪었던 가장 큰 실수를 요약하고, 이를 극복할 수 있는 방법에 대한 주관적인 의견을 제시하고 싶습니다.
#1. 적합한 역할에 대한 올바른 책임
정의를 왜곡하고 스크럼/애자일 방식이 아닌 다른 방식으로 책임을 분배하려 하면, 전체 이니셔티브는 실패하게 됩니다.
- 제품 책임자는 콘텐츠를 소유하고 백로그를 관리해야 합니다. 백로그 스토리를 책임지며, 백로그 스토리가 제대로 정의되지 않았다면 조치를 취하고 수정하는 것은 제품 책임자의 몫입니다. 반면, 스크럼 팀의 인력 할당이나 프로젝트 예산 결정에는 영향을 주지 않아야 합니다.
- 스크럼 마스터는 백로그 콘텐츠에 대해 어떠한 책임도 지지 않습니다. 스크럼 마스터는 이벤트들을 조직하고 애자일 업무 방식으로 팀을 교육하기 위해 팀에 소속됩니다. 제품 책임자의 비서가 되어서는 안 됩니다. 오히려 제품 책임자와 외부 이해관계자로부터 개발팀을 보호해야 합니다.
- 모든 스크럼 팀에는 배송 담당자가 지정되어야 합니다. 이 담당자는 제품 책임자, 스크럼 마스터 및 개발팀을 연결하여 실행 가능한 환경을 만들고, 제공 프로세스를 정의하며, 팀이 가질 수 있는 잠재적인 위험, 문제 또는 충돌을 해결합니다. 배송 담당자는 프로젝트의 인력 배치 및 예산 문제를 결정할 수 있는 적합한 사람입니다. 이 담당자는 모두가 최선을 다할 수 있는 팀 환경을 조성하기 위해 노력해야 합니다.
- 개발팀의 책임은 백로그의 스토리를 개발하는 것입니다. 제품 책임자가 일부 스토리(주로 기술적인 내용)에 대한 콘텐츠를 구성하는 데 도움을 줄 수는 있지만, 로드맵 콘텐츠를 만드는 스토리에 대해서는 책임이 없거나 관여하지 않습니다.
#2. 안정적인 팀
팀의 애자일 교육에 투자하는 것은 매우 중요하며, 빠르게 진행되어야 합니다. 몇 달에 한 번씩 이 지식을 잊어버리는 것은 모든 사람에게 시간 낭비일 뿐입니다.
처음 5개의 스프린트는 팀이 기본적인 스크럼 활동을 익히고 연습할 수 있는 학습 기간으로 활용될 수 있습니다. 팀 전체가 이러한 내용에 익숙해지면 스크럼 팀의 지속적인 개선 프로세스가 시작될 수 있습니다. 하지만 팀 구성원이 정기적으로 변경되면 지속적인 지식 전달과 교육의 굴레에 빠지게 됩니다.
그러한 팀은 완전한 성과를 달성하지 못할 가능성이 높으며, 리더십 팀은 왜 현재보다 과거에 (애자일 전환 이전) 더 효율적이었는지 계속 의문을 제기할 것입니다.
따라서 팀을 구성하고 지식에 투자하여 팀이 새로운 프로세스에 자신감을 갖게 되면, 팀을 유지하고 더 발전시켜나가야 합니다. 여기서부터 완벽을 향한 꾸준한 여정이 시작됩니다.
#3. RACI 매트릭스
실제 작업이 시작되기 직전에 모든 팀 간에 RACI 매트릭스(책임, 담당, 자문, 정보 제공)를 구축하고 합의하는 것이 좋습니다. 이렇게 하면 처음부터 많은 혼란을 제거할 수 있습니다.
특히 혁신 이니셔티브의 초기 단계에서는 매우 중요합니다. 그렇지 않으면, 사람들은 특히 팀의 의사소통을 통해 명시적으로 해결되지 않은 상황에서 누가 어떤 상황에서 무엇을 해야 하는지에 대해 의문을 제기하기 시작할 것입니다.
다음은 일부 책임에 대한 RACI 매트릭스 예시입니다. 프로젝트에 따라 다른 매트릭스를 사용할 수 있습니다. 중요한 것은 관련된 모든 요소를 포착하는 것입니다.
| 배송 담당자 | 제품 책임자 | 스크럼 마스터 | 개발팀 | |
| 스프린트 계획 세션 | C/I | A/I | R | C/I |
| 배송 릴리스 증분 | N/A | I | A/I | C/R |
| 스프린트 검토 | C/I | I | R | I |
| 스프린트 회고 | I | I | A/R | C/I |
| 백로그 개선 | I | A/R | C/I | I |
결론
애자일 전환이 잘못될 수 있는 방법과 이유는 많기 때문에, 아직 다룰 내용이 많을 수 있습니다. 이 글의 목적은 제가 자주 반복해서 생각하는 몇 가지 문제를 지적하는 것입니다.
이니셔티브 자체는 좋은 아이디어입니다. 하지만 몇 가지 기본적인 규칙을 지키지 않으면 참여자 모두에게 악몽이 될 수 있습니다. 저는 몇 가지를 강조했지만, 상식을 사용하면 괜찮을 것입니다. 🙂
다음으로, 애자일 인증에 대한 유용한 학습 자료를 확인해 보세요.