#스크럼 #애자일 #효율성 #개발방법론
많은 팀들이 그렇듯이 저희 팀(스쿼드)의 업무 과정에도 비효율적인 부분들에 대한 논의들이 있었고, 그에 관해 제가 슬랙에서 팀에 얘기한 내용을 정리해서 남겨봅니다. (거의 그대로 옮김)
일반론에 대한 것이 아닌 특수 상황에서 나눈 이야기임을 고려하고 읽어주세요.
우리는 왜 스크럼을 하고 있는가
네. 물론 제 개인적인 생각입니다.
정확히는 왜 아직도 스크럼을 유지하고 있는가에 대한 의문이 있을 것 같습니다.
좀 순화해서 표현하자면 우리가 하고 있는 스크럼이 맞는지에 대한 것이겠죠.
특히 최근에 몇몇 분들이 공유했던 글을 통해서 고민들이 더 많아진 것 같습니다.
https://yozm.wishket.com/magazine/detail/1474/
어제 있었던 테크 세션(미니 세미나?)에서는 여러 부서에 계신 분들의 스크럼에 대한 생각들을 들을 수 있었는데요, 각 부서의 상황이 다르기 때문에 방법과 개선 시점도 조금씩 다를 것 같습니다.
저희 스쿼드에서도 몇분은 참석을 하셨고 의견도 나눴는데요, 관련해서 저도 생각을 정리를 해봤습니다.
나름 프로세스에 대해서 고민을 많이 하는 입장이이서 많은 얘기를 하게 되었는데요, 이후에 여러분들의 의견도 들을 수 있으면 좋겠습니다.
먼저 우리가 하고 있는 데일리 스크럼에 대해 정리를 해봅시다.
재택 업무를 하고 있는 분들과도 소통을 하기 위해, 그리고 일반적인 스크럼 인원보다는 훨씬 많은 인원이 참여를 해야 하는 저희의 환경을 극복하기 위해 슬랙의 허들 기능을 활용하고 있습니다. 사무실 어딘가에 모여서 얘기하기 어려운 상태니까요.
그리고 얼마전부터는 매일 진행하기에는 소요되는 시간이 길다(일하는 시간의 인터럽트가 크다)라는 의견에 맞추어서 2일은 기존의 방식대로, 그리고 3일은 텍스트로만 남기고 각자 정보를 얻어가는 형태로 운영이 되고 있습니다.
또한 목적 조직으로 팀이 변경이 된 이후 상호간의 이해를 하기 위한 목적으로도 활용하기 위해 TMI를 남기고 조금은 자유롭게(어떻게 보면 느슨하게) 대화를 하는 형태로 확장(변형)한 모습은 유지가 되고 있죠.
현재 얻고 있는 것과 잃고 있는 것을 생각해봅시다.
<긍정적으로 생각할 수 있는 부분>
이슈를 잘 공유하고 있다. 필요한 경우 바로 답을 얻거나 후속 논의에 대한 의사 결정이 빠르게 이루어진다.
협업 빈도가 낮은 동료들에 대해서도 어떤 일을 하고 있는지를 포함한 얘기를 들을 수 있다.
(재택을 하더라도) 사람 목소리를 들을 기회가 생긴다.
(그렇지 않아도 잘 할 수 있기는 하지만) 오늘 해야 할 일을 간략하게 생각하고 일을 시작할 수 있다. 이에 더해서 동료들과의 조율을 통해 해야할 일을 변경해서 진행할 수도 있다.
<아쉬운 부분, 개선되었으면 하는 부분>
유연 근무 시간에 인터럽트가 되는 고정된 스크럼 시간이 업무 연속성에 방해가 된다.
나는 관심없는 내용이 많다. 시간이 아깝다.
이슈 사항은 언제든지 직접 물어보거나 슬랙에 남겨두는 것으로 해결이 될텐데 스크럼에서 이슈를 얘기하는 이유는 무엇인가.
TMI가 굳이 필요한가.
여기에 사실 의도적으로 제외한 영역이 있다는 것도 아실 것입니다.
많은 회사가 그렇듯이 회사 전체 방향에 대한 이해도가 부족하다고 느끼는 경우, 혹은 더 나아가서 의사 결정이 된 것에 대한 의문이 드는 경우는 개발 방법론의 범주를 넘어서는 영역이어서 제외를 했습니다. (개인의 문제보다는 보통 원활한 소통의 이슈가 많죠)
냉정하게는 그런 부분이 있다 하더라도 그 안에서 더 나은 방법들을 찾는 것만이라도 해보는 시도가 필요하기도 하고, 이런 문제점을 해결하기 위해 노력하는 사람들이 해당 영역은 조금씩이라도 개선해 줄 것이라고 믿고 나머지에만 집중하자라고 생각해봐도 좋겠습니다.
애자일 소프트웨어 개발 선언을 인용해 봅니다.
http://agilemanifesto.org/iso/ko/manifesto.html
굳이 사람 이름을 포함한 것은 훌륭한 개발자이면서 현재까지도 방법론에 대해 의견(과거 자신의 의견을 보완하는 것을 포함)을 제시하는 분들과 같은 시대에 살고 있다라는 것을 얘기하고 싶어서...
위에 얘기된 우리 조직의 스크럼에서 아쉽거나 개선되었으면 하는 부분중 한가지에 대해서만 '선언'의 내용을 포함해서 설명을 해보려고 합니다.
이슈 사항은 언제든지 직접 물어보거나 슬랙에 남겨두는 것으로 해결이 될텐데 스크럼에서 이슈를 얘기하는 이유는 무엇인가
사실 스크럼과 상관없이 이슈에 대한 대응은 대부분 이미 잘하고 있기도 해서 위의 내용 자체는 '참'에 가깝습니다. 그럼에도 불구하고 '다른 사람의 개발을 도와주면서' 일을 하기 위한 접점을 만들어 둔다의 관점으로 한 번 생각을 해봅시다.
나는 언제나 필요한 도움을 요청하고 궁금한 것들을 물어볼 수 있어. 야, 너도 할 수 있어. 이런 생각을 하고 있지는 않나요?
하지만 상황에 따라서 어떤 사람은 소극적이거나/바쁘거나/귀찮거나/기타 여러가지 이유로 협업의 영역에서 단절될 수 있습니다. 적어도 적극적으로 도움을 받을 수 있는 상황과는 거리가 있을 수 있겠죠.
데일리 스크럼이라는 도구는 이런 부분을 개선하는데에도 활용이 될 수 있다고 생각합니다.
모두가 하기 때문에, 전에 별것 아닌 것으로 보이는 것도 이슈로 얘기하는 내용을 접해봐서, 얘기할 기회는 없었는데 마침 내가 아는 얘기가 나와서 등의 이유로 연결의 끈이 생길 수 있는 것이죠. (추가로 오프라인일 때 더 확장이 되는 부분도 있습니다)
물론 애자일 선언이 진리는 아닙니다. 하지만 적어도 현재의 우리팀이 생각하는 개발에 대한 가치와 상당 부분 같은 맥락을 가지는 내용이라고 생각됩니다.
이 부분에서 먼저 이해를 해주셔야 할 부분은 현재의 개발 조직 리더들이 여러가지 현상에 대해서 무심하거나 강압적이지 않다는 부분입니다. 이것에 대한 최소한의 신뢰는 있겠죠?
'사람은 더 뽑지 않아'이거나 '그냥 시키는대로 해'의 입장이 아니라는 것을 믿는다면, 불편함을 느끼는 수준만큼 적절한 대안을 찾는데 힘을 써주시면 좋겠습니다.
'해결책은 모르겠지만 힘들다고 얘기만 하는 것도 하나의 의견이다'라고 할 수는 있지만, 개선의 방법이나 시기를 찾기 위해 노력하고 있는 사람들의 발목을 잡게 되면서 불편함을 느끼는 시기가 더 늘어나는 악순환에 기여할 수 있다는 점도 인지를 해야 하는 것이죠.
제가 지난 두번의 스프린트 회고 시간과 이후 슬랙에서 별도로 설명을 드렸던 것처럼, 중간 커뮤니케이션을 담당해줄 인원이 부족해서 효율성이 떨어지고 있는 부분은 일단 죄송한 부분이면서 당분간은 해당 영역을 각 개인이 조금씩 감당해야 되는 현실에 대해 말씀을 드렸습니다.
사실 저는 프로세스를 없애고 지우지 못하는 문서나 코드를 삭제하는 결정을 자주 내리는 '전문가'입니다^^. 우리가 하고 있는 스크럼의 효용성이 어느 수준 아래로 떨어진다면 '삭제'를 하고, 발생했던 불편함보다 조금 낮은 수준의 불편한 방법을 찾을 것입니다.
다만 지난번에도 언급드렸듯이 현시점에는 다른 대안들의 필요 조건에 대한 준비가 너무 부족해서 새로운 불편함의 크기가 더 클 것이라고 생각하고 있습니다.
팀내에서 있었던 이야기지만 비슷한 상황에서 고민하고 있는 분들이 있을 것 같아서 남겨 보았습니다. 도움이 되는 분들이 있으면 좋겠습니다.