애자일 네이티브, 비개발 직군이 애자일하게 협업하는 법

협업 툴, 애자일(Agile), 애자일한 방식 그리고 애자일 프로세스 …
이제는 귀에 딱지가 앉게 들어본 것 같은데 그래서 그게 나에게 필요가 있을까?를 고민해보신 분이라면 이번 포스팅을 주목해 주세요.

안녕하세요, 오픈소스컨설팅 마케팅팀에 새롭게 합류하게 된 디지털 마케터 정혜인입니다.
프론트엔드와 백엔드 개발의 차이조차 몰랐던 저는 스타트업에서 커리어를 시작하며, 다양한 협업 툴을 활용하면서 애자일 네이티브(Agile-native)하게 업무 방식을 익혀왔습니다.

처음부터 이렇게 일을 해 온 저로서는 애자일과 워터폴 방식의 명확한 구분이 어렵기도 하고, 두 방식이 혼합된 형태로도 업무를 해왔기에 “애자일하게 일한다는 것”에 대해 스스로도 고민이 많은데요.

그래서 이번 포스팅에서는 애자일의 정의보다는, 비개발직군인 제가 개발자와 협업했던 경험을 바탕으로 하나의 가상 에픽 프로세스로 설명드려 볼게요.

애자일이 그래서 뭔데요?

전통적인 업무는 폭포수(Waterfall) 방식이라고 합니다. 하고자 하는 프로젝트나 업무 범위가 고정되어 있으며, 수행하는 데 필요한 인력과 시간을 추정하는 Plan-Driven 예측 방식이에요.

이 방식은 예측한 대로 수행되지 않으면 리스크가 커질 수 있습니다.
이미 정해진 범위 안에서 업무가 진행되기 때문에 프로젝트 진행 중 고객 의견 반영이나 환경 변화에 따른 요건 변경이 어렵기 때문이죠. 결과적으로 고객과 시장의 니즈를 충족시키기 어려운 방식이라고 할 수 있어요.

반면에 애자일(Agile) 방식은 인력과 시간을 고정해놓고 2~4주간의 반복적인 개발 주기를 통하여 가치를 제공하는 방식으로 매 개발 주기마다 고객의 의견을 반영하는 Value-Driven 방식입니다.

전통적인 방식과 달리 업무 범위 변경이 가능하므로 고객과 시장의 니즈를 제때 반영할 수 있고, 제공된 가치가 잘못되었더라도 빠르게 변경하여 대응할 수 있어 리스크가 크지 않다는 장점이 있어요. 고객의 니즈와 환경이 빠르게 변화하는 현시점에서 다양한 직군이 협업하기에 최적화된 방식이라고 할 수 있죠.

정리하자면, Waterfall 방식과 Agile 방식은 아래와 같이 구분됩니다.

• Waterfall : 프로젝트, 업무 범위가 고정된 Plan-Driven 방식
• Agile : 인력, 시간이 고정된 Value-Driven 방식

애자일에 대해 더 자세히 알아보고 싶으시다면, 아래 블로그 포스팅을 참고해 주세요!
애자일, 애잡을일? 성공의 지름길? – 오픈소스컨설팅 테크블로그

애자일의 동의어라고 할 수 있는 협업 툴

‘우리도 애자일하게 일하자!’하고 바로 뛰어들 수 있었으면 정말 좋겠죠.조직의 규모가 작다면, 협업 툴 사용의 필요성에 의문을 가지실 수도 있을 거예요.

하지만 애자일 협업을 위해서는 다양한 협업 툴이 필요하며, 특히 규모가 큰 조직에서는 팀원 간 소통과 업무 효율을 높이기 위해 협업 툴 사용이 필수적입니다.

협업 툴 하면 떠오르는 대표적인 툴은 아래와 같은 툴이 있는데요. 이름은 많이 들어보셨지만 어떻게 쓰이는지 생소한 툴이 있으신가요? 각 툴이 어떤 목적으로 쓰이는지 간단히 설명드리겠습니다.

• Jira: 팀의 구조, 업무 흐름(work flow)에 따라 매핑할 수 있는 협업 툴. 주로 업무 흐름을 관리할 때 활용
• Confluence: 소프트웨어 프로젝트에 필요한 프로세스별로 문서를 생성, 관리할 수 있는 위키 형식의 협업 툴.
• Miro: 팀의 프로젝트 관리, 제품 디자인 등을 위한 시각적 작업 공간인 화이트보드 협업 툴
• Git: 여러 사용자들 간 파일 변경사항을 추적하고 해당 작업을 조율하기 위한 스냅샷 스트림 기반의 분산형 버전 관리 시스템(VCS)

비개발자가 애자일하게 협업하는 법

1. PO의 Epic 선정

회사에서 매일같이 생성되는 이슈들 모두가 분명 필요한 이슈임에는 틀림없습니다. 하지만, 당장 회사의 목표 성과에 따라 중요도가 나뉘기도 하고, 목표 성과로 연결되지 않더라도 고객 불편 문의가 너무 많이 인입되어 빠르게 수정이 필요한 이슈가 있기도 합니다.

이런 이슈의 중요도는 각 부서마다 체감이 다르기 때문에 중심을 잡고 이슈를 선정하여 진행할 담당자가 필요한데요. PO가 이 중요한 역할을 해내야 합니다.

여러 이슈 중에서 PO가 ‘진행 중인 이벤트를 확인하기 어려워 이벤트를 통한 구매 전환이 낮은 것 같다’는 이슈를 선정했다고 예를 들어볼게요.

이 이슈를 통해서 어떤 성과를 달성하고 싶은지, 해당 니즈가 있는 팀원들의 간단한 의견과 함께 PO는 필수 인력들로 구성된 스쿼드(Squad) 안에서 에픽을 작성합니다. 각 부서별 초기 니즈와 에픽을 포함한 성과 측정 목표, 스프린트별 목표 등은 Confluence와 같은 협업 툴에 내용을 작성하여 팀원들에게 공유하고 스프린트가 진행됨에 따라 필요 사항이나 향후 반영이 필요한 부분 등을 스쿼드원 모두가 필요에 따라 함께 기록하며 협업합니다.

위 이미지와 같은 방식으로 에픽을 진행하게 되면 개발자들로만 구성된 것과 다르게 UX/UI 디자이너와 마케터가 스쿼드에 소속되어 업무를 진행하기 때문에 요청한 페이지가 어떻게 구현될 것인지 즉각적으로 의견 확인이 가능하고, 실 사용자가 될 유저와 페이지를 관리할 마케터가 원하는 방식으로 개발이 진행될지 긴밀한 피드백을 주고받을 수 있어 개발이 완료된 페이지를 수정할 필요 없이 처음부터 니즈에 최대한 가까운 방향으로 개발이 진행될 수 있다는 장점이 있습니다. 바로 애자일 업무 방식의 가장 큰 장점 중 하나죠.

2. Jira / Confluence 등 협업 툴 활용 협업

PO는 Confluence에서 스쿼드원들과 정리한 에픽 내용을 바탕으로 진행될 업무 내용을 정리하여 Jira에 Epic 이슈로 하나의 티켓을 생성합니다. 각 스쿼드원의 업무 정도와 소속된 팀에 따라 Jira 티켓은 유동적으로 운영될 수 있는데요, 스프린트 단위로 티켓을 관리하는 것 외에도 각자 업무상 소속된 팀과의 업무 공유를 위해 아래 그림과 같이 팀 내 보드에서 티켓을 생성하여 진행하는 방식으로도 진행할 수 있습니다. 애자일 방식은 하나의 고정된 방식이 아니라 조직에 맞게 끊임없이 변화할 수 있다는 점에서 이렇듯 유연하게 업무에 적용할 수 있습니다.

설정한 스프린트 종료 기한이 도래할 때까지 스쿼드는 중간 진행 상황을 공유하기 위한 스크럼을 진행하기도 하며 목표한 스프린트 종료 기한 내 목표한 개발을 완료합니다. 스프린트가 종료된 직후, 스쿼드원들은 모여 애자일 방식에서 중요하게 꼽히는 과정 중 하나인 회고를 진행하게 되는데요. ‘스프린트가 최초 니즈에 맞게 진행되었는지’, ‘스프린트가 진행되면서 니즈가 변경되지는 않았는지’, ‘최초 목표한 성과 측정 가치에 맞게 개발이 완료되었는지’ 등을 스쿼드원과 논의합니다. 이 과정에서 다음 스프린트를 진행할 것인지, 기존 계획했던 그대로 진행할 것인지, 개발에 변경이 필요한지 등을 구체적으로 논의하여 다음 스프린트도 논의합니다.

3. 스프린트 종료 회고

개발자가 아닌 타직군의 팀원들이 스쿼드 안에서 함께 협업 하게 되면 니즈 파악이 빠르고 좀 더 긴밀한 피드백을 주고 받으며 일할 수 있다는 장점이 있는 반면, 타직군의 팀원이 해야 할 일이 한 스프린트 안에서 끝나기도 하는데요. 이럴 경우 다음 스프린트에서는 해당 팀원이 참여하지 않는 방식으로도 진행이 됩니다.

이렇듯 각자가 속한 조직의 규모와 프로젝트 규모 등에 따라 조직을 유연하게 운영할 수 있다는 점이 애자일 방식의 가장 큰 장점이 아닐까 싶습니다.

팀 내에서 애자일하게 협업하는 법

타팀과 협업하는 업무가 아니더라도, 팀 내에서도 애자일하게 업무할 수 있는 방법은 다양할 것 같은데요. 회사의 상황과 팀 구성원에 따라 변형되어야 하겠지만, 저는 아래 이미지와 같이 Cross-Functional 한 조직 구조로 팀원들과 업무를 진행했습니다.

우선, 각자의 업무 특성을 고려하여 팀원 각각은 기능 조직 구분에 따라 하나의 조직에 속하게 됩니다. 저는 퍼포먼스 마케터이기 때문에 퍼포먼스 마케팅팀 조직에 속하게 되는 거죠. 회사에서 채용된 목적에 맞는 업무를 하기 위한 조직이라고 생각하면 이해하기 쉬우실 거예요. 퍼포먼스 마케터 채용 – 퍼포먼스 마케팅팀으로 속하게 되는 것과 같은 구조인 것이죠.

그런 다음 회사에서 진행 중인 프로모션이나 시즈널 한 이슈에 맞게 각 팀에서 필요한 인력끼리 뭉친 별도의 목적 조직 팀이 구성됩니다. TF 팀을 조직하는 방식으로 생각하시면 되는데요, ‘프로모션’을 성공적으로 진행하기 위해 필요한 필수 인력들로 구성한 팀이 해당 프로모션이 끝날 때까지 함께 일을 하게 됩니다. 프로모션이 동시에 여러 개가 진행될 수 있고, 각 프로모션마다 필수 인력이 다를 수 있기 때문에 사람마다 소속된 팀이 여러 개가 될 수도 있습니다.

달라진 환경에도 유연한 애자일 방식

예시를 통해 타 팀과 애자일하게 협업하는 방법, 또는 팀 내에서도 애자일하게 일하는 방법에 대해서 작성해보았는데요.

설명만으로는 너무 복잡하고, 굳이 이렇게 세부적으로 일해야 하나 생각하실 수도 있을 것 같습니다.
예시로 설명드린 구조로 일했던 저는 명확하게 단점도 있는 반면, 장점이 좀 더 많다고 느껴졌는데요.

단점

• 업무 내용 공유를 위한 회의가 많다.
• 함께 일하는 팀원이 프로젝트에 따라 자주 바뀐다.

장점

• 프로젝트에서 각자의 몫이 명확하므로, 책임감을 가지고 업무에 임할 수 있다.
• 다양한 프로젝트에 동시에 참여할 수 있어 일의 전문성이 빠르게 향상된다.

장단점을 고려해보았을 때, 애자일 업무 방식은 조직의 규모에 맞게 적절하게 활용한다면 매우 유용한 방식임에는 틀림 없습니다.

👉마케팅 팀에서 디자이너와 협업하는 방식이 궁금하시다면?

오픈소스컨설팅에 합류한 이후로 맡게 되는 업무들 역시 애자일한 프로세스로 진행되고 있는데요.
본부별 업무 요청은 Jira 티켓 생성으로 시작되며, Confluence에서 세부 사항을 기록합니다. 필요한 경우 Miro에서 아이데이션하고, 의견을 취합하기도 합니다.

마케팅 팀 내부에서도 유사한 프로세스로 일하고 있는데요. 이러한 방식은 기존에 제가 경험했던 업무 방식과 크게 다르지 않아 빠르게 적응 중이랍니다!
(애자일 방식은 프로젝트마다 긴밀하게 협업하는 팀원 구성이 계속해서 변화한다는 점에서, 새로운 조직에서도 빠르게 적응할 수 있다는 또 다른 장점이 있어요^^)

어떠신가요. 애자일하게 업무하는 방식, 우리 회사에도 어떻게 적용해 볼 수 있을지 궁금하지 않으신가요?

*참고 – 본 포스팅에서 언급한 협업 툴 보러 가기
Miro
Atlassian Jira / Confluence