AgileByExample : Scaling Agile at LEGO

레고에서의 애자일을 PM인 Lars Roost가 ABE 컨퍼런스에서 공유합니다.

어떤 관점에서 레고가 SAFe을 적용하였는지 살펴보시기 바랍니다.

 

https://www.youtube.com/watch?v=RPhCagS9II8&t=342s 

 

 

아래는 스크립트를 번역하여 첨부하였습니다.

번역은 Chat-GPT 4의 도움을 받았습니다. ^^

 

제 이름은 라스입니다. 저는 레고와 함께 일합니다. 
더 구체적으로 말하면, 저는 소비자 마케팅 에이전시와 함께 일합니다. 엔지니어로 졸업했을 때는 이런 일을 할 줄은 생각하지 못했습니다. 저는 디지털 경험 플랫폼에서 일하고 있습니다. 
이는 글로벌 마케팅에서 웹사이트, 앱, 게임 등을 구축하는 부분입니다. 이제부터 이야기할 내용은 오늘 아침 알게 된 것이지만, 저는 공식적으로 프로그램 매니저라는 직책을 맡고 있습니다. 
이는 예산, 일정 등 기존의 관리 업무를 담당하며 대규모 프로젝트를 수행합니다. 또한, 애자일에 대한 지식도 꽤 있으며, 이번에 제가 이야기할 내용은 제가 맡는 조직의 약 140명의 직원 중 일부가 참여한 실험 중 하나입니다.
하지만 이야기하기 전에, 이 실험에 대해 얘기하기 전에, 지난 1년간의 경험에 대해 소개하고, 이 경험을 토대로 어떻게 애자일을 확장시켰는지에 대해 사진들과 함께 소개할 예정입니다.


그것은 약 1년 전, 제가 현재의 직책을 맡기 시작한 때 시작되었습니다. 그 당시에는 스크럼이나 칸반을 사용하는 14개의 개발 팀이 있었고, 수요는 용량을 초과하는 상황이었습니다. 시장 변화는 점점 더 빨라지고, 우리는 이에 더욱 빠르게 대응해야 했습니다.
그렇다면 어떻게 해야할까요? 제 첫 번째 생각은, 작게 유지하고 따로따로 구성하는 것입니다. 필요한 부분만 확장하는 것입니다. 하지만, 기술적으로 결합도가 높은 기술들이 있었고, 서로 의존하는 제품을 다수 개발하고 있었습니다. 
어떤 팀은 하나의 제품에 대해 스프린트를 수행하고, 또 다른 팀은 다른 제품에 대해 스프린트를 수행하면서, 인적, 기술적 의존성이 여기저기에 존재했습니다. 이러한 상황에서 이미 크고 복잡한 상황에서 애자일을 확장하는 방법은 무엇일까요? 
처음에는 모두 작게 유지하고 따로따로 구성하는 것이 가장 좋을 것이라고 생각했지만, 글로벌 회사에서는 계속해서 마케팅 캠페인을 진행해야 하고, 약 70%의 제품은 매년 새롭게 출시됩니다. 이러한 제품들도 마케팅 자료가 필요합니다. 
따라서 대안은 140명의 직원을 2일 동안 한 방에 모아 실험을 진행하는 것입니다. 이것이 "빅룸 플래닝"이라는 해결책입니다. 이것은 우리가 기본에 집중해야 한다는 믿음에서 출발합니다.


우리는 간단한 것들을 확대하고, 최하위 수준에서의 협력을 확대해야 합니다. 대규모 확장을 하면 보통 부가적인 작업들이 생기며, 우선순위를 조정하고 조정할 필요가 있습니다. 
이러한 것들은 팀을 방해할 수 있습니다. 이것은 팀이 단독으로 일할 때보다 그렇습니다. 우리가 해야 할 일은 "확장"입니다. 이는 프레임워크의 선택에 있어서 문제가 없으며, 몇 가지 프레임워크 중에서 선택할 수 있습니다. 
우리가 선택한 것은 "SAFe"입니다. 이것은 쉽지 않은 것이라고 생각합니다. 인터넷에서 "SAFe"에 대해 검색하면 이 프레임워크의 문제점에 대한 많은 이야기가 있습니다. 그러나 이것은 그냥 어떤 요리책과 마찬가지입니다. 
"SAFe"는 크고 무거운 요리책입니다. 다양한 레시피가 있으며, 이것은 다양한 방식으로 요리를 할 수 있다는 것을 의미합니다. 우리는 이것에서 영감을 받아 일부 레시피를 사용했습니다.

우리가 직면한 상황은 하단에 "스크럼" 팀이 있는 것이었고, 이 팀들은 2주마다 스프린트를 수행하고 있었습니다. 우리는 "칸반"을 적용한 대규모 예산 프로세스가 있었는데, 이것은 소프트웨어 개발뿐만 아니라 레고의 모든 제조 부문에 영향을 미치는 연간 예산 사이클이었습니다. 
우리는 팀과 둘러싸인 환경 간의 중개자가 필요했습니다. 이것은 애자일 프로세스를 모르는 사람들이 이해할 수 있는 것이어야 했습니다. 우리는 이 프로그램 레벨에서 "제약 엔지니어restrain engineer"라고 부르는 스크럼 마스터를 도입하기로 결정했습니다. 
이 사람은 팀 대신에 말을 할 수 있으며, 팀 밖에서 공유되는 프로세스를 담당합니다. 이것은 우리에게 적합했습니다.


또한, 이것이 우리에게 드레스 업 할 기회를 제공한다고 생각했습니다. 이것이 왜 그렇게 생각하는지는 나중에 보여드리겠지만, 우리는 모든 것을 도입하지 않았습니다. 
우리는 이것을 소개했고, 우리만의 방식으로 문제를 해결했습니다. 우리는 첫 번째로 공유된 리듬을 시작했습니다. 지금은 "SAFe"가 2계층 계획 리듬과 함께 작동하는 것이 중요하며, 우리는 거의 스크럼 설정과 동일한 2주마다 스프린트를 유지했습니다. 
그리고 우리는 이것 위에 프로그램 리듬을 도입했습니다. 이것은 8주 리듬이며, 우리의 계획 타이밍을 지배합니다. 이것은 계획 타이밍을 지배하는 것이지 출시 타이밍을 지배하는 것은 아닙니다. 
우리는 여전히 지속적인 배송 조직을 운영하고 있으므로, 제품이 준비되면 언제든지 출시할 수 있습니다.


우리는 스프린트나 프로그램 증분의 끝까지 묶어두지 않고, 제품이 준비되면 즉시 출시합니다. 그러나 우리는 계획에 고정된 리듬으로 계획을 세우므로, 이 큰 조직에서 생기는 많은 복잡성을 처리할 수 있습니다.
하지만 우리는 고정된 리듬으로 계획을 세우고, 이는 이제 약 20개의 팀으로 구성된 이 큰 조직에서의 복잡성을 처리할 수 있도록 해줍니다. 보통 "SAFe"는 하나의 제품을 함께 제공하는 팀 팀의 드라이브 출시 열차에 대해 이야기합니다. 
그러나 우리는 다양한 마케팅 캠페인과 다양한 마케팅 채널을 다루고 있으며, 이들은 상호 연결되어 있습니다. 그래서 우리는 모든 개발 팀이 하나의 리듬으로 함께 작업하도록 선택했습니다. 
그들이 서로 느슨하게 결합되어 있을 수도 있지만, 어쩌면 스프린트나 10개월 프로그램 증분에서는 더 긴밀하게 결합될 수도 있습니다. 그래서 모두 함께 일하게 하고, 어떻게 될지 보고 시작해 보기로 결정했습니다. 


그리고 큰 방 회의가 나타났습니다. 하지만 이것은 처음에 그렇게 생겼던 것은 아니었습니다.
우리 방은 모든 사람을 수용하기에는 너무 작았고, 소음이 매우 심했습니다. 하지만 꾸러미 속에서 들려오는 꿈틀거리는 소리가 들리기도 했고, 일부 팀은 릴리스 일정과 충돌하지 않도록 중간에 나가야 했습니다. 
그 결과 모두 머리가 아프고 첫날은 간신히 스프린트 계획을 수행할 수 있는 너무 좁은 공간이었습니다. 그러나 역할에 따른 재미있는 모자를 준비해 놓아서 좋았습니다.


그러나 이것이 상당히 잘 작동했습니다. 모든 불만과 소음에도 불구하고, 팀은 이것을 계속 사용해야 하는 것으로 느꼈습니다. 이것은 의사 소통을 현장에서 수행하게 해주고, 다른 팀과 바로 대화할 수 있도록 했습니다. 
이번 회의에서 스테이크 홀더도 참여해서 많은 의사 소통이 이루어졌습니다. 그리고 그 의사 소통을 기반으로 팀들은 첫 번째 계획을 수립할 수 있었습니다. 
이를 통해 팀들은 즉각적인 피드백을 받아들여, 다음 스프린트에서 계획을 수정할 수 있었습니다. 그래서 그들은 이후에 빌드할 것이며, 이를 관리부서에서 즉각적인 피드백을 받을 것입니다. 
그래서 그들은 자신들의 계획을 보여주면서 "우리는 다음 두 달 동안 이것을 할 예정입니다" 라고 말할 수 있으며, 관리부서는 "멋져요" 또는 "그건 아니에요" 라고 피드백을 제공할 수 있습니다.

이제 그것이 실제로 어떻게 보이는지 알아보죠. 이것은 지난 달에 수행한 최근 플랜에 대한 오버레이 아젠다입니다. 이 슬라이드의 주요 포인트는 파란색 영역이 관리부서에서 대중에게 전달하는 의사 소통이라는 것입니다. 
노란색 토픽은 팀이 함께 앉아 스프린트 계획을 수행하는 작업이고, 빨간색 영역은 변경 사항에 대한 논의입니다. 이것은 참고용으로 유지해서 현재 어느 부분에 있으신지 파악할 수 있도록 합니다. 일반적으로 시작할 때는 이전 PI에 대한 피드백을 받습니다.

그럼, 팀들이 우리가 원하는대로 제품을 제공했는지, 우리가 기대한 것들을 충족했는지 등 관리층으로부터 팀들에게 피드백을 전달합니다. 
이는 매니지먼트 측면에서 예를 들면 "네, 너희는 멋진 일을 했어" 또는 "아니, 고객이 원하는 것을 몰랐어"와 같은 피드백을 주고, 팀들에게 유용한 다양한 정보를 제공합니다. 
우리는 프로그램 증분을 계획할 때 고려할 수 있는 정보들입니다. 우리는 모든 팀원들이 참여하는 스프린트 데모도 진행합니다. 이것이 빠른 회의 진행의 전체적인 개요입니다. 그리고 팀들이 다가오는 프로그램 증분을 계획할 때 고려해야 할 것들에 초점을 맞추며 진행됩니다. 
이러한 회의 시작에 필요한 것들을 얻는 것은 좋은 방법입니다.

그 후에는 라이트닝 토크(빠른 강연)가 이어집니다. 이는 여러 가지 주제를 다룹니다. 주요 목적은 팀들에게 영감을 주고 내부 계획에 가이드를 제공하는 것입니다. 
일반적인 지침으로 모든 사람이 공유하는 일부 아키텍처 측면과 고객 우선 순위에 대한 높은 수준의 우선 순위도 있습니다. 
물론 각 팀의 제품 소유자들은 해당 팀에만 관련된 추가 세부 정보를 갖고 있지만, 이것이 주요 이야기입니다. 
우리는 또한 팀들이 고려할 것으로 생각되는 주제를 찾는 데 많은 노력을 기울였습니다. 
어린이를 위한 디지털 안전에 관한 것, 아이들이 무엇을 좋아하고 관심을 가지는지에 대한 모든 인사이트를 수집하는 Lego의 중앙 부서인 Global Insights, 변경 및 개인 정보 보호 법률, 심지어 내부적인 것으로 해커톤 등이 있습니다.

여기서는 다른 팀들과의 협력, 의사소통, 계획 등을 중심으로 이야기합니다. 일단 이벤트는 대형 스포츠 홀에서 열리는데, 팀마다 티셔츠 색상이 다르고 팀 당 흰색 보드와 테이블을 배치합니다. 
각 팀은 자체적으로 계획을 세우고, 다른 팀들과의 협력, 기술적인 측면, 의존성 등에 대해 이야기합니다. 
중요한 것은 모든 참가자들이 이벤트 장소에 머물러야 한다는 것입니다. 또한, 계획 작성에 있어서 미래에서 현재로 거슬러 내려오는 방식을 채용하고 있습니다.


해당 회사에서는 다양한 경험과 제품을 기획하기 때문에 이러한 세션 동안 여러 가지를 계획합니다. 일부 팀은 공유 백로그에서 작업하며, 우리가 준비한 기능 백로그에서 기능을 추출합니다. 
이것은 2 ~ 3번째 계획일 때의 모습입니다. 현재는 온라인 또는 오프라인 버전을 시도하며, scrum에 사용하는 도구입니다. 이를 사용하여 우리는 이후에 계획을 추적합니다. 
다른 팀들이 예상한대로 진행되고 있는지, 일부 팀이 과도하게 맡았는지, 혹은 과소약속했는지 등을 확인합니다. 
또 다른 동기화할 내용은 의존성입니다. 20개의 팀이 있으면 많은 의존성이 얽힐 수 있기 때문에, 이를 추적하기 위해 중앙 집중화된 도구를 선택합니다. 
팀이 다른 팀에 대한 의존성을 발견하면 그 팀을 이 보드에 올리고 빨간색 선으로 연결합니다. 

이를 통해 우리는 모든 의존성을 파악할 수 있습니다. 
또한 이 보드를 scrum of scrums 동안에도 사용하여 프로그램 관리자는 어디에 주력해야 할지, 어디에 집중해야 할지, 어느 지점에서 문제가 발생할 수 있는지 파악할 수 있습니다. 
또한 우리는 위험 요소도 분석합니다.


그리고 그들은 다음 두 달간 무엇을 할 것인지에 대한 고수준 계획을 가지고 2-2.5시간 정도의 breakout 작업을 마친 후에, 초안 검토 단계를 진행합니다. 
Safe는 이를 "모두에게 발표하는 대규모 세션"이라고 말하며, 모두가 모두의 작업에 관심을 가지지는 않기 때문에 매우 힘들다고 합니다. 
그래서 이제는 각 팀이 자신의 계획을 발표하고 나머지 팀들이 자유롭게 들어갈 수 있는 4회의 라운드로 구성된 형식을 사용합니다. 이것은 분산된 지식 공유를위한 좋은 공간입니다. 
사람들이 필요로하는 지식을 스스로 선택할 수 있기 때문에 매우 잘 작동합니다.

저희는 이벤트 주기를 통한 협력과 투명성을 증진할 수 있는 백로그 플래닝 패턴을 사용하는 것이 유용하다고 생각합니다. 
이 방법이 모든 조직에 적합한 것은 아니지만, 저희 회사에게는 적합하다는 것을 확인했습니다. 
이를 통해 우리는 협력과 일정, 계획 방법 등에 대한 조직 내 정렬을 증진할 수 있었으며, 위험과 종속성을 더 투명하게 파악할 수 있었습니다. 
이외에도 다른 많은 이점들이 있습니다. 이것이 저희의 주요 요약입니다. 감사합니다.