우리 개발팀의 스크럼, 제대로 되고 있을까?

'진짜 개발' 에 도움이 되는 회사 이야기 1 : 스크럼 회의

많은 개발팀이 매일 아침 스크럼 회의를 진행합니다.

그런데 왜 많은 개발자들이 스크럼을 ‘가장 싫어하는 업무’ 중 하나로 꼽을까요?

스크럼(Scrum)은 원래 럭비에서 유래한 용어입니다.

경기 중 공이 멈췄을 때,

양 팀의 선수들이 머리를 맞대고 서로 밀치며 공을 다투는 장면,

보신 적 있으신가요?

이 장면에서 중요한 건 역할 분담, 협력, 즉각적인 실행입니다.

단순한 회의가 아니라, 공을 되찾기 위한 집중된 전술 수행의 순간이죠.

그런데 많은 기업에서 스크럼은 그저 "어제 뭐 했는지 말하고, 오늘 할 일 말하는 짧은 보고"로만 쓰입니다. 실제로 제가 처음 스타트업에 입사했을 때 대표님은 “스크럼은 서서 하는 거야!”라며 모두를 일으켜 세우고 1시간 동안 보고만 진행하곤 했습니다. ‘서서 하는 회의’라는 형식만 남은 채, 스크럼의 본질은 사라져 있었죠.

진짜 스크럼은 팀이 짧은 시간 안에

정확한 정보를 공유하고,

협력으로 문제를 돌파할 전략을 세우며,

빠르게 실행으로 전환하는 과정입니다.

보고서 같은 느낌이 아니라, 진짜 “공을 따내기 위한 움직임”이어야 합니다. 사실 회의라는 명목하에 한명씩 자기 성과 보고하는 회의가 많습니다. 아래 대화처럼요.

- 관리자 : "A개발자, 어제 뭐했어?”

- 개발자A : " 말씀하신 API 이슈 있잖아요, 그거 로그 다시 보고 에러 핸들링 로직 좀 보강했고요, 또 어제 새로 들어온 요청 때문에 repository 구조도 조금 수정했습니다. "

- 관리자 : " B는? "

-개발자 B : "머지는 이제 막 시작단계이고요. 커밋은 일단 올려놨어요. 그리고 오전엔 코드 리뷰 몇 개 했고, 오후엔 그 백엔드 쪽 배포 이슈가 좀 있어서 보느라 조금 늦춰지고 있어요 "

이 단순한 대화만 봐도 익숙한 사무실 풍경이 스쳐지나 가는 분들이 계실텐데요.

지금은 "지금 구현 중인 기능에 디자인 일부 수정이 필요합니다.”같은 평등한 분위기의 실질적인 협의와 요청이 오가는 스크럼이 필요한 때입니다. 스크럼은 보고가 아니라 조율입니다.

개발팀이 싫어하지 않는 스크럼,

지금부터라도 다시 생각해보는 건 어떨까요?