ScalingAgile@LEGO #3 — 빅룸 플래닝2
LEGO DS에서 henrik kniberg와 Eik Thyrsted Brandsgård가 수행했던 빅룸 플래닝 사례를 소개합니다.
빅룸 플래닝이란 다양한 팀이 서로 의존성을 가지고 일할때 큰 방에 모여 함께 계획을 세우고 논의하는 활동입니다.
Scaled Agile Framework의 PI Planning이 본래의 이름입니다. 여기서 Henrik와 Eik는 본래의 방식에 여러부분을 변경해서 적용하고 있습니다.
원문을 총 6편의 글로 분리해서 올립니다. 원문은 아래 경로에서 보실수 있습니다.
당겨오기 기반 플래닝
중요한 세부 사항을 발견하셨네요. 팀은 (대부분의 경우) 업무를 받아오는 것이 아니라 당겨옵니다. 그과거에 얼마나 많은 것을 전달했는지에 대한 데이터와 현실에 대한 직감에 기반하여 가져올 업무의 양을 결정합니다. 업무를 실제로 수행하기 위해 각 팀에는 PI 플래닝 이벤트 전에 이해 관계자와 협상하고 우선 순위가 지정된 제품 백로그를 준비하는 PO가 있습니다. 따라서 PO와 고객은 우선 순위를 관리하고 팀은 가져올 양을 선택합니다.
일부 팀은 상당히 독립적이며 자체 백로그가 있습니다. 플랫폼 팀과 같은 팀들은 함께 일하며 공유 프로그램 백로그에서 기능을 가져옵니다.
벽에 투영된 프로그램 백로그를 발견하고 서로 다른 팀의 사람들이 그 앞에 서서 어떤 기능을 어느 팀에서 가져와야 하는지에 대해 협상하는 것을 보게 됩니다.
팀은 반-전문화(Semi-specialized) 되어 각각 LEGO ID 인증, 클라우드 기술 또는 검색과 같은 다양한 영역에 집중합니다. 팀은 가장 익숙하거나 가장 덜 까다로운 기능을 가져오는 경향이 있으므로 PO는 때때로 전문 분야와 일치하지 않는 경우에도 우선 순위가 높은 해당 기능을 가져오는 것이 더 낫다는 점을 상기시켜야 합니다.
지금까지 팀은 전체적으로 (잘못된 것을 매우 효율적으로 구축하는 대신) 올바른 것에 집중하고 있는지 확인하기 위해 필요한 만큼 로드 밸런싱에 능숙해졌습니다. 팀원들은 대부분 T자형으로, 어느 정도 전문화되어 있지만 서로를 도울 수 있을 만큼 넓은 범위를 다룰수 있습니다.
다음과 같이 인쇄된 카드를 사용하여 물리적 보드에 프로그램 백로그를 넣는 방식을 사용했습니다.
…. 그러나 물리적인 보드를 사용하는 일은 성가신 일이었습니다. 그래서 우리는 벽에 붙혀진 백로그 관리 도구에서 온라인으로 직접 할 수 있는 방법을 찾았습니다. 활동적인 부분은 적지만 플랫폼 개발을 수행하는 팀이 6개 정도이므로 모든 것이 끝난 시점에 추적하는 것이 더 쉬웠습니다.
주위를 둘러보면 어떤 팀은 테이블에 큰 화면을 가지고 있어 백로그를 디지털로 보여주는 반면 다른 팀은 대부분 아날로그 도구를 사용한다는 것을 알 수 있습니다.
팀보드
각 팀에는 뒤집어 사용할수 있는 화이트 보드로 되어 있는 실제 팀 보드가 있습니다.
공백으로 시작되지만 계획이 구체화되는 낮 동안 공간은 모두 채워집니다.
다른 섹션의 의미는 다음과 같습니다.
이것은 기본적으로 계획 이벤트의 주요 결과물인 다음 4개의 스프린트(각 스프린트는 2주이므로 제품 증분은 8주)에 대한 팀의 상위 수준 계획입니다.
- “어… 8주에 한 번만 배포된다고요?”
- “아니요. 8주는 프로그램 수준의 계획 주기일 뿐입니다. 릴리스 주기는 완전히 별개이며 일부 팀은 더 자주 배포하고 일부는 더 드물게 배포하게 됩니다.”
물론 계획은 각 팀 환경의 변동성에 따라 변경될 것입니다.
변경이 일어나더라도 수립된 계획은 우선 순위, 상호 의존성, 용량 등에 대한 모든 대화를 유도하기 때문에 여전히 유용합니다. 수요는 항상 용량을 초과하니 팀과 고객은 어려운 절충 결정을 내리기 위해 협력해야 합니다.
계획을 돕기 위해 팀은 어제 날씨(http://www.agilenutshell.com/yesterdays_weather)를 사용합니다. 즉, 과거 PI의 데이터를 보고 얼마나 많은 작업을 완료했는지 보여줍니다(스토리 포인트). 이 약간의 데이터는 과하게 약속을 하는 것을 피하기 위한 현실 확인 역할을 합니다. 과도한 약속으로 인해 품질이 떨어지고 마감 시간을 놓치고 고객과 팀 간의 불신으로 이어지는 문제가 일어나는 경우가 많습니다. 불확실성에 직면하면 과도하게 커밋하고 나중에 작업을 미루는 것보다 적게 커밋하고 나중에 더 많은 작업을 가져오는 것이 좋습니다.
“PI 목표”는 팀의 높은 수준의 약속이며, 산출물 기반(output-based, “기능 Y를 제공할 것”)과 달리 이상적으로는 영향 기반(impact-based”, 비즈니스 결과 X 달성”)입니다. 그러나 다양한 방식을 사용합니다. 확장 목표(Stretch goal)는 팀이 완료할 수 있거나 완료하기를 희망하지만 약속할 만큼 자신감이 없는 목표를 의미합니다.
- “하지만 잠깐만, “약속(Commitment)”은 대체 무엇을 의미합니까?”
물어봐주셔서 기쁩니다! 약속된 PI 목표는 다음을 의미합니다.
- “지금 알고 있는 바를 바탕으로 우리는 이것을 실현할 수 있다고 정직하게 믿습니다.”
- “불확실성에 대처할 여유가 있다”. 얼마나 많은 예비 용량이 필요합니까? 다음에 따라 다릅니다
- 관련된 작업의 양에 대해 얼마나 불확실합니까?
- 환경에 대해 얼마나 불확실한가(우선순위 변경 등)
- 이 약속이 얼마나 중요한가? 그것이 더 중요할수록 우리가 약속할 수 있는 다른 목표는 줄어듭니다.
- “최선을 다해 약속을 지키겠지만 100% 확신할 수는 없다.”
- “언제든지 이를 이행할 수 있다는 믿음을 멈춘다면 이해관계자들에게 최대한 빨리 알릴 것입니다.”
과거에 약속(Commitment)의 의미는 종종 “당신을 대신한 누군가가 결정한 비현실적인 약속을 의미했습니다. 그냥 받아 들여라.”. 하지만 이것은 품질과 동기부여를 해치고 계획과 예측을 정말 어렵게 만들었습니다.
