K-조직은 왜 애자일에 실패하는가 불확실성을 뚫고 성공하는 애자일 조직이 일하는 법 매월 수백만 명이 쓰는 토스의 송금 서비스와 쿠팡의 새벽배송은 수많은 실험과 실패에서 학습하는 피드백 루프에서 태어났다. 요즘 성과를 내는 조직은 처음부터 완벽한 서비스를 만들기보다는 서비스를 지속적으로 사용하는 유저의 리텐션을 높이는 데 집착한다. 이를 위해서는 실험이 필요하고 실패는 프로세스의 일부이다. 왜 수많은 조직이 애자일에 실패할까? 효과적인 애자일 조직의 목표는 ‘애자일’ 그 자체가 아니다. 수많은 실험과 실패에서 학습하는 피드백 루프를 만들어 불확실성을 뚫고 비즈니스에 성공하는 것이다. 저자인 스티브 매코널은 초기 애자일을 무조건적으로 좇던 강박에서 벗어나 비전과 우선순위에 따라 자율적으로 일하고 짧은 스프린트와 수직 슬라이스 배포로 성과를 내는 조직의 핵심 애자일 원칙 28을 설득력 있게 제시한다. 해결해야 하는 문제가 난해함보다 복잡함 영역에 있다고 얼마나 확신하는가? 이 책은 이에 따라 달라지는 요구사항의 생명 주기와 2주 단위의 단기 스프린트에도 상위 비즈니스 가치를 잃지 않는 스토리 매핑 전략으로, 성장 마인드셋을 갖고 있는 개인들이 함께 효과적으로 일하는 데 전념하는 조직이 되는 법을 알려 준다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 조직에 알맞은 애자일 경계는 무엇인가? 세부사항이 아닌 성과를 관리하고 있는가? 촘촘한 피드백 루프로 학습을 가속화하고 수정 비용은 최소화하고 있는가? 각 장 마지막에 실려 있는 ‘애자일 리더를 위한 To Do List’로 지금 바로 현 상황을 검토하고 실패 없는 애자일 실천법을 적용하자.

저자 : 스티브 매코널 Steve McConnell 20개 언어로 번역되어 전 세계적으로 백만 부 이상 팔린 베스트셀러 저자이자 컨스트럭스 소프트웨어Construx Software의 CEO이다. 저서《Code Complete 코드 컴플리트》는 역사상 가장 많이 팔린 소프트웨어 개발 서적으로 IT 업계의 아카데미로 비견되는 졸트상을 받았다. 개인, 팀, 조직의 전문성을 향상시켜 소프트웨어 프로젝트를 성공으로 이끄는 데 열정적이다. 컨스트럭스 소프트웨어에서 보다 효과적인 소프트웨어 개발 사례에 중점을 둔 교육 프로그램을 개발하며 컨설팅과 코칭을 제공하고 있다. 저서로《Rapid Development 프로젝트 쾌속 개발 전략》《소프트웨어 프로젝트 생존 전략》《Professional 소프트웨어 개발》《Software Estimation 소프트웨어 추정》등이 있다. ‘애자일’이 아니라 ‘효과가 있는 것’을 지지하며 ‘증거도 없이 과하게 약속하는 것’에 반대한다. 이 책에서는 애자일을 그 효과와 상호작용을 검증할 수 있는, 구체적인 경영 기법과 기술적인 실천으로 다뤘다. www.stevemcconnell.com 역자 : 백미진 LG전자에서 소프트웨어 개발자로 시작해 인하우스 컨설턴트와 애자일 코치로 일했다. 현재는 카카오에서 IT 서비스와 조직의 일하는 방식을 개선하고 더 나은 환경을 만들기 위한 다양한 시도를 하고 있다. 제품을 잘 만들어 시장에 선한 영향력을 발휘하고, 제품과 내가 함께 성장하며, 과정을 함께하는 사람들과 함께 성장하는 여정을 꾸리는 것을 모토로 애자일 코치라는 역할이 회사와 시장에서 자리 잡을 수 있도록 애쓰고 있다. www.banglab.com

비즈니스 리더들의 추천사 01 더 효과적인 애자일 1장 시작 조직은 애자일을 효과적으로 구현하지 못하고 있다 효과가 입증된 애자일 실천 방법 2장 오늘의 애자일 애자일이 순차 개발보다 더 잘 작동하는 이유 애자일 경계선 애자일 리더를 위한 To Do List 더 읽을 거리 3장 복잡성과 불확실성에 대응하기 커네빈 프레임워크 복잡한 프로젝트 성공하기: OODA 핵심 원칙: 검토하기와 적용하기 애자일 리더를 위한 To Do List 더 읽을 거리 02 더 효과적인 팀 4장 스크럼의 기쁨과 슬픔 핵심 원칙: 스크럼으로 시작하기 스크럼이 뭐야? 스크럼 기초 스크럼의 역할들 스크럼에서 흔히 겪는 실패 유형 스크럼에 실패하는 이유 스크럼 성공 요인 성공적인 스프린트 스프린트 시간 할당 스크럼 전환 문제 스크럼 점수표 스크럼에서 검토하고 적용하기: 일일 스크럼 다양한 실천법 애자일 리더를 위한 To Do List 더 읽을 거리 5장 애자일팀 구조 핵심 원칙: 교차기능팀 만들기 테스트 인력 조직 핵심 원칙: 테스터를 개발팀에 통합하기 운영 지원 조직 애자일팀은 블랙박스여야 한다 자율관리팀이 아니라면 애자일은 실패한다 일하는 공간 애자일 리더를 위한 To Do List 더 읽을 거리 6장 애자일팀 문화 핵심 원칙: 자율성, 숙달성, 목적성으로 팀 동기 유발하기 핵심 원칙: 성장 마인드셋 개발하기 핵심 원칙: 비즈니스 주도 개발하기 팀 역할 이론 애자일 리더를 위한 To Do List 더 읽을 거리 7장 분산 애자일팀 핵심 원칙: 피드백 루프 촘촘하게 하기 성공적인 분산 애자일팀 핵심 원칙: 개인이 아닌 시스템 고치기 애자일 리더를 위한 To Do List 더 읽을 거리 8장 개인과 상호작용 효율적인 조직은 개인의 성장을 지원한다 핵심 원칙: 개인 역량을 키워 팀 생산성 강화하기 소프트웨어 팀에는 의사소통 기술이 필요하다 애자일 리더를 위한 To Do List 더 읽을 거리 03 더 효과적인 일 9장 애자일 프로젝트 핵심 원칙: 프로젝트 작게 유지하기 핵심 원칙: 스프린트 짧게 유지하기 속도에 기반한 계획 핵심 원칙: 수직 슬라이스로 배포하기 핵심 원칙: 기술 부채 관리하기 번아웃을 피하는 작업 구조화 애자일 리더를 위한 To Do List 더 읽을 거리 10장 대규모 애자일 프로젝트 대규모 프로젝트에서 애자일은 무엇이 다를까? 브룩스의 법칙 콘웨이의 법칙 핵심 원칙: 아키텍처로 대규모 프로젝트 뒷받침하기 모든 지식은 말로 전달될 수 있다? 요구사항이 가장 문제 대규모 애자일 프로젝트 점수표 스크럼으로 시작하기 SoS와 SAFe 애자일 리더를 위한 To Do List 더 읽을 거리 11장 애자일 품질 핵심 원칙: 결함 감지 간격 최소화하기 핵심 원칙: 완료 정의 만들고 사용하기 핵심 원칙: 릴리스 가능한 품질 유지하기 재작업 줄이기 페어 프로그래밍과 몹 프로그래밍 애자일 리더를 위한 To Do List 더 읽을 거리 12장 애자일 테스팅 핵심 원칙: 개발팀이 만든 자동화 테스트 사용하기 코드 커버리지만큼 중요한 일 클라우드에 특화된 테스트 애자일 리더를 위한 To Do List 더 읽을 거리 13장 애자일 요구사항 만들기 애자일 요구사항의 수명주기 요구사항 손상 VS 요구사항 사전 정의 잘못된 시작과 막다른 골목 스토리 제품 백로그 요구사항을 제품 백로그로 만드는 법 핵심 원칙: 제품 백로그 정제하기 핵심 원칙: 준비 정의 만들고 사용하기 요구사항에 주의 기울이기 애자일 리더를 위한 To Do List 더 읽을 거리 14장 애자일 요구사항 우선순위 매기기 일 잘하는 PO의 조건 티셔츠 사이즈 스토리 매핑 유용한 기술들 애자일 리더를 위한 To Do List 더 읽을 거리 15장 애자일 전달 핵심 원칙: 반복적인 활동 자동화하기 CI/CD를 지원하려면? 학습 속도는 빨라지고 수정 비용은 줄어들고 실제로 지속적 전달을 실행하고 있는가? 애자일 리더를 위한 To Do List 더 읽을 거리 04 더 효과적인 조직 16장 애자일 리더십 핵심 원칙: 세부사항이 아닌 성과 관리하기 핵심 원칙: 지휘관의 의도로 명확한 목적 표현하기 핵심 원칙: 활동이 아닌 처리량에 집중하기 핵심 원칙: 핵심 애자일 행동 모델링하기 애자일 리더를 위한 To Do List 더 읽을 거리 17장 애자일 조직 문화 핵심 원칙: 실수 처벌하지 않기 심리적 안전 핵심 원칙: 측정된 팀 생산성 기준으로 계획하기 애자일을 지원하는 실천 커뮤니티 보다 효과적인 애자일을 지원하는 조직의 역할 애자일 리더를 위한 To Do List 더 읽을 거리 18장 애자일 측정 의미 있는 작업량 측정하기 작업 수량과 품질 사이에 균형 맞추기 측정하기 쉬운 것 말고 가장 중요한 것을 측정하라 툴로 수집한 데이터가 유효한가? 애자일 리더를 위한 To Do List 더 읽을 거리 19장 애자일 프로세스 개선 기준으로서의 스크럼 생산성을 극적으로 향상시키는 법 진행 중인 작업 매핑해 모니터링하기 회고와 변화 측정 조작을 주의하자 검토하기와 적용하기 개인의 생산성을 측정할 수 있을까? 애자일 리더를 위한 To Do List 더 읽을 거리 20장 애자일 예측성 백로그와 예측성 예측성에 접근하기 비용과 일정 엄격하게 예측하기 피처 세트 엄격하게 예측하기 추정의 목표는 정확한 예측이 아니다 예측성과 애자일 경계선 애자일은 예측성을 지원한다 복잡하고 민감한 문제들 애자일 리더를 위한 To Do List 더 읽을 거리 21장 규제 산업에서 더 효과적인 애자일 애자일이 규제 상품 개발을 더 어렵게 만든다? 규제 환경에서 스크럼이 동작하는 법 규제 시스템과 애자일 경계선 어디서 비롯된 규제인가? 애자일 리더를 위한 To Do List 더 읽을 거리 22장 애자일 포트폴리오 관리 중요하고 빨리 끝낼 수 있는 작업 먼저하기 티셔츠 사이즈와 WSJF 애자일 리더를 위한 To Do List 더 읽을 거리 23장 애자일 도입 직관에 따르면 될까? 도미노 변화 모델 혁신은 표준정규분포를 따라 확산된다 이렇게 애자일을 도입하자 애자일 리더를 위한 To Do List 더 읽을 거리 05 마무리 노력의 결실을 즐기자 핵심 원칙 요약 감사의 글 옮긴이의 글 참고문헌 찾아보기

애자일 개발의 이점은 ‘애자일’을 둘러싼 아우라에서 나오는 게 아니다. 표 2-1에 나열된 애자일에서 강조하는 것들의 효과는 쉽게 이해할 수 있다. 릴리스 주기가 짧으면 오류 수정을 더 시기적절할 때 더 적은 비용으로 할 수 있고, 막다른 길에서 낭비하는 시간을 줄이며, 보다 즉각적인 고객 피드백, 신속한 절차 수정, 수익 증대와 운영비용 절감을 위한 경로 단축 등이 가능하다. 소규모 배치로 수행되는 엔드투엔드 개발 작업 역시 유사한 이유로 이점을 제공한다. 즉, 더 엄격한 피드백 루프를 통해 보다 낮은 비용으로 오류를 더 빨리 감지하고 수정할 수 있다.
_2장 오늘의 애자일

그동안 효율적으로 정착된 스크럼보다 비효율적으로 돌아가는 스크럼을 더 많이 봤다. ‘조건부 스크럼’Scrum-but이 가장 비효율적이다. “우리는 스크럼을 해, 하지만 어떤 주요 실천법은 사용하지 않아.” 예를 들면, “우리는 스크럼을 해, 하지만 일일 스탠드업은 하지 않아.” “우리는 스크럼을 해, 하지만 회고는 하지 않아.” “우린 스크럼을 해, 하지만 프로덕트 오너는 없어.” 등이 있다. 비효율적인 스크럼을 구현한 곳은 일반적으로 최소한 하나 이상의 스크럼 필수 속성을 제거했다.
_4장 스크럼의 기쁨과 슬픔

스크럼의 애자일 실천법은 스크럼팀을 명시적으로 ‘블랙박스’로 취급한다. 만약 당신이 조직의 리더라면 팀의 투입과 산출은 볼 수 있지만, 팀 내부 업무에 대해서는 크게 신경 쓰지 말아야 한다. 스크럼에서 이러한 아이디어는 팀이 각 스프린트를 시작할 때 정해진 양의 작업(스프린트 목표)을 수행한다고 말함으로써 구현된다. 팀은 스프린트가 끝날 때까지 무슨 일이 있어도 작업을 완수할 것을 약속한다. 그런 다음, 팀은 스프린트 기간 동안 블랙박스로 취급된다. 아무도 내부를 들여다볼 수 없고, 누구도 스프린트 중에 일감을 더 넣을 수 없다. 스프린트가 끝나면 팀은 처음에 약속했던 기능을 전달한다. 스프린트가 짧기 때문에 관리자는 팀이 약속을 지켰는지 확인하기 위해 기다릴 필요가 없다.
_5장 애자일팀 구조

수직 슬라이스를 이용하면 일반적으로 비기술적 이해관계자 입장에서 비즈니스 가치를 이해하고, 관찰하고, 평가하기가 더 쉽다. 수직 슬라이스는 팀이 더 빨리 릴리스하고 실제 비즈니스 가치와 실제 사용자 피드백을 실현할 수 있는 옵션을 만든다. 수평 슬라이스에 초점을 둔 팀은 여러 스프린트에 해당하는 일을 한번에 수행하며 절망적인 길을 걷게 될 수도 있다. 어떤 의미에서는 ‘생산적인’ 스토리를 만들지만, 관찰할 수 있는 비즈니스 가치를 창출하지는 못한다.
_9장 애자일 프로젝트

이렇게 비즈니스 가치와 개발 비용 간의 관계를 형성함으로써 비기술 이해관계자는 “스토리 B의 비즈니스 가치는 스몰이기 때문에 만약 개발 비용이 라지라면 없어도 됩니다”라고 말할 수 있다. 이는 스토리 정교화 초기 단계에 내릴 수 있는 엄청나게 유용한 의사결정이다. 어느 정도의 정제, 아키텍처, 디자인 작업 등을 거쳐 스토리를 전달하더라도 결과적으로는 비용을 정당화할 수 없는 스토리에 노력을 쏟는 수도 있다. 소프트웨어에서 빠른 ‘아니오’의 가치는 높다. 티셔츠 사이즈를 활용하면 스토리를 전달하지 않고도 프로젝트 초기에 스토리를 배제하는 의사결정을 할 수 있다.
_14장 애자일 요구사항 우선순위 매기기

앞서 언급했듯이, 애자일 개발은 계산된 실수를 하고 거기에서 배우며 개선을 도모하는 학습 주기인 검토와 적용을 주요하게 사용한다. ‘계산된 실수’란 결과에 자신이 없다는 것을 알면서도 결정을 내리고 결과에 상관없이 결과에서 배우는 일에 주의를 기울이는 것을 의미한다. 커네빈 용어로 난해한 프로젝트는 적은 수의 계산된 실수를 만들고, 복잡한 프로젝트는 많은 수의 계산된 실수를 만든다. 그러니 조직은 오류를 감추고, 수치스러워하고, 조직에 유해한 것으로 치부할 게 아니라 시각화하고, 검토하고, 궁극적으로 조직에 유익하도록 오류를 처벌하지 않아야 한다.
_17장 애자일 조직 문화

K-조직은 왜 애자일에 실패하는가 불확실성을 뚫고 성공하는 애자일 조직이 일하는 법 매월 수백만 명이 쓰는 토스의 송금 서비스와 쿠팡의 새벽배송은 수많은 실험과 실패에서 학습하는 피드백 루프에서 태어났다. 요즘 성과를 내는 조직은 처음부터 완벽한 서비스를 만들기보다는 서비스를 지속적으로 사용하는 유저의 리텐션을 높이는 데 집착한다. 이를 위해서는 실험이 필요하고 실패는 프로세스의 일부이다. 국내에서도 애자일이 일 잘하는 조직의 디폴트가 된 지 오래다. 밑바닥부터 시작하는 스타트업은 물론 레거시 시스템이 산더미같이 쌓여 있는 대기업도 불확실한 상황과 복잡한 문제에 기민하게 대응하는 조직을 추구하며 직급을 없애고 호칭을 바꾸고 교차기능팀을 꾸렸다. 그래서 현실은 어떠한가? 일일 스크럼은 일일 업무보고와 다를 바 없고, 일정은 그대로인데 요구사항만 중간에 추가되거나, 일단 해보고 안 되면 고치는 게 애자일이라며 스프린트를 반복되는 재작업의 악순환으로 만들어 버린 조직이 다수다. 애자일 조직의 리더가 답해야 하는 첫 번째 질문 지금 조직이 해결해야 하는 문제가 난해한 것인가 복잡한 것인가? 저자 스티브 매코널은 애자일을 도입하려는 조직의 리더라면 이에 답할 수 있어야 한다고 말한다. 난해한 문제는 전문가를 통해 어떻게 질문하고 답을 얻어야 하는지 알 수 있다. 개발해야 하는 서비스가 무엇인지 명확하다면 꼭 애자일이 아니더라도 순차 개발을 통해 요구사항을 해결할 수 있다. 복잡한 문제라면? 전문가에게도 질문을 찾는 게 도전이다. 해결책을 구하려면 촘촘한 피드백 루프로 막다른 길에서 낭비하는 시간을 줄이고 보다 낮은 비용으로 오류를 수정해야 한다. 이 책은 커네빈 프레임워크로 상황의 복잡성과 불확실성에 따라 유용한 전략을 소개하고(3장 복잡성과 불확실성에 대응하기), 각 조직에 맞는 애자일 경계를 그리는 방법을 알려 준다(2장 오늘의 애자일). 나아가 초기 애자일을 무조건적으로 좇던 강박에서 벗어나 비전과 우선순위에 따라 자율적으로 일하고 짧은 스프린트와 수직 슬라이스 배포로 성과를 내는 조직의 핵심 애자일 원칙 28을 설득력 있게 제시한다. K-조직에 애자일 절망편이 펼쳐지는 이유 포스트잇으로 가득한 벽이 있다고 해서 반드시 팀이 체계적이고 효과적인 방식으로 업무를 수행한다는 의미는 아니다. 순차 개발이 관료 체제로 실패한다면, 애자일은 무정부 상태로 실패한다. 애자일 안티 패턴은 진정한 자율관리팀을 만들지 않고 스크럼을 채택하는 것이다. 만약 경영진이 세부적인 수준에서 팀을 지휘하고 통제하면서 말로만 팀에 결정권이 있다고 한다면, 애자일 구현은 실패할 것이다. 기꺼이 의지가 있고, 준비되어 있고, 자율관리팀을 만들어 이를 지원하려는 조직이 아니라면 애자일을 채택해서는 안 된다. 이 책에는 효과적인 애자일팀으로 거듭나기 위한 실용적인 스크럼 실천법(4장 스크럼의 기쁨과 슬픔)과 교차기능팀을 만들고 지속 가능하게 운영하는 방법(5장 애자일팀 구조)이 나와 있다. 또한 더 효과적으로 일하는 데 전념하는 조직은 소프트웨어 프로젝트의 목적을 보다 포괄적인 성장 마인드셋 관점으로 바라본다(6장 애자일팀 문화, 8장 개인과 상호작용). 물론 프로젝트는 동작하는 소프트웨어를 생산해야 하지만, 소프트웨어를 만드는 팀의 능력을 향상시키는 것도 필요하다. 대부분의 생산성 연구에 따르면 생산성은 다른 어떤 요소보다 동기에 의존하는 정도가 더 높은데, 소프트웨어 개발 업무의 경우, 여러 가지 동기 중 내적 동기가 가장 중요하다. 문제는 요구사항이야 저자는 소프트웨어 개발 분야에서 일한 25년 동안, 프로젝트가 어려움에 처하거나 실패한 원인을 조사한 모든 연구에서 문제의 주요 원인은 불완전하고, 부정확하고, 모순이 있는 등 형편없는 요구사항이었다고 토로한다. 요구사항을 책임지는 프로덕트 오너의 역할이 왜 갈수록 중요해지고 있는지 알 수 있는 대목이다. 이 책은 해결해야 하는 문제의 복잡함 정도에 따라 달라지는 요구사항의 수명주기(13장 애자일 요구사항 만들기)와 2주 단위의 단기 스프린트에도 상위 비즈니스 가치를 잃지 않는 스토리 매핑 전략(14장 애자일 요구사항 우선순위 매기기)으로 더 효과적으로 일하는 법을 전달한다. 특히 효과적인 소프트웨어 개발의 원칙으로 피드백 루프를 최대한 촘촘하게 하는 것을 강조한다. 왜 우리는 애자일팀에 프로덕트 오너를 두려고 할까? 요구사항과 관련 있는 피드백 루프를 강화하기 위해서다. 왜 교차기능팀을 만들려고 할까? 의사결정에 필요한 피드백 루프를 강화하기 위해서다. 왜 요구사항을 작은 단위로 정의하고 전달할까? 요구사항을 정의하는 과정에서 실행 가능하고 동작하는 소프트웨어로 피드백 루프를 강화하기 위해서다. 왜 개발하기 전에 테스트를 먼저 수행할까? 코드와 테스트 사이의 피드백 루프를 강화하기 위해서다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 효과적인 애자일 리더는 명확한 우선순위를 전달하는 것으로 팀을 지원한다. 많은 조직이 모든 것을 최우선 순위에 두고 팀이 파악하도록 맡겨 버린다. 우선순위를 너무 자주 재조정하거나, 너무 세밀한 수준으로 지정하거나, 우선순위를 아예 거부하기도 한다. 이러한 실수는 매우 흔하고 비효율적이다. 우선순위를 매기지 않는 건 리더십이 약하다는 신호다. 이는 의사결정에 대한 책임을 포기하는 것과 같다. 혁신은 표준정규분포를 따라 확산된다. 저자는 조직에 애자일을 성공적으로 도입하기 위한 도미노 변화 모델(비전, 공감대, 실력, 자원, 인센티브, 실행 계획)을 제시한다(23장 애자일 도입). 도미노 변화 모델은 누락된 요소가 하나라도 있으면 변화가 일어나지 않는다. 여기서 리더십의 역할은 필수적이며 핵심적이다. 조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 조직에 알맞은 애자일 경계는 무엇인가? 세부사항이 아닌 성과를 관리하고 있는가? 촘촘한 피드백 루프로 학습을 가속화하고 수정 비용은 최소화하고 있는가? 책의 각 장 마지막에 실려 있는 ‘애자일 리더를 위한 To Do List’로 지금 바로 현 상황을 검토하고 실패 없는 애자일 실천법을 적용하자.