My scribbling

아메드 시드키의 워크샵은 정말로 멋졌습니다.

제가 가지고 있던 궁금증 중에 가장 커다란 것을 어느정도 해결할 수 있는 시간이었습니다.
지혜씨가 소개한 mind mapping을 통해 친해진 노키아에 다니는 친구는
'이 워크샵이 지금까지 진행되었던 과정중에 최고다' 라고 치켜세웠습니다.

이 워크샵은 극단적으로 보이기만 하는
이름까지도 극단적인 extreme programming 을 어떻게 프로젝트나 회사에 적용할가에 대한 것이었습니다.

대부분의 agile 방법론을 예찬하는 사람들은 조금씩 극단적입니다.
'agile 이 아니면 프로젝트는 무조건 망한다'
'waterfall 방법론은 진부하기 그지없으며, 이를 고수하는 것은 시대 착오적인 것이다.'

이 말에 따르면,
우리나라에서 진행되는 프로젝트는 대부분이 망해야하는 것이고, 진부한 것이 되어버립니다.
사실은..... 꼭 그렇지는 않죠.

'Agile 방법론이 상대적으로 더 낫다' 라는 것은 책을 읽어 보거나 인터넷을 찾아보면 누구나 다 알수 있습니다.
문제는, '이 사실을 어떻게 고객이나 회사에 설명하는가?'입니다. 

이의 가치와 효용성을 이야기하고 설득하자면, 앉혀놓고 굉장히 많은 시간을 소비해야 합니다.
게다가 그만큼의 공부와 실행을 통해 얻은 스스로에 대한 확신과 화술 또한 갖춰야 합니다.
이 일들은 평생 컴퓨터 앞에서 프로그램만 한 배 나온 개발자들에게는 굉장히 어려운 일입니다. 

이를 위해 아메드 시드키는 현실적인 대안을 제시합니다.
이 대안에 대한 효용성을 증명하기 위해 워크샵 동안 두 번의 실습 토론을 했습니다.

첫번째는 4명씩 한조로 나누고, 2팀으로 나뉘어 2명은 고객 2명은 agile 컨설턴트를 맡습니다.
(배경지식으로 이 참가자들의 대부분은 10년 정도 agile 컨설팅을 수행해 온 분들입니다.)

첫번째 실습은,
1. 한 팀의 고객 pair 는 창조력을 발휘하여 어떠한 회사의 상황을 만들고(10분)
그 시간동안 agile 컨설턴트 팀은 agile 가치 카드들을 정리하며 자신들의 우선순위를 잡습니다.
(ex) 1. pair programming 2.customer on site 3. continuous integration ...)

2. 이 작업이 끝나면 고객쪽은 5분간 회사의 상황에 대해 presentation 을 합니다.

3. 그리고 이 프리젠테이션이 끝나면 consultant 는 자신들의 우선순위 list를 보며
한 가지씩 고객사에 제시 할 수 있는 agile 방법들을 제시합니다.

4. 고객은 자신의 상황과 관련하여 논리적으로 그 방법을 수용 할 수 있으면 그 방법이 적힌 카드에 파란 스티커를 붙여주고
적용할 수 없다면 빨간 스티커를 붙입니다.

이때 저와 지혜씨는 agile 쪽 경험이 별로 없기 때문에 고객 pair 를 맡았습니다.
이때 thoughtworks 의 JJ 라는 분이 늦게 들어와 우리 조에 합세했는데
그 분과 함께 우리는 가장 극단적인 고객군을 만들었습니다(^^;) 이건 정말 재미있었습니다.

'우리는 분산된 조직을 가지고 있고, 하나는 LA에 하나는 멕시코에 하나는 나도 모르는
전세계 어딘가에 있다. 우리 부서끼리 서로 대화하는것은 매우 싫어하는 일이며,
우리가 믿기에 waterfall은 지금까지 현존하는 어떠한 것보다 완벽한 방법론이고
우리는 이 방법론을 사랑한다.
하지만, 우리는 문서 만들기를 싫어한다. 코드 컨벤션도 없고, 모든 일을 개발자의
직관에 따라 작업한다. 개발자들은 스스로 일하는 방식을 고수하며, 남들이 하는 일을
받아들일 생각이 없다. 등등등'

^^;

우리 팀 컨설턴트 중 야후에서 일하는 한 분은 우리 프리젠테이션이 끝나자 농담으로 이렇게 말했습니다.
'나 너네 컨설팅 안할래'

우리는 소리내어 모두 한참 웃었습니다.

아무튼 결과는 3개의 빨간색 1개의 파란색이었습니다.
다른 조들도 대부분 빨간색 소수의 파란색을 받았습니다.

'아..!!!!!'

Agile 방법론을 고객의 상황에 맞춰 설득하고 적용하는것은 정말로 어려운 일이었습니다.

이에 씨드키 아저씨는 대안을 제시했습니다.
-------------------------------------------------------------------------
첫번째 실습을 통해 여러분들은 많은 것을 느꼈을 것이다.
우리가 추구하는 애자일은 변화를 요구하고 아래의 theme 들을 가져간다.
A. embrace change to deliver customer value
B. plan and deliver SW frequently
C. human centric
D. technical excellence
E. customer collaborator

이 theme 들은 케이크 처럼 모든 레이어를 한꺼번에 맛봐야만 가치가 있다.
하지만 이를 실현하기 위해 적용하는 방법은 한꺼번에 모두 이루기가 굉장히 어렵다.

문제가 생긴 경우에 변화를 하지 않으면 chaos 상태로 가게 되는데,
이 chaos 로 간 상태라면 모든 것을 revert 하기를 기관에 요구하는 경우가 허다하다.

이것은 매우 위험하며 현실적이지 않은 방법이다.

물론 모든 프로젝트의 종류와 성격이 달라 프로젝트에만 요구하는 것이라면
어느정도의 변화를 감수할 수 있다.

하지만 이것이 기관 자체를 변화하게 만드는 것이라면 굉장히 큰 벽에 부딪히게 된다.
애자일 방법론은 A 아니면 Z 의 극단적인 흑백 논리가 아니다.

사실 변화를 포용하라 라는 애자일 방법론은 A가 안된다면 B 가 될 수도 있고 C 가 될 수도 있는 그러한
flexibility 를 보장한다.

내가 제안하는 것은 위와 같이 반드시 A이지 않아도 agility 를 프로젝트 또는 기관에 적용할 수 있다는 것이다.
또한 chaos 로 가기전에 chaos 로 갈 수 밖에 없는 요소들을 어느정도 제거하여
그곳으로 향하는 것을 막아보자는 것이다.

이를 위해 300 개 이상의 indicator 를 이용하여 각 oraganization 에 적용할 애자일 방법들을 level 별로 나누고
카테고라이징을 했다.

그리고 이 agile adoption framework 를 통해 기관에 guide 하고 assist 하기 위해
collaraborative => Evolutionary => Effective => Adaptive => Emcompassing(우리가 본 자료와 아래 자료는 약간의 차이점이 있습니다)
레벨로 나눴다.

그리고 레벨별로 적용할 수 있는 방법을 가지고 고객과 대화한다.

자 그럼 두번째 activity 를 해보자

---------------------------------------------------------------------------

두번째 실습을 수행하기전 조의 컨설턴트들만 자리를 바꿨습니다.
다른 고객, 다른 컨설턴트가 온 상황이 된 것이죠.

두번째 실습은 씨드키 아저씨가 정리한 agile adoption framework 를 가지고
대화를 통해 먼저 고객의 level을 정의했습니다.

collaraborative => Evolutionary => Effective => Adaptive => Emcompassing

처음에 우리 상황을 들은 컨설턴트 들은 어이가 없다라고 얘기하고
차라리 관두고 휴가를 가겠다. 라고 말했습니다.
이에 또 한번 크게 웃었습니다.

대화 끝에 컨설팅쪽에서 우리 회사는 level2 (Evolutionary) 라고 정의했습니다.
그리고 씨드키 아저씨가 300명의 인디케이터와 정의한 frame work 을 따라 질문을 하고
방법을 제시했습니다.

결과는 '4개의 파란색, 0개의 빨간색'

똑같은 상황에 대단한 발전이었습니다.
다른 팀또한 대부분 비슷했습니다
'8개의 파란색, 1개의 빨간색'
'6개의 파란색, 0개의 빨간색'

Agile 방법론을 회사나 프로젝트 상황에 맞춰 체계적으로 접근할 때 어떠한 변화가 있는지 모두가 느끼고 공감할 수 있었습니다.

이 워크샵때 사용했던 material 을 달라고 email 을 보냈는데, 아직 답이 없군요.

우선 제가 찾은 씨드키 아저씨의 다른 자료를 첨부합니다. 한번씩 읽어 보세요

이 글들은 더 생각나는게 있을때마다 업데이트를 하겠습니다