애자일 방법론 적용 실패 사례 공유

[Wonderer]

항상 좋은 내용을 많이 얻어가고 있습니다.

 

다만 가끔 애자일관련 메일링이나 게시판 보다보면 자주 느끼는 바가 있는데
다음과 같습니다.

 

1. 애자일 방법론을 적용했다 실패한 사례를 보게되면
   무언가 방법론을 잘못 이해했거나 잘못 적용했다고 판단하는 경우가 많다.
   (제대로 적용했지만 실패하는 경우나 제대로 적용하기 힘든 환경 등의 경우를 배제한다?)

 

2. 그럼 애자일 방법론이라는 것은 완벽하게 적용하지 않는 이상 의미가 없는 것인가?
   반대로 애자일 방법론을 완벽하게 적용하면 반드시 프로젝트는 성공하는가?
   책에서는 분명 그건 아니라고 하고 있다. 그렇다면 분명 제대로 적용해도 실패할 수도
   있다는 것이 아닐까?

 

3. 애자일 방법론의 추종자들은 애자일 방법론의 단점이나 헛점이 있다고
   인정하고 싶어하지 않아한다.
   (애자일 방법론을 반대하는 사람들의 표적이 될 수 있으므로?)

 

위와 같은 느낌을 느낄 때가 여러번 있었던 것 같습니다.
(솔직히 조금 무섭습니다;)

 

개인적으로는 애자일의 성공사례는 상당히 많이 보았고
오히려 실패사례를 많이 공유하고 싶다는 생각이 듭니다.

 

다만 분위기상으로 실패사례를 이야기하면 돌아오는 느낌은
애자일 방법론을 잘못 적용한 것에 대한 부분을 집요하게 추궁당하는
그런 느낌인 것 같습니다. 그래서 공유하기도 쉽지 않다고 생각을 하는데요.
그러나 아마도 김창준님 같은 분이 실패사례를 말씀하신다면 돌아오는 느낌은
상당히 다를 것이라 생각됩니다. (실패경험이 있으신지는 모르겠습니다만^^;)

 

언젠가 애자일 방법론 성공사례를 제외한 실패사례를 공유할 수 있는 자리를 만드는
것은 어떨까요? 실패사례를 공유하는 자리라면 많은 분들이 부담없이
참여할 수 있지 않고, 애자일 방법론의 긍정적인 전파도 많이 기대할 수 있다고
생각합니다.
 

 

[June Kim]

저도 실패사례 많습니다.

딘 케이스 시몬톤(Dean Keith Simonton) 교수라는 창의력 연구가가 있습니다. 특히 과학분야의 창의성에 대해
연구를 했죠. (그분의 책들 강추)

그 분의 연구에 따르면 학계에 큰 영향을 끼친 논문을 쓴 사람일수록 논문 발표수가 (굉장히) 많다는 것이고, 또 그 중에는
형편없는 것도 많다는 사실입니다.

그래서 그분의 결론은 이겁니다. 논문으로 성공하려면 가장 좋은 전략은 발표수를 늘리는 것이다.

성공을 많이 한 사람들은 그만큼 실패도 많이 했습니다. (일단 연구된 것으로는 과학계에 대해서만)

저는 요즘 강연에서 애자일의 한계를 말합니다.

보통 스탠디쉬그룹의 보고서(http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS)를
인용해서 말하는데요,

1) User Involvement
2) Executive Management Support
3) Clear Business Objectives
4) Optimizing Scope
5) Agile Process
...

일단 애자일이 프로젝트 성공요인 5위를 했다는 사실만으로도 매우 긍정적이긴 하나, 1등이 아니라는 것이고 성공요인에는 다른
여러가지도 많다는 점을 주목하라고 합니다.

즉, 위에서 1, 2, 3, 4가 제대로 안되면 애자일 도입했다고 해서 프로젝트 성공하는 건 아닐 수도 있다라는 말을 합니다.
다만, 1번과 4번은 애자일에서 추구하는 목표점 내로 볼 수 있는 것 같고, 남은 2번과 3번이 관건이겠죠.

하지만, 프로젝트의 성공에는 정말이지 많은 요소들이 관여합니다. 그래서 어느 하나 해서 프로젝트가 성공하냐 마냐 하는 것은 어불성설입니다.

학생의 예를 들어보죠. 내가 반에서 꼴등하고 폭력적인 학생을 변화시켜서 몇 년에 걸쳐서 태도도 바꾸고 성적도 올렸습니다.
그런데 어느날 부모님이 이혼을 합니다. 그러면서 다시 나락으로 떨어집니다. 선생님들은 이런면에서 한없이 겸손할 수 밖에
없습니다. 자신이 컨트롤할 수 없는 것들이 있다는 사실을 인정해야 합니다.

방법론을 이야기하는 사람도 마찬가지입니다.

그래서 저는 애자일이 성공을 보장하지 않는다고 말합니다. 대신 성공률의 개선이 가능하다고 말합니다.

2008/12/15 Wonderer <won...@gmail.com>:

[DH]

저는 매일/매순간 "실패"한다고 느끼고 있습니다.

실패를 어떻게 정의하느냐의 차이겠지만 전혀 낭비가 없는 모두의 생각이 정확히 일치하는 이상적인 상태를 성공이라고 정의한다면 항
상 실패한다고 느낍니다. 다만 그 실패의 피해가 크지 않고 즉시 복구되어 바로 이전 상태보다는 나은 상태로 전이하는 경우가 실패
한 상태에 머무르거나 오히려 더 나빠지는 경우보다는 훨씬 많다는 점에서 현재 방식을 옹호할 뿐입니다.

정말 중요한 점은 해당 프로젝트 팀리더들과 팀원들이 얼마나 매순간 좀더 나은 상태로 가야한다는 "집착"을 얼마나 가지고 있으며
이 과정에서 서로에 대한 존중과 이에 걸맞는 프로정신을 얼마나 책임감있게 발휘하느냐라고 생각합니다.

> 2008/12/15 Wonderer <wond...@gmail.com>:

> > 생각합니다.- 따온 텍스트 숨기기 -
>
> - 따온 텍스트 보기 -

[강석천]

2 : 예전에 포스팅할 때 '30% 의 애자일, 60%의 애자일 적용 모양새가 있다면 어떠한 모양새일까?' 라는 질문을 한
적이 있었습니다. 적용을 해 나갈 때에는 Small Step 으로 걸어나갈테고, 그러는 중에는 애자일 적용 모습에도 다양한 빛깔
이 있으리라 생각합니다.

그럼에도 불구하고 초창기에 몇몇 분들 대화를 듣다가 아쉬웠던 점은, 커스터마이징이란 이름하에, 결국은 '자기들이 평소 쓰
던 방법과 별 차이 없는' 해석을 만들어놓는 경우들도 있었습니다. 짝 프로그래밍의 경우 어떤 분들은 작업하다가 잠깐잠깐 5분
10분 같이 코딩하면 '짝 프로그래밍' 이야기하시던 분도 있었고, . 그때는 오히려 '순수하게 해당 Practice 를 적용하
는 모습' 을 보는 것이 의미가 있었을 것 같습니다. (최근에 제 근처 어떤분이 열심히 Debugger & Logger
Driven 방식으로 개발하시고는 '자신이 하는 방식이 TDD 이다. 이렇게 해야 한다' 하는 걸 보고.. '이 방식을 어디까
지 TDD 로 봐줄까..' 한참 고민했습니다.; 나름 기분 안상하게 해드리려고 '피드백을 명확히 빨리 확인하시는게 좋죠' 정도
로 끝냈습니다.;)

지금은.. 서적도 많고, 적용 사례에 대하여 이야기한 것들도 많고, 여러 다양한 시도를 하시는 분들도 많고. 그리고 '이름없
이 전파하기' 가 빛을 발하는 것처럼, 초기에 '일단 순수하게 Practice 를 적용해보고 점차적으로 Customize 를 하
자' 란 모습이 오히려 '순수하게 100% XP, Agile 적용해야 해' 의 강요랄까요.. 부담감이 되어 실제 적용하기 더 어
려운 무엇으로 만들어낸 것도 있지 않았을까 생각해봅니다.

[Sangchel Hwang]

저도 강석천님의 의견에 동의합니다.

일단 좋은 사례에서 이야기 하는대로 따라 해야 합니다.
좋다 나쁘다를 이야기 하는것은 그 다음이 되어야 합니다. 말할때 자신에게도 떳떳해 지지 않을까요.

2008/12/16 강석천 <free...@gmail.com>

--
Blog URL: http://moai.tistory.com

[강석천]

근데.. 애자일 성공 사례가 그렇게 많았나요?;; 주변 분들 이야기 들을 때면 맨날 '힘들다' '기존 팀 사람들과 충돌중이다'
'는 이야기였는데;;

[Wonderer]

느낌상으로는 분명 실패 사례도 성공 사례에 비해 만만치 않게 많다. 라는 느낌이긴 합니다만,
성공 사례의 경우는 아주 작은 성공도 쉽게 공유가 되는 반면(애자일 관련 서적만 봐도 쉽게 볼 수 있죠)
실패 사례의 경우에는 공유를 하지 않거나 조용한 외침으로 묻히는 경우가 많은 것 같습니다.

[강석천]

이전에 강규영님이 마소에 소개하신 오픈마루 사발면 프로젝트 사례는 어떠신지요?

[chauchau0]

사발면 프로젝트 사례는 여기 있네요. http://blog.openmaru.com/80
석천이 오랜만~ ^_-

[bonna choi]

개발팀은 성공적으로 프로젝트를 마쳤다고 생각했으나, 고객이 만족하지않은 경우... 이 프로젝트는 성공일까요 실패일까요.

http://www.infoq.com/presentations/A-Story-of-Project-Failure-Mitch-Lacey

2008/12/23 chauchau0 <chau...@gmail.com>

--
"I am only one, but still I am one.  I cannot do everything, but still I can do something; and because I cannot do everything, I will not refuse to do something that I can do."  Helen Keller

[June Kim]

프로젝트의 "중요한" 스태이크홀더들을 만족시키는 것이 프로젝트 목표라고 봅니다. 작동하는 소프트웨어를 전달하는 것이 아니라요.

그런데 사실 전체적으로 성공이냐 실패냐를 흑백으로 가리는 것은 매우 어려울 뿐만 아니라 그다지 유용하지 않은 것 같습니다.

[Wonderer]

저는 굳이 성공이냐 실패이냐를 판단하자면 실패에 가깝다고 봅니다.

고객의 필요로 인해 만든 제품을 고객이 만족하지 못한다면

개발팀은 정말 비효율적이고 낭비투성이의 제품을 만든 셈이 된 것 아닌가요?

 

오히려 고객은 만족했으나 개발팀이 프로젝트에 많은 불만을 갖게 된 경우

이 프로젝트는 성공일까 실패일까 판단하기 힘들군요.

 

물론 가장 좋은 것은 둘 다 만족하는 것이겠지만요.

 

 

---

From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of bonna choi
Sent: Thursday, December 25, 2008 11:51 AM
To: xp...@googlegroups.com

Subject: Re: 애자일 방법론 적용 실패 사례 공유

[gyehong park]

개발팀과 고객의 평가가 다른 상황이 생기면 실패한 프로젝트라고 생각이 되네요.

개발팀과 고객은 한가지 목표를 공유한 "팀"이 되어야겠죠.
한 팀내에서 개인적으로 프로젝트에 대한 평가는 달라질 수 있지만, 팀의 프로젝트 평가는 동일해야합니다.
(url 내용이 그렇게 하기 위한 방법을 다룬 내용이죠? 이눔의 영어.......)

2008/12/27 Wonderer <won...@gmail.com>

[gyehong park]

Lessons Learnd (51')

• Lack of cohesive vision of the system - it was only through inspect and adapt that this was revealed
• No clear customer representative that understood what the system needed to do end to end, which ties back to vision
• The person that we worked with would provide the team direction of functionality and it was not until late in the project when the actual users of the functionality raised the issue that the functionality did not meet their needs
• The customer project manager did not take on the role of project owner, so we relied on the primary business user
• The customer project manager was money and time focused, the business user was feature focused - bad combination
  
• Customer did not review the system when they said they did
• Customer did not understand the process and the impacts their had
• They agreed to take a direction and then move on
• They did not understand the impacts
• We later found they would not be accountable
  
• Release plan
• we failed to communicate early and clearly where the line was on the product backlog and
• we failed to associate how the line would move up(reduced functionality) due to increases in taxes
• We failed to hold them accountable to their decisions, many times
• It was not that we did not document the decisions (and we could have done a better job documenting them), because we had the data, however when push came to shove, it was our fault it was not delivered

In Summary

• Learn from your mistakes and try to not repeat them
• Have the courage to confront uncomfortable truths early
• Ensure the customer and stakeholders dearly understand their roles in an agile project
• Defer the project start date until they are fully committed
• OR use an alternative model and start immediately, with a clause to switch to value driven once change rears its ugly head
• Manage the Product Backlog and release plan
• Accept that project costs are what they are - fooling yourself into thinking you can make cuts is just that, fooling yourself.

2008/12/27 gyehong park <gyeho...@gmail.com>

[신병호]

저는 비즈니스에 도움이 되지 않는 프로젝트의 종료가 프로젝트의 실패라고 생각되네요.

 

같이 스테이크를 먹는 분들이나 고객이 만족을 못해도 비즈니스에 득이 되면 실패가 아니겠지만...

그런 경우는 없을테니 보통 실패가 되겠네요.

 

 

 

----- Original Message -----

From : gyeho...@gmail.com

To : xp...@googlegroups.com

CC :

Sent : 2008-12-27 02:32:03

"약속과 사죄에는 목숨을 걸어라..."

[Youngrok Pak]

2008/12/18 강석천 <free...@gmail.com>

근데.. 애자일 성공 사례가 그렇게 많았나요?;; 주변 분들 이야기 들을 때면 맨날 '힘들다' '기존 팀 사람들과 충돌중이다'
'는 이야기였는데;;

늦었지만 이 이야기에 답글을 좀 달면..

저도 Wonderer님의 첫 글을 봤을 때 석천님과 비슷한 느낌을 받았습니다. 눈 씻고 찾아봐도 국내엔 애자일 성공 사례가 거의 없는 것 같은데 왜 저런 말씀을 하실까 하는 의문이 들었죠. 창준님 같은 분은 컨설팅을 해서 여러 팀을 보시니까 성공 사례를 많이 보셨겠지만 대개의 개발자들이 접하는 사례란 자기 주변 아니면 블로그나 커뮤니티에서 접하는 사례가 전부일 것입니다. 그런데, 커뮤니티 등에서 공개된 애자일의 성공 사례는 국내에는 참 드물죠. 인정할 만한 사례는 최근에 xper 메일링에 올라온 버스 시스템 구축 사례가 유일한 사례가 아닐까 싶습니다. 그래서 그런 내용을 공유해주신 분이 참 고마웠죠. 그런 면에서 전 오히려 창준님 같은 분이 성공 사례들을 좀더 많이 공유해주시면 좋겠다는 생각이 들기도 합니다.

그렇지만 한 편으로는 Wonderer님의 심정도 이해가 갑니다. 뭔가 애자일 해보다가 잘 안된 이야기를 커뮤니티에 올리면 애자일을 잘못 이해하고 적용했다는 말을 듣는 경우가 꽤 많죠. 페어프로그래밍은 그렇게 하면 안돼. 이건 TDD가 아니야. feedback은 그런 뜻이 아니라고! 등등. 다소 공격적인 반응을 맞게 됩니다. 설령 말은 부드럽게 하더라도 어쨋든 내용은 "니가 잘 모르고 적용해서 그래"라는 경우가 많죠. 그래서 "이 인간들은 정말 애자일을 해서 잘 성공하고 있는 거야? 좀더 솔직하게 실패 사례를 이야기해줄 인간은 없나?" 하는 생각을 하기도 하는 것 같습니다.


그러나, 또 한 편으로는 그렇게 공격하는 사람들도 이해가 됩니다. 그 이유는 두 가지입니다. 하나는, 실제로 애자일을 제대로 이해하지 못한 상태에서 적용하는 경우가 많다는 것입니다. 석천님이 뒤에 다시 제기했던 사례들이 그런 경우죠. 코에 걸면 코걸이, 귀에 걸면 귀걸이라고 자기 팀에 맞게 커스터마이즈했다는 명목으로 원래 프랙티스의 뜻을 살리지 못한 채 변형시켜버리는 경우가 많더군요. 얼핏 예를 들어봐도

 * Daily Standup이 팀장의 연설 시간으로 변질되거나, 혹은 아침에 하는 1시간 짜리 회의로 변질되는 경우
 * 삼투적 커뮤니케이션을 장려하는 War room을 만들겠다고 인구 밀도에 대한 고려 없이 사람들을 다닥다닥 붙여 놓는 경우
 * daily release를 하겠다고 버그 투성이인 제품을 매일 고객에게 보내주는 팀 (저도 이런 적이 있죠-_-)
 *  User Story를 한다면서 스토리를 todo list로 쓰는 팀, 스토리의 추정치를 반드시 해내야 하는 확정 기간으로 받아들이는 리더
 * 위에 잠시 언급된 스프링노트 사례에서 '애자일하다'를 '좋다'로 이해하는 상황

이런 것들이 바로 생각이 나는 군요. 한 10분만 더 생각하면 스무 개 쯤 쏟아낼 수 있을 것 같습니다. 이런 사례들을 보면 저도 모르게 악플을 달고 있는-_-a  머 어쨋든, 이렇게 애자일 방법론을 제대로 이해 못한 상태에서 적용하면 효과를 볼 리가 만무합니다. 위험성이 있는 프랙티스도 많구요. 실제로 게시판 등에 상담(?)으로 올라오는 사례들을 보면 이런 사례가 허다합니다. 그래서 그런 공격적인 댓글들을 보게 되는 것이죠.

그리고 또 하나의 이유는 그런 상담건들은 표현 자체가 책임을 프랙티스나 주변 상황으로 돌리는 경우가 많기 때문입니다. 다음과 같은 경우들이죠.
 * 우리팀은 이러이러한 상황이니까 그런 프랙티스는 적용할 수 없어,
 * 이 프랙티스는 오히려 신뢰를 깨뜨리기만 하던 걸?
 * 이런 프로젝트는 오히려 애자일 하면 더 안 좋아.

요컨대, 애자일에 결점이 없고 제대로만 하면 무조건 성공이라서 그런 공격적인 반응들이 나오는 게 아니라, 애자일을 제대로 적용하지 않은 사례가 실제로 많기도 하고, 또 반대로 실패의 책임을 애자일로 돌리는 것 때문에 애자일홀릭들의 반격을 받는 게 아닌가 싶습니다.


여기까지가 제가 Wonderer님이 처믕 쓰신 글에서 1번 질문에 대해 하고 싶은 대답입니다. 2, 3번 질문은 특별히 그게 궁금했다기보다 1번 질문의 연장선 상에 있는 것 같아보이구요. 이미 그 답도 알고 있으시리라 생각됩니다.


한 가지 덧붙인다면, Wonderer님이 보셨던 공격적인 반응을 한 사람들 모두가 애자일을 성공적으로 적용하고 있는 것은 아닐 것이라는 점을 말하고 싶습니다. 저 역시도 5년 간 애자일 방법론을 활용해왔고 팀 사정상 안될 경우에는 혼자서 하는 프랙티스라도 써오고 그랬지만 아직 남들에게 뚜렷하게 자랑할 만한 성공 사례는 없습니다. 제 주변에 애자일 좋아하는 사람 많습니다만 어느 누구도 만족스럽게 적용하고 있지 못합니다. 재야에 숨은 고수팀들이 애자일을 잘 적용하고 있는지는 모르겠으나 드러난 사례는 거의 없다고 보는 게 맞을 겁니다. 애자일이 캐즘을 넘었다는 이야기가 나오기도 하지만 아직은 먼 나라 이야기인 듯 합니다.

어쨋든 아직도 애자일 모임에서 화두가 애자일의 적용인 걸 보면 애자일 방법론이 적용하기 참 어려우면서도 또 포기하기 힘든 매력이 있는 방법론인가봅니다.


p.s. 이 글을 보고 뭔 소리야 이렇게 성공사례가 많은데! 하면서 성공 사례를 좌아악 보여주는 답글들이 달리면 참 좋겠다는 생각이 드네요.

[강석천]

agile anti-pattern 을 모아봐도 재밌겠다는 생각이 듭니다.;;

ex) A 모 회사 모팀 페어 사례 : 페어로 팀장과 팀원이 페어하는데 맨날 주니어 실수하면 윽박지르고 '이런것도 틀리냐' 큰소
리 칩니다. 그 덕에 주니어는 점점 맹점 모드 (Blind spot)에 빠집니다. 하다못해 평소 일상적으로 쓰던 svn 커맨드라
인 명령까지 틀리고, 시니어는 다시 '이런 것도 틀려!' 하며 수정하고, 주니어는 점점 더 맹점 모드로 빠져서 시니어가 답을 해
주기 전까진 한 줄도 진도를 나갈 수 없는 식이 됩니다.

완화책 : 명시적으로 이야기하진 않았지만, 저랑 둘이 작업할 때, 저는 그 사람에게 주로 솔로 작업 시간을 주었습니다. 저랑 작
업할 때 솔로 : 페어가 한 70 : 30 정도 되었는데, 그 사람이 제게 '같이 작업할 시간이 더 많은게 좋았을 것 같아요'
하더라는..

나중에 그 팀원분께 Blind Spot 책을 건내드렸습니다.; 생각해보니 팀장분께 책을 건내드렸어야 했을 것 같은..

On 12월27일, 오후3시00분, "Youngrok Pak" <pak.young...@gmail.com> wrote:
> 2008/12/18 강석천 <free1...@gmail.com>

[아샬]

안티패턴 재밌네요 :)

2008년 12월 28일 (일) 오후 3:29, 강석천 <free...@gmail.com>님의 말:

[Wonderer]

안티패턴 정말 괜찮은 아이디어인 것 같습니다.

-----Original Message-----
From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of 강석천
Sent: Sunday, December 28, 2008 3:29 PM
To: xper
Subject: Re: 애자일 방법론 적용 실패 사례 공유

[Jake J. Kim]

안녕하세요.

Ailge 에 대해서 배우고 싶고 의견교환을 많이 하고 싶은 새로 가입한 풋내기입니다.

처음으로 제 생각을 적어 봅니다.

무엇이든지 너무 맹신하면 득보다는 실이 더 많은것 같습니다.

방법론이라는게 "론"이지 과학이 아니거든요. 가설을 세우고 그를 뒷받침할 실험을 하고 수치적으로 결과를 내서 그 가설을 입증할
수 있는 과학이 아니지 않습니까.
수 많은 프로젝트 경험을 바탕으로 "이렇게 하면 잘 되더라" 하는 것이지 수치적으로 과학적으로 증명을 할 수 있는 성격의 것이
아니니까요.
조직에 따라, 조직의 구성원의 특성에 따라, 그리고 해당 프로젝트, 또는 그 조직이 속한 산업에 따라 Agile 이나 XP에서
권장하는 똑같은 방법을 적용해도 안 될 가능성은 충분하다고 생각합니다. 세상에 똑 같은 상황은 전혀 없으니까요.

어느 방법론을 맹신하고 그대로 따라하려 하기 보다는 그 방법론이 지향하는 방법을 이해하고 현실에 맞게 적용하는 것이 더 중요하
지 않을까 싶습니다.

Agile을 제대로 모르고 적용을 잘 못해서 실패했다는 관점은 Agile을 제대로 이해하고 적용해서 성공했다는 관점 만큼이나 결
과론적인 것이 아닐까요.

Agile을 이해하는 만큼이나 그 조직이나 그 조직의 사업특성을 이해하는 것도 중요하지 않을까 생각합니다.

[강석천]

모든 공로를 애자일로, 혹은 모든 책임을 애자일로 돌리는 건 그리 현실적이지 않은 것 같습니다. ^^ 잡지나 사이트에서의 애자
일 기사라면 당연히 기사 주제가 애자일이니까 애자일이 성공과 실패를 결정하는 것 같이 포장되지만, 중요한건 그 일을 '애자일 스
럽게 해온 사람들' 아닌지요.

위의 '애자일' 을 다른 단어로 바꿔도 마찬가지일 듯 합니다. UP 이건, CMMI 이건, Test 이건..

* 저희 회사에선 프로세스가 뭐냐고 이야기하면 'Waterfall' 이라고 합니다. ;) 그리고 그 Waterfall 로 8
년 이상 유지되어왔고요. 물론 순수 Waterfall 일 리가 없고요.; WBS 그릴 때 기본 모델 틀이 Waterfall 이
라는 겁니다. 당연 팀히 간 협업도 있고 사람들 간 협업도 있고, 대화도 있고, 커피 마시고 담배 필 때 의견교환도 있고, 코
드 저장소도 있고, 프로젝트 단위의 중간 커밋 & 머징 & 태깅도 있고, 릴리즈도 있고 테스팅도 있고요. 개발 구현 중의 테스팅
도 있고, 위에서 언급한 말도 안되는 Pair 도 있고, 말도 안되는 Testing 도 있고요..;

만일 회사에서 프로젝트가 실패 했다면 'Waterfall' 이 문제일까요? ;)