미국 플로리다 주 올랜도에서 열린 애자일 2010(http://agile2010.org) 컨퍼런스에 참석한 내용을 Xper (http://xper.org) 에서 공유한 자료입니다. 컨퍼런스 분위기와 기억에 남는 3 개의 세션을 요약하였습니다. 맨 마지막에는 "애자일 코치로서 효과적인 질문하기" 세션에서 다루었던 실습을 해보았습니다.

1. Xper
Agile 2010 공유회
2010년 9월 16일(목)
심우곤
Mail: wgshim@gmail.com, Twitter: @wgshim
1/41

2. 계획: 테네시 주, 내쉬빌
Gaylord Opryland Resort
2/41

3. Flood!! May 1~2
3/41
http://en.wikipedia.org/wiki/2010_Tennessee_floods

4. 변경: 플로리다 주, 올랜도
Walt Disney World Dolphin Resort
4/41

5. 5/41

6. 숫자로 살펴보는
Agile 2010
6/41

7. 227/934
7/41

8. 24%
8/41

9. 180
9/41

10. 34
10/41

11. 1,400+
11/41

12. 무엇이 크게 달라졌나?
12/41

13. 강화/신설된 트랙
• Business Track
• UI/UX Track
• Research Track
• Engineering/Technical Track
13/41

14. 늘고 있는 한국 참가자
LG전자 (2),
Agile 2008 4명
LG CNS (2)
LG전자 (3),
Agile 2009 6명
삼성 SDS (3)
LG전자 (2)
Agile 2010 8명 LG CNS (3)
삼성 SDS (3)
14/41

15. 분위기
15

16. 16/41

17. Video 시청
http://www.youtube.com/watch?v
=BGnFmZ4Sx_Q
(00:15” ~ 01:00, 03:10” ~ 03:30”, 05:25” ~ 05:45”)
17/41

18. 분위기
• Kanban 도입이 대세
• Programmer 를 위한 Practical 세션 부족
18/41

19. 저의 참가 목적
19

20. 참가 목적
• 회사 차원의 Agile 확산 전략/경험
• 외주/협력사에 Agile/Scrum 적용 사례
• 관련 해외전문가 접촉
20/41

21. 소감 및 메시지
21

22. 소감
• 영어 압박! ㅡ,.ㅡ
– 대부분의 세션이 토론/참여 식
• 우리 나라 사례도 충분히 발표할 수 있다.
– 비슷한 수준의 고민
• 일본인들의 참여도 높음
• 기본에 충실하지 않고 유행을 따르면 走火
入魔 에 빠진다!!
• 코딩능력이 있는 테스터들이 과반수 이상!
22/41

23. Insightful Message
• Architect 가 별도로 존재해서는 앆 된다.
Architect 는 역할일 뿐이다.
– 품질이 특정 부서의 일이 되어서는 앆 된다.
23/41

24. 세션 내용 공유
3 개만!!
24

25. An Unplugged Retrospective on the Agile
Ⅰ
Decade : "Mirror Mirror on the wall are we
really the most beautiful of all?"
Dave Thomas
• Bedarra Research Lab. (founder)
• Object Mentor (managing director) 25/41

26. 기억에 남는 것
• Agile 이 무계획, 문서 X, ... 과 같이 잘못 이해하
는 경우가 많다.
• 작금의 Agile 의 자격 중시 대한 풍자.
– 인증(Certification)  Return to Craftsmanship!!
• TDD 에서의 Done 의 의미: Unit & Acceptance
Tested!
– Practice! before Method & Tools
– Practice first! method is set of practices
– Tools & Automation streamline development
26/41

27. 기억에 남는 것 (계속)
• Lean and Agile
– Lean is a top-down process
– Agile is a bottom up team centered process
• 아키텍트는 역할이지 직업이 아니다.
– 자싞이 코딩을 수행할 수 없는 사람은
설계자로 문제가 있다.
• Estimates must be ranged to include risk
– min, max or min, max, expected
27/41

28. 현재 처한 문제점
• IT 가 가치를 제공하기 보다는 비용을 소모
하는 경향이 있음
– Many biz executives still don't understand IT
– Agile is FrAgile as it depends on sustainable
leadership and discipline
• Skills are in relatively short supply
28/41

29. 몇 가지 가능한 해결책
• 교육
– Teamwork teaching, story telling
– Invest in non CS education
– Enable more end user programming
• SW 개발
– Use more expressive higher level language (SICP 책
강추)
– Smaller programs which are loosely coupled
– Design for change (e.g., more data driven)
29/41

30. How Agile Taught IBM Ⅱ
About New Leadership Competencies
Sue Mckinney
• VP of Development
Transformation at IBM
• VP of Engineering at
Pitney Bowes Inc 2010
30/41

31. IBM 의 SW 그룹 특성
• 짂정한 글로벌 팀
– 전세계, 25,000 명 이상
• 엄청나게 많은 회사를 인수/합병
– 매년 10개 정도
• 변화:
– 80년대(Waterfall)
– 90년대(Iterative)
– 2006년부터(Agile)
31/41

32. 변화 시도
• 처음에는 2명이 문서 없이 교육
• 250 회 이상의 워크샵 실시
– 관심 있는 사람들 중심으로
• 8,000 명 이상 교육
• 현재 70% 이상의 팀이 Agile 을 사용
– 한 가지 이상의 Agile Practice 를 사용
32/41

33. 교훈
• 프로세스 개선 + 경영짂 설득
– Pull and push model
• Agile CoC (Center of Competence) with
full time coaches
• When to mandate, measure or motivate
• one size fits all 이란 없다!!
33/41

34. “Short, time box iterations
with stakeholder feedback –
working software”
34/41

35. 결 론
• Give up command & control (=> recipe style)
• the opposite of control is discovery
• free the team to question, analyze
• create a place where people want to be not
have to be
• give people what they need to succeed
• support from senior leaders
• create small successes and share
35/41

36. 핵심: 신뢰를 쌓아라!!
• Create a culture of TRUST
– 높은 싞뢰의 회사가 그렇지 않은 회사 대비
10년 간 경영성과 2 배
– 높은 싞뢰의 회사가 그렇지 않은 회사 대비
43% 높은 생산성
36/41

37. Ⅲ
Arto Eskelinen, Sami Honkonen
http://bit.ly/aVSS3c
37/41

38. 질문
• What
• When
• Who
• How many
• How much
•How
•Who (blame)
•Why  What, When, … 38/41

39. GROW Model
Goal
G 목표
고객이 원하는 궁극적인 상태
목표 대비 현 상태를 파악하고,
Reality
R 현실성
목표를 달성하기 위한 단계와 방법에 집중
(※ Goal 과 동일한 용어로 기술)
Obstacles
목표 달성을 방해하는 장애요소 파악
장애요소
O
Options
장애요소를 해결/회피하기 위한 대앆들을 마련
대안
Way Forward
W 실행 방안
구체적이고 실행 가능한 액션 아이템
39/41

40. 시나리오 I
과거 3 ~ 4 차례의 회고를 통해 팀은 문제를
야기하던 장애요인들을 식별하였습니다. 매
번 팀은 장애요인을 해결/제거하기 위해 몇
가지 액션 아이템들을 도출하였습니다. 팀은
여러 차례 도출된 액션 아이템들을 실행하지
못했고, 문제는 여전히 남아있음을 알게 되
었습니다. 이제 팀원들은 더욱 열심히 일하
기로 결정하였습니다.
40/41

41. 시나리오 II
당싞은 팀원 몇 명이 모여 그 자리에 없는
사람에 대해 이야기 하는 것을 우연히 듣게
되었습니다. “어제 퇴귺하기 직전에 김 대리
가 또 컴파일 되지 않는 코드를 체크인 했지
뭐야. 덕분에 수정하느라 한 시간 동앆 남아
있어야 했다구.”
41/41