[LeSS#1] 왜 레스(LeSS)인가?

이 글은 공식 Less 사이트에 있는 Why LeSS?를 옮긴 것이다.

예전부터 팀 단위의 애자일 방법론을 대규모 조직에 적용하고자 하는 노력은 꾸준히 있었고, 현재 시점에서 SAFe와 LeSS가 가장 인기있는 대규모 애자일 프레임워크라고 할 수 있다. 많은 이들이 애자일 트랜스포메이션에 관심을 갖고 있는 우리의 상황에서 비슷한 고민을 오래 전에 먼저 시작한 이들의 문제 인식과 통찰을 살펴보는 것은 흥미로운 일이다.

이 글을 시작으로 LeSS 관련 글들을 꾸준히 소개해보고자 한다.

0. 대규모 스크럼, 레스(LeSS)
1. 왜 레스(LeSS)인가?
2. 레스(LeSS)의 규칙
3. 피처 팀(Feature Teams)
4. 제품 책임자(Product Owner)
5. 스프린트(Sprint)
6. 제품 백로그(Product Backlog)
7. 제품 그리고 완료의 정의
8. 팀간 조율 및 통합
9. 스크럼 마스터(ScrumMaster)
10. 레스(LeSS)의 적용

전통적인 순차 개발 방식은 그다지 바람직하지 않다. 작은 제품을 개발하는 프로젝트든 큰 제품을 개발하는 프로젝트든 마찬가지다. 2001년 이후 애자일 개발, 특히 스크럼은 소프트웨어 개발에 혁명을 일으켰지만, 어떻게 하면 대규모 그룹에 애자일 개발을 적용할 수 있는지 물어보면 많은 사람들이 이렇게 말했다. “하지 마세요”, “작은 팀에서만 사용하세요”, “스크럼은 팀 차원에서 하는 겁니다”. 그 누구도 시원한 답을 내놓지 못했다. 개발 프로젝트에 추가로 사람을 투입하는 일은 피하는 것이 상책인 것인 사실이지만 대규모 제품 개발이 사라질 리도 없기에, 우리는 방법을 찾아내야만 한다.

우리(크레이그와 바스)는 RUP, CMMI 등 전통적인 순차 개발 방식에 있는 온갖 역할을 다 하면서 오랫동안 소프트웨어 개발에 참여해왔다. 그 무엇도 적합하지 않았다. 반면에, 스크럼은 단일팀 개발에 적합했다. 그래서 “어떻게 하면 그 강점을 잃지 않고 스크럼을 확대할 수 있을까?”라는 질문을 하게 되었다.

레스(LeSS)는 스크럼을 확대한 것이다

스크럼의 강점은 무엇일까? 대답하기 쉬운 질문은 아니다. 물론 투명성, 경험적 프로세스 제어, 반복 개발, 자기 관리 팀과 같은 스크럼 이면에 있는 개념과 원칙은 중요하다. 하지만 이러한 원칙들은 꽤 오랫동안 있어왔기 때문에 스크럼의 성공을 설명해주는 것은 아니다. 우리는 많은 논의를 거쳐 다음과 같은 결론을 내렸다.

스크럼의 강점은 추상적인 원칙과 구체적인 실천법의 절묘한 균형이다.

따라서 대규모 스크럼도 스크럼이라면 그런 절묘한 균형을 갖추어야 할 것이다. 그래서 이렇게 말할 수 있다.

레스(LeSS)는 정의된 구체적인 요소와 경험적 프로세스 제어의 절묘한 균형을 대규모 그룹에게 제공한다.

이것이 다음과 같은 결정으로 이어진다.

레스(LeSS)는 단순해야
규모를 확대하다 보면 새로운 역할, 산출물, 프로세스 등을 추가하는 경향이 생긴다. 프로세스가 제품 그룹의 경험을 통해 만들어질 수 있도록 이를 피해햐 한다. 다른 대부분의 스케일 애자일 프레임워크는 정의된 프로세스를 제공하는 함정에 빠진다. 우리는 그 함정을 피하고 싶다.
레스(LeSS)는 스크럼을 확대한 것
우리는 스크럼을 스케일 프레임워크의 구성 요소로 간주하기보다, 스크럼을 살펴보고 각 요소에 대해 “이게 왜 여기에 있지?”라고 묻고, 이어서 “여러 팀이 있는 경우라면, 어떻게 하면 같은 목적은 더 큰 규모에서도 달성할 수 있을까?”라고 질문해야 한다.
맞춤 보다는 확대를
보편적이고 가장 핵심적인 프레임워크를 정의한 후 맥락에 따라 맞춰 조정하는 것이 프로세스를 개발하는 일반적인 개념이다. 하지만, 사람들은 종종 자기 맥락에는 전부 다 필요하다고 가정하기 때문에 이것은 좋은 방법이 아니다. 이러한 가정이 비대한 프로세스라는 결과로 이어지는 경우가 많다. 레스(LeSS)는 최소한으로 유지해야 한다. 확대를 하다보면 “더 많은 것들”이 필요하게 된다는 사실은 인정하지만, 선택적 요소들로 레스(LeSS)를 “오염”시키기보다 레스 휴즈(LeSS Huge)라는 별도의 프레임워크를 만들었다.

레스(LeSS) 개요

우리가 레스를 바라보는 방법은 아래 그림에 가장 잘 나타나있다.

레스(LeSS)는 실험을 활용한다

우리가 쓴 첫 두 권의 책 Scaling Agile and Lean Development와 Practices for Scaling Agile and Lean Development에서 우리는 원칙을 지닌 일련의 실험을 통해 대규모 스크럼을 구성했다.

최적의 실천법(best practice) 같은 것은 존재하지 않는다. 오직 특정 맥락에서 좋은 실천법이 있을 뿐이다.

그러다보니 두 책에는 우리가 했던 실험으로 가득 차 있다. 시도해 볼 것을 추천하는 것도 있고, 피할 것을 권장하는 것도 있으며, 어떤 맥락에서는 잘 먹히겠지만 또 어떤 맥락에서는 그렇지 못할 것이라는 경고도 있다. 이 방식은 효과적이었고 많은 긍정적인 피드백을 받았다.

또한 사람들로부터 약간은 헷갈리는 피드백을 받기도 했다. 그들에게는 어떤… 맥락의 영향을 덜 받는 … 지켜야 할 규칙이 좀 더 필요했다. 이 피드백을 근거로 우리는 슈하리(Shu Ha Ri) 학습 모델을 반영시켰다.

이 모델은 학습자가 새로운 개념을 배울 때 겪는 여러 단계를 보여준다

수(守, Shu)—기본을 배우기 위해 규칙을 따른다
파(破, Ha)—규칙을 깨뜨리고 맥락을 발견한다
리(離, Ri)—완전히 익혀고 자신만의 방법을 찾는다

이전에 했었던 작업에서는 우리가 수(守) 단계에 아무 것도 제공하지 않았다는 사실을 깨달았다. 대규모 제품 그룹에서 애자일 개발을 이제 막 시작한 사람들은 그 단계에서 어려움과 혼란을 겪는다. 좀 더 예측적인 다른 확대 방식이 초급자 레벨의 조언을 제공하기 시작하면서 이 점은 훨씬 더 분명해졌다. 그래서…

레스 프레임워크(LeSS Framework)

레스(LeSS)는 단순한 원칙과 실험의 모음이 아니다. 규칙이 있는 프레임워크도 함께 제공한다. 레스 규칙(LeSS Rules)에서는 레스(LeSS)란 무엇인지(또는 무엇이 아닌지)를 정의하며, 레스(LeSS)를 적용하기 위한 구체적인 프레임워크를 제공한다. 제품 그룹은 레스 프레임워크(LeSS Framework)에서 실험을 적용하고 특정 순간에 무엇이 자신들에게 최선인지 발견할 수 있다.

또한 이것이 Large-Scale Scrum이라고 부르는 우리 세 번째 레스(LeSS) 책의 기반이다. 이 책에서는 레스(LeSS)를 다음으로 정의한다.