ScalingAgile@LEGO #1 — 배경과 문제

jonghyun yoo
safe-community.kr
Published in
5 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

사회적 이벤트로서의 플래닝

Scaling Agile @ LEGO

Henrik Kniberg & Eik Thyrsted Brandsgård

2016년 12월

- 무엇을? 1일간의 150명의 회의

- 예!! 두달마다! 매우 잘 작동함!!

- 하지만 어떻게? 왜?

배경

LEGO Digital Solutions(DS)는 컴퓨터, 태블릿, 앱, 웨어러블, VR 등 사용하는 모든 장치를 통해 부모와 어린이의 커뮤니케이션을 지원한느 20개 이상의 팀으로 구성된 그룹입니다. 또한 우리는 또한 미래의 제품 개발, 새로운 기술을 수용하는 방법, 장난감을 가지고 노는 고전적인 방법을 포함하여 증강 현실과 같은 멋진 무언가와 결합하는 방법 또는 실제 모델을 “스캐닝”하고 게임에 넣는 방법에 대해 연구합니다. 대부분의 팀은 덴마크의 Billund에 있지만 인도에도 많은 팀이 있습니다.

LEGO는 본질적으로 디지털 회사가 아닙니다. 80년 역사의 17000명 규모의 조직으로 물리적 장난감의 디자인과 제조, 마케팅에 최적화되어 있습니다. 대부분의 회사와 마찬가지로 LEGO는 변화가 지속적이고 민첩한 개발이 표준이 되는, 더 빠르게 변화하는 디지털 세계에 적응하기 위해 노력하고 있습니다.

Digital Solutions은 LEGO에서 이러한 변화의 최전선에 있으며, 우리는 여러분과 공유하고 싶은 매우 흥미로운 여정을 진행하고 있습니다!

문제

5개 정도의 개발 팀만 있던 시절에는 계획과 동기화가 상당히 관리하기 쉬웠습니다. 팀과 제품 소유자는 기본적으로 서로 이야기하고 무엇을 해야 할지 알아낼 수 있습니다. 그러나 우리가 15–20개의 팀으로 성장하면서 상황이 점점 더 고통스러워지기 시작했습니다.

LEGO는 전체적으로 꽤 좋은 포트폴리오와 예산 책정 프로세스를 가지고 있습니다. 투자 프레임은 매년(프로젝트 Y의 경우 X시간) 협상되는 반면 실제 콘텐츠 결정에은 재무 결정과 분리되므로 부서는 얼마나 많은 리소스를 투입할지에 대해서는 상당히 유연할 수 있었습니다.

그래서 2014년에는 이 안정적인 포트폴리오 관리 프로세스가 최상위 수준에 있었고 팀 수준에서는 스크럼과 스프린트를 하는 15–20개 팀이 있었습니다. 문제는 중간 프래그램 수준에 있었습니다.

우리는 스크럼을 사용하여 애자일 방식으로 작업하려고 했지만 기본적으로 프로젝트를 수행하는 매트릭스 조직 형태였습니다. 제품 소유자는 거의 모든 시간을 어떤 일을 해야하는지를 결정하기 위해 팀을 조정하는 회의에 참여하는데 보냈습니다. 하지만 결국에는 다른 팀에 다른 우선순위가 있기 때문에 결국 필요한 것을 얻지 못하게 되었습니다.

플랫폼 제품 소유자로서, 10명의 사람들이 찾아와서 요청하는 것은 너무 많기 때문에 모든 것을 제공할 수 없습니다. 그렇다면 어떻게 더 중요한 것을 결정해야 할까요? 때로는 팀들이 동일한 것을 만들어 버릴 수도 있습니다. 예를 들어, 이미 다섯 대의 회전목마가 있는데 롤러코스터도 추가하면 좋겠다고 생각하는 경우가 있을 수 있습니다. 좋은 것은 많을수록 좋다고 생각하지만, 이런 상황은 발생하지 않아야 합니다.

요약하자면, 우리는 다음과 같은 어려움을 겪었습니다.

  • 교차 팀 방향 정렬 — 팀이 서로 걸려 넘어지지 않고 같은 방향으로 움직이도록 하는 방법
  • 클라이언트 협업 — 과도한 약속 없이 현실적인 기대치를 설정하고 클라이언트를 만족시키는 방법
  • 릴리스 계획 — 여러 스프린트, 여러 팀 및 여러 제품에 걸쳐 작업을 계획하고 우선 순위를 지정하는 방법
  • 플랫폼 개발 — 일회성 솔루션을 구현하지 않고 미래를 위해 투자하는 방법

2014년 말에 가까워지면서 우리는 다른 것을 시도하기로 결정했습니다.

--

--