애자일 스크럼의 시작을 되돌아보며

주변 동료들과 애자일 이야기를 하면서 우리 팀이 애자일을 어떻게 시작하게 되었는지를 회상하게 되었다. 

나의 생각을 정리할 겸, 경험한 여러가지 중에서 애자일을 도입하게 된 배경과 변화들을 이야기하려 한다. 

배경

지금도 그렇지만 약 2년전에도 업무와 관련되어 추정을 실패하거나 계획의 변경은 자주 일어났다.

• 우리는 연간 해야할 일을 계획한다.
• 놀랍게도 매달 새로운 해야할 일이 탄생한다.
• 생물처럼 이슈들이 계속 증식하고 발생한다. 
• 연간 2-3회 최소 1달이상은 연속으로 야근하게 만드는 높은 중요도와 긴급도를 갖는 이슈들이 탄생한다.

연말에 1년간의 일을 되돌아보면 계획한 일들의 내용은 많이 바뀌어 있었다. 예상되지 못하는 일들이 우리를 힘들게 했는데, 특히 유지보수를 위한 비용이 많이 들었다. 이 과정에서 나를 포함하여 팀 구성원들은 고통을 받았다. 왜냐하면 대부분 긴급한 일이라 디버깅하고 수정하는데 신체적, 정신적 스트레스가 많이 소요되기 때문이다.&nb p;재발 방지를 위한 개선사항 아이디어들은 계획만 세워질 뿐 우선순위가 매번 뒤로 미루어지게 되니 번아웃 현상까지 만나게 되었다. 그 당시에는 이러한 상황을 벗어날 수 있는 탈출구를 찾기 위해 막연히 애자일의 문을 열게 된거 같다.

이미 애자일중에서 스크럼이 유행하고 있었고, 구글에서도 다양한 자료들이 있어서 큰 고민 없이 스크럼을 활용하기로 하였다. 팀 동료가 찾은 ice scrum이란 도구를 활용해서 무작정 시작을 하였다. 정확히 1년간 운영했던 ice scrum 도구는 우리를 여러모로 고생시켰지만 팀 구성원들 모두가 스크럼 프로세스를 이해하고 성숙하게 만드는 좋은 도구였다. 

약간의 반전을 이야기하자면, 이 도구는 사용성이 떨어져서 결국 지금은 사용하고 있지는 않다. 

변화

스크럼 운영을 하면서 가장 좋았던 점은 특정 스프린트 주기로(우리는 2주 단위로 스프린트를 운영하였다) 진행할 업무를 추정하고 잘 진행했는지 회고할 수 있게 도와준다는 점이었다. 팀 구성원들은 계획한 일들을 작은 단위로 나누어 명시하고 진행사항들을 스크럼 보드에 업데이트 해주었고 새롭게 발생한 긴급 업무들을 기록함으로 >써 우리가 갖고 있는 문제점을 팀 모두가 고민하고 이야기할 수 있도록 변화하게 되었다.

그 다음으로 좋은 점은 산출물을 공동의 책임으로 인정하고 각자의 업무를 투명하게 공유할 수 있다는 점이다.

우선 산출물을 공동의 책임으로 인정하면서 업무 형태가 많이 변경되었다. 이전에는 모든 구성원이 모든 모듈을 알지 못하고 있었다. 왜냐하면 효율성을 위해서 모듈에 대해 담당자를 두고 코드 작업을 진행 했었기 때문이다. 같은 팀이지만 내가 맡은 업무가 아니기 때문에 관심이 없어질 가능성이 높아진다. 또한 품질을 지키기 위한 코드 리뷰 시스템을 도입하기도 어렵다. 관심이 없어지거나 잘 모르는 코드에 대해서 심도있는 리뷰를 해줄 수 없다. 우리는 산출물을 공동의 책임으로 하기 위하여 모듈 담당 제도를 제거하고 팀내 교육을 시작했다. 시간이 조금 걸렸지만 그 결과 서로가 어려운 상황을 도와줄 수 있는 환경으로 변화하게 되었고, 코드 리뷰 시스템을 활용할 수 있게 되었다. 

두 번째로 일일 스크럼과 스프린트 리뷰를 통하여 팀의 업무가 가시적으로 그리고 투명하게 공유된다. 그 과정에서 기간내 계획된 업무를 완료하기 위한 도움을 요청할 수 있고, 기술 >공유등을 통하여 팀 구성원간의 성장을 유도하고 코드 품질을 높일 수 있게 도와주었다. 그리고 스프린트 회고를 통해서 개발 프로세스를 개선하기 위한 노력을 지속적으로 하게 되었다.

지금도 여전히 추정과 계획은 어렵지만 우리는 좋아지고 있고 계속해서 변화하고 있는 중이다.