강제로 스크럼 하기~

[주넥]

제목이 참 애자일 스럽지 못한듯 합니다.

제가 지난 2008년 봄에 애자일을 접한 뒤, 팀에 애자일을 정착시킬려고 나름 노력했는데요.
결과적으로 참 쉽지 않더군요.

가장 어려운 점은 팀원들로 하여금 SCRUM에 애정을 가질 수 있도록
열정을 유지시키는 것이었습니다.

일에 바빠 쫓기다 보면 무질서하게 닥치는 데로 일할려고하는 습성들이 나타나게 되더군요.

마치 어렸을 때 방학을 맞이 하여 멋있게 계획표를 작성하고 벽에 붙여두는데,
첫 1주일은 잘 지켜지는듯 하다가 시간이 갈수록 잘 지키지 못하게 되는 것과 같은 현상...

총 20여명의 팀원들이 있는데, 이를 3개팀으로 나누어 운영 중입니다.

이 중 한팀은 비교적 SCRUM이 잘되는 편인데,
나머지 2팀은 자꾸 SCRUM이 무너지더군요.

그래서, 고민하다 택한 것이 "강제로라도 스크럼을 하자" 는 것이었습니다.
스크럼을 하면 좋은 점을 스스로 알고 해야겠다는 자발적인 열정이 생기지가 않는다면,
강제라고 꾸준히 하다 보면 습관화되겠지... 라는 생각이었지요.

이러한 생각을 가지고 우선 SCRUM을 강제시킬 툴을 찾았습니다.
예전에 이 mailing list를 통해 tool을 한번 search해본 적이 있었지요.
그때 누군가가 BaseCamp를 추천해주었구요...
http://basecamphq.com/
이 툴이 simle하면서 좋기는 한데, 웹 서비스 형태로 월 사용료를 지불해야하고,
scrum기록들이 원격 db로 남게되고,
서비스를 연장하지 않으면 계정이 close되면서 그간 기록들이 날라가게되구요.

그래서, 찾은 것이 collabtive라고 basecamp를 benchmarking해서 만들 툴입니다.
http://sourceforge.net/projects/collabtive/

task가 지원되는데 각 task에 estimate를 기록할 수 없어서
기록할 수 있도록 수정하고 BDC 그리는 기능을 추가하는 등
저희 scrum에 맞게 이를 직접 수정해서 사용하게 되었습니다.

이툴의 경우 본인이 한 업무를 일일이 하루 24시간 기준으로 몇시 부터 몇시까지
무엇을 했는지 기록하도록 되어 있어서
한편 생각하면 강력한 감시도구라서, 툴의 도입 시 감시의 목적이 아님을
수차례 팀원들에게 강조하고 설득하였구요.

툴의 사용 목적을 SCRUM에서 계획 게임과 마찬가지로
주기 시작에 주기에 할 업무들을 나열하고 계획한 후,
task가 끝났을 때 collabtive tool에서 close를 할 때의
쾌감을 자꾸 즐기라고 강조하였습니다.

이제 툴을 강제 사용한지 한 6개월이 흘렀습니다.
어찌되었건 팀원들이 마지 못해서 하든 어쨌든
습관적으로 주기 계획회의를 하고 툴에다 주기에 할 업무들을 기록하고 있습니다.

강제로 툴을 도입하면서 느꼈던 것은
열심히 공부하면 인생이 편해짐을 부모님들이 알고
자식들에게 공부해라 공부해라 하는 느낌입니다.
애자일을 도입하여 정착되고 성공하면,
업무 처리 방식이 수동적에서 능동적으로, 마구잡이식에서 계획적으로 바뀌면서
즐거워질 수 있는데, 자꾸 안할려고 하니, 해라해라 하는 느낌이라고 말해야할까요?

부모님들이 항상 생각하시지요...
스스로 동기를 가지고 알아서 열심히 하면 얼마나 좋을까~

[대량]

"감시의 목적이 아님을
수차례 팀원들에게 강조하고 설득...."

제 경험으로는 Agile은 형식이 아니고 마음가짐입니다.
XP가 아닌 SCRUM은 더욱 그러합니다.
그리고 변화는 감동에서부터 발생합니다.
특히 스크럼은 생산성에 집중하게 하는 프로세스인데, 생산성은 결국에 개인의 생활습관(생산성)이 바뀌지 않으면 아무것도 얻어지는
것이 없습니다.
얻어지는 것처럼 보일 수 는 있느나 문제상황이나, 급박한 상황에 닥치면 이전의 행태로 돌아가게 됩니다.

조금 기다리고, 느리게 가더라도, 자발적 마음을 가지게 하지않으면 이전의 '프로젝트 관리기법'으로 돌아간다고 생각합니다.
저는 이런 방식으로 2-3개의 프로젝트를 성공적으로 진행 또는 완료하였습니다.

다른분들의 의견도 듣고싶군요.

On 7월9일, 오후2시56분, 주넥 <june...@gmail.com> wrote:
> 제목이 참 애자일 스럽지 못한듯 합니다.
>
> 제가 지난 2008년 봄에 애자일을 접한 뒤, 팀에 애자일을 정착시킬려고 나름 노력했는데요.
> 결과적으로 참 쉽지 않더군요.
>
> 가장 어려운 점은 팀원들로 하여금 SCRUM에 애정을 가질 수 있도록
> 열정을 유지시키는 것이었습니다.
>
> 일에 바빠 쫓기다 보면 무질서하게 닥치는 데로 일할려고하는 습성들이 나타나게 되더군요.
>
> 마치 어렸을 때 방학을 맞이 하여 멋있게 계획표를 작성하고 벽에 붙여두는데,
> 첫 1주일은 잘 지켜지는듯 하다가 시간이 갈수록 잘 지키지 못하게 되는 것과 같은 현상...
>
> 총 20여명의 팀원들이 있는데, 이를 3개팀으로 나누어 운영 중입니다.
>
> 이 중 한팀은 비교적 SCRUM이 잘되는 편인데,
> 나머지 2팀은 자꾸 SCRUM이 무너지더군요.
>
> 그래서, 고민하다 택한 것이 "강제로라도 스크럼을 하자" 는 것이었습니다.
> 스크럼을 하면 좋은 점을 스스로 알고 해야겠다는 자발적인 열정이 생기지가 않는다면,
> 강제라고 꾸준히 하다 보면 습관화되겠지... 라는 생각이었지요.
>
> 이러한 생각을 가지고 우선 SCRUM을 강제시킬 툴을 찾았습니다.
> 예전에 이 mailing list를 통해 tool을 한번 search해본 적이 있었지요.

> 그때 누군가가 BaseCamp를 추천해주었구요...http://basecamphq.com/

> 이 툴이 simle하면서 좋기는 한데, 웹 서비스 형태로 월 사용료를 지불해야하고,
> scrum기록들이 원격 db로 남게되고,
> 서비스를 연장하지 않으면 계정이 close되면서 그간 기록들이 날라가게되구요.
>

> 그래서, 찾은 것이 collabtive라고 basecamp를 benchmarking해서 만들 툴입니다.http://sourceforge.net/projects/collabtive/

[Chungha Yun]

"이툴의 경우 본인이 한 업무를 일일이 하루 24시간 기준으로 몇시 부터 몇시까지
무엇을 했는지 기록하도록 되어 있어서"

팀장님으로써 위의 기록들이 감시가 아닌 어떤 의미 혹은 목적이 있는지 알고 싶습니다.^^

2010년 7월 11일 오후 5:26, 대량 <wild...@hanmail.net>님의 말:

--
Chungha Yun
blog : http://sozu.tistory.com

[Jeong Soo Park]

2010년 7월 12일 오전 9:14, Chungha Yun <chu...@gmail.com>님의 말:

"이툴의 경우 본인이 한 업무를 일일이 하루 24시간 기준으로 몇시 부터 몇시까지
무엇을 했는지 기록하도록 되어 있어서"

팀장님으로써 위의 기록들이 감시가 아닌 어떤 의미 혹은 목적이 있는지 알고 싶습니다.^^

저도 고민하고 있던 사항이라서 제 생각을 말씀드리려고 합니다.

제가 위의 내용을 봤을 때는, '해야할 일 목록'을 정보방열판처럼 공유하는 것과, 자신이 오늘 하루 어떤 일을 '했는지' 기록하는 것으로 이해가 되고, 그에 대해 가지고 있던 생각들을 써볼까 합니다.

팀장으로서 팀원들의 업무를 조망할 때, 아쉬운 점들이 눈에 띄곤 합니다. 이런 것들을 예측과 측정으로 해소할 수 있지 않을까 평소에 생각하곤 합니다.

'해야할 일'을 공유하는 목적

내 업무 뿐만이 아니라, 다른 사람들의 업무를 잘 살펴서, 팀 내에서 내가 하고 있는 업무가 어떤 위치이고, 어떤 사람과 어떤 관계가 있는지, 팀장이 지시한 단위 업무 사이 사이에 있는 간극을 잘 살펴주기를 팀원들에게 바라곤 합니다. 그러기 위해서는 팀 전체의 '해야할 일 목록'이나 due date, estimated time 등이 투명하게 공유되는 것이 좋다고 생각하고, 내 업무가 어떤 맥락에서 이루어지는지 알리는 측면에서 공유하는 것이 필요하다고 봅니다.

'오늘 한 일'을 기록하는 목적

Project management tool에서의 기록과 약간 차이점은 있을 수 있겠지만, 저는 팀 내에서 개발 저널을 쓰게 할까 생각을 계속 해오고 있습니다. 반발이 있을까 하고 아직 시행은 하고 있지 못하지만요. 그런 필요를 느끼게 된 배경은 다음과 같은 것들이 있습니다.

팀원들 각자가 터널 현상에 빠지는 경향을 보곤 합니다. 한 문제에 몰두해서 몇시간 동안 끙끙대는데, 옆에서 보면 간단한 것들인거죠. 또는 터널 현상에 빠지지는 않았지만, 스펙을 바꾸면 더 쉽게 해결할 수 있었던 경우 등 여러 비효율들을 옆에서 보면서 발견하곤 합니다. 그렇다고 그것들을 일일이 옆에서 지적을 해주면, 시어머니 리더십의 악영향이 나타나게 되는 것 같습니다. 수동적이거나 방어적으로 되는거죠. 

저널을 쓰면, 이렇듯 각자 개인 회고의 목적을 달성할 수 있지 않을까 하는 생각이 들었습니다. 간단히 내가 쓴 시간을 정리하는 것만으로도 '아 내가 이 일에 이렇게 시간을 많이 썼었나?' 하는 것을 발견할 수 있지 않을까 하고 말이죠. 

프로젝트 관리 도구에서 제공하는 기능의 목적은 약간 다를 수도 있겠습니다만..

--
Name | Jeong Soo, Park
Blog | http://toracle.egloos.com
Twitter | http://twitter.com/toracle
PGP ID | 0x375E3DA4
Fingerprint | 2586 C3E7 6589 1CBC 8B04 A308 8932 145F 375E 3DA4

[Steve Yoon]

안녕하세요? 윤경록입니다.

얼마 전에 신규입사자 교육에 다녀왔습니다. 그 동안 고만고만한 회사에만 다녀서 이런 교육은 처음 받아보았는데요. 무척 즐겁고 유용했던 것 같습니다.

그 교육 시간 중에 '열정'에 대한 이야기가 나와서 제가 질문하고 답변받은 내용을 공유할까 합니다.

Q1: 야동을 아내와 함께 보는데 저만 발그레 하는 것 같습니다. '열정'은 어떻게 하면 전파할 수 있을까요?

A1: 열정은 저절로 전파됩니다. 만약 주변 사람들이 열정적이지 않다고 느끼셨다면, 본인의 열정이 부족하다고 생각해 보시는건 어떨까요.

Q2: 야동이 40분짜리인데 저는 언제나 처음 3분 밖에 못 봅니다. '열정'은 어떻게 하면 지속할 수 있을까요?

A2: 은근과 끈기. 참는 수 밖에 없습니다.

아쉽지만, 시간이 없어서 묻지 못한 것이 있습니다.

Q3: 일주일 내내 야동을 보면 너무 피곤해서 다음 주 동안 일도 못 합니다. '열정'에 의한 피로(burn out)는 어떻게 해결해야 할까요?

주넥님께서 던지신 화두와 맥락이 통하는 것 같아서 글을 이어봅니다.

그럼 이만 줄입니다.

윤경록 드림

[주넥]

On 7월12일, 오전9시14분, Chungha Yun <chun...@gmail.com> wrote:
> "이툴의 경우 본인이 한 업무를 일일이 하루 24시간 기준으로 몇시 부터 몇시까지
> 무엇을 했는지 기록하도록 되어 있어서"
>
> 팀장님으로써 위의 기록들이 감시가 아닌 어떤 의미 혹은 목적이 있는지 알고 싶습니다.^^
>
>

팀장인 저도 20여명의 팀원들의 업무를 파악하고 이를 정리해서 다시
임원인 연구소장님에게 보고를 해야 합니다.

이것은 통상 어느 회사든 간에 있는 관리의 일반적인 형태이겠지요.

팀원들의 업무 기록은 제가 열람하여
업무 내용 파악과 정리등을 위한 관리 자료로 활용됩니다.

감시와 관리와의 차이점이 뭘까요? ^^;;;

저는 팀원들에게 time tracking을 해서 무었을 했는지 적을 때,
소감이나 하면서 느꼈던 점, 개선 점 등도 적어서
다른 사람들과 공유될 수 있는 기록으로 나중에 본인이 다시 뒤져서
도움이 될 수 있는 기록으로 남기라고 하는데, 잘 안되더군요...

00시 ~ 00시 까지 뭘 했다. 정도로 ... 간략해지더군요.

[sMiLo]

2010/7/12 주넥 <jun...@gmail.com>

감시와 관리와의 차이점이 뭘까요? ^^;;;

어떤 체계에 의해서 팀원들이 부정적인 감정(예를 들어, 불쾌감?)을 느낀다면 감시겠고,
긍정적인 감정(예를 들어, 만족감?)을 느낀다면 관리가 아닐런지요.

그리고 대량님이 말씀하신대로 개인의 생활습관이 가장 중요한 것 같습니다.
강제적으로 도입하기 보다는 개인이 스스로 변화하게끔 유도하는게 좋지 않을까요?
시간이 많이 걸리려나요? ^^

업무 보고 형식을 자유롭게 하되 꼼꼼하고 꾸준히 작성하는 팀원에게는 보상을 해주는건 어떨런지요.
고과에서 + 점수를 준다던가 아니면 주기적으로 선물을 준다던가 하는 식으로요.
분기별로 우수 팀원의 업무 보고 파일을 팀원들과 공유함으로써 서로서로 자극을 주어
참여를 유도하는 것도 좋을 것 같습니다.

[진선생]

주제와 관련 있는 이야기는 아니지만 저희는 targetprcess 라는 툴을 사용합니다.

http://www.targetprocess.com/

릴리즈/ 이터레이션 계획부터 태스트 관리 + 버그트래킹까지 하나에 쑤셔넣은 툴이라 있을 기능은 다 있지만...
있을 기능이 다 있다보니 복잡한 감이 좀 있습니다.
설치형 형태로 5인까지 무료로 사용 가능하니 5인 이하 프로젝트에서는 도입해볼만 할 것 같습니다.

(... 하지만 툴이 일을 시켜주지는 않더군요... 계속 시행착오를 거쳐가며 일을 하고 있습니다. ㅠ_ㅠ)

On 7월9일, 오후2시56분, 주넥 <june...@gmail.com> wrote:

> 제목이 참 애자일 스럽지 못한듯 합니다.
>
> 제가 지난 2008년 봄에 애자일을 접한 뒤, 팀에 애자일을 정착시킬려고 나름 노력했는데요.
> 결과적으로 참 쉽지 않더군요.
>
> 가장 어려운 점은 팀원들로 하여금 SCRUM에 애정을 가질 수 있도록
> 열정을 유지시키는 것이었습니다.
>
> 일에 바빠 쫓기다 보면 무질서하게 닥치는 데로 일할려고하는 습성들이 나타나게 되더군요.
>
> 마치 어렸을 때 방학을 맞이 하여 멋있게 계획표를 작성하고 벽에 붙여두는데,
> 첫 1주일은 잘 지켜지는듯 하다가 시간이 갈수록 잘 지키지 못하게 되는 것과 같은 현상...
>
> 총 20여명의 팀원들이 있는데, 이를 3개팀으로 나누어 운영 중입니다.
>
> 이 중 한팀은 비교적 SCRUM이 잘되는 편인데,
> 나머지 2팀은 자꾸 SCRUM이 무너지더군요.
>
> 그래서, 고민하다 택한 것이 "강제로라도 스크럼을 하자" 는 것이었습니다.
> 스크럼을 하면 좋은 점을 스스로 알고 해야겠다는 자발적인 열정이 생기지가 않는다면,
> 강제라고 꾸준히 하다 보면 습관화되겠지... 라는 생각이었지요.
>
> 이러한 생각을 가지고 우선 SCRUM을 강제시킬 툴을 찾았습니다.
> 예전에 이 mailing list를 통해 tool을 한번 search해본 적이 있었지요.

> 그때 누군가가 BaseCamp를 추천해주었구요...http://basecamphq.com/

> 이 툴이 simle하면서 좋기는 한데, 웹 서비스 형태로 월 사용료를 지불해야하고,
> scrum기록들이 원격 db로 남게되고,
> 서비스를 연장하지 않으면 계정이 close되면서 그간 기록들이 날라가게되구요.
>

> 그래서, 찾은 것이 collabtive라고 basecamp를 benchmarking해서 만들 툴입니다.http://sourceforge.net/projects/collabtive/

[심우곤]

주넥 님 안녕하세요~ ^^

팀을 변화시키는 방법은 여러 가지가 있고, Top-down 식 강제적 방법도 한 가지 방법이긴 합니다.
스스로 잘 하기까지 인내하고 계속 지원하는 것이 쉽지 않고..
회사 차원에서도 언제까지 그냥 방치하고 있을 수는 없기 때문입니다.

특히나 2 년 정도 지켜보시다.. 더 이상 이 방식으로는 안되겠다고 생각하셨기 때문에
이런 처방을 내리셨을 것이라 생각하고 공감합니다.

정답은 없습니다.

하지만, 부모의 마음으로 자식이 공부안한다고 기숙학원에 보내고
독서실과 학원에 강제적으로 보내면 *얼마간* 은 잘 따라오는 것 같지만
결국 공부에 흥미를 잃고 공부하는 흉내만 내게 됩니다.

경험해 보셔서 아시겠지만, 막 공부할라고 하는 참에 부모님께서 "공부 좀 하라"고
하면 반발심이 생기면서 공부하기가 확 싫어지듯이 말이죠.

1. 팀 스스로가 느끼도록 해야 합니다.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

대량 님께서 말씀하신 대로 자발적인 마음이 아니고서는 지속할 수가 없습니다.

제가 아는 팀장님도 본인 주도로 Scrum 과 Agile 프랙티스를 팀에 뿌리내리려고
부던히 애를 썼지만 잘 안됐다는 이야길 들었습니다.

팀장이 뭔가를 팀원들의 동의없이 추진하게 되면, 관리적 용도나 개발 속도를
떨어트리는 장애물로 밖에는 인식되지 않습니다.

그러면 결국 반발심에 성공은 먼 나라 이야기가 될 가능성이 큽니다.

팀은 스스로 문제를 해결할 수 있는 공동체입니다.
팀을 믿고 팀이 처한 장애물을 해결하는데 팀장이 노력한다면,
팀장의 진정성이 받아들여 질 것이고 그들 스스로 변할 것입니다.

최근에 "섬기는 리더십" 이 바로 이러한 믿음으로 언급되는 것이겠지요.

단 기간에 내가 원하는 모습으로 팀을 바꾸시기 원하십니까?
내가 원하는 모습은 아니지만, 장기적으로 그렇게 스스로 변화하려는 팀을 원하십니까?

2. 시스템 보다는 습관이 중요
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

문제는 스크럼도 그렇고 모든 활동이, "기존에는 하지 않던 활동" 일 것입니다.
정보 방열판을 쓰더라도, 원래 안하던 사람들에게는 부가작업으로 받아들여집니다.

하지 않던 활동이 익숙해지지 않은 상태에서 시스템을 들이밀면 요식행위로
전락하게 되거나, 시스템이 버려지게 되는 경우를 많이 봐왔습니다.

어느 정도 활동이 습관화 되기 전에 시스템을 도입하지 않으셨으면 합니다.

자발적인 의도에서 시스템을 사용하는 팀은,
"시스템이 이런 기능도 제공해줄까?" 하고 극대화하는데 집중합니다.
하지만 억지로 떠밀려서 시스템을 사용하는 팀은,
"이것만 하면 되겠지?" 하고 활용을 최소화하는 쪽으로 가게 되고
심지어 시스템을 간파하고 나면 "거짓 데이터" 를 입력하기도 합니다.

3. 잘 하고 있는 팀에 집중하세요.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

팀장이 아닌 팀원들의 이야기가 그들에게는 더 설득력이 있습니다.
잘하는 팀이 좋다고 이야기 하는 것이 효과가 더 크다는 것이죠.

하지만 나쁜 소문은 금새 퍼질 뿐더러 팀 전체에 악영향을 미치게 됩니다.
하기 싫은 팀일 수록 그 소문을 빨리 많이 퍼트립니다.

팀 전체가 건강한 상태를 유지하고 싶으시다면,
잘하고 있는 팀이 더 잘할 수 있도록 하시는 편이
팀 전체를 위해서도, 주넥 님의 정신건강을 위해서도 좋을 것 같습니다.

너무 원론적인 이야기를 한 것 같습니다. ^^

주넥 님의 접근도 필요하다고 생각합니다. 다만 시점의 문제겠지요.
나중에 경험을 함께 공유해 주셨으면 합니다. :-)

[주넥]

앞서 팀을 3개의 Sub팀으로 나누었는데 1팀이 잘된다고 했는데...
이팀은 툴을 적용하고 있지 않습니다.

알아서 스스로 Excel파일을 이용해서 BDC뿐 아니라 스크럼관리를 잘 하더군요.

그럼 잘되는 Sub팀과 안되는 Sub팀의 차이는 뭘까 해서 살패보니,

먼저 사람의 성향이 중요하구요.
스크럼의 필요성을 알고,스스로 열정을 가지고 노력하는 사람들이 과반수를 넘구요.

그다음 중요한 것이 일의 성격입니다.

현장에서 스크럼을 적용해보니,
스크럼이 팀 관리 툴이라기 보다 프로젝트 관리 툴이라는 느낌이 강하게 오더군요.

즉, 프로젝트가 발생하고 프로젝트를 위해서 팀이 구성되구요.

해당 프로젝트가 완료되기 전까지는
팀내에서 팀원들에게 다른 업무의 인트럽트가 적게 걸리고
해당 프로젝트에 집중할 수 있다면, 스크럼이 잘 working하는 편인듯 합니다.

하지만 이미 통상 팀은 존재했고
이미 다양한 성격의 업무들을 수행하고 있으며,
팀원들간에 맡은 업무들이 파티션 되고 고정되어 있어서
서로 간에 공유가 잘안되어 있는 경우,
이미 판매한 제품의 유지 보수등으로 영업이나 고객 지원으로부터
적지않게 수시로 대응 요청에 반응적으로 업무를 해야하는 것이
많이 발생하는 경우에는 스크럼 도입이 많이 어렵다는 것입니다.

사실 서로간의 업무에 관심을 가지고,
누가 어떤 업무를 맡던 해낼 수 있는 cross functinality가 확보된 상태에서는
스크럼 운영이 비교적 쉽지만 이미 업무가 파티션이 되어 있는 경우,
그리고 이것이 cross functional해지기란 상당히 쉽지 않더군요.
(꾸준이 pair 를 해보라고 하고 pair matrix 라는 챠트로
얼마나 pair를 했는지 통계를 내고 목표치를 상향해서 진행하라고 했지만,
시간이 지나서 보면 허지부지 되어 있더군요.)

그리고, 대외 요청 업무, 즉 interrupt가 상당 부분 있는 경우,
이를 뺀 나머지 업무들로 계획적으로 스크럼을 진행하고,
interrupt업무 양을 계속 통계를 내고,
계획된 업무들의 팀 속도를 통계를 내어 그만큼만 계획해서하라고
계속 유도했지만, 결국 팀이 인터럽트 성의 업무가 반정도가 되면
자꾸 스크럼을 방해하는 엄청난 요소가 됩니다.
물론 인트럽트 업무를 1주기만을 밀고 일을 해보자고 계속 유도하였지만,
영업적인상황, 심리적인 상황등을 포함해서 쉽지 않더라구요.

그다음 잘되는 팀과 잘안되는 팀에 큰 차이 가
회고를 잘하고 있는 팀인가 하는 부분입니다.
회고를 잘하는 팀은 스스로 문제 해결을 위한 열정과 추진력을 얻게 되는데,
회고활동 자체가 허지부지 해져 버리구요.

주기 계획 활동은 하나 계획된 업무 진행에 대한
백로그 관리가 허지 부지 하게 되어서
제가 업무 파악하기가 쉽지 않아지더군요.

일단 툴을 도입한 현재 제 심정은
툴로 업무를 계획하고 업무 수행을 tracking하면서 업무 수행 완료 후
Open된 task를 Close하면서, 계획적인 업무 수행에 대한 즐거움을 팀원들이 느끼기를 바라는데,
뭐 화이트 보드 상에서 백로그로 했을 때 백로그를 Doding에서 Done으로 옮기면서
즐거움을 느끼지 못한 팀원들이 툴을 강제적으로 사용하면서 마지 못해서 하다 보면
느끼게 되지 못할 수도 있을 것 같은 느낌이 드네요.

그렇게 되면 툴이 그냥 저를 위한 팀 관리 툴로 전락하고 말겠지요.
그래도 개인적으로 BaseCamp같은 이러한 툴이 전통적은 MSProject와 같은 PMS보다는 낫다는 생각이 듭니다.

[주넥]

한가지 더 첨언 하자면,
제가 화두에서도 이야기했듯 툴 도입하면서 기대했던 것은 강제적용을 통한 습관화 입니다.

현재 저희 팀 내에서 스크럼 프랙티스중에 지금은 습관화 되어서 그마나 계속 이행되고 있는 것이
한가지 있다면 아침,저녁 기립회의 입니다.

이것은 허지부지 되지 않고 계속 하게 되더군요.
그래서 생각했던 것이 어떻게든 습관화 시켜보자는 것이었습니다.

아예 스크럼을 하지 않는 것 보다,
툴로 강제하여 스크럼을 기계적으로라도 하다 보면 몸에 배지 않을까 하는 것입니다.

공부를 아예 하지 않는 것 보다,
강제라도 학원들에 보내시 시킨다고 하면 옳은 비유인지 모르겠네요~

일단 한 1년 툴로 강제 적용 시키다가
현재 잘하고 있는 팀 처럼 다시 Excel파일을 이용한 자율 관리를 해보라할까 합니다.

[Chungha Yun]

인터럽트가 많은 경우에는 스크럼을 적용하기가 매우 어려운것 같습니다. (저도 경험상..)

말씀하신데로 war-room 상황에서 가장 어울리다고 생각합니다. (물론 war-room에서도 인터럽트는 발생합니다.)

예전 팀에서는 인터럽트 대응에 대한 해결책을 제시해봤지만 말씀하신데로 영업적인 상황 등으로 인해 (대부분 유지보수 업무라서..) 하지 못했었습니다.

얼마전에 다녀온 세미나 에서는 이러한 인터럽트에 대응하기 위해 스크럼+칸반(간반이라고 읽으시던데..뭐가 맞나요? 칸반 게임이랑은 또 뭐가 다른건지;;)을 시도하고 있다고 합니다.

스크럼의 장점인 데일리 스크럼, 스토리, 회고등과 함께 칸반의 요소(lead-time 측정, work-flow 제한 등)를 결합한 방법을 시도중이라고 합니다.

항상 개선하고자 고민하시는 모습을 보면 곧 팀원들도 따라올꺼라 생각됩니다.^^

2010년 7월 12일 오후 6:22, 주넥 <jun...@gmail.com>님의 말:

[듬뿍]

저도 "강제로" 도입을 했습니다.
도입하기 전에 저희 조직은

1. 이슈트래킹시스템을 쓴 지 5년이 넘었고, (레드마인씁니다.)
2. 형상관리와 이슈트래킹시스템을 연동하여 사용한지도 5년이 되었고
3. 거의 2-3 단위로 새로운 릴리즈를 내보내는 상태였습니다.

이미 겉모습은 스크럼을 닮아있었습니다.

그래서 스크럼을 도입하게 되면 매우 잘 될 것으로 판단을 했습니다.
실상은 그렇지 않았구요. 차라리 알아서 2-3 단위로 릴리즈 할때가 더 편했다고 회고를 하는 직원들도 있었습니다.

저는 언급하신 시스템을 도입하는 것을 고민했지만, 매우 조심스러워서 먼저 풍토를 만들고 필요하면 그때 시스템을 도입하자고
했습니다. 청하님 블로그에 보니까, 아예 시스템도 없어지고 아날로그로 바뀌었다는 것을 본 적이 있는데, 저희의 경우도 그런 것
을 주장하는 팀원이 일부 생기고 있습니다. (비주얼을 강조하는 거!)

다행히 저희의 경우에는 "일단 해보자!" 하는 분위기가 있어서 도움이 될까 하고 간단하게 몇 자 올립니다.

1. 시간단위로 뭘 했는지는 저희 같은 경우에도 입력이 되도록 하였습니다. 그러나, 그것으로 체크를 하지 않았습니다.
이것의 목적을 "추정시간을 X로 잡았는데, 실지로 X가 걸렸는지 Y가 걸렸는지를 서로 회고"하기 위한 수단으로만 사용했습니다.
언제 뭘했는지는 쓰지 않구요. 그 일에 얼마를 사용했는지만 기록하는 방식입니다. (레드마인이 이 기능을 제공해주고 있습니다.)
이것을 잘 활용하면, 번다운차트를 만들 수 있는데, 번다운 차트를 주단위로 그려서 서로 보고 평가를 했습니다. 이것도 압박의 수
단으로 활용하지는 않았습니다.

2. 데일리미팅 때, 당연히 시간단위의 보고는 없고 한일, 남은일을 문제점의 형식으로 보고하는데, 처음엔 매우 형식적이어서 자신
의 문제를 잘 털어놓지 못하고 비밀스럽게 하거나, 감시당한다고 느끼거나, 경우에 따라서는 다음날 데일리미팅에 뭔가를 얘기해야 하
니까 불필요하게 야근까지 하면서 일을 만드는 일도 있었습니다. 데일리미팅에서 전체적인 맥락을 못 그린다고 봐서 "항상" 전체의
그림을 그리고 무엇을 지금 집중해야 하는지를 반추하도록 해봤습니다.

3. 회고랍시고, PROOF도 도입해보고, 많이 했습니다. 주단위로 진행했습니다. 처음에 이런 식의 회고를 하더군요. "이번 주
에는 잘 몰랐던 리눅스 커널 관련 사항을 새로이 습득했습니다. 좋았습니다. XXX는 잘 몰랐는데, 답답했습니다.". 그래서, 바
꿔봤습니다. 일을 진행하는 데 있어서 "협력과 협동"이 얼마만큼 이뤄지고 낭비적인 요소가 뭐였으며, 아쉬운 점이 뭐였는지? 잘
한 점이 뭐였는지로 바꿔 보았는데, 좀 반응이 좋은 것 같습니다.

4. 추정시간을 정하고 난 다음에 그 시간을 사용하는 데 대한 전권은 개발자에게 주었습니다. 언제 뭘하든지 알아서 일을 꺼내어
서 진행하고 하고 싶은 스타일대로 해보자고 진행을 했습니다. 기존에 간트 차트 그려놓고 일단위로 해야할 일을 정해놓고 하는 것보
다는 훨씬 더 자유롭고 적극적인 것 같았습니다.

5. 한번은 팀원 전체가 완전히 따로 국밥인 일을 하는 경우가 있었습니다. 이 경우에는 진짜 데일리미팅 하는데, 딴청 피우는 일
이 발생하게 되더군요. 그래서 일부러 일을 섞어서 만들었습니다. 그랬더니 조금 개선되더군요.

지금은 당장 어떤 실천도구를 쓸지부터를 팀원들이 결정하고 움직이자고 제안을 해둔 상태이며, 아마도 점진적인 개선이 이뤄질 것 같
습니다.

아직도 갈길이 멀지만, 스스로 움직이고 깨닫고 서로 회고하는 과정에서 경험하고 되새기고, 문제를 찾아가는 방식이 맞는 것 같습니
다. 씨앗을 강제로 뿌릴 수 있지만, 결국 싹이 올라오는 것은 그 씨앗의 몫인 것 같습니다. 그렇다고 한겨울에 씨앗을 뿌릴 수
없는 것이긴 하지만요. 그런 경우라면 난로와 비닐하우스를 준비해줘야 하겠지요.

같은 고민을 하시는 분이 있어서 반가웠습니다.

On 7월9일, 오후2시56분, 주넥 <june...@gmail.com> wrote:

> 제목이 참 애자일 스럽지 못한듯 합니다.
>
> 제가 지난 2008년 봄에 애자일을 접한 뒤, 팀에 애자일을 정착시킬려고 나름 노력했는데요.
> 결과적으로 참 쉽지 않더군요.
>
> 가장 어려운 점은 팀원들로 하여금 SCRUM에 애정을 가질 수 있도록
> 열정을 유지시키는 것이었습니다.
>
> 일에 바빠 쫓기다 보면 무질서하게 닥치는 데로 일할려고하는 습성들이 나타나게 되더군요.
>
> 마치 어렸을 때 방학을 맞이 하여 멋있게 계획표를 작성하고 벽에 붙여두는데,
> 첫 1주일은 잘 지켜지는듯 하다가 시간이 갈수록 잘 지키지 못하게 되는 것과 같은 현상...
>
> 총 20여명의 팀원들이 있는데, 이를 3개팀으로 나누어 운영 중입니다.
>
> 이 중 한팀은 비교적 SCRUM이 잘되는 편인데,
> 나머지 2팀은 자꾸 SCRUM이 무너지더군요.
>
> 그래서, 고민하다 택한 것이 "강제로라도 스크럼을 하자" 는 것이었습니다.
> 스크럼을 하면 좋은 점을 스스로 알고 해야겠다는 자발적인 열정이 생기지가 않는다면,
> 강제라고 꾸준히 하다 보면 습관화되겠지... 라는 생각이었지요.
>
> 이러한 생각을 가지고 우선 SCRUM을 강제시킬 툴을 찾았습니다.
> 예전에 이 mailing list를 통해 tool을 한번 search해본 적이 있었지요.

> 그때 누군가가 BaseCamp를 추천해주었구요...http://basecamphq.com/

> 이 툴이 simle하면서 좋기는 한데, 웹 서비스 형태로 월 사용료를 지불해야하고,
> scrum기록들이 원격 db로 남게되고,
> 서비스를 연장하지 않으면 계정이 close되면서 그간 기록들이 날라가게되구요.
>

> 그래서, 찾은 것이 collabtive라고 basecamp를 benchmarking해서 만들 툴입니다.http://sourceforge.net/projects/collabtive/

[주넥]

> 지금은 당장 어떤 실천도구를 쓸지부터를 팀원들이 결정하고 움직이자고 제안을 해둔 상태이며, 아마도 점진적인 개선이 이뤄질 것 같
> 습니다.
>
> 아직도 갈길이 멀지만, 스스로 움직이고 깨닫고 서로 회고하는 과정에서 경험하고 되새기고, 문제를 찾아가는 방식이 맞는 것 같습니
> 다. 씨앗을 강제로 뿌릴 수 있지만, 결국 싹이 올라오는 것은 그 씨앗의 몫인 것 같습니다. 그렇다고 한겨울에 씨앗을 뿌릴 수
> 없는 것이긴 하지만요. 그런 경우라면 난로와 비닐하우스를 준비해줘야 하겠지요.
>
> 같은 고민을 하시는 분이 있어서 반가웠습니다.

스크럼이 잘 정착되기를 진심으로 바랍니다.

사실 애자일 도입 초기부터 팀원들은 TDD, Pair Programming, CI Server등의 다른 것에 비해서
스크럼에 대해서는 별로라고 생각했었지요.

관리자로서 저는 스크럼을 접하고 가슴이 뛰었었습니다.
피동적이고 수동적이고 침체된 분위기를 바꾸줄 수 있을 것이라는 희망때문에요.

그간 쭉 스크럼을 안정화 시킬려고 노력하면서
최고로 달성하고 싶으나 손에 잡히지 않는 신기루 같은 것은
바로 "cross-fuctionality" 인듯 합니다.

팀원 중 누구든 팀에 할당된 어떠한 업무라도 할 수 있을 만큼 공유된다면,
계획 미팅시 추정도 정확해질 것이고, 협력도 잘될 것이고,
어려움이 있어도 쉽게 극복되어 목표 완수률도 좋아져
팀의 속도도 개선될 것이고,
무엇보다 정보 방열판의 관리가 잘 될 것이니,
스크럼은 저절로 잘될 것 같았습니다.

그래서 이에 대한 해결책으로 "pair programmnig"이라고 들었고,
사실 "pair programming"이 관리자들이 싫어해서 잘 안된다고 들어서,
관리자인 제가 열심히 하라고 하면 잘 될 줄만 알았습니다.

그런데 실상은 아무리 "pair programming"을 하라고 해도,
완전 새로운 프로젝트를 처음부터 수행 시
하나의 backlog를 협력이 될 만한 2인에게 할당되는 것이 아니라
애시당초 맡은 업무가 분할되어 처리되고 있는 상황에서는 쉽지 않구요.

또한 팀이 해야할 업무량이 절대적으로 pair 를 위해서
다소 여유가 있지 않다면 힘든 상황이 됩니다.

아무리 팀장인 제가 pair programming을 하라고 종용해도,
팀에 할당된 업무량이 줄지 않으면 잔업을 해서라도 pair로 하라고 종용할수는 없는 것이구요.

제가 pair programming을 위해서 팀원들 더 뽑아달라고
윗선에 이야기를 할 수 있는 상황도 아니구요.

그나마 모르는 것이 있으면 주저하지 말고
선임자에게 pair 요청을 하고 선임자는 가급적 열심히 도와주라고 하고,
연말 인사 평가시 저에게 주어진 평가 권한을 다대다 평가를 통해서
팀원들에게 돌려주고 여러 사람을 잘 도와주는 사람들에게
인사평가를 후하게 주는 보상 방식으로

과거보다는 그래도 도움을 주고 받는 분위기는 좋아졌으나,
이것만으로 팀이 crossfunctional해질 수는 없는 듯 하더군요.

[Jisung, Ahn]

르네상스시절에 "완성된 인간"을 목표로 했던 것처럼 완전한 cross-functionality는 신기루라고 생각합니다.

일부 소수의 예를 제외하고 완전한 cross-functionality는 추구해야하는 이상이지 달성가능한 목표는 아니지 않을까요.

불완전한 인간끼리 최대한 잘해보가자 애자일이 추구하는게 아닐까 싶습니다.



2010. 7. 13., 오후 4:15, 주넥 작성:

[Hanuri7421]

안녕하세요^^
초보갸발자 석 한울 입니다~

회사에 거의 말단으로 있는 입장에서 윗분들이 어떻게 하면 우리(저와 제 동료들)에게 스크럼혹은 애자일을 적용할 수 있을까 생각을 해 보았습니다

문득 떠오른 방법이 직원들에게 본인들이 회사 생활을 하면서 가지고 있는 문제나 일하면서 느꼈던 문제점들이나 생각 들을 물어본뒤 그 문제점들을 정리해서 그 문제들의 해결책으로 가장 적합한 실천법들을 문제의 해결책으로 직원들에게 권유 해 보는것은 어떨까 생각해 보았습니다.

보통 동료들과 밥을 먹거나 커피한잔하면서 이야기를 나누다 보면 그래도 각자 개인이 생각하는 어려움들이 몇가지씩 가지고 있더군요. 제생각에는 그 문제들을 몇가지 애자일 실천방법들을 적용해 보면 낳아질 수도 있겠다~ 라는 생각을 자주 해 보았습니다

음 이렇게 말하고 나니 중요한것은 회사에서 직원들의 상황에 자주 관심을 가지고 대화(일방적이 아닌)를 해 보는게 중요하겠구나 라는 생각이 드네요.

문제들을 수집하고 문제에 적합한 실천법들을 먼저 적용이 아닌 제안!!을 직원들에게 해 본다가 제 생각 입니다.

나의 iPhone에서 보냄

2010. 7. 13. 오후 5:20 "Jisung, Ahn" <nar...@gmail.com> 작성: