애자일 개발의 이점은 ‘애자일’을 둘러싼 아우라에서 나오는 게 아니다. 표 2-1에 나열된 애자일에서 강조하는 것들의 효과는 쉽게 이해할 수 있다. 릴리스 주기가 짧으면 오류 수정을 더 시기적절할 때 더 적은 비용으로 할 수 있고, 막다른 길에서 낭비하는 시간을 줄이며, 보다 즉각적인 고객 피드백, 신속한 절차 수정, 수익 증대와 운영비용 절감을 위한 경로 단축 등이 가능하다. 소규모 배치로 수행되는 엔드투엔드 개발 작업 역시 유사한 이유로 이점을 제공한다. 즉, 더 엄격한 피드백 루프를 통해 보다 낮은 비용으로 오류를 더 빨리 감지하고 수정할 수 있다.
---「2장 오늘의 애자일」중에서
그동안 효율적으로 정착된 스크럼보다 비효율적으로 돌아가는 스크럼을 더 많이 봤다. ‘조건부 스크럼’Scrum-but이 가장 비효율적이다. “우리는 스크럼을 해, 하지만 어떤 주요 실천법은 사용하지 않아.” 예를 들면, “우리는 스크럼을 해, 하지만 일일 스탠드업은 하지 않아.” “우리는 스크럼을 해, 하지만 회고는 하지 않아.” “우린 스크럼을 해, 하지만 프로덕트 오너는 없어.” 등이 있다. 비효율적인 스크럼을 구현한 곳은 일반적으로 최소한 하나 이상의 스크럼 필수 속성을 제거했다.
---「4장 스크럼의 기쁨과 슬픔」중에서
스크럼의 애자일 실천법은 스크럼팀을 명시적으로 ‘블랙박스’로 취급한다. 만약 당신이 조직의 리더라면 팀의 투입과 산출은 볼 수 있지만, 팀 내부 업무에 대해서는 크게 신경 쓰지 말아야 한다. 스크럼에서 이러한 아이디어는 팀이 각 스프린트를 시작할 때 정해진 양의 작업(스프린트 목표)을 수행한다고 말함으로써 구현된다. 팀은 스프린트가 끝날 때까지 무슨 일이 있어도 작업을 완수할 것을 약속한다. 그런 다음, 팀은 스프린트 기간 동안 블랙박스로 취급된다. 아무도 내부를 들여다볼 수 없고, 누구도 스프린트 중에 일감을 더 넣을 수 없다. 스프린트가 끝나면 팀은 처음에 약속했던 기능을 전달한다. 스프린트가 짧기 때문에 관리자는 팀이 약속을 지켰는지 확인하기 위해 기다릴 필요가 없다.
---「5장 애자일팀 구조」중에서
수직 슬라이스를 이용하면 일반적으로 비기술적 이해관계자 입장에서 비즈니스 가치를 이해하고, 관찰하고, 평가하기가 더 쉽다. 수직 슬라이스는 팀이 더 빨리 릴리스하고 실제 비즈니스 가치와 실제 사용자 피드백을 실현할 수 있는 옵션을 만든다. 수평 슬라이스에 초점을 둔 팀은 여러 스프린트에 해당하는 일을 한번에 수행하며 절망적인 길을 걷게 될 수도 있다. 어떤 의미에서는 ‘생산적인’ 스토리를 만들지만, 관찰할 수 있는 비즈니스 가치를 창출하지는 못한다.
---「9장 애자일 프로젝트」중에서
이렇게 비즈니스 가치와 개발 비용 간의 관계를 형성함으로써 비기술 이해관계자는 “스토리 B의 비즈니스 가치는 스몰이기 때문에 만약 개발 비용이 라지라면 없어도 됩니다”라고 말할 수 있다. 이는 스토리 정교화 초기 단계에 내릴 수 있는 엄청나게 유용한 의사결정이다. 어느 정도의 정제, 아키텍처, 디자인 작업 등을 거쳐 스토리를 전달하더라도 결과적으로는 비용을 정당화할 수 없는 스토리에 노력을 쏟는 수도 있다. 소프트웨어에서 빠른 ‘아니오’의 가치는 높다. 티셔츠 사이즈를 활용하면 스토리를 전달하지 않고도 프로젝트 초기에 스토리를 배제하는 의사결정을 할 수 있다.
---「14장 애자일 요구사항 우선순위 매기기」중에서
앞서 언급했듯이, 애자일 개발은 계산된 실수를 하고 거기에서 배우며 개선을 도모하는 학습 주기인 검토와 적용을 주요하게 사용한다. ‘계산된 실수’란 결과에 자신이 없다는 것을 알면서도 결정을 내리고 결과에 상관없이 결과에서 배우는 일에 주의를 기울이는 것을 의미한다. 커네빈 용어로 난해한 프로젝트는 적은 수의 계산된 실수를 만들고, 복잡한 프로젝트는 많은 수의 계산된 실수를 만든다. 그러니 조직은 오류를 감추고, 수치스러워하고, 조직에 유해한 것으로 치부할 게 아니라 시각화하고, 검토하고, 궁극적으로 조직에 유익하도록 오류를 처벌하지 않아야 한다.
---「17장 애자일 조직 문화」중에서