ScalingAgile@LEGO #6 — 그래서, 지금의 문제는

jonghyun yoo

Published in

safe-community.kr

14 min readJul 3, 2023

LEGO DS에서 henrik kniberg와 Eik Thyrsted Brandsgård가 수행했던 빅룸 플래닝 사례를 소개합니다.

빅룸 플래닝이란 여러 팀이 서로 의존성을 가지고 일할때 큰 방에 모여 함께 계획을 세우고 논의하는 활동입니다.

Scaled Agile Framework의 PI Planning이 본래의 이름입니다. 여기서 Henrik와 Eik는 본래의 방식에 여러부분을 변경해서 적용하고 있습니다.

원문을 총 6편의 글로 분리해서 올립니다. 원문은 아래 경로에서 보실수 있습니다.

https://crisp.se/wp-content/uploads/2016/12/Agile@Lego.pdf

큰 방 계획 외에 변경된 사항은 무엇입니까?

많습니다! PI 플래닝은 우리가 만든 변경 사항의 무게 중심이지만 분명히 그 이상의 것이 있습니다. ‘실제’ 작업은 실제로 PI 플래닝 사이에 일어나는 일입니다.

PI 동안 팀은 일반적으로 스프린트 계획, 일일 스탠드업, 백로그 개선, 스프린트 검토 및 스프린트 회고와 같은 일반적인 스크럼 행사와 함께 스크럼 및 2주 스프린트를 수행합니다. 또한 공유된 PI 데모 및 회고가 있습니다. 그러나 우리는 그것들에 대한 세부사항을 이야기하지는 않을 겁니다. 이 글은 PI 플래닝 이벤트에 초점을 맞추고 있습니다. PI 플래닝이 우리가 달성하고자 하는 분산 조정과 상향식 의사결정을 보여주기 때문입니다. PI 플래닝은 전체 프로세스와 문화를 들여다보는 거울과 같습니다.

강조할 가치가 있는 활동 중 하나는 PO가 함께 모여 향후 PI의 기능에 대해 논의하고 우선 순위를 지정하는 PI 사전 플래닝(PI Pre Planning)입니다. 각 PI 플래닝 전에 이러한 사전 플래닝 세션이 세 번 있습니다. 여기에서 요건들은 헤드라인에서 가치, 시간 중요도 및 노력에 따라 우선 순위가 지정된 잘 이해되는 기능으로 발전됩니다. 더 자세히 알고 싶다면 지연 비용 또는 WSJF(가중치 최단 작업 우선)를 읽어보십시오. 더 깊이 들어가고 싶다면 Don Reinertsen의 책 “Principles of Product Development Flow”를 확인하십시오.

PI 기획 행사의 실제 목적은 무엇입니까?

한 마디로: 정렬(alignment)입니다.

PI 플래닝은 빅룸 플래닝 이벤트이며 목적은 팀이 서로 정렬되도록 하는 것입니다.
빅 룸 플래닝의 가치는 얼마나 많은 종속성이 있는지와 직접적인 관련이 있습니다. 물론 가장 좋은 방법은 팀 구조와 아키텍처를 설계하여 종속성을 최소화하고 큰 방 플래닝과 같은 작업이 필요하지 않도록 하는 것입니다. 그러나 동일한 제품에 대해 작업하는 여러 팀이 있거나 (우리의 경우와 같이) 공유 기술로 밀접하게 관련된 제품에 대해 작업하는 경우 빅 룸 플래닝이 매우 유용합니다.

스프린트의 경우 각 팀에는 2주의 플래닝 범위가 있습니다. PI 플래닝은 팀이 함께 모여 미래(2개월, 하나의 “제품 증분”)를 더 자세히 내다보는 더 높은 수준의 플래닝 범위에 추가하지만 세부 사항은 많지 않습니다.

비결은 정확하고 상세한 계획을 세우려는 유혹을 피하는 것입니다. 정확히 틀린 것보다 대략적으로 맞는 것이 좋습니다.
제품 증분은 — 그렇게 보이지는 않지만 — 빅뱅 릴리스가 아닙니다. 그것은 동기화 지점, 팀이 서로 정렬하기 위해 함께 모이는 시간과 장소입니다. 이것은 릴리스 주기에서 완전히 분리됩니다. 다른 팀은 작업의 특성에 따라 다른 주기로 릴리스합니다. 그래서 우리는 일정을 계획하고 필요에 따라 출시합니다.

PI 플래닝은 팀이 잘못 정렬되어 발생하는 모든 좌절과 낭비의 문제를 해결합니다. 그것은 사람들에게 공통의 목표, 즉 다수의 자율적인 팀을 동기화하는 “Big Heart Beat”를 만드기 위한 연결점을 제공하기 위한 플랫폼입니다.

얼굴을 맞대고 있는 것보다 좋은 방식은 없습니다. 공유되는 정보의 양과 PI 플래닝 중에 만들어지는 결정의 수는 실제로 매우 놀랍습니다. 이것은 모든 두뇌에 대한 신뢰와 권한 부여가 동시에 같은 방에서 모이기 때문에 가능합니다. 대화가 필요한 사람은 지금 바로 여기 방에 있습니다. 캘린더 초대장을 보내거나 적절한 회의 시간을 기다릴 필요가 없습니다.

계획 이벤트가 없으면 동일한 작업을 수행하기 위해 별도의 조정 회의와 이메일 및 스프레드시트가 많이 끼어들기때문에 대기 시간이 더해지고 오해가 생깁니다. 작업의 세부 사항은 PI 플래닝 이후(스프린트 중)에 논의되지만 큰 뼈대는 빅룸 플래닝 이벤트에서 생성됩니다. PI 플래닝의 또 다른 이점은 대규모 소프트웨어 개발의 고유한 복잡성을 드러내는 근본적인 투명성을 생성한다는 것입니다. 이러한 부분은 외부에 약간 경외감을 전달해 줄 수 있습니다

이해 관계자들이지만 실제로 복잡성 괴물을 길들이기 위해 노력하는 팀에 대해 더 잘 이해하고 존경심을 갖게 됩니다.
그렇다면 단점은 무엇일까요? 글쎄요, 비용이라고 말하고 싶지만 사실 그렇게 큰 문제는 아닙니다. 사람들은 PI 플래닝에 있든 없든 동일한 급여를 받습니다. 유일한 실제 간접 비용은 행사장과 음식이며 얻은 가치에 대해 지불하기에는 작은 가격입니다.

한 가지 심리적 단점은 당신이 통제광이라면 마음의 평화와 수정처럼 명확한 계획을 가지고 나오지 않을 것이라는 점입니다. 전체 설정이 상당히 혼란스럽고 구조화되지 않은 것처럼 느껴질 수 있습니다.

그러나 형식에 익숙해지면 회의가 목표를 달성할 수 있을 만큼 충분히 좋은 개요를 제공하는 동시에 특히 중요하다고 생각하는 영역을 확대할 수 있다는 것을 알게 됩니다. 나머지는 신뢰를 바탕으로 팀에 맡겨야 합니다. 결국 팀구성원들은 일반적으로 꽤 똑똑하고 헌신적인 사람들입니다. 다른 사람들을 고용할 이유가 없습니다. :)

이것이 어떤 영향을 미쳤습니까?

완벽한 것은 없지만 전반적으로 그 영향은 놀라울 정도로 긍정적이었고 아무도 과거로 돌아가고 싶어하지 않는 것 같습니다.

중복 작업이 적습니다. 팀은 서로 더 잘 조화를 이루므로 중복 작업에 시간을 덜 낭비합니다.
종속성 문제가 적습니다. 팀은 서로를 기다리는 데 방해되는 시간을 덜 낭비합니다. 팀은 다른 부서 및 이해 관계자와 보다 원활하게 상호 작용합니다.
관리자는 실제로 무슨 일이 일어나고 있는지 더 잘 알고 있기 때문에 우선 순위를 업데이트하고 장애를 더 빨리 해결할 수 있습니다.
고객은 팀이 무엇을 하고 있고 왜 하는지 더 잘 이해하고 있기 때문에 고객의 신뢰가 향상되었습니다.
팀과 포트폴리오 계획자는 우리가 얼마나 많은 일을 할 수 있고 우리의 실제 역량이 어느 정도인지 알기 때문에 계획이 더 쉽고 약속이 더 자주 충족됩니다.

더 중요한 것은 팀원들의 동기부여가 향상되었다는 것입니다. 혼란과 낭비가 적으면 출근이 더 즐겁습니다. 그리고 동기 부여된 사람들은 더 나은 일을 하므로 긍정적인 주기입니다!

우리가 목격한 또 다른 영향은 LEGO의 다른 부분이 회의를 방문하고 큰 영감을 얻고 자신의 부서에서 이러한 원칙과 관행 중 일부를 구현하는 방법을 탐구하기 시작했다는 것입니다. 사실 애자일(Agile)은 회사 내에서 바이러스처럼 퍼지고 있고, PI 기획 이벤트의 가시성이 높은 성격은 촉매제와 같습니다.

그럼에도 불구하고 여전히 복잡하고 힘든 작업(우리가 즐겨 부르는 “하드 펀”)이며 개선의 여지가 많습니다. 그러나 공유 목표를 향해 더 잘 일치하고, 더 많은 권한을 부여받은 팀을 확보하고, 고객에 대한 올바른 기대치를 더 잘 설정하고, 상호 의존성을 더 잘 식별함으로써, 이 모든 것이 우리가 올바른 일을 올바른 방식으로 해나아가는데 더 능숙해졌다는 느낌을 만들어 냅니다.

이 모든 것이 어떻게 시작되었습니까?

아직 궁금한 것이 남아 있나요? 이 모든 것이 처음에 어떻게 시작되었는지 알고 싶습니까? 자, 여기 뒷이야기가 있습니다.
90년대 후반의 삶은 좋았습니다. 소수의 사람들(오늘날 교차 기능 팀이라고 칭함)이 GIF와 HTML로 LEGO의 모든 온라인 도구를 만들었습니다. 그러나 디지털이 성장함에 따라 디지털 솔루션을 제공하는 데 필요한 인력도 늘어났고 개발 도구도 훨씬 더 발전했습니다. 15개 팀 정도에서 정말 서로 발로 밟고 서로 다른 방향으로 밀고 당기고 있었어요. 처음에 우리는 이 문제를 해결하기 위해 많은 프로젝트 관리자를 넣어서 해결해보려 했지만 실제로 도움이 되지 않았습니다. 그들은 항상 한 발짝 뒤쳐져 있는 것처럼 보였습니다. 일반적인 증상: 지속적으로 계획을 업데이트하고 운영 위원회에 추가 자금 또는 출시 날짜 연기를 요청합니다.

우리는 2009년경에 팀 수준에서 도입한 애자일 원칙을 여전히 믿었지만 실제로 확장하는 방법을 몰랐습니다. 프로젝트 관리자 중 한 명이 “Scaled Agile Framework”라는 것에 대해 들어본 적이 있으며 이에 대해 자세히 알아보기 위해 갔습니다. 그는 그가 돌아왔을 때 그것을 공유했고 우리는 그것에 대한 결정을 계속 미루었습니다…몇 년 동안.

그런데 갑자기 일이 진행되기 시작했습니다. 일부 팀과 논의한 후 프로젝트 관리자는 이 프레임워크가 우리를 도울 수 있다고 확신했습니다. 따라서 부서의 모든 관리자는 프레임워크에 대한 소개에 초대되었습니다. 그들은 완전히 확신하지 못했지만 그럼에도 불구하고 그것이 도움이 될 것 같았고 상황을 악화시킬 가능성은 거의 없어 보였습니다. 그래서 도대체 한 번 시도해 보지 않겠습니까? 그래서 선임 관리자가 이를 뒷받침하고 부서의 120명 모두를 교육할 자금을 확보했습니다.

시뮬레이션을 포함하여 3일간의 교육을 받은 후 다음 날 믿음을 갖고 프로그램 백로그를 작성하고 첫 번째 PI 계획을 예약했습니다. 시끄럽고 비좁고 혼란스러운 시작이었습니다. 그러나 놀랍게도, 우리는 실행에 착수했고 이벤트는 우리가 우려했던 것보다 더 잘 진행되었습니다.

다음은 성공적인 시작에 도움이 된 몇 가지 사항입니다.

팀이 이 방식을 통해 도움 받길 원했습니다. 팀이 그것을 받아들이지 않았다면 우리는 비참하게 실패했을 것입니다. 프레임워크의 일부에 대한 회의론에도 불구하고 그들은 실제로 노력을 통해 성공하기 위해 최선을 다했습니다.
기존의 애자일 경험. 팀은 수년간 애자일을 운영해 왔으며 조직의 상당 부분이 원칙을 이해하고 있었습니다. 이것은 확장할 수 있는 정말 좋은 기반이었습니다.
경영진의 동의. 경영진의 충분한 지원과 믿음이 있었기 때문에 성공할 수 있었습니다. 직접적인 관련이 있는 고위 관리자는 거의 없었지만 그들은 관련된 위험을 수용하고 상황이 전개될 여지를 주었고 관련된 모든 사람을 교육하고 훈련할 수 있는 충분한 재정적 지원이 있는지 확인했습니다.
비독단적 접근. Scaled Agile Framework를 실행 패드로 사용했지만 종교적으로 프레임워크를 따르지는 않았습니다. 프레임워크는 우리의 요구에 대해 너무 많은 세부 사항을 포함하고 있으며, 우리 팀이 다양한 제품과 서비스를 작업하는 동안 한 제품에 대해 작업하는 여러 팀에 최적화되어 있습니다. 그래서 각각의 새로운 PI에 대해 프로세스를 사용자 정의하고 조정하여 필요한 요소를 추가하고 가치를 추가하지 않는 요소를 제거했습니다. 그것은 사람들에게 주인의식을 주었고, 그 반대의 경우가 아니라 프로세스와 구조가 그들에게 봉사하기 위해 존재한다는 것을 알 수 있었습니다.

이제 뭐? 당신의 현재 도전 과제는 무엇입니까?

우리는 계속 실험합니다. 각각의 변화는 상황을 개선하거나 악화시키거나 차이를 만들지 않을 때도 있습니다. 그러나 우리는 작동하는 것은 유지하고 작동하지 않는 것은 버리므로 시간이 지남에 따라 상황이 점차 개선됩니다.

가장 큰 개선 사항은 초기에 있었지만 지금은 변경 사항이 더 작아서 지속 가능한 흐름을 찾은 것 같습니다. 대부분 사소한 조정 및 절충안. 방에 너무 많은 사람들이 있기 때문에 모든 사람이 정말 행복하다고 확신할 수는 없지만 적어도 아무도 매우 불행하지 않다는 것은 확인할 수 있습니다.

우리의 가장 큰 도전은 우리가 다양한 유형의 일을 한다는 것입니다. 우리는 대부분 동일한 도구와 기술을 사용하는 한 부서이지만 일관된 단일 제품을 구축하지 않습니다. 이상적으로는 특정 제품이나 가치 흐름을 기반으로 하는 여러 소규모 팀 클러스터로 재구성하는 것이 좋습니다. 그런 다음 큰 몬스터 회의 대신 여러 개의 작은 PI 계획을 가질 수 있습니다.

그러나 우리는 아직 그것을 알아내지 못했고, 계획을 위해 모두가 같은 방에 있는 편리함에 익숙해졌습니다. 결과적으로 명확한 스토리 라인으로 한두 가지 주제에 PI 계획을 집중하기가 어렵습니다. 대신 우리는 서로 다른 팀과 이해 관계자에게 제공되는 다양한 목표의 묶음으로 끝납니다. 관리자는 팀이 작업할 내용에 대한 명확한 스토리를 원하기 때문에 만족스럽지 않습니다. 현재 상황과 전반적인 우선 순위에 대한 명확한 이해를 원하기 때문에 팀도 만족스럽지 않습니다. 일종의 닭과 계란 문제입니다.

프로세스를 실험하고 조정하는 것은 좋은 일처럼 보이지만 때때로 우리는 메타 질문을 스스로에게 묻습니다. 우리는 정말로 올바른 변수를 최적화하고 있습니까? 아니면 단지 변화를 위해 무언가를 바꾸고 있습니까? 예를 들어, PI 계획이 더 이상 가장 큰 제약이 아닌 경우 계속 개선해야 합니까? 지금까지 우리는 우리가 올바른 것을 개선하고 있다고 솔직히 생각하지만 가끔 확인하는 것이 좋습니다.
또 다른 과제는 추진력입니다. 처음에는 모두가 변화에 흥분(또는 불안)했고 에너지가 높고 분위기가 좋았습니다. 그러나 때때로 우리는 편안한 “평소와 같은 비즈니스” 사고방식에 빠져 추진력을 잃습니다. PI 계획 중 작은 변화와 놀라움은 사람들이 계속 생각하게 만드는 좋은 일이 될 수 있습니다. 상황은 항상 개선될 수 있습니다. 우리는 때때로 그것에 대해 스스로에게 상기시켜야 합니다.

마무리

이 글이 도움이 되었기를 바랍니다! 이 글은 확실히 우리에게는 유용했습니다 — 우리가 무엇을 하고 배웠는지에 대해 정말로 반성할 기회를 주었습니다 :o) 우리의 접근 방식은 애자일 확장에 대한 “정답”이 아니라는 점을 명심하십시오. 이는 진행 중인 여정의 스냅샷일 뿐입니다. Agile은 지속적인 개선에 관한 것입니다. 이는 지점이 아니라 방향입니다.

그래도 한 가지는 확실합니다. 우리가 처음부터 이 전체 변경을 계획하려고 했다면 아무 것도 얻지 못했을 것입니다! 대신 변화를 만들고 싶다면 지금 있는 곳에서 시작하여 일종의 목표를 설정한 다음 실험을 시작하십시오. 모든 것은 사람들에 관한 것입니다. 그들이 변화에 동참하고 아이디어를 지지한다면 발전할 것입니다. 그렇지 않은 상황이라면 잘되지 않을 겁니다.

그리고 기존 프로세스 프레임워크를 사용하거나 다른 회사 또는 사례 연구(이와 같은)에서 아이디어를 차용하는 것을 부끄러워하지 마십시오. 바퀴를 재발명할 필요가 없습니다! 상황에 맞게 조정했는지 확인하십시오. 요구 사항에 맞는 완벽한 솔루션을 찾을 수는 없지만 올바른 방향으로 공을 굴리는(또는 벽돌이 날리는) 솔루션을 찾을 수 있을 것입니다.
행운을 빕니다!