8장. 애자일팀의 지속적인 개선#4

#8-4 애자인팀의 성숙

#8-4 애자일팀의 성숙  

ACT는 다른 여러 조직과 협업을 하면서 다양한 마찰을 겪에 되고 이를 통해 배움으로써 유연함을 익히게 되었다. 그리고 조직 구성원들은 더 단단해졌다. 

처음에는 '15년 당시 강렬한 협업을 통해 배운 P사의 모델을 가지고 그대로 프로젝트를 수행했다. P사의 방식은 기획자, 디자이너, 개발자의 3박자를 갖추어 사용자 경험을 극대화하는 MVP나 제품을 만드는데 최적화된 방식이었다. 하지만 ACT가 해야 하는 프로젝트 중에 P사의 방식을 그대로 쓸 수 있는 프로젝트는 그렇게 많지 않았다. 

ACT의 세미나

예를 들어, 화면만 연결하여 고객에게 피치 해야 하는 MVP를 만들어야 하는 경우도 있었다. 이 때는 개발자들이 많이 필요하지 않았다. 또한 화면이 없이 기술적인 알고리즘을 테스트하고 이를 API로 제공하는 경우도 있었다. 이경우는 디자이너가 필요하지 않았다. 

이외에 플랫폼이나 프레임웍 형태로 고객에게 제공되어야 하는 내용도 있었다. 이 경우 디자이너의 도움은 아주 적게 필요하고, 보다 플랫폼 형태를 이해하는 개발능력이 필요했다. 이외 납기가 가장 중요한 상태에서 완전히 기능 위주의 개발을 해야 하는 경우도 있었고, 운영/유지보수를 위한 애자일 방식에 협업을 하는 경우도 있었다.

 

다양한 종류의 프로젝트를 거치며 ACT는 '지속적인 개선'이라는 이름으로 그 일을 하던 팀과 함께 적합한 개선안을 만들기 위해 노력했다. 이 가운데 현실과 맞물리는 여러 가지 타협이 일어나는 경우도 있었다. 하지만, 고집스럽게 두 가지의 원칙은 반드시 지키려고 했는데 그것은 사용자를 만나 검증하는 것과 소스코드의 품질을 지키기 위해 테스트 코드를 작성하는 것이었다. 원칙을 기반으로 ACT만의 노하우를 쌓아갔다. 

8개 프로젝트가 함께한 이벤트

이러한 움직임과 함께 회사에는 긍정적인 변화들과 부정적인 변화가 동시에 생겼다. 긍정적인 영향은 개인별로 역량을 높이기 위해 애자일 방식을 쓰는 곳이 늘어났다. 개발 조직의 리더들이 주도하는 강력한 리더십의  바탕으로 개발 문화를 개선하기 위한 노력을 기울였다. 

그리고 코드에 대한 중요성이 부각되었다. 코드 리뷰를 해야 한다는 움직임과 테스트 코드를 작성해야 한다는 주장이 힘을 얻기 시작했다. 또한 사업 조직은 사용자 인터뷰를 위한 비용을 공식적으로 마련하기 시작했다. 이를 통해 사용자들에 대한 피드백을 보다 쉽게 받을 수 있도록 프로세스의 변화가 일어나고 있었다. 

팀 회고

부정적인 변화는 일부 프로세스 강제화가 시작되었다. 테스트 코드나 코드 리뷰를 강제화하는 프로세스가 생겼다. 프로세스화를 통해 보다 품질이 좋은 제품을 만들기 위한 전사적인 조치였다. 문제는 레거시 시스템 2~3개를 한 명이서 다루는 경우도 있었고, 그러한 담당자들이 여럿이 있는 곳에서는 코드 리뷰가 그다지 의미가 없는 경우들이 있었다. 

즉, 조직적인 관점과 고객과의 관계가 전혀 달라지지 않은 현재 상태에서 무조건 기법만 적용하라고 하는 방식은 다양한 마찰을 불러일으켰다. 애자일 방식에 더 많은 부정적인 여파가 생겨나기도 했다.