이러한 변화에도 불구하고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. 많은 기업, 개발팀들이 애자일 전환 전에도 있던 문제들이 전환 후에도 여전하다. 릴리즈된 제품에 수정사항을 적용하는 데도 너무나 오랜 시간이 소요된다. 여전히 과거의 기술적 부채에 허덕인다. 처음부터 애자일로 시작한 프로젝트임에도 기술적 부채가 쌓인 경우도 있다. 동기부여도 큰 문제다. 품질보증(QA) 담당자가 아직도 개발팀 주위를 돌아다니고 전화를 돌리고 독촉메일을 보낸다. 각 개발 반복 주기마다 별도의 테스트 기간(며칠에서 몇 주)을 갖는 일도 여전히 많다. 애플리케이션을 변경하는 일은 상당히 고통스럽다. 코드 베이스는 엉망진창이어서 진척도를 높이는 데 발목을 잡는다. 버그 목록은 줄어들지를 않는다. 담당자가 아니면 이해할 수가 없어 모두가 수정하기를 꺼리는 코드들도 여기저기 숨어있다. 아직도 디버깅과 로그 파일 분석만이 뭐가 어떻게 돌아가고 있는지 파악할 수 있는 주요 수단이다. 관리자들은 개발한 지 겨우 몇 년밖에 안 된 애플리케이션인데도 기능 추가/수정 비용이 너무 많이 들고 비즈니스를 어렵게 한다는 이유로 통째로 버리고 새로 만드는 카드를 만지작거린다.

애자일 방식으로 개발한 애플리케이션임에도 불구하고 애자일 도입 전과 마찬가지로 설계도 잘못되었고 복잡한 데다가 버그도 많다. 상황이 이렇다면 비즈니스가 절실하게 요구하는 변화들을 제대로 수용할 수 없다. 개발자 입장에서는 절차와 소통 방식이 개선되었지만 실제 기술적인 산출물은 바뀌지 않는다. 심지어 이전의 문제들이 그대로, 똑같이 나타난다. 정체된 개발자 역량, 낮은 수준의 동기부여, 잔뜩 쌓여 있는 기술적 부채, 기술적 전문성 부족, 신뢰할 수 없는 릴리즈 절차, 불안정한 시스템, 늦은 버그 발견, 신뢰할 수 없는 데다가 비싼 테스트, 비효율적인 개발/디버깅/배포 주기, 오래 걸리는 빌드, 난해한 요구사항 등이 여전히 존재한다. 시장에서 문제가 나오면 “도대체 뭐가 잘못된 거지? 그런 제품은 판 적이 없는데?”라고 한탄한다. 애자일을 도입하여 모든 절차를 뒤바꾸는 궁극적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다. 그 목적을 달성하지 못하면 이 노력들은 모두 허사다.