Agile 방법론
Agile 방법론이란?
이전 Section에서 우리는 Waterfall 방법론에 대해 배웠다.
그렇다면 Waterfall Model의 가장 큰 단점이 무엇일까? 바로 이전 단계로 돌아갈 수 없다는 Waterfall 모델의 특성상 고객의 요구사항이나 돌발 상황에 대처하기 어렵다는 것이다.
Agile 방법론은 Waterfall Model의 단점을 해결하기 위해 나온 개발 방법론으로써 "문서화" 중심의 개발을 버리고 "고객과의 소통"을 중심으로 하는 개발 방식이다.
궁극적으로 Agile은 고객과의 소통을 통해 "고객의 변화에 대응하는 것"을 가장 큰 목표로 두고 있는 개발 방법론인 것이다.
고객과 소통을 하면서 개발을 진행한다면 고객은 SW를 실시간으로 확인 가능하기 때문에 프로젝트의 진행상황을 빠르게 확인할 수 있다. 또한 고객이 직접 기능을 활용해 보며 느낀 누락된 요구사항이나 추가되는 요구사항들에 더욱 빠르게 대응할 수 있어 더욱 완벽한 SW를 만들 수 있을 것이다.
개발 중인 SW는 항상 고객에게 공개되어 있기 때문에 고객의 기대치와 개발팀의 SW 수준의 간극이 커질 때쯤 피드백을 통해 간극을 줄이는 작업을 수행할 수 있으므로 고객의 기대치와 비슷한 수준의 SW를 만들 수도 있을 것이다.
애자일 선언문을 통해 본 애자일
2001년 SW 엔지니어 업계의 리더들이 모여 "애자일 선언문", 정확히는 애자일 소프트웨어 개발 선언문을 발표했다.
이 애자일 소프트웨어 개발 선언문이 애자일 기법을 가장 잘 설명하는 4문장이라고 할 수 있겠다.
위 사진에 나오는 4문장이 애자일 선언문인데, "왼쪽에 있는 것들보다 오른쪽에 나온 것들이 더욱 높은 가치를 가진다"는 것이 핵심이다.
여기서 착각하면 안되는 것이 왼쪽에 있는 것들이 필요 없다는 것이 아니다.
당연히 왼쪽에 있는 "공정과 도구", "포괄적인 문서", "계약 협상", "계획"도 가치가 존재하지만, 이것들보다 오른쪽에 있는 것들에 더욱 큰 가치를 두는 것이 애자일 선언문이 말하고 싶은 바인 것이다.
애자일 선언문에 대해서는 나중에 한 번 제대로 분석해 볼 가치가 있기 때문에 공부가 어느 정도 끝나면 제대로 분석해보도록 하자. 일단 지금은 왼쪽은 Waterfall Model에서 중요시하는 가치들, 오른쪽은 Agile 방법론에서 중요시하는 가치들이라고만 이해하고 넘어가자
애자일 방법론 수행 방법
Agile 방식은 짧은 주기로 작은 개발 단위를 반복하며 하나의 프로젝트를 완성해 나가는 방식이다.
블로그를 만든다고 할 때 Waterfall Model은 처음에 블로그에 추가하고 싶은 기능을 모두 파악하지만 Agile 방식에서는 Blog의 틀과 기본적인 기능들만 구현하여 고객에게 제공하고, 고객은 SW를 사용하며 생기는 추가적인 요구사항을 통해 좀 더 완벽한 Software를 만들어나가는 것이다.
Agile 방식에서 "짧은 단위의 작업 계획"을 Sprint라고 한다. 그리고 Sprint가 끝날 때마다 나오는 결과물을 Release(릴리즈)라고 한다.
애자일 개발 방법론은 1개의 Sprint가 끝날 때마다 1개의 Application이 만들어진다고 볼 수 있다.
즉, 애자일 개발 방법론에서는 Software가 언제나 구현되어 있는 상태임과 동시에 항상 완벽히 구현되어 있지는 않은 상태인 것이다.
애자일 개발의 수행 과정은 위 사진과 같다.
1개의 Sprint는 "Discover → Design → Develop → Test" 과정으로 이루어져 있으며 Test 과정이 끝나면 SW(릴리즈)가 생성된다. 개발팀은 Sprint를 여러 번 수행함으로써 점점 완성도 있고 품질 높은 SW를 만드는 것이다.
결국 Sprint는 Waterfall Model의 축소판이라고 보면 된다.
Discover를 통해 "이번 Sprint"에서 해결해야 할 요구사항들을 파악한다. 그리고 이 요구사항을 어떤 방식으로 해결할지 Design, 즉 계획을 짠다. 여기에서 말하는 계획은 모든 Sprint에 대한 계획이 아닌 이번에 실행할 Sprint 1개에 대한 계획이다.
계획이 다 짜졌으면 Sprint 계획에 맞도록 개발(Develop) 과정을 거치며 개발이 끝난 이후 Test 과정을 통해 올바르게 작동하는지 확인하였다면 즉시 배포하여 Software를 한 단계 발전시키는 것이다.
Agile 방법론 중 대표적인 Scrum 수행 과정을 통해 한 번 더 과정을 이해해보자. 먼저 특정 기간 동안 해야 할 목표와 필요 작업을 명시한다. 이후 Backlog(백로그)에 수행해야 할 내용과 개발이 완료된 내용을 적어 현재 Sprint 개발 상황을 파악할 수 있게 하고 Sprint가 끝나는 시점, 혹은 매일 Sprint 회의를 수행하여 함께 작업에 대해 리뷰하고 피드백하며 개발에 직접적으로 참여하지 않은 다른 개발자들도 개발 내용을 이해하고 Software의 큰 그림을 이해할 수 있도록 하는 개발 과정을 거치게 된다.
비고
Agile은 엄밀히 따지자면 SW 개발 방법론은 아니다. 애자일은 수많은 SW 개발 방법론을 묶을 수 있는 큰 개념일 뿐이고 Agile 방법론에 속한다고 알려진 칸반, 스크럼 등이 SW 개발 방법론이다.
결국 Agile이란 SW 개발 방법론이라기보다는 고객의 요구사항에 즉시 대응할 수 있도록 짧은 Sprint를 가지는 SW 개발 방법론의 통칭, 혹은 범주라고 이해하는 것이 더욱 정확할 것이다.
애자일이 각광받는 이유
그렇다면 어째서 직관적이며 이해하기도 쉬운 Waterfall Model의 대안인 Agile 방식에 그렇도록 환호할까?
애자일 방식이 각광받는 이유를 확인하기 위해서는 먼저 Waterfall Model 개발 방식을 활용하는 팀 내의 개발자들의 피로도를 알아볼 필요가 있다.
개발자들은 PM, 혹은 고객들로부터 끊임없이 요청을 받을 것이다. 처음에는 없는 요구사항이었으나 고객 측의 단순 변심으로 인해 요구사항이 생성되거나 변경될 수 있고, 요구사항 명세서에 누락된 요구사항에 있을 수도 있으며, 정책이나 트렌드가 바뀌어 요구사항이 수정되는 경우도 발생할 것이다.
특히 정책이나 트렌드가 바뀌어 요구사항이 수정되는 경우 웃으며 넘길 수가 없는 문제이다. 지금 개발하고 있는 SW가 휴짓조각보다 가치 없는 결과물이 될 수도 있는 중요한 문제이기 때문이다
이런 추가 요구사항들을 만족하기 위해서는 당연히 개발 기간이 계획보다 길어질 수밖에 없다. 그리고 모든 Waterfall Model의 계획은 납기일을 기준으로 짜여있다.
이것이 무엇을 의미할까? 계획보다 길어진 개발 기간은 결국 납기일 지연으로 이어지게 된다는 것이다.
당연히 고객 측에서는 납기일 준수를 가정하고 있었을 것이며 고객의 추가적인 요구사항이 기존 Software를 뒤집는 수준이 아니라면 납기일 미준수는 온전히 기업의 책임이다. 결국 기업은 개발자들에게 강한 압박을 줄 수밖에 없다.
개발자들은 기업에서 주는 압박, 납기일에서부터 오는 압박, 끊임없는 야근과 해도 해도 줄어들지 않는 업무 등으로 인해 빠른 번아웃에 다다르게 된다. 이렇게 개발자를 갈아서 생성한 Software를 고객이 검수할 때 최종 결과물과 고객의 원하는 Software 수준이 차이 날 수도 있으며, 이를 해결하기 위해 다시 개발자를 갈아 넣어 간극을 줄이거나 계약 미이수로 인한 파기라는 최악의 결과로까지 이어질 수 있다.
추가로 Waterfall Model을 활용할 때는 새로운 기술을 적용하여 불확실성을 주는 것에 대한 부담감이 있기 때문에 개발자는 활용하던 기술만 반복하여 활용하는, 재미없는 개발 과정의 연속이 될 것이다.
Agile 방법론은 이런 문제를 해결할 수 있다는 기대를 받으며 등장한 방법론이다.
애자일 방법론이 가장 각광받는 이유는 "시장의 빠른 변화에 대한 적응력"과 "고객의 요구사항에 대한 수용력"이라고 볼 수 있겠다.
개발자들은 Waterfall Model 방식으로 개발하면서 고객의 요구사항을 전달받아 완벽히 분석하는 것이 사실상 불가능하다는 것을 깨달았으며, 동시에 모든 개발 일정은 계획대로 수행될 수 없다는 것도 체감했다. 추가로 과거에는 기술의 발전이 더디고 시장의 변동성이 적었으나 최근에는 기술의 발전이 매우 빠르며 이에 영향을 받아 시장의 변동성이 매우 커졌기 때문에 고객의 추가 요구사항이 발생할 빈도 또한 크게 증가했다.
결국 고객의 추가 요구사항이나 시장의 트렌드에 대한 즉각적인 피드백이 더욱 중요해졌고, 이런 문제를 (이론적으로) 완벽히 해결할 수 있는 Agile 방법론이 각광받게 된 것이다.
개발자들의 역량이 높아졌다는 것도 Agille 개발 방법론이 각광받는 이유 중 하나이다.
과거에는 개발자의 역량이 (지금보다는) 높지 않아 기능 1개를 구현하는데 오랜 시간이 걸렸다. 따라서 과거에는 Agile 방법론을 활용했다 하더라도 추가 의견 반영에 오랜 시간이 걸렸을 것이며, 이 경우 Agile 개발 방법은 개발 일정에 대한 관리도 어려운데 즉각적인 피드백 반영도 안 되는 쓰레기 방법론에 불과했다.
하지만 최근에는 개발자들의 역량 자체가 높아져 개발 기간이 짧아졌고 SW와 HW 발전 또한 빠른 개발에 큰 도움을 줬다. 추가로 협업 기술 또한 증가하여 협업 환경이 좋아졌고, 소통에 걸리는 시간을 줄여 개발 기간이 축소되었으며 이는 즉각적인 피드백을 가능하게 했다.
Agile 방법론 실제 사례
애자일 방식은 Microsoft의 익스플로러 개발(IE)에 적용되면서 처음 존재감을 뽐냈다. 마이크로소프트는 (지금은 사장된) IE3(인터넷 익스플로러) 개발이라는 프로젝트를 추진한다. 이때 마이크로소프트는 기본적인 기능만 수행되도록 SW를 만든 뒤 짧은 기간 내에 첫 시제품을 내놨다. 이후 프로젝트 팀은 계속해서 들어오는 사용자 피드백을 듣고 SW에 기능을 계속해서 추가함으로써 SW를 진화시켰다. IE3는 계속해서 발전하였고, 사용자는 발전되는 IE3에 대해 계속해서 자신이 원하는 기능들을 요구하였으며 이런 요구사항은 다시 IE3를 발전시키는 선순환이 발생하였다.
Microsoft 입장에서는 전체적인 틀만 만들어 놓고 세부 기능은 고객이 요청할 때마다 구현하면 되기 때문에 일정에 대한 부담감이 없었으며 고객의 요구사항이 곧 트렌드이기 때문에 시장에 대한 분석에 시간을 많이 쏟지 않아도 트렌드에 부합하는 SW로 발전시킬 수 있었다. 고객 입장에서도 자신이 원하는 기능을 바로 요구할 수 있으며 기능이 즉시 적용되며 만족도를 실시간으로 평가할 수 있다는 점에서 User 친화적인 브라우저라고 느낄 수 있었고, 이는 IE3의 점유율을 높이는데 큰 역할을 했다.
결국 이런 선순환은 최종 출시된 IE3를 출시 3년 만에 웹브라우저 시장의 80%를 차지하는 결과를 가져왔다.
Agile 장점
유연성
Agile 방식은 각 팀이 자율성을 가지고 있다는 특징을 가지고 있다.
기능만 구현된다면 각 팀이 채택한 방법과 계획에 대해서 전적으로 신뢰한다는 의미이다.
이런 점에서 항상 사용하던 방식만 활용해야 했고, 좋은 아이디어가 있더라도 상사나 다른 팀에서 반대하면 사용하지 못했던 Waterfall Model의 단점을 해결할 수 있었다.
Agile 방식은 많은 고객과의 소통을 통해 즉각적인 피드백을 받을 수 있으므로 신기술을 적용했을 때 반영한 기술이 잘 작동되는지 실시간으로 확인하면서 빠른 피드백이 가능하기 때문에 새로운 기술을 접목시키는 데에 부담감이 적고, 기술의 도입에 있어서도 유연한 개발 방법이라고 할 수 있다.
Agile 방식은 고객의 요구사항을 즉시까지는 아니더라도 빠른 시일 내에 처리할 수 있는 개발 방법론이다. 따라서 트렌드에 대해 빠르게 대처 가능하며 계획하지 않았던 사태가 터지더라도 유연하게 문제를 처리할 수 있다는 점에서 사건사고나 급변하는 시장 상황에 대해 유연성을 가지고 있다.
Agile 방식은 매일, 혹은 Sprint가 끝나는 시점마다 회의를 통해 개발 과정을 공유한다.
즉, 개발에 직접 참여하지 않더라도 풍부한 커뮤니케이션을 통해 전체 프로젝트 및 개발한 기능들에 대한 이해가 동반되어야 하는 개발 방식이다.
커뮤니케이션을 통한 상황 공유는 프로젝트에 대한 이해도 상승이라는 장점을 가지고 오며, 이는 다른 팀의 개발에 참여하거나 도와줘야 할 때도 빠르게 적응할 수 있다는 장점을 가지고 온다.
높은 비즈니스 가치
요즘 시대에서 가장 가치 있는 것은 무엇일까? 나는 "데이터"라고 생각한다.
그렇다면 데이터 중 가장 가치 있는 것은 무엇일까? 나는 "고객이 주는 데이터"라고 생각한다.
실제로 고객이 주는 데이터는 곧 수익을 의미한다.
시장이 변화하는 것은 시장이 의지를 가지고 있어 바뀐다기보다 고객들의 생각이 점차 바뀌며 생각이 바뀐 고객의 비율이 어느 정도 넘어갔을 때 시장이 변화한다고 느끼는 것이다.
치킨을 예로 들어보자.
예전에는 BHC, BBQ 등 프랜차이즈 치킨집에서 사 먹는 치킨이 매우 유명했다. 하지만 최근 트렌드는 반값 치킨이라고 불리는 이마트, 홈플러스에서 나오는 저가 치킨이 큰 각광을 받고 있다.
물론 이 흐름에서는 고물가 시대, 그리고 어려운 경제 상황이라는 사회적 상황도 반영되었을 것이다.
하지만 궁극적으로는 "치킨은 서민 음식이었는데 너무 비싸졌다"라는 생각이 흐름을 조금씩 변경시킨 것이다.
그리고 이 흐름은 최근에 갑자기 발생한 흐름이 아닌 파도와 같이 점차 커진 흐름이었다.
만약 치킨을 좋아하는 고객들(치킨을 좋아하는 사람들의 블로그 등)으로부터 실시간으로 데이터를 받았다고 가정해보자.
데이터를 받은 사람들은 점차 고객들이 최근 치킨이 너무 비싸다는 생각이 많아졌음을 깨닫게 될 것이고 자연스럽게 가격이 싼 치킨을 팔면 수요가 있지 않을까?라는 생각을 하게 될 것이다. 그리고 이를 실제로 실행시킨 결과는 우리도 봤다시피 뉴스에서까지 대서특필한 저가 치킨 시대의 도래였다.
이런 예시로 봤을 때 고객이 주는 데이터는 생각한 것 이상의 가치를 가지고 있다.
조금 이야기가 샜지만, Agile 방식은 "고객의 피드백"을 통해 끊임없이 발전하는 Software를 개발하는 방법이다
즉, 실제로 사용할 고객들이 아무런 대가 없이 데이터를 제공하는 것이다.
기업 입장에서는 돈 주고도 못 얻을 수 있는 "고객의 데이터"를 매우 저렴하게 얻을 수 있으며, 이를 통해 SW를 고객의 Needs에 맞게 개발할 수 있게 된다. 고객들은 이렇게 발전된 SW를 활용해보며 매우 편리함을 느끼고 SW를 사용하게 될 것이다. 이 과정에서 불편함을 느끼면 고객은 요구사항을 제출할 것이고, 이 요구사항을 개발하여 SW를 진화시킨다면 새로 개발한 기능에 끌린 새로운 고객을 얻을 수 있는 선순환이 벌어지는 것이다.
급변하는 Trend를 주도하는 고객에게 직접 데이터를 받아 처리할 수 있다는, 그래서 Trend를 뒤따라가는 후발주자가 아닌 Trend가 되기 전 한 발 앞서 선두주자가 되어 잠재고객들을 흡수할 수 있는 매우 가치 높은 개발 방식이 Agile 방식인 것이다.
고객의 만족도에 최우선을 둔 개발
Waterfall 방식으로 개발을 진행하면 문서화에 집중하게 되고, 당연히 고객의 만족도에 초점을 두기는 어려워진다.
하지만 SW를 개발할 때 가장 중요시 여겨하는 것은 고객의 만족도이다
고객의 만족도를 의미하는 용어인 UX가 있을 만큼 SW 개발에 있어서 고객의 만족도는 매우 중요하다.
결국 SW라는 것은 고객이 사용하기 위해 만드는 것이며, 고객이 SW의 만족감을 느끼지 못해 사용하지 않는다면 종이 조각보다 못한 쓰레기가 되는 것이다.
Agile은 Waterfall Model에서 간과된 User의 만족도라는 지향점을 중요시하며 "고객 중심의 개발"을 목적으로 둔다.
이런 목적은 고객의 만족도 향상으로 이어지며, 위에서 말했듯 고객의 만족도 증가는 곧 수익의 향상과 잠재 고객을 실제 고객으로 만들 수 있는 선순환의 시작이 되기도 한다.
정리하자면, Agile 방식은 작은 단위로 개발을 수행하기 때문에 요구사항 반영이 쉬워지며, 고객의 요구사항이 빠르게 처리된다는 점에서 고객은 불편함을 최소한으로 겪으면서 SW를 활용할 수 있게 된다.
결국 고객의 만족도에 가장 큰 중점을 두며 SW를 개발할 수 있는, 현재 Trend에 가장 적절한 개발방식이 되는 것이다.
Agile 방식 단점
회사 및 팀 전체의 노력이 필요함
Agile의 가장 큰 단점이자 (최소한 한국에서) 잘 정립되지 못하는 이유는 나 혼자 잘해선 안 되는 개발 방법론이라는 것이다
Agile에서는 모든 팀이 자율성을 지니며, 현대 사회에서 자율성이란 곧 책임이라는 말과 동일하다.
모든 팀은 SW에 대한 책임이 존재하며 모든 팀원들은 프로젝트가 정상적으로 진행될 수 있도록 프로젝트에 참여하고 최선의 노력을 기울여야 한다.
만약 한 팀이라도 이런 노력이 동반되지 않는다면 모든 팀을 직접 관리하는 Waterfall Model보다 더욱 낮은 성능을 보이게 된다.
여기에서 이어지는 것이 Agile 방식은 기업이 Agile을 위한 문화를 도입해야 하는데 이것이 매우 어렵다는 점이다.
기업(특히 대기업)들은 기존에 존재하던 프로세스를 포기하기가 어렵다.
먼저, 대기업일수록 팀 크기가 크기 때문에 변화를 위한 비용이 많이 들고 변화를 빠르게 적용하기도 힘들기 때문에 충돌이 발생할 수 있다. 상자는 옮기기 쉽지만 아파트는 옮기기 어려운 것과 동일한 개념이라고 생각하면 된다.
두 번째로 편리함이다. 대기업일수록 임원진이나 관리자의 경력이 쌓여 있을 경험이 있다. 당연히 사람은 자기에게 편한 것을 선호하게 되어 있으며, 관리자들은 자신에게 편한 기존 프로세스를 버리고 처음 경험해보는 새로운 프로세스를 받아들이는데 거부감을 느낄 것이다.
세 번째로 안정성이다. Agile 방식은 각 팀이 자율성을 가지고 책임을 가져야 한다고 말했다. 그리고 책임을 가지지 않는다면 Waterfall Model 방식보다 낮은 성능을 보일 수도 있다. 안정적인 서비스 공급을 원하는 기업들은 당연히 실패할 가능성이 있으며 낯선 Agile보다는 익숙하며 실패 가능성이 적은 Waterfall Model 방식을 선호하게 되는 것이다
고객의 참여 요구가 필수적
애자일 방식을 한 마디로 표현하면 "테스트하면서 발전시키는 Software 개발 방식"이라고 말하겠다.
그렇다면 이 테스트는 누가 할까? 바로 고객이다.
Waterfall Model의 고객의 낮은 참여는 단점이 될 수도 있지만, 고객의 상황에 따라 오히려 장점이 될 수도 있다.
고객의 참여도가 낮다는 것은 다른 말로 고객이 굳이 개발에 참여하지 않아도 개발이 진행될 수 있다는 의미이기 때문이다.
애자일 방식은 고객 참여가 없다면 그저 품질 낮은 깡통일 뿐이다. 따라서 애자일 방식은 Sprint가 끝나고 Software Release가 발생할 때마다 고객은 직접 품질 확인을 수행하며 피드백을 제공해야 한다.
이런 과정은 바쁜 고객 입장에선 귀찮은 작업 혹은 시간을 빼앗는 작업으로 여겨질 수도 있다.
참여할 고객이 있으면 그나마 다행이겠지만, 고객의 참여 자체가 없는 경우가 존재할 수도 있다는 점도 고려해야 한다.
IE의 예시를 들어보자. 만약 Microsoft라는 회사가 아닌 중소기업에서 IE에 Agile방식을 도입했다면 성공적으로 끝났을까?
개인적으로는 IE를 개발한 회사가 "Microsoft"라는 이름 있는 회사였기 때문에 많은 베타테스터들이 모였으며 베타테스터들도 Microsoft이니깐, 신뢰감 있는 회사이니깐 기대감을 가지며 요구사항을 제출했다고 생각한다.
만약 신뢰감 없는 회사였다면 초기 브라우저를 활용한 베타테스터들은 쓰레기 브라우저라며 다시는 사용하지 않는, 그렇기 때문에 피드백을 받지 못하여 그저 초기 SW 상태로 남아 있다 조용히 사라졌을 수도 있을 것이다.
즉, Agile 개발 방법을 활용할 경우 SW의 완성도는 개발자의 실력도 물론 요구되겠으나 고객의 적극적인 참여에 의해 정해진다는, 고객의 참여 정도라는 제어할 수 없는 요소에 SW 완성도가 정해진다는 단점을 가진다.
너무나 잦은 변경
Agile에서 잦은 변경은 양날의 칼이다. 고객의 피드백을 빠르게 반영할 수 있다는 장점이 될 수도 있으나, 잦은 변경으로 인해 프로젝트의 큰 흐름이 너무 자주 변경된다는 단점이 될 수도 있는 것이다
1개의 기능을 기획할 때 디자이너와 기획자는 많은 고민을 한다.
어떤 디자인이 좋을까? 어떤 방식으로 작동하는 것이 좋을까? 어떤 방법을 활용해야 할까?
하지만 애자일 모델은 이런 계획에 상관없이 "다 사용해보고 가장 괜찮은 것을 쓰자!"라는 개발 방법론이다.
따라서 변경사항이 잦을 수밖에 없고, Sprint를 진행하는 과정에서 기존에 세웠던 계획이나 기획들이 망가질 수도 있는 것이다.
이는 Agile 방식이 너무 개발자 중심의 방법론이라는 단점과도 연결된다.
Agile 방식은 Sprint라는 짧은 기간 동안 고객의 여러 요구사항들을 충족시켜야 하기 때문에 개발자의 역량이 높아야지만 Sprint 기간 내에 개발을 완료할 수 있다는 점에서 개발자의 역량이 높아야 하는 개발 방식이다.
개발자의 역량이 높더라도 문제는 발생한다.
개발이라는 것이 개발팀만 존재하면 수행되는 것이 아니다. 디자이너팀도 존재할 것이고, 기획팀도 존재할 것이다.
그런데 Agile 방식을 활용할 경우 개발팀은 계속해서 Software를 수정하게 되며, 당연히 이 과정에서 디자인 콘셉트가 잦게 변경될 수 있고 기존에 세웠던 기획들도 망가질 수 있다. 이는 디자이너팀과 기획팀이 개발에 참여한다는 느낌보다는 들러리라는 느낌을 받을 수 있게 한다.
시간 불충분
Waterfall의 시간 부족 문제가 Agile에서 나타나지 않는 것은 아니다.
Agile의 작은 작업 단위인 Sprint 또한 작업 기간이 정해져 있다.(대부분 1주일 ~ 4 주일로 정해진다)
Agile에서는 Sprint의 결과물이 곧 시제품으로써 바로 제공되어야 하기 때문에 단일 스프린트 기간 동안 계획이 수행되지 못한다면 SW 출시에 차질이 생기는 것과 유사한 상황이 되는 것이다.
따라서 이런 문제를 해결하기 위해 팀은 진행되는 Sprint의 우선순위를 변경해야 하거나 비용(혹은 자원)을 추가로 투입하여 추가 Sprint를 확보해야 한다.
물론 Waterfall처럼 최종 납기일에 문제가 생기는 것은 아니고 고객의 요구사항에 대한 처리가 1주일 정도 미뤄지는 정도이기 때문에 큰 단점이라고 생각하지는 않는다.
