1장.시작하기
1.1사고의 도구와 조직의 도구
1.2실행 도구
1.3실험: 해보자. & 하지 말자.
1.4한계

2장.시스템 사고
2.1시스템 역학 보기
2.2멘탈모델 보기
2.3 예 : "빠른 것은 느린 것이다 - 급할수록 돌아가라"의 역학
2.4근본 원인 파악하기
2.5국지적 최적화 찾아보기 (그리고 듣기)

3장.린 사고
3.1린 사고 : 큰 그림
3.2배경
3.3린 요약: 린 사고 하우스
3.4린 목표: 지속적으로 가치를 빠르게 제공하라.
3.5린 토대: 린 사고 관리자 - 교사
3.6첫 번째 사상: 인간 존중
3.7두 번째 사상: 지속적 개선
3.814가지 원칙
3.9린 제품 개발
3.10사례: "칸반 시스템 KANBAN SYSTEM" 분석

4장.큐 이론
4.1사이클 타임 단축을 위한 큐 관리
4.2큐 이론
4.3숨겨진 묶음: 기능 묶음을 보는 눈
4.4숨겨진 큐: 큐를 보는 눈
4.5업무 단위의 크기와 사이클 타임 단축의 간접 이익
4.6스크럼에서 큐 관리의 적용
4.7제약 이론

5장.잘못된 이분법
5.1스크럼의 경험적 프로세스와 가중치 부여법
5.2잘못된 이분법
5.3실험: 상대주의를 지나치게 주장하지 말자.
5.4오해

6장.애자일 해져라
6.1애자일 선언: 4가지 가치 value
6.2스크럼: 다섯 개의 가치
6.312가지 애자일 원칙 principles
6.4애자일 관리 원칙 Agile management principles

7장.피처팀
7.1피처팀 소개
7.2실험: 단일-기능팀을 만들지 말자.
7.3실험: 컴포넌트팀을 만들지 말자.
7.4실험: 피처팀을 만들자.
7.5전환

8장.팀
8.1실험: 자기 조직팀을 만들자.
8.2실험: 도전적이지만 현실적인 목표를 설정하자.
8.3실험: 교차 기능팀 cross-functional team을 만들자.
8.4실험: 오래 지속되는 팀을 만들자.
8.5실험: 우리 팀만의 프로세스를 가지고 일하자.
8.6실험: 팀은 외부 의존성 EXTERNAL DEPENDENCIES을 잘 관리하자.
8.7실험: 헌신하는 팀 멤버가 되자.
8.8실험: 다재다능한 사람이 되자.
8.9실험: 의사 결정은 팀이 하자.
8.10실험: 팀의 갈등을 겉으로 드러내자.
8.11조직에 미치는 영향
8.12실험: 자원을 단계별로 할당하지 말자.
8.13실험: 병렬 출시를 하지 말자. 그룹이나 업무가 제대로 잘 구성되지 않았다는
증거다.
8.14실험: 계단식 브랜치를 생성하지 말자. 그룹이나 업무가 제대로 잘 구성되지
않았다는 증거이다.
8.15실험: 제품 개발 시 프로젝트를 만들지 말자. 그룹이나 업무가 제대로 잘 구성되지 않았다는 증거다.

9장.요구사항 영역
9.1실험: 한 명의 제품 책임자가 한 개의 제품 백로그를 책임지도록 하자.
9.2실험: 요구사항 영역을 만들어보자.
9.3실험: 전체 팀을 새로운 영역으로 이동시켜보자.
9.4요구사항 영역으로 전환
9.5실험: 팀을 요구사항 영역으로 한번에 전환시켜보자.
9.6실험: 개발 영역 내에서만 머무르지 말자.
9.7도구들

10장.조 직
10.1목적과 전략
10.2업무
10.3구조
10.4프로세스
10.5보상
10.6사람

11장.대규모 스크럼
11.1개요
11.2실험: 10개 팀을 위한 대규모 스크럼 프레임워크(FW-1)를 적용해보자.
11.3실험: '여러' 팀을 위한 대규모 스크럼 프레임워크 2(FW-2)를 적용해보자.
11.4확대 적용과 관련된 이슈들

12장.스크럼 입문
12.1전통적인 소프트웨어 개발
12.2애자일 개발과 스크럼
12.3스크럼 요약
12.4스크럼 역할들
12.5스크럼 시작하기
12.6스프린트 계획회의
12.7일일 스크럼
12.8스프린트 백로그와 스프린트
소멸 차트 갱신하기
12.9제품 백로그 구체화
12.10스프린트 끝내기
12.11스프린트 리뷰
12.12스프린트 회고
12.13릴리스 백로그 및 소멸차트
갱신하기
12.14다음 스프린트 시작하기
12.15릴리스 스프린트
12.16릴리스 계획하기 및 초기 제품
백로그 구체화하기
12.17한 애플리케이션이나 제품에
집중하기
12.18일반적인 도전들
12.19스크럼의 결과

추천 도서
BIBLIOGRAPHY
찾아보기