Project Research

Agile 방법론에 대해 글을 올리다보면 제게 Agile은 소스통합, 코드리뷰 등을 포함하여 technical하게 중요시해야한다고 이야기하는 분도 계셨는데요. 맞는 말씀이긴 합니다만, 제가 바라보는 시점은 좀 더 큰시각으로 프로젝트관리자가 갖춰야하는 PMBOK/42지식체계를 어떻게 Agile로 승화하여 적용시키느냐입니다.  우선 이러한 General Management 가 확립한 후 Technical Management/ Governance 로 접근해야지요.

 

물론 개발자 분들께는 XP라든가 FDD 가 좀더 현실적이겠지만, 이러한 Management Skill을 익혀야 개발PM으로 혹은 개발리더로써 역량을 발휘할 수 있지 않을까요?  중요한것은 Manifesto 및 12원칙의 핵심을 지키기위해, 현재 기업/프로젝트의 AS-IS 환경을 어떻게 TO-BE 모델을 잡아 단계적으로 적용하느냐입니다.

 

이러한 관점으로 Agile을 PMBOK과 연계하여 진행하는 기업 Agile 체화 강의/멘토링을 하면서 받은 피드백을 정리해 봅니다. (다들 IT PM분야 5-10년차 이상 분들의 피드백입니다.)

 

 

시간이 날때마다 주제별로 상세 설명드려볼께요. 다양한 댓글 의견 환영합니다.

 

 

[비유/기존프로세스와다른점]

1. 소화제 (소:소통, 화:화합)

2. 실시간 교통정보 시스템이 반영된 차세대 3D 네비게이션

3. 과거 진도율 체크가  완료여부관점으로 변환, 과거 요구사항 프리징이 요구사항의 유동적 적용이 차별화

4. 기존이 What/관리에 초점을 맞추었다면, Agile은 구체화/R&R/Daily확인에 초첨을 맞춤. 결국 HOW였음

5. 기존 산출물이 형식적인 면이 강한데, Agile은 참여를 통한 의사소통 증대를 통한 실용성면이 강함

6. 교훈의 공유에 동감 함

7. 실패확율을 줄이기 위한 Tool

8. 기존 PMBOK/프로젝트관리기법과 Agile에 차이점 대해 이해

 

 

[사람/전문성/자발성/인간존중]

9. Agile Process의 중요성과 “갑”의 Engagement가 중요함을 깨달음

10. 수평적 조직, 자발성 중요, 선성설로 우수한 팀원이 기본이 되어야 함,

11. 자발적인 참여를 위한 팀원까지 Level-up 이 필요해 보임

12. PM이 현업 능력 부족시 Agile 활용하면 좋을 것 같음 (의사소통기반 팀원 위주 진행이기때문에)

13. 참여자의 자율성이 중요함

14. 고객/요구 프로젝트 수해자간 의사소통

15. 요구사항의 수용, 변동 %

16. 민주화로 집단 토론 유발을 통해 사용자의 자발적 관심도 향상 및 참여 유도

 

 

[소통/협업/화합]

17. Collaboration, 작동SW, 주기적인도, 수평적 대화/적용 기법이 중요함을 깨달음

18. Visualization 의 시각화 중요성 및 유용성 확인 함

19. Virtual Team에서의 독립성 및 Dashboard의 중요함을 깨달음

20. Burndown-chart의 시각적 중요성과“갑”의 요구사항의 적절한 반영이 인상적

21. 참여/창의성/소통을 중요시 여김

22. 소규모 프로젝트에서 유리

 

 

 

PMPcafe 주관으로 “프로젝트에 유용하게 활용하는 애자일 기법”이라는 주제로 세미나를 마쳤습니다.  애자일을 응용한 사례로 Visual Planning , Visual Dashboard를 곁들어 일반 Non-IT도 애자일기법을 충분하게 도입하여 효과보고 있고 볼 수 있다는 측면을 강조하여 진행하였습니다.

 

 

우선 CNN 기준 2010년도 직업 만족도 조사 50선 중 17개 분야가 IT 분야고, IT 중 35%에 해당하는 직종이 Management 기법이 필요한 직종입니다.

 

이런 Management 관리 기법은 미국프로젝트협회인 PMI 에서 이미 Project > Program > Portfolio 관리 기법에 대해 지식체계가 있으며, 이밖에도 조직 지식인 OPM3와 WBS, 일정, CM, Risk 및 EVM에 대한 실무 서적만 공부하면 커버될 수 있는 영역입니다.

 

이러한 PM 기법의 지식을 제대로 교육을 받았는지, 또한 제대로 경험이 있는지를 평가하는 자격증 제도가 있고, 국내에는 프로그램관리전문가 1명, 프로젝트관리전문가인 PMP가 1만명, 리스크전문가 7명, 일정관리전문가 5명 및 이제 대학을 막 졸업하였지만 기초 PM지식이 있는 학생이 약 27명 정도가 있습니다.

 

이러한 PM지식체계 혹은 PM자격증을 취득한다고 프로젝트가 100% 성공하는 것은 아닙니다만, 아무런 기법없이 맨파워에 의해 진행되는 프로젝트보다는 일정/예산준수율 증가, 범위추가율 감소, 프로젝트 목표 도달율이 훨씬 높습니다. 이때문에 PMBOK기반의 PMP 자격증을 따는 것이지요. 애자일기법은 프로젝트 Monitor & Controlling의 도구에 가깝습니다.

 

이후에는 애자일 ▲개요, ▲구성 및 ▲ PMBOK과의 비교에 대해 설명하였으며, 이 내용은 이미 프로젝트에 유용하게 활용하는 애자일 기법 에서 설명하였으므로 skip 합니다.

 

 

애자일의 응용방법으로 IT 분야가 아닌 일반 사무직을 위한 Visual Planning 및 Visual Dashboard에 대해서 설명하였습니다.  포스코 광양제출소에서 추진하고 있는 VP(Visual Planning)을 통해 BSC 실행 추진을 MBO > 연간목표 > 분기목표 > 월간목표 > 주간목표 > 일간목표에 의해 매일매일 20여분씩 팀내에서 공유하고 멘토링하는 방법의 효용성에 대해서 설명하였습니다.

 

이러한 Visual Planning은 초기에 도입 및 3-6개월여 몸소 체험하고 익숙해지기까지는 매우 고달프나, 이 단계를 지나면 팀장과 팀원의 업무 진행 스타일이 바뀌게 되며, 지시가 아닌 멘토링 기법과 더불어 자발적인 업무 진행을 하기 때문에 생산성이 향상된다는 사항을 설명하였습니다.

 

또한 어린이집에서 Visual Planning 기법으로 교장선생님과 교사선생님들 사이에서의 목표에 따른 업무 추진이 투명하게 공유되면서, 의사소통이 월활하게 관리되어 최고의 어린이집으로 거듭날 수 있었다는 설명을 드렸습니다.

 

포스코의 사례를 본따서 만든 웅진그룹의 행가래 역시 청출어람에 대항하는 좋은 사례입니다. 전사적으로 9시부터 15분간 행가래 음악에 맞추어 스탠딩 회의를 하게 되고, 이 과정에서 팀장은 팀원을 멘토링하여 자발적인 목표 수행을 할 수 있도록 하는 사례에 대해 설명하였습니다.

 

대규모 조직뿐만 아니라 15명 정도 되는 중소기업에서도 이러한 애자일보드의 응용 보드를 활용하여 회사의 목표와, 부서의 목표에 대해 월간,주간 단위로 점검하고 공유하여, 직원들간의 단절될 수 있는 타부서의 주요 중점 과제 및 프로젝트 상황을 공유하게되어 불필요한 오해를 줄임으로 업무 생산성을 높일 수 있었다는 점과, 이런 효과를 불과 10만원도 안되는 비용으로 추진하였다고 설명하였습니다.

 

이어 커피숍 창업을 주제로 애자일 실습을 하였습니다. 4-5명씩 조를 이뤄 투자자, Product Owner(지점장), Scrum Master (PM/창업컨설턴트), 팀원(바리스타,캐쉬어), Sponsor(투자자)로 역할을 나누어, 계획대비 업무 진척을 Sprint2에 나눠 매일매일 총 10회의 Daily Standing 회의 및 2회에 걸처 Sprint 리뷰/회고를 직접 체험해 보도록 하였습니다.  실습 참여를 통해 즐거웠다고 하시면서, 애자일의 원리이해를 하신것 같아 약간의 보람이.. (덕분에 세미나는 계획대비 30분을 더 넘겼습니다.ㅜㅜ)

PRIME IT 김인섭 차장님께서 실습 후기를 올려주셨습니다. 애자일(Agile) 프로젝트관리 방법론 실습(커피숍 창업) 후기

 

 

앞서 CNN 행복 인기 직업 50개 중 35%인 17개 직종이 IT인 반면 우리나라의 IT는 우울하다 못해 참담한 시점입니다. 우리나라도 IT직종의 만족도 향상 및 글로벌 경쟁력을 확보하기 위해서는 프로젝트, 프로그램 및 포트폴리오 관리 기법에 대해 체계적고 약간의 한국형 테일러링이 가미된 지식/프로세스가 필수적이라고 생각합니다.  이를 위해 ▲프로젝트 기준으로는 애자일 (응용) 기법 체험 실습과정, ▲프로그램 관리를 위해 ALM 훈련 과정, ▲ 포트폴리오 관리를 위해 상위 요약 핵심 정보에 대해 Visual  Dashboard에 관련된 멘토링업무를 하고 있습니다.

기업내의 프로젝트, 프로그램 및 포트폴리오 도입이 필요하나 어디서 부터 해야할지 난감하시다면 연락주세요. 컨설팅이 아닌 멘토링 기법으로 도와드리겠습니다. 저의 연구 논문들은 Peter가 제안하는 Enterprise 2.0 협업 환경 (Enterprise 2.0 관련 논문/ PT 정리)을 참고하세요.

 

최근 애자일 관련 강의를 하면서 코칭/멘토/서번트 리더쉽을 상당히 많이 강조를 합니다. 최근 읽은 컬럼 중 “8 Habits Of Highly Effective Google Managers” 에 코칭 관리 기법에 대한 좋은 사례인 것 같아, 어설픈 번역이지만 공유하고자 합니다.

 

구글에서는 엔지니어가 좋은 관리자가 되기 위해 성과위주 리뷰, 피드백 혹은 설문/보완체계, 성과보상 및 데이터 기반의 드라이브를 추천합니다. 이중 중요한 순으로 8가지를 정리하였고, 더불어 몇가지 빠지기 쉬운 관리 오류도 언급하고자 합니다.

 

구글의 우수한 관리자의 8가지 법칙

 

 

1. 좋은 코치가 되어주세요. (Be a good coach)

- 좋은 점과 나쁜 점을 균형있게 구체적이고 건설적으로 피드백을 해주세요.

- 팀원의 강점을 더욱 강화하기 위한, 문제점 개선에 대해서는 개별적으로 해결책을 제시해 주세요.

 

2. 팀원을 일일이 간섭하지 말고, 권한을 주세요. (Empower your team and don’t micromanage.)

- 팀원에게 자율성을 부여해주고, 조언을 통해 균형을 맞춰주세요.

- 팀원 스스로가 문제점을 제거해 나갈 수 있도록 역할을 확대해주세요.

 

 

3. 팀원의 성공과 개인사에 관심을 가져주세요. (Express interest in team members’ success and personal well-being)

- 팀원을 밖에서는 동일한 시대를 살아가는 같은 인간으로써 대해보세요.

- 새로운 팀원이 쉽게 적응할 수 있도록 반갑게 맞이해 주세요.

 

 

4. 생산성과 결과지향적으로만 관리하세요. (Be productive and results-oriented)

- 팀이 달성해야할 목표가 무엇인지, 팀원들이 그 목표를 달성할 수 있도록 도와주는 것만 집중하세요.

- 업무의 우선순위 조정과 장애물을 극복하기 위한 의사 결정은 팀원 스스로가 할 수 있도록 해주세요.

 

 

5. 팀의 이야기를 많이 들어주시고 좋은 커뮤니케이터가 되세요. (Be a good communicator and listen to your team)

- 좋은 커뮤니케이션이란 듣기와 공유 두가지 뿐입니다.

- 가능한 모든 미팅은 삼가해주시고, 팀의 목표를 구체화하는 일에만 집중하세요.

- 팀원이 격고 있는 문제에 대해 듣고, 열린대화를 통해 격려를 해 주세요. 

 

6. 팀원들의 경력 개발을 도와주세요. (Help your employees with career development)

 

 

7. 팀에 명확한 비전과 전략을 제시해 주세요. (Have a clear vision and strategy for the team)

- 혼돈과 소란 중일지라도, 오로지 팀이 목표과 전략에 집중할 수 있는 환경을 만들어 주세요.

- 팀 스스로가 팀의 비전과 목표, 진행상황을 스스로 수립하고 점검할 수 있도록 해주세요.

 

 

8. 핵심 기술을 유지하세요. 그래야 팀원들에게 조언을 해 줄 수 있습니다. (Have key technical skills, so you can help advise the team)

-  팔을 걷어붙이고, 필요할때 옆에서 팀의 조력자 역할을 해주세요.

- 팀의 도전적인 목표 스펙을 충분히 이해하세요.

 

 

위험한 3가지 관리 습관

 

1. 팀리더 선발에서 문제를 일으키지 마세요. ( Have trouble making transition to team leader)

- 관리 스킬이 다소 부족하더라도 우수한 실력의 팀원은 관리자로 승격될 수 있습니다.

- 외부에서 영입된 직원은 회사의 구체적인 방법을 이해못할때도 있습니다.

 

 

2. 팀원의 성과와 경력 개발을 소홀히 하지 마세요 (Lack a consistent approach to performance management and career development)

- 팀원에게 회사가 원하는 것을 이해하도록 강요하지 마세요.

- 팀원 스스로가 개발하고 역량확장 할 수 있는 부분을 굳이 코치하려하지 마세요.

- 적극적이지 못한 행동 : 직원 스스로가 극복하도록 기다리기만 해서는 안됩니다.

 

 

3.  관리와 의사소통에 너무 적은 시간을 할애하지 마세요. (Spend too little time on managing and communicating)

 

 

번역원문 :  8 Habits Of Highly Effective Google Managers

참고문 :  Google’s Quest to Build a Better Boss


프로젝트경영협회에서 “Agile 프로젝트 관리 기법 / PMI Agile 자격증 소개”에 대한 세미나를 마쳤습니다.

최근 소프트웨어(SW) 개발 방식의 하나인 `애자일(Agile) 개발 방식’에 대한 관심이 높아지고 있으며, 2011년 하반기에는 미국 PMI에서도 애자일 자격증이 출시됩니다. 사전적으로 “민첩한, 기민한”의 의미 처럼 애자일기법은 사용자 시나리오 개발, 코딩, 품질 테스트를 단기적으로 한정된 시간 안에 진행하는 하나의 스프린트(Sprint, 단거리 경기)를 구성하여, 이를 순환반복해서 프로젝트를 완성시켜나가는 방법론입니다.

발표 자료 중 중요한 몇가지 요소만 발췌해 봅니다.

우선 범위/일정/비용/품질/인적자원에 대한 기준이 전통적인 방식에서 틀이 깨지고 있습니다.

(1) 61%가 무조건 납기를 맞추는 것이 아닌 사용하기 적합한 시점에 인도되어야 한다는 점,

(2) 87%가 최초 정의된 Spec 보다는 이해당사자의 실제적인 요구사항의 반영이 수시로 적용되어야 한다는 점,

(3) 79%가 예산내 납기가 가닌 ROI 가 도출되어야 한다는 점,

(4) 87%가 일정과 예산에 무조건 맞추는 것 보다는 고품질의 인도물을 받기 원한다는 점,

(5) 75%가 일정과 예산에 맞추는 것보다 육체적/정신적으로 일체감일 이뤄야한다는 점과, 환경이 갖추어진 상태에서 일을 해야한다는 점 이죠.

물론 EVM 기반의 전통적인 대규모 프로젝트에 애자일을 적용할 수 없습니다. 하지만 그 이외의 불확실한 기술을 도입해야하고, 상호 협의되지 않은 요구사항을 수렴해야하는 부분이 큰 복잡한 프로젝트에는 Agile 방식의 기법을 추천합니다.

Agile 경험자 642명으로 효용성을 설문조사 해보니 생산성 증대효과 82% 체험, 품질향상 77% 체험, 고객만족 78% 체험을 느꼈다고 합니다.

이를 수 밖에 없는게 하단의 애자일 흐름도 및 팀원 직접 찹여하고, PM의 서번트 리더쉽/멘토링에 의해 원활히 돌아가며, 매주/매일매일 리뷰와 회고가 이뤄지기 때문에 당연한 결과입니다. (물론 이것을 제대로 수행하기 위해서는 참여 인원들의 애자일 철학 및 방법에 대한 충분한 숙지가 되어있어야 합니다. 그냥 좋다고 도입만 한다면 100이면 100 실패합니다.)

애자일 구성 방법은 어렵지 않습니다. 정말 2-3일 정도만 체험하게 되면 바로 적용할 수 있습니다. 중요한 용어는 WBS에 해당되는 Backlog (유저스토리 혹은 FBS), 마일스톤에 해당하는 Sprint,  Monitor/Control에 해당하는 Daily/Weekly 리뷰 및 회고는 프로젝트의 공감 및 리스크/품질은 기본이고, 납기까지 준수할 수 있는 정말 좋은 도구입니다.

이의 실천은 어렵지 않습니다. Spec (혹은 Product Log)가 정해지면 이를 주간 단위로 잘개 쪼개고, 다시 일간 단위로 쪼개는 작업을 한 후, 총 할일을 하나하나 수행하며 제거해 나가는 겁니다. 할일이 100개고, 10주의 시간 산정이 되었다면, 이의 수행하마 하나하나 빼는 거죠. 중요한 것은 PM이 리더쉽을 발휘해서 나홀로 프로젝트를 이끌어가는것이 아닌, 팀원이 직접 참여/발표/회고하게끔 PM이 멘토링을 해야한다는 겁니다”

PMBOK과의 관계가 헛갈릴 수 있는데, 이의 차이점은 명확합니다.  PMBOK은 프로젝트 수행 기간동안 무엇을 점검해야하는지에 대해 지침을 내려준 ANSI/미국 표준 프로젝트 지침서라면, Agile/애자일은 이를 수행하기 위해 어떻게/HOWTO를 기술한 Tool & Technique 입니다.

PMI에서도 이러한 애자일 유용성 및 대중적 확대를 인지하고 2011년 3Q 내에 PMI Agile 자격증이라는 이름으로 자격제도를 출시합니다. 이는 3년 이내에 필히 PMP와 더불어 IT프로젝트의 기초 요건 자격증이 될 것이라고 확신합니다.

2시간 밖에 안되는 짧은 시간동안 애자일 철학/구성/기법/PMBOK비교/자격증설명을 하는 것이 쉽진 않았지만, 저의 지식 영역내에서 최대한 전달했다고 생각됩니다.

전 세계에서 유일하게 우리나라만 IT가 저평가 되어있습니다. 이는 남의 탓이 아닌 우리 IT 구성원들의 대충대충/ 결과지향적으로만 일하는 습성 때문인 것 같습니다. 이를 극복하기 위해서는 자신만의 (좀더 확대해서 우리 IT 산업에 맞는) 표준화된 철학과 방법론을 가지고 있어야만 하며, 아직까지는 미국의  PMBOK/AGILE 을 그대로 적용하여 각자 자신의 회사/팀에 맞는 테일러링된 철학/방법론을 내놓아야 한다고 생각합니다.  미국의 Smart Work으로 대중적으로 성공한 37signals 의 Getting Real 및 Rework 철학과 basecamp, highrise, backpack, campfire 관계 처럼요.

발표자료는 공개하고 싶지만, 저도 워낙 인용을 많이해서 부끄럽네요. 댓글로 요청하시면 바로 보내드리도록 하겠습니다.