제조업에서 SAFe(Scaled Agile Framework) 하기

불완전하게 SAFe를 도입한 이 프로젝트는 실패한 것일까요?
신기하게도 반애자일 요소와 혼란함을 가지고 진행된 S프로젝트가 최근에 완료된 다른 프로젝트들에 비해서 훌륭한 성과를 거둡니다.

---

주의!!

여기서 소개해드릴 "제조업에서 SAFe"내용은 SAFe를 적요한 프로젝트의 일반적인 모습은 아닙니다.

일반적인 SAFe의 적용 이야기을 기대하신 분들은 Open Source Consulting에서 진행한 SAFe 활동 이야기를 참조하시기 바랍니다.

tech.osci.kr/2020/11/11/104413735/

오픈소스컨설팅은 애자일한가요?

제조업에서 SAFe을 적용하여 프로젝트를 수행한 경험에 대해서 소개하고자 합니다.

일반적인 SAFe의 프랙티스나 방법론을 설명하기 보다는 실제로 수행했던 내용을 공유드리고자 합니다.

조직의 특성, 여러 기업과의 협업, 코로나19라는 제약 사항들이 반영된 이야기로 생각하시면 됩니다.

 

편의상 고객이 되는 기업은 A, 자사는 B라고 표현하겠습니다.

또한 사례가 되는 프로젝트는 S프로젝트라고 표현하겠습니다.

프로젝트 환경/배경

제조업 기반의 B2B비즈니스를 하는 회사입니다.

B2B도 여러 방식이 있습니다. 가장 먼저 떠올르는 모습은 기업용 솔루션을 개발하여 다른 기업에 파는 형태가 있습니다.

두번째로는 완성된 솔루션이 아닌 개발을 함께 진행해 나가며 고객과 함께 솔루션을 만들어 가는 방식입니다. 제품을 만들어 판다는 개념보다는 내부에 있는 기술력을 제공하는 형태로 생각하시면 됩니다.

 

여기서 소개하는 사례는 두번째에 해당합니다.

 

S프로젝트에는 모두 4개의 회사가 프로젝트에 참여하고 있고 B사는 그 중에 중간 정도의 위치(소통채널, 기업규모 등등)에서 참여하고 있습니다.

그리고 B사에서만 개발자, 각종 매니저, 품질팀...등등 해서 150명 정도의 사람들이 참여합니다. 각 구성원들은 기능 단위로 묶인 펑션팀을 이루고 있습니다.

 

개발 기간은 꽤 길어서 1년을 넘는 시간 동안 개발을 진행합니다.

 

하나의 PI는 4개의 이터레이션을 가지고 3주로 진행됩니다.

그래서 하나의 PI는 총 12주의 시간을 갖습니다.

(SAFe 커뮤니티에서 제공하는 자료에서는 하나의 PI는 5개의 이터레이션 2주씩 진행됩니다.)

 

내부적으로 3~4 명 정도의 소수인력이 SAFe의 지식을 가지고 있었으며

고객으로 부터 SAFe을 적용에 대한 요청을 받고 있었습니다.

 

4개의 기업, 3주와 4이터레이션의 PI, 하드웨어 기반의 S-Project

이제 프로젝트에 진행에 영향을 미치는 몇가지 사항에 대해서 먼저 이야기를 해봅니다.

계약 방식

SAFe는 Scaled Agile Framework입니다. 크지만 결국 애자일이라는 의미입니다.

애자일은 고객과 협업을 통해서 Win-Win을 하는 것을 목표로 합니다.

애자일의 이런 사상은 SAFe에서는 Agile-Contract에 잘 반영되어 있습니다. (참고 : www.scaledagileframework.com/agile-contracts/)

 

SAFe에서 이야기하는 Agile Contract 방식, S-Project에서 이런일은 일어나지 않았다

 

하지만 S과제는 애자일 컨트랙트와 같은 형태로 이루어진 계약을 맺지 못했습니다.

 다르게 이야기하면 계약상의 A사와 B사는 약속을 절저치 지켜야 하며 약속을 지키지 못했을 경우에 비용적인 손해를 감수해야 하는  상황으로 서로 긴장상태를 유지하며 프로세스 진행 속에서 스스로를 보호하려는 분위기 흐르게 된다는 의미입니다.

 

계약 이야기를 먼저 하는 이유는 이런 긴장이 애자일의 필수적인 효과적인 업무 조정을 방해하여 B사의 개발 영역에서 필요이상의 많은 업무를 하게 된다는 말씀을 드리고 싶었습니다. A사 또한 시장 변화에 적응하기 위한 효과적인 변경 요청을 쉽사리 하기 힘들어지 집니다. 계약서 상으로 모든 변화는 비용추가로 반영되기 때문입니다.

 

이 문제는 여러 애자일 활동을 경직시킬수도 있는 요소이며 과중한 개발 업무로 인해서 애자일 활동(업무 조정, 플래닝, 리뷰, 회고)에 개발팀이 온전히 집중하지 못하도록 만드는 상황을 연출합니다.

 

계약 방식으로 인해서 여전히 Gate가 중요한 이벤트가 됩니다.

Gate가 중요한 이벤트가 되는 것은 문제가 아닙니다. 문제는 이 Gate에서만 특정 활동이 이루어지는 것이고 이로 인해 각 역할자가 함께 일하는 것이 아니라 분리되어 일하게 됩니다. 특히 품질관리자와 개발자가 분리되는 것은 큰 문제입니다.

소통 구조

 하드웨어 기반의 B2B 비즈니스를 진행합니다. 꽤 규모가 큰 프로젝트이다 보니 여러 기업이 참여를 하고 있습니다. 

 여러 기업들이 프로젝트를 진행함으로 인해서 기능 중심(Feature)으로 함께 팀을 꾸리지 못하는 환경은 두가지 방향의 소통 채널을 만들어 냅니다.

 먼저 요구사항에 대한 소통 관점으로 설명을 드려보겠습니다.

 고객사의 PM과 일부 PO가 만들어낸 사용자 관점의 스토리는 A사 내부에 있는 하드웨어 기술에서 멀리 떨어진 일부 애자일팀에만 전달됩니다. 보통 어플리케이션 개발팀입니다. 그리고 스토리는 여러팀을 거쳐서 B사의 하드웨어 기술 기반(HAL이나 MW와 같은)의 애자일 팀으로 전파되어 갑니다.

 하드웨어와 가까운 거리에서 일하고 있는 애자일팀에 스토리의 조각이 전달될 때는 개발자의 언어로 된 요구사항이 전달됩니다. 예를 들어 "상위 레이어의 개발자로서 어떤 목적을 위해서 어떤 기능을 원한다."와 같은 형태입니다. 귀엽게도 사용자 스토리처럼 작성되어 있기도 합니다. 

 다시 말하면 하드웨어와 가까운 거리의 애자일팀에 전달되는 요구사항은 사용자 관점의 에픽/스토리가 아니며 개발자의 언어로 만들어진 요구사항 들입니다.

 이러한 이유로 B사 애자일팀의 PO는 개발자의 언어를 잘 이해하는 시니어 개발자가 맡게되는 것이 자연스럽습니다. 실제 이렇게 팀이 만들어집니다. 또한 애자일팀에 요구사항을 전달하는 사람도 PM이 아닌 A사의 개발자 또는 개발리더가 됩니다.

두번째로는 거버넌스 관점입니다.

 여러 기업이 개발자들이 통합된 팀이 아닌 형태로 하나의 프로젝트에 참여하게되는 경우 각 기업들마다의 개발/품질 관리 방식을 적용하게 됩니다.

 결국 기업마다 다른 방식의 개발/품질 관리 방식을 운용하게 되며 각 기업마다 통제를 위한 관리자(PL/PM)가 필요합니다.

 이런 PL/PM은 개발팀에 진척, 개발건에 대한 정보에 대한 요청을 하게 됩니다.

 

요구사항 관점과 거버넌스 관점 소통 방향을 그림으로 그리자면 아래와 같은 형태가 됩니다.

개발진척, 요구사항, 사내 거버넌스 모두 개발자에게로 향한다. 

 모든 요청이 B사의 개발팀으로 모이게 됩니다. 지못미....

---

 SAFe 적용 전후로 가장 큰 변화는 Product Icrenemt(PI) 주기와 PI Planning 을 수행하는 것입니다.

 S프로젝트에서의 이부분에 대해서 소개를 하도록 하겠습니다.

S프로젝트의 PI 플래닝

SAFe에서 가이드하는 2일 길이의 PI Planning, https://www.scaledagileframework.com/pi-planning/에서 퍼왔다.

 

SAFe에서 가이드하는 PI는 보통 2일간 진행됩니다.

 

첫날은 Business와 개발, 경영진과 실무자 등이 모두모여 Alignment를 만들고 실제 플래닝을 하게 됩니다.

둘째날에는 플래닝에 대한 리더들의 리뷰 결과를 반영하고 개발팀 리뷰와 합의과정을 거치게 됩니다.

이 과정 동안 모든 이해관계자들은 모두 한자리에 모아서 회의를 진행합니다.

 

여러 기업이 하나의 프로젝트를 함께 진행하는 경우에는 한자리에 모이기 쉽지 않습니다.

특히나 그중에서 Common Platform을 만드는 외부 업체가 있다면 그들만의 프로세스를 가지고 움직이며 여러 업체들에 플랫폼을 제공하기에 특정업체의 프로세스나 이벤트에 참여하지 않습니다.

여기에 코로나19로 함께 모이는 것이 더 어려워진 상황이었습니다.

 

결국 회사들마다 지역마다 모두 서로의 계획을 세우게 되고 계획을 세운 후 일부 리더들이 회의을 통해 계획을 조정하는 방식으로 변경되었습니다.

 

Internal Planning(내부 플래닝)과 Integrational PI Planning(고객과의 조정)

과거 방식의 계약으로 인해서 B사의 PL/PM과 경영진은 애자일팀이 무리한 계획을 세우는 것을 경계합니다. B사의 애자일팀이 요구사항을 A사의 개발자들로 부터 직접 전달받기 때문에 과거 PL/PM을 통해서 요구사항을 전달받았던 시기보다 더욱 조심스럽게 대응합니다.

 

그래서 고객과 함께 플래닝을 하는 것보다는 내부에서 플래닝을 먼저 진행하고 내부에서 승인과정을 거쳐 고객에게 오픈하는 방식을 취합니다. 내부에서 먼저 수행하는 플래닝, 여기서는 Internal Planning이라고 불러보겠습니다.

 

일반적인 SAFe에서 애자일 팀의 PO은 실제 플래닝이 시작하기 전까지 주기적으로 PM을 만나 요구사항을 구체화하고 정제하는 작업을 가집니다. 하지만 S프로젝트의 SAFe에서는 개발에 대한 부담으로 플래닝에 대한 준비을 할 수 없는 상태입니다. B사 애자일팀의 PO들이 Senior 개발자라는 이유로 개발에 대한 흥미와 전문성은 그들 스스로 개발 참여를 하게 만드는 동기를 제공합니다.

 

 따라서, 그들은 개발 업무와 요구사항에 대한 분석 업무가 있다면 개발 업무에 흥미를 느끼고, A사 고객들의 많은 개발 요청들은 이를 더욱 강화합니다.

 

따라서 Internal Planning 시기에 되었을때 Planning을 할수 있을 정도로 요구사항이 충분히 구체화 되고 정제되기를 바라는 것은 무리입니다. 부족한 요구사항 분석을 위해서 SAFe에서 가이드한 2일짜리 Internal Planning은 몇주로 늘어납니다. 7~8일 추가된 기간 동안은 B사의 애자일팀은 그동안 쌓아놓은 요구사항을 정제하고 구체화하는 시간을 가집니다.
(사실 이때도 많은 애자일팀은 플래닝과 개발과 병행합니다.)

 

 그리고 충분히 정제된 요구사항은 2일간의 Internal Planning을 거치게 됩니다. 코로나19로 인한 제약으로 많은 사람이 동시에 같은 공간에 있을 수 없기에 십여개의 애자일팀은 순번대로 Planning한 내용을 PL/PM과 공유하고 피드백을 받아 수정하고 계획을 세웁니다. 앞서 말씀드린 것처럼 워터폴 방식의 계약으로 인해서 약속을 지키는 것은 더욱 중요한 목표이며 도전적인 업무 목표보다는 안전한 수준에서 수행할수 있는 정도의 업무를 B사의 PL/PM은 애자일 팀에 요청하게 됩니다. 

 

 2주의 시간동안의 요구사항에 대한 정제, 구체화와 Internal Planning이 끝나면 이제 고객과의 조정이 남아 있습니다.

 

고객과의 조정을 통해 Planning을 확정하고 타사와의 일정과 통합하는 과정을 거칩니다. 여기서는 Integrational PI Planning이라고 부르겠습니다.

 Internal Planning한 결과에 대해서 고객과 공유하고 고객의 피드백을 받아서 조정합니다.

Integrational PI Planning 기간 동안 고객은 모든 애자일팀과 개발 항목에 대한 협의를 지속합니다. 합의가 될때까지요. 합의가 된다는 것은 약속을 지킨다는 의미이고 약속을 지키지 못한다는 것은 금전적인 손해를 의미하므로 합의는 지리한 과정을 거칩니다. 이러한 과정을 거치며 Due Date을 가진 개발 요건 리스트가 합의됩니다.

고객은 만족하지 못하는 계획 부분에 대한 논의를 지속합니다. 요구사항들에 대한 전체적인 합의가 이루어지면 일부 합의되지 않은 애자일 팀과 업무 범위에 대한 논의를 하게 됩니다.

 

 여기서 업무 범위가 크게 변경됩니다.

 

 다행인 점은 A사의 개발팀과 B사의 애자일팀은 긴밀한 협업으로 서로의 사정에 대해서 높은 수준으로 이해를 하고 있다는 점입니다. 이런 이유로 B사 애자일팀에 유리한 방향으로 결정되는 경우가 종종 있습니다.

 

이부분까지 완료가 되면 PI는 합의 완료가 되고 개발기간으로 넘어갑니다.

S-Projec의 Pl Planning, 여전히 고된 작업

플래닝이 종료되면 개발이 시작됩니다.

 

개발

 개발은 3주를 주기로 진행됩니다. SAFe에서는 Iteration Planning이 존재하지만 S Project에서는 의미 없게 진행됩니다.(사실 거의 수행하지 않았습니다.) 이미 고객과의 PI Planningr결정사항들은 무거운 의미의 약속이며 이를 어기면 안되기 때문에 Iteration Planning을 통해서 조정되기 보다는 과거의 약속을 따르는 것이 합리적입니다.

 

 개발이 진행되는 동안 B사의 PL/PM들은 개발 요건에 대한 정보를 습득해 나아가게 됩니다.

 B사의 PL/PM들은 Planning에서 피상적으로 알고 있었던 개발 요건들에 대해서 실체적 진실을 마주하게 되는데요. 몇가지를 새롭게 알게 됩니다.

 그 중에 하나가 리스크가 큰 개발 건들이 PI Planning 후반에 몰려 있다는 것입니다.

 애자일 팀의 개발자들이 약속을 지키지 못하는 것을 우려해 주기 후반에 일감들의 Due Date을 몰아둡니다. 경우에 따라서는 자신의 약속을 지키기 위해서 미리 완료된 업무를 일정에 맞춰서 Integration 하는 경우도 발생하며 개발 주기 후반부는 리스크의 행진을 하게 됩니다.

그래서, 제조업에서의 SAFe는 실패인가?

불완전하게 SAFe를 도입한 이 프로젝트는 실패한 것일까요?
신기하게도 반애자일 요소와 혼란함을 가지고 진행된 S프로젝트가 최근에 완료된 다른 프로젝트들에 비해서 훌륭한 성과를 거둡니다.

 

이후 분석을 해보며 두가지 이유가 있다는 것을 알게 되었는데요.

 

첫번째, 개발 사이클의 축소

과거 몇년이라는 긴 "설계-개발-검증" 사이클을 3달의 PI로 짧게 만들어 준 것만드로 엄청난 개선이 된 것입니다.

몇년 동안 쌓이는 기술적 부채가 몇개월 단위로 줄어 들었고 주요 리스크는 3개월만에 확인이 됩니다. 개발 후반부에서나 통합되었던 여러 기업들의 개발 산출물은 과거에 비해서 조기에 통합됩니다. 

 그리고, 3개월 단위로 시장의 변화, 기술적인 어려움에 대응할수 있는 기회를 얻게 된것이죠.

 

 두번째, 요구사항 변경에 대한 빠른 대응

 과거에는 요구사항 변경에 대해서 B사의 PL/PM이 직접 대응하였습니다.

 요구사항 변경이 많은 것은 죄악 이라는 관점이 요구사항 변경이 많아지지 않도로 제약했고 그로 인해서 소수의 PL/PM들이 소화할수 있는 수준의 변경건만 전달되었습니다.

 하지만 빠르게 변화하는 시장을 반영하려는 많은 기업들은 CR 비용을 감수하고서라도 많은 양의 변경사항을 요구하는 단계에 이르렀고 기존의 소수의 PL/PM이 소화할수 없는 요구사항 변경량은 프로젝트를 실패로 이끌었습니다.

 하지만 지금은 각 애자일팀의 PO(비록 기술전문가이기는 하지만)가 이 변화를 병렬처리 수용하는 스펀지 역할을 하게 되면서 시장의 변화에 대응할수 있게 된것입니다.

 중앙집중이 아니라 분산처리로 변경사항을 처리하게 된거죠.

한 발 더 나아가기

 성공적을 S프로젝트를 마무리했지만 이 상태에서 머무르는 것은 위험합니다.

 이유는 모든 요구사항을 수용해야 하는 개발팀들이 이 방식을 지속하다보면 "지속가능한 속도로 일하기"가 불가능해지는 상황이 발생할수 있기 때문입니다. 이 방식을 개선하지 않으면 개발자들은 나가 떨어질 가능성이 있습니다.

 

 그리고 여전히 개선할수 있는 부분이 있습니다. PI단위의 3개월 업무 주기는 여전히 개선할수 있는 여지가 있습니다.

 고객과의 협력 방식으로 개선한다면 3주 단위 주기를 적용할수 있을 것입니다.

 

 따라서 지속적인 개선을 통해서 이곳에 머물기 보다는 더 앞으로 나아가야 합니다.