SAFe 기본 다지기 3편 – 칸반

SAFe는 스크럼(Scrum)이라는 애자일 방법론 뿐만 아니라 칸반(Kanban)과 XP(eXtreme Programming)을 포함해, 모두 3가지의 애자일 방법론을 적극 활용하고 있습니다. SAFe가 가진 장점이 될수도 있지만, 이 방법론들을 모두 이해하고 활용하는 것이 오히려 SAFe 도입을 더욱 어렵게하는 요인이 되기도 합니다. 양날의 칼인셈입니다.

이글에서는 칸반의 기본에 대해 이해하고, SAFe에서 어떻게 칸반을 활용할 수 있는지를 살펴보도록 하겠습니다.

많은 기업들이 서비스 및 프로세스를 만들고, 지속적으로 개선하며 관리하고 있습니다. 그런데 서비스나 프로세스는 한순간의 노력으로 결과를 만드는 것이 아닌 “지속적인 개선”이 필수적입니다. 시장 상황이나 법, 기술이 끊임 없이 바뀌고, 경쟁 조직에 대한 우위를 지켜내야하는 현대 사회에서 변화에 대한 지속적인 대응은 매우 중요한 일이기 때문입니다.

팀 칸반은 경쟁 상황 속에서도 팀이 지속적으로 고객에게 가치를 빠르게 제공하기 위해 사용하는 애자일 방법이며, SAFe 팀 칸반은 이터레이션 주기에 맞춰 SAFe의 ART와 공조를 이루는 특성을 갖고 있습니다.

그럼 칸반이 가진 특징들을 하나씩 살펴볼까요?

일과 프로세스에 대한 시각화 중시

애자일에서 요구사항 관리 목적으로 사용하는 유저 스토리를 칸반에서도 사용합니다. 이때, 유저 스토리를 완료할 때까지 이르는 프로세스를 단순하게 “계획”, “진행중”, “완료”로 구분하여 칸반 보드(Kanban Board)에 표시할 수 있습니다. 하지만 큰 규모의 조직에서는 UX 검토, 제3자 테스트, 기존 업무와 통합 등 다양한 조직과의 협업 또는 시스템 연계 등을 반영한 복잡한 프로세스를 구성할 수도 있습니다. 중요한 것은 요구사항을 가시화 시키고 요구사항이 프로세스의 어디에 위치하고 있는지, 일과 프로세스를 가시화시켜 누구나 현재의 진행 상황을 한눈에 파악할 수 있게 관리한다는 점입니다.

풀(Pull) 방식으로 요구사항 관리

전통적인 방법론을 사용하는 조직은 개발 조직에게 업무를 할당할 때 푸시(Push) 방식을 사용합니다. 즉, 관리하는 주체의 관점에서 일을 수행하는 조직에게 요구사항을 할당하는 것입니다. 하지만, 칸반은 그 반대로, 일을 수행하는 사람들이 자기가 할 일을 요구사항 리스트에서 가져옵니다.

이전 방식에 비해 칸반 방식이 가진 큰 차이점은 “범위” 관리를 수행 팀 자율에 맡기면서 “개발자 특성”을 최대로 살려 능동적으로 업무를 할당하는 것입니다. 팀 구성원 스스로가 범위 관리를 하면서 업무를 가져오는 칸반은, 팀의 작업에 대한 몰입감을 높일 수있고, 스스로 맡은 일에 대한 팀의 책임감도 높일 수 있으며, 보다 적극적으로 이슈를 해결하는 긍정적인 팀마인드를 갖게하는데 도움을 줍니다.

중요한 것 먼저 수행

IT 관련 조직이라면 장애 관리를 중시하며, 긴급 패치와 같은 업무는 최대한 먼저 처리하는 것이 필요합니다. 칸반은 일과 프로세스를 가시화시켜 현재의 업무 진행 상황을 파악하고 있기 때문에, 긴급한 일이 떨어졌을 경우, 어떻게 빠르게 처리하고, 다른 일을 어떻게 조율할 것인지를 효율적으로 관리할 수 있습니다.

병목(Bottleneck)을 막기 위해 프로세스 내 처리 업무량 제한

일을 하다보면 특정 작업에 일이 몰려 대기하는 상황이 발생할수 있고, 이는 전체 프로세스의 비효율 및 팀의 저성과로 이어질 수 있습니다. 그래서, 경험적으로 병목이 발생하기 쉬운 작업 구간에는 일의 최대 허용치를 두고, 최대 허용치를 넘는 상황에는 일을 할당하는 대신에 병목 구간에 존재하는 일을 우선적으로 처리할 수 있도록 동료를 지원하거나 함께 협업합니다.

이처럼 칸반은 일의 병목도 막고, 팀이 전체 일의 진행을 파악하면서 팀 구성원들간의 협력을 촉진시킬 수 있습니다. 경영진으로부터 빠른 일처리 요구가 빈번하거나, 중요한 헬프 데스크 대응이 많거나, 장애가 비교적 빈번하다면 칸반을 적극적으로 활용하여 시장이나 고객의 요구에 빠르게 대응할 수 있는 프로세스를 조직에 정착시킬 수 있습니다.

다양한 측면에서 일의 흐름을 관리

위의 그림을 보면 하나의 유저 스토리를 완료시키는데 몇일이 걸렸는지를 파악하고 있으며 이상점(완료까지 시간이 많이 걸린 유저 스토리)을 쉽게 파악하고 있습니다. 이와 같은 흐름 관리를 통해 유저 스토리의 크기를 포함하여 요구사항을 관리할 때의 다양한 문제점을 파악하고 개선시킬 수 있습니다.

기획부터 개발까지의 큰 흐름을 관리

이 그림은 CFD(Cumulative Flow Diagram)로 아이디어에서 유저 스토리를 완료할 때까지의 다양한 작업을 포괄적으로 표현합니다. 즉, 유저 스토리가 어떻게 완료되는지의 개발 업무 뿐만 아니라, 기획 단계에서 유저 스토리가 정의되는 과정까지 포괄해서 작업 흐름을 살펴볼 수 있습니다.

이 그림을 통해 일정 시점별 작업의 생산성을 파악할 수 있을 뿐만 아니라, 효율적으로 일을 완료시키는데 어려움이 있는 구간을 파악할 수도 있습니다. 문제가 파악되면, 스크럼 마스터 주도로 문제를 개선하는 회의를 열고, 지속적으로 흐름을 개선해갈 수 있습니다.

칸반보드 기본 활용 예시

이 그림은 SAFe에서의 칸반보드 활용 예시인데, 이 예시를 기반으로 앞에서 이야기했던 사항들을 전반적으로 정리해보겠습니다.

먼저 “WIP(Work in Process) Limit”는 특정 구간에 일이 몰려 병목 현상이 발생되지 않도록, 해당 구간의 작업이 머물 수 있는 최대 “일의 수를 제한”하는 것입니다. 이 그림에서는 작업의 수가 “Doint” 구간에 3개를 초과할 수 없도록 제한을 걸었습니다. 이 경우, 특정 작업자가 “To Do”에서 “Doing”에 유저 스토리와 같은 작업을 옮기고 싶다면, 현재 “Doing”에서 작업중인 동료의 유저 스토리 작업을 도와주면 됩니다.

“Column” 부분은 작업 구간을 나타내는 이름으로 이 그림에는 가장 간단한 형태인 “계획”, “진행중”, “완료”의 3가지를 표현하고 있습니다.

“Card”는 일을 나타내는 것으로 애자일 팀이라면 “사용자 스토리”가 되고, 전통적 기업이 칸반을 도입한다면 “CR”이 될 수 있습니다.

“Swimlane”은 장애 조치나 경영진의 긴급 지시 등 빠르게 일을 처리해야하는 경우 “신속 처리(Expedte)”에 작업을 할당하고, 끝마치는 일정 준수가 중요한 일은 작업 준수 영역인 두번째 칸에 작업을 할당하고, 나머지 일은 세번째 칸에 일을 할당하면 됩니다.

마지막으로 “Policy”는 팀이 칸반 보드를 운영하면서 지켜야하는 규칙이나 정책을 표현합니다. 이 그림에서는 유저 스토리와 같은 작업 항목의 이동 시 합의가 중요하다는 것을 나타내고 있습니다.

프로세스와 팀 워크플로우와의 매핑 예시

칸반의 기본 프로세스를 “할일(To Do), 작업 중(Doing), 완료”처럼 매우 간결하게 정의할 수도 있지만, “요건 정의(Define)”, “설계(Design)”, “전문가 검토(SME Review)”, “코딩(Code)”, “통합(Integrate)”, “테스트(Test)”, “완료(Done)”와 같이 조금 더 구체적인 팀의 워크플로우로 개선시켜 관리할 수도 있습니다.

팀 워크플로우의 진화 – 예시

팀의 워크플로우에, 요구사항 수집 과정이 중요하다면 “수집(Funnel)”이라는 과정을 추가시키고, 설계 뿐만 아니라 개발 전 준비사항이 많이 있다면 “준비(Ready)”라고 기존 프로세스 이름을 조정 및 개선시킬 수도 있으며 “구축(Building)”이라는 단계를두어 개발과 통합에 대한 흐름을 구조화시킬 수도 있습니다. 또한, 테스트와 스테이징 환경에서의 검증을 분리시켜 “검증(Validating)” 프로세스를 별도로 구분시킬 수도 있습니다.

팀 상황에 진화시킨 칸반 보드 예시

초기의 팀 칸반보드에 비해 조금은 복잡해진듯 하지만, 시간에 따라, 작업 상황에 따라 팀의 합의에 의해 진화시킨 결과입니다. 이렇게 팀은 최대의 성과를 낼 수 있는 자기들만의 작업 흐름을 지속적으로 개선 및 진화시켜, 팀성과를 개선시킬 수 있습니다.

SAFe의 다양한 수준에 걸친 칸반 활용

이 그림은 SAFe에 존재하는 다양한 칸반 시스템과 백로그를 거쳐 워크플로를 관리하는 과정을 보여줍니다. 이와 같이 여러 수준에 걸친 칸반 시스템은 전략적 변화를 구현 팀의 작업까지 신속하게 전달시켜줍니다. 이와 같은 칸반 시스템을 통해 조직은 변화하는 비즈니스 전략에 맞춰 부서 및 팀들이 만드는 제품을 체계적이면서도 신속하게 조정할 수 있습니다. 하지만, 모든 작업이 포트폴리오 수준에서 시작되는 것은 아니며, 더 작은 수준에서의 시작 및 변경도 중요합니다. 때로는 ART 수준에서 또는 팀 수준에서 독립적인 작업을 시작하고 수행할 수 있습니다.

마치며…

SAFe의 팀 칸반은 작업과 프로세스를 시각화하고, 풀 방식으로 요구사항을 관리하며, 병목 방지를 위해 WIP 제한을 두고, 중요한 작업을 우선 처리하여 팀 효율성을 극대화합니다. 이를 통해 지속적인 개선과 협업을 촉진하며, 시장 변화와 고객 요구에 신속히 대응할 수 있는 애자일 프로세스를 구축합니다.

또한, 팀 칸반뿐만 아니라 ART 수준 및 전사 포트폴리오 수준에서의 칸반도 조직 차원의 전략을 하부 조직에 효과적으로 전달할 수 있어, 큰 수준의 프로세스 최적화를 만들어갈 수 있습니다.