저희 회사는 애자일에 대해서 2009년 부터 단계적인 적용을 해왔고, 책을 통해서 애자일에 대한 이해는 어느정도 하고 있는 상황입니다. 제가 애자일에 관심이 높았던 지난 몇년을 돌아보면 그 중 사내에 도입해서 가장 효과가 좋았던 실천법은 뭐니뭐니 해도 회고가 아닐까 하는 생각이 듭니다. 



저희 사내에서 회고는 SW개발 팀원뿐만 아니라, 전사적인 전략 수립, 직무평가 워크샵, 고객관리 등에서도 다양하게 사용되었고, 참여하는 팀원들도 모두 좋아하고 만족도가 높은 멋진 방법임이 분명합니다.


하지만, 회고를 책으로 배워서 그런지 몇가지 답답한 부분이 있었죠.

(창준님이 하시는 AC 코스에 가고 싶은 마음도 몇번이나 있었는데, 의지 부족으로 아직 참여는 못했네요)


언제나 처럼 xper 메일링을 눈팅만 하던 중, 이번에 주제가 애자일 회고이기도 하고 물어볼 수 있는 트랙도 준비되었다는 소식을 접하고, 제가 회고를 하면서 어려웠던 점을 몇가지 정리해서 회사의 팀원 두명과 함께 xper 정모에 참석했습니다.

저도 너무 오랜만에 참석하는 자리였고 같이 간 팀원들도 처음 참석하는 거라 은근히 어색함을 걱정했지만, 새로운 참석자에 배려가 좋은 xper의 문화와 준비를 꼼꼼하게 해주신 퍼실리테이터 분들 덕분에 금방 친해질 수 있어서 좋았습니다.


xper 정모 안내문



맛있는 김밥과 음료수를 먹고 테이블에 계신 분과 인사를 나누고 웃고 떠드는 시간이 지나고

회고에 대한 컨설팅을 받을 수 있는 트랙이 시작되었습니다.


제가 김창준님에게 던진 질문은 아래의 두 가지입니다.

질문1. 저희 회사는 매주 주간보고의 말미에 PMI 회고를 수행하는데 그 목적과 다르게 참여도가 낮고 의견을 말하지 않습니다. 어떻게 하면 좋을까요?


질문2. 저희 회사는 6개월의 내용을 모아서 정기회고를 전사적으로 하는데 책 속의 애자일 회고 순서로 진행합니다. 하지만 인사이트 발굴과정에서 어려움을 느낍니다. 어디를 고치면 좋을까요?



한시간 반 정도의 시간동안 3명이서 돌아가며 자신이 회고에서 느낀 어려움을 묻고 답하는 형식으로 진행되었습니다. 김창준님과 박준표님이 좋은 의견을 많이 이야기 해주셨고, 아래 사진처럼 앞 뒤로 빼곡하게 말해주신 내용을 받아 적었습니다.




저의 경우는 상담시간이 끝날 즈음에 저희 회사에서 진행하는 회고의 개선점을 몇가지 찾게 되었고 그 내용을 요약하자면 다음과 같습니다.


보고와 회고를 섞어서 하는 것 보다는 분리하는 것이 좋고, 회고는 형식에 얽매이지 말고 짧게 할 것

회고 자체보다는 평상시 상호작용을 통한 심리적 안정감을 강화하는 노력이 더 중요함

회고에 즐거움을 디자인해서 동물적으로 그 회고가 좋아지도록 할 것

좋은 회고는 결국 꾸준한 연습이 필요하므로. 매일 2명씩 짝지어 10분간 회고해볼 것

회사뿐만 아니라 집에서도 부인과 함께 매일 회고를 연습해보는 것이 좋다.



xper 모임을 마치고 돌아오는 길에 이런 생각을 했습니다.

우선 전체 팀원에게 회고란 무엇이라고 생각하는 질문해보자.

만일 회고를 반성하는것이라고 느낀다면 오늘 들었던 인지적, 정서적, 신체적 관점에서 해결책을 찾아내서,

새롭게 사내 회고를 디자인 해야겠다! 재미있겠는걸~ㅋ


후기를 쓰면서 정리하다 보니, 애자일의 꽃이 회고라던 퍼실리테이터 분의 말이 생각납니다. 저 역시 애자일 실천법을 여러가지 적용하면서 회고가 가장 멋진 거라고 생각하고 있습니다. 회고를 잘 하려면 눈치도 빨라야하고 리더십도 필요하며 좋은 기법도 있어야 합니다. 하지만 여러가지 기법보도 더 중요한 것은 서로를 비난하기 보다는 참여한 모든 사람이 스스로 점검하고 되돌아보는 것에 초점을 맞추는 자세라고 생각됩니다. 



사내에 개선된 회고를 디자인해보고 적용한 결과를 나중에 공유할 수 있었으면 좋겠네요 :-)

xper 여러분 덕분에 즐거운 시간이 되었습니다. 자주 자주 만나요~



다른 분의 후기


'취미 그리고 생각' 카테고리의 다른 글

NHN NEXT  (0) 2013.03.08
트렌드코리아 2013  (0) 2013.02.25
왜 세계의 절반은 굶주리는가  (0) 2013.01.16
누워서 읽는 퍼즐북  (0) 2012.11.26
안철수의 생각  (0) 2012.08.28



오늘은 팀원과 서로가 원하는 이상적인 팀의 운영이란 어떤것인지 팀 운영방식에 대한 이야기를 할 기회가 있었습니다.

좋은 팀이란 무엇보다도 상대에 대한 이해를 기반으로 해야 하는데, 대화를 해보니 팀 리딩에 있어서 팀원들과 함께 팀의 미래에 대한 비젼을 공유하지 못하고 있는 것 같아서 좋은 팀에 대한 제 생각을 한번 정리해 보려고 합니다.


지난 몇년간 애자일하게 일하는 SW기업이 되고자 이런저런 고민을 많이 하고 있습니다.

그 중 'Self-Organizing Team' 이라는 키워드는 매력적이었고 제가 원하던 모델이었죠.


저는 전통적인 조직운영 방식에서 보이는 강력한 중앙집중형 리더십이 조직을 이끌어가는 형태가 아니라

통제가 적고 구성원의 자유도가 높은 리더십으로 운영이 되는 애자일한 조직운영을 하고 싶었습니다. 


Source : http://blogs.seapine.com



제가 이해한 'Self-Organizing'은 멋진 용어이지만, 실제 현업에서 몇년간 해보니

자율적인 업무결정권을 자유로운 업무방식으로 오해하는 팀원이 생기고 그로인해 갈등이 심해지는 경우들이 발생되었습니다.


프로젝트에서 너무 적은 리더십을 가진 스크럼마스터는 팀원이 상호작용하여 협업이 되도록 하기에는 부족하였고

팀원에게 많은 결정사항을 위임하는 자율적 결정방식은 수동적이 지시에 의존해온 팀원들에게 괴로움만 가중시키게 되었습니다.


'서툰 목수가 연장을 탓한다'고 하더니 이게 그런 모습이네요. ㅎㅎ

사실 이것은 리딩을 제대로 못한 저의 무능력 때문이지, 자기조직적팀(Self-Organizing Team)이 잘못된 것은 아니라고 생각합니다.


제가 생각하는 자기조직적인 좋은 팀이란?


프로젝트의 핵심가치를 위반하지 않고 유연하게 해당 업무를 수행할 수 있는 능력이 충분한 사람들의 모임.

- 상호간 업무수행에 있어서 친화력(affinity)이 있을 것.

- 핵심가치를 달성하기 위하여 충분한 자격(competent)을 가질 것

- 팀의 공동문화에 대한 이해와 지지

- 리뷰는 각각의 일정에서 가장 높은 우선순위로 처리하는 태도

- 핵심가치의 달성이라는 목표의 업무안에서는 자체적인 활동

- 중앙집중형 의사결정이 아니라 팀에 의사결정 권한을 분산하고 결과에 대한 책임도 공유

- 개개인은 문제해결을 위하여 능동적인 대응


최근에는 운영방식을 좀 변경했는데 최종결정을 내리는 의사결정프로세스를 명확하게 하여 팀원의 책임을 덜어주면서

팀원들이 능력을 최대한 발휘할 수 있도록 독려하는 형태를 유지하려고 하고 있습니다.


모든 일을 잘하는 슈퍼개발자를 원하는 것은 아니지만 분석, 설계, 코딩, 테스트, 배포를 할수 있는 스크럼 팀원이 다수 있어야 하는데 자원의 확보(항상 팀원이 부족합니다 ㅎㅎ)부터 교육이나 인적자원 관리 등의 이슈가 많아서 팀 리딩이 어려운것은 여전합니다. 하지만, 팀원들이 모두 잘 따라주어서 예전 보다는 훨씬 나아졌으니 앞으로 점점 좋아질거라고 믿습니다.






비트앱센터에서 어제 저녁 “Scrum 네~ 이놈!” 이라는 제목으로 세미나가 있었다. 
아마도 제목을 보고 많이들 신청하지 않았을까?

서둘러 간다고 했지만 저녁시간이라 배고픔을 참지 못하고 버거킹에 들러서 약간 늦었다.
(참석하는 예의상 그러면 안되지만 참을 수 없는 허기 ㅋㅋ) 

강사분은 현업에서 오랫동안 해오신듯 했지만 어떤분인지는 잘 모르고  그냥 강사 약력을 보고 참석했다.
외국에서 스크럼과 관련한 몇가지의 인증을 획득한것을 보니 뭔가 다른 이야기가 있지않을까 하는 생각에서 참석했다.



주요한 내용)
1. 현업에서 경험한 많은 고민거리들에 대한 자신의 생각
2. 스크럼에 대한 설명
3. 스크럼을 적용하는 데 가장 중요한 것은 무엇인가

많은 좋은 이야기를 들었지만  스크럼만으로 모든것을 해결하려는 태도보다는 기존의 전통적인 방법론에 대한 이해와 사람과 프로젝트에 대한 이해가 필요하다는 이 그림이 강의의 핵심인것 같다. 



돌아오는 길에 나는 몇가지의 생각을 했다.

1) 예상보다 더 많은 자료를 보니 많은 준비를 하셨구나. 짝짝~
2) 주의 집중을 위해서 마술도 하는 준비성 깜놀. 짝짝~
3) 마지막에 보여준 '박이사와 박봄'은 대중의 기호를 무시한 듯 ㅋㅋ
 
처음에는 스크럼에 집중했지만 점차 시간이 지날수록 사람에 집중하게 되는 이야기를 하는데
나도 겪고 있는 이야기를 들어서인지 고개가 끄덕여지더라.

우리 주변에서 자꾸 이런 강의가 많아지는 것은 즐거운 일이다.  
세상이 점점 좋아지고 있다. 
어제는 Agile Korea 컨퍼런스가 열렸습니다.

늦잠을 잔 덕분에 서둘러서 출발했지만 상암동은 내게 너무 먼 거리. 도착해서 들어가니 Ice Breaking 이 진행중이었습니다. 얼른 테이블의 종이를 챙기고 진행했습니다. 같이 참석한 분은 참석자들이 낄낄거리며 인사하는 모습을 보고 일번적 컨퍼런스와 다른 그 분위기에 좀 놀라는 모습이었습니다.



애자일의 첨병으로 활동하는 김창준님의 키노트는 많은 생각을 하게 했습니다.
애자일의 약점이라는 주제로 실제 프로젝트에서 저도 느끼고 있던 느낌들을 이야기하더군요.

1) 애자일은 사회적 측면이 중요하지만 신뢰를 구축하기 위해서 좋은 방법이 없다. 따라서 긍정심리학, 코칭등의 추가적인 준비가 필요하다. 애자일기법만으로는 부족하다.

2) 외부 팀과의 폐쇄적인 운영으로 인하여 팀 스스로 잘되고 있는것처럼 생각하기 쉽다. 번다운차트를 떨어뜨리는 것을 목표로 스프린트를 완성하는 단기피드백에 너무 치중하기보다는 외부와의 교류를 통해 팀의 단점을 들여다보고 개선해가야 한다. 애자일은 장기전이다.

3) 애자일은 사람에대한 도메인을 다루고 있다. 사람에 대한 도메인은 복합적 요소를 가진 영역이므로 베스트프랙티스를 맹목적으로 따르는것은  도움이 안되며, 유연성이 중요하다. 행복한 가정일수록 패턴이 다양하다는 연구도 있음.


외부에서 구경하기 힘든 여러가지 애자일사례를 만날 수 있었고, 특정 주관사가 아니라 많은 자원봉사자의 자발적인 참여로 만들어진 행사라서 더욱 뜻깊었네요 열심히 준비해주신 분들에게 감사를 드립니다.

<득템한 멋진 플래닝포커>
어제 지인과 식사도중 개발자의 실력에 대한 안철수씨의 강연내용 이야기가 나왔습니다. (이런 주제를 이야기 할 수 있는 지인이 있다는건 참 행복한 일이죠)

“현대는 한 사람의 천재가 모든 것을 할수 있는게 아니라 한 사람이 못할 일을 여러 전문가가 함께 모여 만들어가는 시대다”며 “전문가의 실력은 전문 지식 곱하기 커뮤니케이션 능력이다”

Source : “고단한 SW개발자 생태계, 그래도 희망은 있다” - http://goo.gl/i12Z7

전문지식 곱하기 커뮤니케이션 능력이 실력이라니~
개발자는 제대로된 기능을 만들기도 벅찬데, 커뮤니케이션 능력도 배양해야 한다니 쉬운일이 아닙니다.
게다가 현업에서 보면 A개발자와 B영업간에 "뭔 말이 통해야 말을하지~" 하는 푸념을 종종 듣습니다.
하지만, 대부분의 개발자는 자신이 커뮤니케이션 능력이 부족하다고 생각하지 않습니다. 상대방이 논리가 빈약하고 실체가 없는 모호한 대화방식이 아니라, 좀 다른 대화방식으로 이야기하기를 바라는것 뿐이죠 :-)

그럼 개발자와 대화를 이끌어내기 위해서는 어떻게 해야할까요?

얼마전 트위터에서 웃음을 자아냈던 공대생 남친 관리법(http://goo.gl/qvBUC)에서도 보이듯이, 개발자는 개발자스러운 대화방식으로 접근해야 커뮤니케이션이 가능합니다. 개발자는 자신이 이해가능한 합리적인 결과물에 대해서는 큰 이견을 제시하지 않는다는 특성을 가지고 있죠. 꼭 개발자가 아니라도 합리적 내용물을 기반으로 이야기하면 쉬운 대화가 가능합니다.

제 생각에 개발자와 대화하기 가장 좋은 방법은 애자일 실천법 중 하나인 CTIP(Continuous Test & Intergration Platform) 라고 생각됩니다. 지난 몇년간 Agile 기법에 대한 학습과 현업에서 적용결과, 저는 애자일의 핵심이 사람과의 소통인것을 얼마전에야 깨닫게 되었습니다.

혼자 개발하는 문화에 익숙한 개발자는 무엇인가 함께 만들어야만 하는 상황을 만나면, 구성원간 커뮤니케이션에 어려움을 겪습니다. 이때 CTIP를 통한 정적분석도구를 활용한 결과물과 코드커버리지, 그리고 이슈관리도구를 통하여 문제점을 가시화하고 합리적 결과에 기반한 개발자와의 대화를 시도하면 SW개발자와의 쉬운 대화가 가능합니다.

저는 SW개발의 생산성을 향상시키기 위한 최선의 방법은, 좋은 개발문화를 형성하여 개발자간 커뮤니케이션능력을 배양하고, 협업을 통한 시너지가 창출될 수 있도록 유도해주는 것이라고 생각합니다.


Source : 2011 한국소프트웨어 아키텍트 대회
<지속적 테스트와 통합을 위한 SW개발 아키텍처>


<이슈관리시스템을 통한 문제제기>


<위키를 이용한 문서협업>




<SW개발을 위한 공개SW 기반의 지속적 테스트와 통합 아키텍처>


그리고, Agile 2011 Conference가 8월6일 열린다고 합니다. http://pragmaticstory.com/1776 에 트랙에 대한 설명을 해주셨네요. 언젠가는  가 볼 기회가 있겠죠?  :-)


실용주의 프로그래머.
몇년만에 다시 보게 되었는데, 다시 읽어보아도 참 주옥같은 문구가 가득한 책입니다.
어떤 언어를 사용하시던지, 반드시 읽어보시면 좋은 책이라고 생각됩니다.
아직 안보신 개발자분은 꼭 필독하시기를 강추!!!

실용주의_프로그래머

출판사에서 제공하는 목차
http://insightbook.springnote.com/pages/275777

실용주의 프로그래머의 70개 Tips
http://goo.gl/W1Or5

+ Recent posts