SAFe 사례 연구: 현장의 변환 참고 사항

이 기사는 팀 확장 노력에서 프로젝트 관리자를 안내하기 위해 설계된 Toptal의 Agile 확장 시리즈의 3부입니다. 1부 "5가지 애자일 확장 프레임워크 비교: 어떤 것을 사용해야 하나요?"를 반드시 읽어보세요. 및 2부, "애자일 확장: 스크럼 마스터를 위한 SAFe 모범 사례".

15th Annual State of Agile Report 에 따르면 기업의 94%가 어떤 방식으로든 민첩성을 실천하고 있습니다. 그러나 연구에 따르면 조직의 90%가 전사적 애자일 구현에 어려움을 겪고 있습니다. 일반적으로 이러한 노력을 이끌고 조직하는 것은 애자일 코치, 스크럼 마스터 및 기타 프로젝트 관리 전문가의 작업입니다. 종종 그들은 이해하기 어려운 회사 ​​문화에서 변화에 저항하는 팀이나 부서와 협력합니다.

이 원탁 회의에서는 세 명의 Toptal 프로젝트 관리자가 Agile 혁신을 주도하는 데 따른 과제에 대해 논의합니다. 그들의 솔루션이 SAFe(Scaled Agile Framework)와 호환되기 때문에 우리는 SAFe의 창시자인 Dean Leffingwell과도 이야기를 나눴습니다. 그들의 집합적인 통찰력은 SAFe 실무자가 민첩성이 무엇인지에 대한 명확한 비전과 완고한 팀을 합류시킬 수 있는 리더십 계획을 준비해야 할 필요성을 보여줍니다.

프레임워크 작성자와 SAFe에 대해 이야기하기

Scaled Agile이 공식화한 프레임워크인 SAFe는 2014년으로 거슬러 올라갑니다. 그러나 Leffingwell의 경우 작업은 2000년대 초 처음 Agile 팀을 만났을 때 시작되었습니다. 소프트웨어 개발 방법론자로서 그는 개발 팀에서 애자일 관행의 결과에 깊은 인상을 받았고 즉시 회사 전체에 사고 방식을 적용할 수 있는 방법을 탐구하기 시작했습니다. 애자일 팀이 결과를 산출할 수 있다면, 애자일 팀이 정렬된 팀은 무엇을 산출할 수 있을까요? 애자일 방식은 국내 또는 국제 기업의 본격적인 혁신 프로젝트에 어떻게 사용될 수 있습니까? Leffingwell이 말했듯이 “나는 소프트웨어 개발을 사랑합니다. 나는 애자일을 사랑한다. 나는 단지 그것을 크게 원한다.”

이후 몇 년 동안 기업은 납기 단축, 제품 품질 향상, 효율성 향상, 직원 참여도 증가 등 SAFe의 이점을 인식했습니다. 2021년 현재 전 세계 조직의 3분의 1 이상이 SAFe를 사용하고 있으며 가장 중요한 측면은 SAFe가 제공하는 공유 프로세스와 통합 언어입니다. 예를 들어 한 팀은 스프린트가 2주라고 생각하고 다른 팀은 30일이라고 생각하면 Leffingwell이 설명하는 "바벨의 탑 문제"가 발생합니다. 팀이 "기능"이 의미하는 바에 동의하지 않는 경우 추가할 기능에 대해 논의하기가 어렵습니다. "큰 솔루션을 구축하려면 일반적인 방식으로 작업하는 사람들이 필요합니다."라고 그는 말합니다. “우리 업계에는 '반복', '스프린트' 또는 '백로그'와 같이 과부하되지 않은 용어가 없습니다. 팀과 지역 경계를 넘어 작업하려는 경우에는 도움이 되지 않습니다.”

애자일 성공 사례

회사의 모든 사람이 일에 대해 말하고 일하는 통합된 방식을 채택하도록 하는 것은 변화가 매우 시급한 경우에도 어려운 작업입니다. 기존 기업에서는 더 어려울 수 있습니다. Leffingwell은 다음과 같이 설명합니다. “당신은 많은 돈을 벌고 믿을 수 없을 정도로 잘하고 경쟁하는 세계 최대의 회사를 보고 있습니다. 그리고 그들은 변화해야 합니다. 글쎄요, 그들에 대한 질문은 왜 그래야 합니까?” 여기에 소개된 Toptal 프로젝트 관리자는 각자 자신의 확장 활동 중에 이와 같은 질문에 직면했으며 SAFe를 사용하여 Agile 변환을 통해 작업하는 고유한 방법을 찾았습니다.

가치 입증

칠레 산티아고의 Toptal 프로젝트 관리자인 Alvaro Villena는 최근 교차 비즈니스 플랫폼을 개발하는 포트폴리오에 대한 SAFe 전환을 완료했습니다. "전환의 첫 번째 이정표는 가치 흐름 워크샵을 실시하는 것이었습니다."라고 그는 말합니다. 간단히 말해서 가치 흐름 워크숍은 개념에서 전달에 이르는 전체 비즈니스 프로세스와 그 사이의 모든 단계, 사용자, 시스템 및 고충을 식별하기 위한 시작 회의입니다.

Villena는 전체 기업의 대표자들을 워크샵에 초대함으로써 회사 문화와 그의 장애물이 무엇인지 이해하는 데 도움이 되었습니다. “워크숍을 구현하기 전에는 한 회사에는 팀이 있고 다른 회사에는 팀이 있고 다음 회사에는 팀이 있는 구조였습니다. 세 사람은 서로 이야기하지 않았습니다.”

Villena는 모든 팀이 비슷한 고충을 공유했지만 솔루션에 대한 공동 작업이 없다는 것을 발견했습니다. 예를 들어 포트폴리오의 모든 기업이 제품을 배송했지만 추적 시스템을 개발한 기업은 단 한 곳뿐이었습니다. 아무도 지식을 공유하지 않았다는 점을 제외하고는 모두 사용하지 못할 이유가 없었습니다. 워크숍에서 대화가 시작되자 팀, 기업, 제품 소유자 간에 지식이 흐르기 시작했습니다. “그런 종류의 대화는 프로그램에 정말, 정말 강력했습니다. 좋은 출발점이 되었습니다.”라고 Villena는 말합니다. DevOps, 디자인 및 제품이 모두 다른 팀이 하는 일을 알고 있을 때 회사에 사용할 수 있는 솔루션이 있음을 알게 됩니다. “그들은 '내가 그것을 어떻게 가질 수 있습니까?'라고 묻기 시작합니다. 그리고 거기에 들어가서 '이 프로세스를 따르십시오'라고 말합니다.”

“그 이유를 알기 전까지는 아무도 변화를 원하지 않습니다. 따라서 이유부터 시작하여 더 나은 미래를 제공합니다.” SAFe의 창시자 딘 레핑웰(Dean Leffingwell)

Leffingwell은 팀이 때때로 저항한다는 것을 알고 있습니다. "그 이유를 알기 전까지는 아무도 변화를 원하지 않습니다."라고 그는 Toptal에 말합니다. "그래서 이유부터 시작하여 더 나은 미래를 제공합니다." 팀이 얼마나 더 효율적일 수 있는지 보여주는 것은 변화 리더십을 위한 강력한 도구입니다.

모든 사람이 열정적으로 탑승하더라도 여전히 불안정한 출발을 예상해야 합니다. 예를 들어, 전통적인 Waterfall 개발 및 대규모 릴리스에 익숙한 팀은 가치를 보더라도 보다 반복적이고 민첩한 개발 프로세스로 이동하는 데 어려움을 겪을 수 있습니다. "우리가 한 첫 번째 프로그램 증가는 팀에 일종의 재앙이었습니다."라고 Villena는 말합니다. “그리고 우리는 그렇게 될 것이라는 것을 알고 있었습니다. 우리는 고객에게 처음 3개월은 어려울 수 있다고 예상했습니다.” 이를 보완하기 위해 그는 팀이 진행 상황을 평가할 수 있는 첫 번째 프로그램 증분(PI)이 끝날 때 1주일 동안 반복되는 기능을 구축했습니다. 그는 일반적인 검사 및 적응을 넘어선 프로세스 개선 및 평가에만 전념하는 스프린트를 조직했습니다. 그는 제품뿐만 아니라 비즈니스 전환에도 애자일 사고방식을 적용하는 것이 유용하다는 것을 깨달았습니다.

작은 승리 만들기

SAFe 채택에 있어 예상치 못한 장애물에 대비하는 것이 중요합니다. 몇 년 전, 세르비아 베오그라드의 Toptal 프로젝트 관리자 Miroslav Anicin은 통신 회사를 SAFe로 전환하고 있었습니다. 회사는 모든 소프트웨어 개발을 아웃소싱했습니다. 오프사이트 팀을 통합하는 것은 특별히 어려운 작업이 아니었습니다. 관련된 문제는 주로 물류였습니다. 그러나 이러한 노력으로 인해 회사 자체를 전환하는 데 예상치 못한 문제가 발생했습니다. "저는 릴리스 트레인에서 필요한 역량을 찾고 있었습니다."라고 그는 말합니다. "그리고 내가 선택해야 하는 모든 사람들은 마케팅, 법률, 제품, 재무 분야에서 온 사람들이었습니다. Agile 사고 방식이나 Agile 경험이 전혀 없었습니다."

경영진이 Agile 팀을 처리한 경험이 없다는 것이 분명해졌습니다. 분산된 의사 결정을 위해서는 관리자가 일부 제어 권한을 포기해야 합니다. 사실 리더십은 Agile 프레임워크에 대한 경험이 없는 경우 주저할 수 있습니다. 이를 해결하기 위해 Anicin은 아래에서 위로, 위에서 아래로 훈련해야 했으며 팀과 함께 지도자를 코칭해야 했습니다.

보다 분권화된 의사 결정을 내리기 위해서는 "명령과 통제에서 섬기는 리더십을 통해 일하는 방식을 학습 문화와 Agile 문화, 그리고 실수를 용인하는 능력으로 바꾸는 것"이 ​​필요하다고 Leffingwell은 말합니다.

Anicin은 SAFe 프레임워크가 아닌 단일 팀 내에서 소규모 Agile 프로젝트를 수행하여 개별 팀이 실제 경험을 개발할 수 있도록 점진적으로 확장하는 프로세스를 시작했습니다. 이러한 프로젝트는 첫 번째 시도에서 문제가 발생하더라도 회사가 해를 입지 않을 만큼 중요하지 않고 작아야 했지만 접근 방식으로 달성할 수 있는 것을 팀에 보여줄 수 있을 만큼 유용해야 했습니다. 예를 들어, 마케팅 팀은 내부 마케팅 캠페인을 만들었고, 그 동안 Anicin은 스크럼의 기초를 가르쳤습니다. Villena의 워크샵과 유사하게 이 소규모 프로젝트는 Agile의 가치를 실제적으로 보여주므로 팀 구성원과 경영진은 전면적인 전환 전에 단기 릴리스 및 지속적인 개선의 이점을 확인할 수 있습니다.

팀의 요구 사항 충족

파리에 기반을 둔 Toptal 프로젝트 관리자인 Imane Marouane은 대규모 다국적 금융 기관의 변혁을 이끌었을 때 개별 팀이 견고한 업무를 수행했지만 회사 전체의 비전을 공유하지 않는 혼란스러운 환경에 발을 들였습니다. “팀마다 우선순위가 있었습니다. 각 제품 관리자는 제품이 먼저 배송되기를 원했습니다.”

이 문제에 대한 SAFe의 솔루션은 WSJF(Weighted Shortest Job First) 모델에서 찾을 수 있습니다. WSJF는 작업의 우선 순위를 지정하는 표준을 제공하므로 다음 작업이 무엇인지 결정할 때 첫 번째 단계는 중요도 순위 지정 방법에 대한 논쟁을 포함하지 않습니다. 흐름 기반 애자일 시스템에서는 모든 것을 한 번에 제공하는 것에 대해 걱정할 필요가 없습니다. Leffingwell이 말했듯이 “가장 중요한 것은 다음에 할 일입니다. 그리고 그것은 가장 가치 있는 직업이 무엇인지보다 대답하기 훨씬 쉬운 질문입니다.” SAFe는 팀 간의 종속성을 해결하는 방법을 제공합니다. 이 결과를 위해서는 작업 주문이 필수적입니다.

종속성 해결을 위한 Marouane의 경로는 불확실해졌습니다. "두 번의 스프린트 후 첫 번째 검사 및 적응 전에 일부 팀이 우리의 PI 계획을 따르지 않고 있음을 발견했습니다." PI 계획에 정의된 종속성이 지켜지지 않아 다른 팀의 기여가 준비되지 않아 한 팀의 작업을 시작할 수 없었습니다.

"첫 번째 반복이었고 팀은 이런 종류의 작업에 익숙하지 않았기 때문에 종속성에 대한 진행 상황을 논의하기 위한 주간 회의인 추가 행사를 개최하기로 결정했습니다."라고 Marouane은 말합니다. "각 팀에서 한 사람이 기여에 대한 진행 상황을 업데이트하기 위해 왔습니다." 이렇게 하면 팀 A가 배달할 수 없다고 말하면 팀 B는 스프린트 시작 시 실현되지 않을 기여를 기다리는 대신 미리 알고 그에 따라 계획을 세울 수 있습니다.

Leffingwell은 SAFe에 이러한 종류의 조정을 할 때 주의를 당부했습니다. “SAFe는 책임 시스템입니다. … 적응할 수 있지만 정말 조심해야 합니다.” 프레임워크는 적응할 수 있도록 의도되었지만 재평가되지 않으면 변경 사항이 적용되는 경향이 있습니다. Essential SAFe 구성은 모든 변경 사항이 기본 기준을 충족하는지 확인하기 위해 존재합니다.

Marouane의 추가 의식은 두 번째 PI에 다시 포함되었으며 세 번째 PI에는 단계적으로 중단되었습니다. 팀은 아직 전달되지 않은 보고할 것이 없었습니다. 약간의 추가 유연성 덕분에 Marouane은 팀을 보다 전통적인 프로세스 트랙으로 되돌릴 수 있었습니다. 그녀는 전환 자체가 금융 기관의 팀을 최대한 활용하기 위해 애자일 사고 방식을 요구한다는 것을 발견했습니다. 그리고 중요한 것은 지속적인 개선에 대한 헌신을 통해 그녀가 만든 변화가 궁극적으로 Essential SAFe의 기초가 되는 린-애자일 원칙에 기여했다는 것입니다. 그녀의 솔루션은 회사에 통합된 비전을 제공하고 팀이 동일한 우선 순위를 위해 함께 작업할 수 있도록 했습니다.

미래를 위한 적응

대규모로 운영되는 모든 프레임워크에는 어려움이 따릅니다. 움직이는 부품의 수와 경쟁하는 이해 관계는 엄청납니다. 그러나 결과는 똑같이 크며 잘 실행된 전환은 팀이 공통 목표를 향해 작업하는 데 필요한 도구를 제공할 것입니다. 이러한 대규모 구현에서 직면하는 장애물은 예측할 수 없으며 민첩한 사고 방식은 Villena, Anicin 및 Marouane이 예기치 않은 문제에 적응하는 데 도움이 되었습니다. 결국 지속적인 전달이 필요한 이유는 예상치 못한 상황에 적응할 수 있는 도구로 프로세스를 강화하는 것입니다.

Scaled Agile은 또한 새로운 기술과 진화하는 산업 표준에 적응하여 필요에 따라 새로운 도구와 기능을 도입합니다. 모두가 민첩성을 유지하고 예상치 못한 상황에 대비해야 합니다. "우리는 수정 구슬이 없습니다."라고 Leffingwell은 말합니다. "우리는 단지 빨리 달리고, 열심히 이끌고, 열심히 따르고, 가능한 한 빨리 글을 씁니다."