추천사 4
프롤로그 11
이 책의 7인 ― 갈등의 지도 19
당신의 자리에서 시작하라 ― 역할별 진입 20

PART 1 전원 ON 전에 점검하라
도입 전 필수 확인 스위치

#01 우리 조직, 애자일이 정말 맞긴 한가 23
#02 탐색형인가, 전달형인가, 혼합형인가 28
#03 우리 팀은 어떻게 일하기로 했는가 32
#04 “다 됐다”는 말을 믿을 수 있는가 36
#05 스프린트에 들어가도 되는 일인가 40
#06 경영진·고객·팀이 기대하는 것이 같은가 45
#07 무엇을 언제 어떤 순서로 바꿀 것인가 50
#08 실패 없이 첫 스프린트를 시작하는 법 55
#09 크로스펑셔널 팀, 어떻게 꾸릴 것인가 60
#10 협업을 막는 공간과 도구를 바꿔라 65
#11 PO·SM·팀원, 각자 뭘 해야 하는가 70
#12 첫 팀을 잘못 고르면 전사 도입이 흔들린다 75

PART 2 열심히 달리는데 왜 제자리인가
실행이 막히는 구조 스위치

#13 스프린트, 계획인가 소망인가 81
#14 2주의 방향을 한 문장으로 말할 수 있는가 86
#15 매일 15분, 형식인가 흐름 점검인가 91
#16 이해관계자가 스프린트 리뷰에 안 오는 이유 96
#17 속도(Velocity)를 측정하는가, 관리하는가 101
#18 동시에 벌이는 일이 많을수록 완료는 늦어진다 105
#19 일의 흐름이 보이지 않으면 병목도 안 보인다 110
#20 테스트는 마지막에 한다는 믿음을 버려라 115
#21 통합은 나중에 몰아서 하면 된다는 착각 120
#22 고정 납기와 유연한 개발, 공존할 수 있는가 125
#23 장애물은 드러내야 사라진다 130
#24 릴리즈 계획 없이 스프린트만 달리는 팀 134
#25 스프린트 중 변경 요청, 받을 것인가 막을 것인가 139
#26 회고는 했는데 왜 같은 문제가 반복되는가 143
#27 스프린트 목표를 매번 달성하는데 고객이 불만인 이유 147
#28 백로그는 있는데 우선순위가 없다 152
#29 회의가 너무 많다는 팀과 너무 없다는 팀 156

PART 3 무엇에 불을 켤 것인가
가치 발견과 제품 정의 스위치

#30 우리가 왜 이것을 만드는지 말할 수 있는가 163
#31 만들어야 할 것의 목록이 살아있는가 167
#32 다음 스프린트 전에 백로그가 준비됐는가 171
#33 기능 명세서가 아닌 고객 관점으로 써라 176
#34 큰 스토리는 스프린트를 집어삼킨다 181
#35 완료를 확인하는 기준이 있는가 186
#36 얼마나 걸릴지 아무도 모른다는 팀에게 191
#37 무엇을 먼저 만들 것인가 결정하지 못하는 팀 196
#38 백로그가 아닌 사용자 여정으로 그려라 201
#39 기능과 비즈니스 목표가 연결되지 않는 팀 206
#40 최소한으로 만들어 먼저 검증하라 211
#41 고객 피드백이 개발 주기에 연결되지 않는 팀 216
#42 고객을 구체적인 인물로 그려본 적 있는가 221
#43 요구사항 추가인지 기능 개선인지 구분하는 법 226
#44 비즈니스 핵심 시나리오를 먼저 그려라 231

PART 4 혼자 빛나는 전구는 없다
팀 협업과 신뢰 스위치

#45 회고가 불평 시간이 되지 않으려면 239
#46 회고에서 나온 개선안이 실제로 바뀌는가 244
#47 팀이 스스로 정한 규칙이 있는가 249
#48 이 팀에서 솔직하게 말할 수 있는가 253
#49 발언이 안전하다는 경험을 반복시켜라 258
#50 피드백이 자연스럽게 흐르는 구조인가 262
#51 팀 갈등을 회피하면 곪는다 267
#52 누가 어떤 결정을 내리는지 아무도 모른다 271
#53 열심히 달리다 팀이 먼저 쓰러진다 275
#54 새 팀원이 합류하는 데 한 달이 걸리는 팀 280
#55 팀이 자신의 성과를 스스로 볼 수 있는가 285
#56 기획·개발·디자인·QA가 진짜 같은 팀인가 289
#57 자기 조직화 팀은 선언한다고 만들어지지 않는다 293
#58 팀장이 자율을 준다면서 모든 결정을 확인받으라 한다 297
#59 겸직 팀원이 많으면 스프린트는 처음부터 구멍이 난다 302

PART 5 코치의 손전등
퍼실리테이션과 개입 스위치

#60 답을 주는 대신 생각을 흔드는 질문 309
#61 코칭 대화에도 구조가 있다 314
#62 코치와 팀이 기대하는 것이 같은가 318
#63 저항하는 사람이 문제가 아니다 323
#64 회의실에 침묵이 흐를 때 코치는 무엇을 하는가 328
#65 변화의 어느 단계에 있는지 알아야 개입할 수 있다 333
#66 갈등의 표면이 아닌 본질을 건드려라 338
#67 워크숍은 설계가 90%다 343
#68 참여자가 의제를 정하는 대화의 힘 348
#69 Powerful Question은 불편해야 한다 353
#70 SM 한 명이 몇 팀을 맡을 수 있는가 358
#71 코치는 언제 들어가고 언제 나와야 하는가 363

PART 6 두꺼비집을 바꿔야 집 전체가 밝아진다
조직 변화 스위치

#72 팀 구조 자체가 협업을 막고 있다 369
#73 여러 팀이 하나의 제품을 함께 만들려면 373
#74 팀이 10개가 넘으면 소통이 먼저 무너진다 377
#75 조직 변화는 속도가 아닌 순서가 중요하다 381
#76 애자일 환경에서 경영진 보고를 재설계하라 385
#77 승인 단계가 팀의 속도를 죽이고 있다 389
#78 규제와 계약 안에서 애자일을 살리는 법 393
#79 조직 저항의 원인은 사람이 아닌 구조다 397
#80 변화 속도가 너무 빠르면 조직이 부러진다 401
#81 고정가 계약에서 애자일을 운영하는 현실적인 방법 405
#82 디자인은 항상 개발보다 늦다 ― 시차 스프린트 설계 409

PART 7 불확실성이 두 겹인 프로젝트
AI 서비스 개발에서 애자일 스위치를 다시 켜는 법

#83 AI 프로젝트도 적합성 진단이 먼저다 415
#84 AI 서비스의 범위는 요구사항이 정하지 않는다 420
#85 데이터는 인프라가 아니라 제품이다 425
#86 AI 스프린트 목표는 완성이 아니라 검증이다 430
#87 AI 서비스의 DoD는 품질 기준을 포함한다 435
#88 실패 케이스를 데모하라 440
#89 AI 컴포넌트 통합은 비결정성을 전제로 설계한다 445
#90 AI 서비스는 출시가 끝이 아니다 449

PART 8 불꽃을 유지하는 법
지속 가능한 애자일 스위치

#91 우리 팀은 지금 어느 수준인가 455
#92 코치가 없어도 팀이 스스로 돌아가는가 459
#93 언제든 릴리즈할 수 있는 코드 상태를 유지하라 463
#94 개발과 운영이 벽을 허물면 속도가 달라진다 467
#95 실패를 학습으로 전환하는 조직이 살아남는다 471
#96 6개월 지나면 흐지부지되는 애자일의 공통점 475
#97 컨설턴트가 다 설계해줬는데 왜 우리 스스로 못 하는가 479
#98 속도·품질·가치를 함께 보는 측정 체계 483
#99 레거시를 끌어안고 달리는 팀의 프리징 전략 487
#100 코드 리뷰가 병목인가, 문화인가 491
#101 다음 스위치는 스스로 찾아야 한다 495

에필로그 499
목격자 이력서 501