애자일 조직은 이렇게 일합니다

K-조직은 왜 애자일에 실패하는가
불확실성을 뚫고 성공하는 애자일 조직이 일하는 법

매월 수백만 명이 쓰는 토스의 송금 서비스와 쿠팡의 새벽배송은 수많은 실험과 실패에서 학습하는 피드백 루프에서 태어났다. 요즘 성과를 내는 조직은 처음부터 완벽한 서비스를 만들기보다는 서비스를 지속적으로 사용하는 유저의 리텐션을 높이는 데 집착한다. 이를 위해서는 실험이 필요하고 실패는 프로세스의 일부이다.
국내에서도 애자일이 일 잘하는 조직의 디폴트가 된 지 오래다. 밑바닥부터 시작하는 스타트업은 물론 레거시 시스템이 산더미같이 쌓여 있는 대기업도 불확실한 상황과 복잡한 문제에 기민하게 대응하는 조직을 추구하며 직급을 없애고 호칭을 바꾸고 교차기능팀을 꾸렸다. 그래서 현실은 어떠한가? 일일 스크럼은 일일 업무보고와 다를 바 없고, 일정은 그대로인데 요구사항만 중간에 추가되거나, 일단 해보고 안 되면 고치는 게 애자일이라며 스프린트를 반복되는 재작업의 악순환으로 만들어 버린 조직이 다수다.

애자일 조직의 리더가 답해야 하는 첫 번째 질문

지금 조직이 해결해야 하는 문제가 난해한 것인가 복잡한 것인가? 저자 스티브 매코널은 애자일을 도입하려는 조직의 리더라면 이에 답할 수 있어야 한다고 말한다. 난해한 문제는 전문가를 통해 어떻게 질문하고 답을 얻어야 하는지 알 수 있다. 개발해야 하는 서비스가 무엇인지 명확하다면 꼭 애자일이 아니더라도 순차 개발을 통해 요구사항을 해결할 수 있다.
복잡한 문제라면? 전문가에게도 질문을 찾는 게 도전이다. 해결책을 구하려면 촘촘한 피드백 루프로 막다른 길에서 낭비하는 시간을 줄이고 보다 낮은 비용으로 오류를 수정해야 한다. 이 책은 커네빈 프레임워크로 상황의 복잡성과 불확실성에 따라 유용한 전략을 소개하고(3장 복잡성과 불확실성에 대응하기), 각 조직에 맞는 애자일 경계를 그리는 방법을 알려 준다(2장 오늘의 애자일).
나아가 초기 애자일을 무조건적으로 좇던 강박에서 벗어나 비전과 우선순위에 따라 자율적으로 일하고 짧은 스프린트와 수직 슬라이스 배포로 성과를 내는 조직의 핵심 애자일 원칙 28을 설득력 있게 제시한다.

K-조직에 애자일 절망편이 펼쳐지는 이유

포스트잇으로 가득한 벽이 있다고 해서 반드시 팀이 체계적이고 효과적인 방식으로 업무를 수행한다는 의미는 아니다. 순차 개발이 관료 체제로 실패한다면, 애자일은 무정부 상태로 실패한다.
애자일 안티 패턴은 진정한 자율관리팀을 만들지 않고 스크럼을 채택하는 것이다. 만약 경영진이 세부적인 수준에서 팀을 지휘하고 통제하면서 말로만 팀에 결정권이 있다고 한다면, 애자일 구현은 실패할 것이다. 기꺼이 의지가 있고, 준비되어 있고, 자율관리팀을 만들어 이를 지원하려는 조직이 아니라면 애자일을 채택해서는 안 된다. 이 책에는 효과적인 애자일팀으로 거듭나기 위한 실용적인 스크럼 실천법(4장 스크럼의 기쁨과 슬픔)과 교차기능팀을 만들고 지속 가능하게 운영하는 방법(5장 애자일팀 구조)이 나와 있다.
또한 더 효과적으로 일하는 데 전념하는 조직은 소프트웨어 프로젝트의 목적을 보다 포괄적인 성장 마인드셋 관점으로 바라본다(6장 애자일팀 문화, 8장 개인과 상호작용). 물론 프로젝트는 동작하는 소프트웨어를 생산해야 하지만, 소프트웨어를 만드는 팀의 능력을 향상시키는 것도 필요하다. 대부분의 생산성 연구에 따르면 생산성은 다른 어떤 요소보다 동기에 의존하는 정도가 더 높은데, 소프트웨어 개발 업무의 경우, 여러 가지 동기 중 내적 동기가 가장 중요하다.

문제는 요구사항이야

저자는 소프트웨어 개발 분야에서 일한 25년 동안, 프로젝트가 어려움에 처하거나 실패한 원인을 조사한 모든 연구에서 문제의 주요 원인은 불완전하고, 부정확하고, 모순이 있는 등 형편없는 요구사항이었다고 토로한다. 요구사항을 책임지는 프로덕트 오너의 역할이 왜 갈수록 중요해지고 있는지 알 수 있는 대목이다. 이 책은 해결해야 하는 문제의 복잡함 정도에 따라 달라지는 요구사항의 수명주기(13장 애자일 요구사항 만들기)와 2주 단위의 단기 스프린트에도 상위 비즈니스 가치를 잃지 않는 스토리 매핑 전략(14장 애자일 요구사항 우선순위 매기기)으로 더 효과적으로 일하는 법을 전달한다.
특히 효과적인 소프트웨어 개발의 원칙으로 피드백 루프를 최대한 촘촘하게 하는 것을 강조한다. 왜 우리는 애자일팀에 프로덕트 오너를 두려고 할까? 요구사항과 관련 있는 피드백 루프를 강화하기 위해서다. 왜 교차기능팀을 만들려고 할까? 의사결정에 필요한 피드백 루프를 강화하기 위해서다. 왜 요구사항을 작은 단위로 정의하고 전달할까? 요구사항을 정의하는 과정에서 실행 가능하고 동작하는 소프트웨어로 피드백 루프를 강화하기 위해서다. 왜 개발하기 전에 테스트를 먼저 수행할까? 코드와 테스트 사이의 피드백 루프를 강화하기 위해서다.

조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가?

효과적인 애자일 리더는 명확한 우선순위를 전달하는 것으로 팀을 지원한다. 많은 조직이 모든 것을 최우선 순위에 두고 팀이 파악하도록 맡겨 버린다. 우선순위를 너무 자주 재조정하거나, 너무 세밀한 수준으로 지정하거나, 우선순위를 아예 거부하기도 한다. 이러한 실수는 매우 흔하고 비효율적이다. 우선순위를 매기지 않는 건 리더십이 약하다는 신호다. 이는 의사결정에 대한 책임을 포기하는 것과 같다.
혁신은 표준정규분포를 따라 확산된다. 저자는 조직에 애자일을 성공적으로 도입하기 위한 도미노 변화 모델(비전, 공감대, 실력, 자원, 인센티브, 실행 계획)을 제시한다(23장 애자일 도입). 도미노 변화 모델은 누락된 요소가 하나라도 있으면 변화가 일어나지 않는다. 여기서 리더십의 역할은 필수적이며 핵심적이다.
조직이 추구하는 성공이 어떤 모습인지 구성원에게 생생하게 표현할 수 있는가? 조직에 알맞은 애자일 경계는 무엇인가? 세부사항이 아닌 성과를 관리하고 있는가? 촘촘한 피드백 루프로 학습을 가속화하고 수정 비용은 최소화하고 있는가? 책의 각 장 마지막에 실려 있는 '애자일 리더를 위한 To Do List'로 지금 바로 현 상황을 검토하고 실패 없는 애자일 실천법을 적용하자.

비즈니스 리더들의 추천사

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 마무리
노력의 결실을 즐기자
핵심 원칙 요약

감사의 글
옮긴이의 글
참고문헌
찾아보기

스티브 매코널 Steve McConnell
20개 언어로 번역되어 전 세계적으로 백만 부 이상 팔린 베스트셀러 저자이자 컨스트럭스 소프트웨어Construx Software의 CEO이다. 저서《Code Complete 코드 컴플리트》는 역사상 가장 많이 팔린 소프트웨어 개발 서적으로 IT 업계의 아카데미로 비견되는 졸트상을 받았다.
개인, 팀, 조직의 전문성을 향상시켜 소프트웨어 프로젝트를 성공으로 이끄는 데 열정적이다. 컨스트럭스 소프트웨어에서 보다 효과적인 소프트웨어 개발 사례에 중점을 둔 교육 프로그램을 개발하며 컨설팅과 코칭을 제공하고 있다. 저서로《Rapid Development 프로젝트 쾌속 개발 전략》《소프트웨어 프로젝트 생존 전략》《Professional 소프트웨어 개발》《Software Estimation 소프트웨어 추정》등이 있다.
'애자일'이 아니라 '효과가 있는 것'을 지지하며 '증거도 없이 과하게 약속하는 것'에 반대한다. 이 책에서는 애자일을 그 효과와 상호작용을 검증할 수 있는, 구체적인 경영 기법과 기술적인 실천으로 다뤘다.
www.stevemcconnell.com