안녕하세요. 오픈소스컨설팅 Playce Dev 팀에서 프론트엔드 개발을 하고 있는 강동희 입니다.
여러분들은 혹시 ‘애자일’, ‘애자일하다’ 라는 말을 들어보신 적 있나요? 애자일 이란 일종의 소프트웨어 개발 방법론 중 하나인데, 요즘 많은 IT 회사에서 애자일 방법론을 채택해 제품을 개발하고 있습니다.
저희 Playce Dev 팀에서도 Agile 방법론으로 솔루션 제품들을 개발하고 있답니다. 연 단위의 여러번의 PI, PI 속의 여러번의 Iteration, Iteration 속에서 여러번의 Sprint 를 돌고 있는데요, 스프린트를 진행함에 있어서 매일 팀 단위의 DSU 를 진행하고 있습니다.
이번 포스팅은 저희 Playce Dev 팀이 스프린트를 진행하면서 DSU 방식에 겪었던 문제들과 해당 문제를 해결하기 위해 어떤 방식으로 DSU 를 진행하고 있는지, 또 진행방식을 바꿈 으로 마주하게 된 문제는 앞으로 어떤 방식으로 해결하면 좋을지 고민한 개인의 견해를 공유하도록 하겠습니다.
애자일 방법론은 수학이 아닙니다. 1+1=2 처럼 정답이 정해있지 않기에 항상 최선의 방법을 찾기 위해 노력하고 있습니다.
DSU 가 궁금하시다면 아래 링크를 통해서 확인해주시기 바랍니다! 🥸 애자일 실무 가이드(3): 데일리 스탠드업(Daily Stand Up: DSU)
최근 아래의 포스팅을 봤습니다. 제목부터 자극적 입니다. “Why your daily stand up fail” 번역하면 “왜 당신의 dsu는 실패일까” 입니다.
저희 Playce Dev 팀의 DSU 는 실패는 아니었습니다 만, 글을 읽으면서 격하게 공감이 갔던 부분들이 있었고, 팀원 들이 느꼈던 DSU 에 대한 문제들을 우리만의 방식으로 해결 했었던 과정이 생각났습니다.
👿 Why your daily stand-ups fail
기존의 Playce Dev 팀의 DSU 는 약속한 시간에 구글 화상회의에 접속하여 서로 얼굴을 보면서 전날 했었던 일, 오늘 할 일에 대해서 이야기 하는 식으로 진행했습니다.
보통 DSU 를 진행하는 방식은 구성원들이 서로 어제 한 일, 오늘 할 일, 일의 장애 요소를 공유하는 방식으로 길지 않고 짧은 시간 진행됩니다. DSU 를 진행하는 목적은 제품 개발에 있어서 장애요소를 파악하고 해결을 하며 팀 단위에서 어떤 문제가 있는지 파악하고 목표를 정확히 바라볼 수 있도록 함 입니다.
저희 Playce Dev 팀은 PO, 디자이너, 기획자, QA 엔지니어, TW, 프론트엔드 개발자, 백엔드 개발자 로 총 14명으로 구성되어 있습니다.
모든 팀원이 하나의 구글 화상 회의에 접속해 스크럼 마스터가 진행하는 방식으로 한 명씩 자신이 어제 했던 일과 오늘 할 일에 대해서 발표하는 식 이였습니다. 아주 많은 인원은 아니지만 14명이 돌아가면서 업무에 대해서 이야기 하던 시간은 점점 DSU 의 목적을 잃어버리고 매일 자신이 하고 있는 일을 발표하는 시간이 되어가고 있었습니다. 매일 똑같은 업무를 하는 팀원은 매일 똑같은 발표를 하고 시간만 잡아먹는 불필요한 Stand Up 이 되어가고 있었던 것 입니다. DSU 의 목적이 장애 요소를 파악하고 해결하여 스프린트의 goal 에 도달하고자 하는 것임에도 불구하구요.
많은 팀원 들은 이런 방식의 DSU 는 불필요하다고 생각을 했던 것 이었을 까요? Sprint 를 끝내고 회고를 할 때 SSC (Start, Stop, Continue) 로 여러번 DSU 에 대한 언급이 나왔었습니다.
결국 저희 팀의 DSU 는 팀 내에서 파트 별로 분리하기로 했습니다.
프론트엔드 / 백엔드 / 디자이너, 기획자, QA, TW 의 세 파트로 나눠서 DSU 진행하게 됐습니다.
모든 팀원이 함께하는 DSU 가 아닌 최소한의 이해관계자들이 모여 각각의 Scrum master 들이 DSU 를 진행하는 방식으로 방법을 바꾸어 봤습니다.
DSU 방식을 변경한 지 다섯 달이 지났습니다. 저희 프론트엔드 파트는 스크럼 마스터로써 프론트엔드 리더 분께서 매일 아침 9시 15분에, 재택을 하는 날에는 온라인으로 재택을 하지 않는 날에는 한 자리에 옹기종기 모여서 DSU 를 진행하고 있습니다. DSU 는 Jira 의 Scrum Board 를 살펴가며 파트원의 어제 했던 일, 오늘 한 일, 장애 요소 를 파악하는 식으로 진행이 됩니다.
사실 진행하는 방식은 그대로 입니다. 바뀐 점은 단지 인원 뿐 입니다. 그럼 도대체 뭐가 바뀐 것 이길래 이런 방식의 DSU 를 진행하고 있는 것 일까요?
첫 번째로는 스프린트를 진행함에 있어서 문제가 되는 점을 정말로 공유할 수 있다는 것 입니다. 사실 팀원이 많던 적든 문제를 공유할 수는 있습니다. 하지만 인원이 많다 보면 타 팀원의 시간을 뺏을수도 있다는 생각으로 정확하게 장애 요소를 공유하지 않거나, 너무 많은 사람들 앞에서 나의 장애 요소를 공유하기 힘들다는 심리적인 압박감이 존재합니다. 소수의 인원으로 구성된 파트 별 DSU 를 진행함으로써 스프린트 목표 달성에 있어서 장애 요소들을 팀원에게 공유하고 스크럼 마스터에게 공유하여 문제를 정확히 해결할 수 있게 되었습니다.
두 번째로는 의미 없는 시간이 단축 되었다는 점 입니다. 시간의 개념은 상대적 입니다. 의미가 있고 없고의 차이는 개인마다 다르지만 대다수가 의미 없다고 느꼈던 소모적인 시간 낭비 Stand up 이 없어졌다는 것 입니다. 실제로 많은 팀원이 이를 느끼고 있는 것 같습니다.
세 번째로는 업무를 깊숙하게 파악이 가능하다는 점 입니다. 파트간 DSU 로 놓치고 있는 점을 서로 짚어주며 정확히 이슈를 해결할 수 있다는 장점이 있습니다.
DSU 방식이 파트간 DSU 로 변화함에 따라서 생긴 문제점도 있습니다.
첫 번째로는 파트 간 이슈 내용의 공유의 문제 (협업 관점에서 놓치는 부분이 발생) 입니다. 아무래도 파트 간 DSU 를 진행하다 보니, 타 파트와 유기적으로 협업을 해야 하는 부분에서 소통의 문제가 발생합니다. 또한 의견과 업무 공유에 소통 부재가 생김으로써 이 부분은 다른 파트가 하겠지 라는 생각으로 놓치게 되는 부분들도 생기기 시작했습니다.
두 번째로는 파트 간 더욱 고착화 되는 현상의 발생입니다. 기존엔 팀 전체가 하나로 묶여서 DSU 를 진행했다면, 요즘엔 파트 별로 DSU 를 진행하다 보니 재택을 하는 날에는 인사 조차 나누지 못하는 팀원 들이 생기기 시작했습니다. 이런 문제가 심화되면 팀 의식이 사라지게 되면서, 각 파트들이 서로에게만 고착화되는 현상이 발생하기 시작합니다.
각 스프린트가 끝나고 스프린트 혹은 Iteration 회고를 하며 바뀐 DSU 방식의 문제를 도출하고 이를 해결하기 위한 방안을 고민 했습니다. 그리고 개인적으로 해당 문제를 개선하고자 생각해봤습니다.
첫 번째로는 협업을 강화하자 입니다. 저희 팀은 협업 도구로 Jira, Confluencer, Slack 등 다양한 도구를 사용하고 있습니다. 협업을 위한 여러 도구가 있는 만큼 해당 도구들을 더욱 효율적으로 활용하는 것은 어떨까 생각해봤습니다. 문제를 발견했을 시 적극적으로 도구를 활용해 타 팀원에게 이슈를 공유하고 다가가는 것 입니다. 개인적으로 사무실에서 근무할 땐 소통의 창구로 Slack 보다는 직접 자리로 찾아가서 의견을 공유하는 방식이 좋다고 생각해봤습니다.
두 번째로는 스크럼 마스터 입니다. 스프린트를 진행하면 당연히 스크럼 마스터는 존재합니다. 파트 별 DSU 로 나눈 이후, 파트 간 DSU 를 진행하는 각 스크럼 마스터 이외에 스프린트를 관장하는 스크럼 마스터의 역할에 대해서 생각해봤습니다. 스크럼 마스터가 스프린트를 진행함에 있어서 놓치고 있는 것들을 발견한 후 팀에 정확히 공유하는 방식, 문제가 생겼을 시 bottom to top 방식으로 아래에서 위로 의견을 전달하는 방식에 대해서 생각해 봤습니다.
세 번째로는 팀 단위의 티 타임 입니다. 파트 간 고착화를 해결하기 위해 팀 단위의 티 타임 시간을 갖게 된다면, 업무 뿐만 아니라 팀의 결속력이 강화됨 으로 팀 의식 강화 및 더욱 유기적인 협업을 기대해볼 수 있지 않을까 생각합니다.
마지막으로 이 모든 해결 방안의 중점은 서로에 대한 존중이 아닐까 생각합니다.
더 좋은 DSU 방식을 찾기 위한 여정은 아직 현재 진행형 입니다. 현재는 이런 방식으로 DSU 를 하고 있지만 앞으로 또 다른 문제점을 발견하여 다른 방식으로 DSU 를 진행할수도 있습니다.
어떤 방식의 DSU 를 취하던, DSU 를 진행하는 목적은 같으며, 더 좋은 제품을 만들기 위한 방법론 이라고 생각합니다.
위에서 언급했지만, 방법론은 1 + 1 = 2 이 아니라고 생각합니다. 그리고 저희 팀은 항상 더 좋은 방법을 찾기 위해 나아갈 것 입니다.
감사합니다.
[AKC2022] 키노트 : 여러분의 애자일은 안녕하신가요 - 김대일(오픈소스컨설팅)
One reply on “Dev 팀의 DSU 를 소개합니다!”
1+1=2 ‘만’ 맞다고 생각하는 순간 모든게 어그러지는거 같아요. 동희님 화이팅!!