‘린’, ‘애자일’ IT 기업이 최신 개발 기법을 도입해 상품(혹은 서비스)를 개발하려는 노력은 계속되고 있다. 그러나 개발팀에게 최신 개발 기법을 사용하라고 종용하면서, 개발 조직은 구태의연한 상명하복식의 위계질서를 유지하고 있지는 않은가? 애자일 방법론을 사용하려면 개발자뿐 아니라 조직이 애자일하게 바뀌어야 한다. 한국식 기업 문화와 신규 IT 기술이 혼재하고 있는 한국의 기업이라면 조직을 애자일하게 만든다는 것이 무엇인지 진지하게 살펴보아야 한다.

애자일한 조직
과연 애자일이란 무엇인가? 영어로 Agile은 민첩하다란 뜻이 있다. 그런데 이 책에서 말하는 애자일이란 그 의미가 다르다. 조직을 민첩하게 만들라는 뜻이 아니라, 애자일 선언에 맞는 조직을 디자인하라는 뜻이다.

애자일 선언이란 다음과 같다.
- 프로세스나 도구가 아니라 개인과 상호작용을,
- 폭넓은 문서화가 아니라 소프트웨어를 실제 작업하는 일을,
- 계약이나 협상이 아니라 고객과의 협조를 추구하는 일을,
- 지침을 따르는 게 아니라 변화에 대응하는 일을

예를 들어서 소프트웨어를 개발하는 도중에 버그를 발견했다고 치자. 전통적인 기업문화라면 버그 발견 리포트를 만들어서 보고하고, 그 보고서에 따라 버그를 잡는 팀에게 업무가 배정된다. 그러나 애자일 선언에 따르면 버그를 발견한 즉시, 개선할 수 있는 버그라면 개발자가 바로 개선하면 된다. 버그를 개선했다는 것만 가볍게 노트를 해두면 보고 과정 없이도 소프트웨어를 개선할 수 있다.
그러나 보고 문화, 상위팀의 승인이 없으면 특정 업무를 할 수 없는 문화가 만연해 있다면 이런 개선은 일어날 수 없다. 또한 개발과 테스트가 한 팀에서 근무할 수 있도록 조직을 디자인하지 않는다면 버그를 해결할 수 없다.
즉, 조직이 애자일해지지 않으면 애자일 선언이나 방법론은 아무 소용이 없다. 이 책의 목적은 조직 디자인도 IT가 주도할 수 있다는 내용을 담고 있다.

스케줄이 아니라 가치를 추구한다
소프트웨어 개발은 생산 공정이 아니라 디자인 공정이다. 물건이 생산되고 끝나는 것이 아니라 개발은 디자인 과정일 뿐이고, 생산은 소비자의 손에 들어가는 순간 시작된다. 디자인은 그 자체로 이미 딜리버리가 가능한 상태일 뿐만 아니라 지속적으로 개선될 수 있다. 생산이라면 딜리버리는 모든 공정이 끝나고 나서야 가능하다.
이런 개념을 받아들이고 나면, 소프트웨어 개발이 언제까지 끝나야 하는지 스케줄에 영향을 받는 게 아니라, 초기에 설정한 가치가 달성되었는지를 보는 가치 위주로 바라봐야 한다는 것을 이해할 수 있다. 가치를 추구하고, 같이 일하는 사람과 끊임없이 상호작용하며, 변화에 재빨리 대응하는 조직을 우리는 디자인할 수 있다.

따라서 이 책은 다음과 같은 사람들이 봐야 한다.
- IT 조직 디자인이나 IT 거버넌스에 대한 의사결정을 해야 하는 임원
- ISV와 온라인 비즈니스 관련 회사의 상위 경영진
- 제품 개발, 엔지니어링, 소프트웨어 개발 담당 IT 이사, 기타 임원
- 회사의 IT 인력과 (외부의) IT사업 파트너와 업무를 진행하는 담당 임원
- 재무담당자, IT 재무 분석가, 투자담당자
- 디지털 사업 관련 투자자
- 임원 리더십에 관심이 있는 기술 전문가
- ICT(Information Communication Technology) 전략가
- IT 거버넌스 그룹의 멤버들
- 결과품질(Process Quality)과 SEPG(Software Engineering Process Group) 그룹 멤버들, 품질 담당 컨설턴트와 코치들

서문 감사의 글 용어설명 1장 전체 내용의 이해 1.1 포커스 1.2 사업, IT, 셰도우 IT 1.3 사업- IT 간의 효율성 1.4 디지털 트랜스포메이션 1.5 바이모달 IT와 듀얼 운영 시스템 1.6 이 책이 담고 있는 범위 1.7 요약 2장 애자일 강령 2.1 애자일 선언문 이해하기 2.1.1 사례 1 2.1.2 사례 2 2.2 지속적 딜리버리와 데브옵스 2.3 애자일 문화 2.4.1 빨리 실패하라 2.4.2 점진보다는 반복을 2.4.3 가치흐름 최적화 2.4.4 정보 라디에이터 2.5 애자일이 한 물 가진 않았을까? 2.5.1 그럴싸한 실행 2.6 요약 3장 핵심 테마들 3.1 소프트웨어 개발의 재검토 3.1.1 소스 코드나 바이너리는 제품이 아니다 3.1.2 제품은 사용자나 고객이 사용하는 모든 것, 그 자체다 3.1.3 소프트웨어 개발은 디자인 공정이다 3.2 예측 가능성보다 가치를 관리하라 3.3 비용 효율이 아니라 신속한 반응력을 갖추도록 조직을 구성하라 3.4 내재적 동기부여가 발생하고 비공식적 협조가 가능하도록 디자인하라 3.4.1 자율성 3.4.2 숙련 3.4.3 목적성 3.4.4 비공식적인 협조 3.4.5 자연발생적인 접근방법 3.5 요약 4장 상부구조 4.1 사업 활동과 성과 4.1.1 성과에 집중하면 자율성이 함양된다 4.1.2 성과소유자 4.1.3 성과 디자인 4.2 집중화와 분권화 4.3 사일로 4.3.1 사업-IT 간의 균열 4.3.2 IT 내부의 사일로 4.3.3 상위 레벨의 사일로 4.4 핵심 내용 요약 4.5 해야 할 일 요약 5장 팀디자인 5.1 문제를 프레이밍하기 5.2 활동지향팀 5.2.1 핸드오프 대기 시간이 길어질 때 발생하는 문제 5.2.2 기능 조직의 전통적 매력 5.2.3 활동지향팀을 유지해도 괜찮은 경우는 언제일까? 5.2.4 독립적인 테스트, 검증과 확인 5.3 서비스 공유 5.3.1 서비스를 공유하면 목적성이 사라진다 5.3.2 서비스 공유 인터페이스에서 마찰을 줄이기 5.4 기능횡단 팀 5.4.1 데브옵스 = 기능횡단 개발 + IT 운영팀 5.4.2 반응력이 뛰어난 조직 구성 5.4.3 활용 5.4.4 T형 역량을 갖춘 인력 5.4.5 팀의 크기 5.5 다른 분야에서의 기능횡단 5.5.1 병원 포드 팀 5.5.2 기능횡단 박물관 레이아웃 5.5.3 태스코노미 5.6 기능횡단팀으로 이동하기 5.6.1 임무의 분리 5.7 CoP 5.8 유지 담당 팀 5.9 아웃소싱 5.10 매트릭스: 문제를 해결하거나 해체하거나 5.10.1 공유 서비스의 매트릭스 5.10.2 역량을 독점 사용하지만 대체 가능한 인력으로 구성된 매트릭스 5.10.3 독점 사용할 수 있는 역량과 인력으로 구성된 매트릭스 5.10.4 별도로 구성된 기능횡단 제품 팀 5.10.5 기능횡단 구조로 세팅된 행위 중심의 하부 팀 5.10.6 기능횡단 구조로 세팅된 성과 중심의 하부 팀 5.11 핵심 내용 요약 5.12 해야 할 일 요약 6장 책무 6.1 권력과 서열 6.2 자율성과 책무 간의 균형 6.3 책무 할당 6.3.1 누가 성과를 소유하고 있을까? 6.3.2 책무 지도 6.4 권력 투쟁을 최소화하기 6.4.1 매트릭스 마비 6.4.2 절대적인 서열 6.4.3 교수-사업가 6.5 성과소유자에 대한 결정 6.6 전환 6.7 결정에 대한 책임 6.7.1 결정 기록 6.7.2 도구 6.7.3 기록이 필요한 업무 범위 6.7.4 저항 6.8 기획과 실무 6.8.1 기획과 실무를 분리했을 때 발생하는 문제점 6.8.2 숲과 나무 6.8.3 중첩 6.8.4 반대 의견에 대한 적절한 반응 6.9 조직도 부채 6.10 핵심 내용 요약 6.11 해야 할 일 요약 7장 배열 7.1 일반적 배열을 위한 명확한 전략 7.1.1 뛰어난 운영, 제품 리더십, 고객 친밀도 7.2 IT와 사업 배열하기 7.2.1 MIT의 운영 모델 7.2.2 속도계층적인 어플리케이션 전략 7.2.3 배열 지도 7.3 구조적 배열 7.4 사업이 제 본분을 다하도록 만들기 7.4.1 IT 사업 파트너 - 새로운 역할 7.5 핵심 내용 요약 7.6 해야 할 일 요약 8장 프로젝트 8.1 계획을 기반으로 하는 소프트웨어 프로젝트는 무슨 문제가 있을까? 8.2 프로젝트가 아니라 역량을 위한 예산 8.3 사업-역량 위주의 IT 8.4 프로젝트 사업성 검토서 8.4.1 지속적 딜리버리에 근거한 이익 측정과 분석들 8.4.2 재무 사업성 검토서에 대한 의존도를 줄이다 8.5 가치 위주 프로젝트 8.6 프로젝트 관리자 8.7 거버넌스 8.8 변화 프로그램과 변혁 8.8.1 디지털 트랜스포메이션 프로그램 8.8.2 진행 중 업무(WIP) 제한 8.9 핵심 내용 요약 8.10 해야 할 일 요약 9장 재무 9.1 목적적합성 9.2 비용 발생 부서 혹은 수익 발생 부서 9.3 비용 배분 9.4 자본 비용과 운영 비용 9.4.1 시간 기록 없이 자본 비용과 운영 비용을 구분하여 회계 처리하기 9.4.2 활동의 분류 9.5 전통적인 예산 짜기 9.5.1 비용 목표 9.5.2 예산 짜내기 9.6 애자일 예산 수립 9.6.1 애질리티를 규칙적으로 손보기 9.6.2 공동 예산 수립 9.6.3 기업 IT를 위한 벤처 펀딩 9.7 핵심 내용 요약 9.8 해야 할 일 요약 10장 인사 관리 10.1 인력 부족 사태를 다루는 요령 10.1.1 업무의 범위와 복잡한 정도를 제한하기 10.1.2 조직 디자인으로 직원 유지하기 10.2 프로젝트팀 그 이상을 위하여 10.2.1 비용 10.2.1 난관들 10.2.3 그 외 반대 의견 10.3 보다 나은 인사 관리 10.3.1 역할이 아닌 역량 위주로 팀 조직하기 10.3.2 직위 10.3.3 역량을 명확하게 정리하기 10.3.4 파트타임 업무를 피하라 10.3.5 다양한 인성을 팀 내에 포함시키기 10.4 핵심 내용 요약 10. 5 해야 할 일 요약 11장 도구 사용권 11.1 비공식적인 협조를 위한 접근 제한 11.2 툴체인이 가져오는 미묘한 영향 11.2.1 도구 사용 권한이 가져오는 사일로 11.2.2 도구 사용에서 발생하는 사일로 11.2.3 도구의 전문화에서 비롯된 사일로 11.3 기술은 가치 중립적이지 않다 11.3.1 이메일은 우리를 어떻게 변화시켰는가 11.4 도구의 평가 11.5 핵심 내용 요약 11.6 해야 할 일 요약 12장 성과지표 12.1 성과지표가 모든 것을 말해주지는 않는다 12.1.1 측정 가능, 예측 불가 12.1.2 속도 12.1.3 알려지지 않은 미지수를 다루는 요령 12.2 무지를 불러일으키는 대시보드 12.3 목표와 인센티브가 불러오는 문제들 12.3.1 목표는 부분 최적화를 불러온다 12.3.2 목표는 일종의 통제 기제가 된다 12.3.3 목표와 인센티브 때문에 내재적인 동기부여가 사그라든다 12.3.4 게임으로 몰아가는 목표들 12.3.5 굿하트의 법칙 12.3.6 내재된 목표들 12.3.7 목표는 인센티브를 내포한다 12.4 성과지표 구조 재정비하기 12.4.1 인센티브의 제거 12.4.2 점진적으로 목표 완화하기 12.4.3 평가하는 문화 12.5 보다 나은 성과지표 디자인하기 12.5.1 성과 위주 성과지표 VS. 활동 위주 성과지표 12.5.2 종합적 성과지표 VS. 상세하고 치밀한 성과지표 12.5.3 적용가능성 성과지표 VS. 예측가능성 성과지표 12.5.4 후행지표들과 친숙해지기 12.5.5 보상지표 12.6 성과지표 개선에 대한 반대 12.6.1 막연한 대화로는 체계를 잡을 수 없다 12.6.2 우리 팀이 오로지 당근과 채찍에만 반응한다면 12.6.3 (비용 절감을 위한) 시도 12.7 전환 12.8 핵심 내용 요약 12.9 해야 할 일 요약 13장 규범 13.1 규범이란 무엇인가? 13.2 규범을 강화하기 13.2.1 강화 메커니즘 13.3 경쟁이 아니라 협력을 13.4 현실과 근접한 정책 13.5 통일성보다 일관성을 13.6 허락이 아니라 용서를 구하다 13.7 비공개 서베이 13.8 이론과 실천 사이의 균형 13.9 핵심 내용 요약 13.10 해야 할 일 요약 14장 커뮤니케이션 14.1 내재적 동기부여 14.2 개인 간의 커뮤니케이션: 문제들 14.2.1 서열 끄집어내기 14.2.2 일상생활에서 이루어지는 마이크로어그레션: 말로 하지 않는 경우 14.2.3 일상생활에서 이루어지는 마이크로어그레션: 말로 이루어지는 경우 14.2.4 전쟁 비유 14.3 사람 간의 의사 소통: 완화 14.3.1 신규 채용 직원 오리엔테이션 14.3.2 펄스차트 14.4 내부 커뮤니케이션을 통해 직원 참여도 높이기 14.4.1 그룹 미팅 14.4.2 블로그와 비디오 14.4.3 서베이 14.4.4 온라인 포럼 14.5 심사숙고해서 글을 쓰다 14.6 시각 자료의 사용과 오용 14.6.1 시각자료는 의도치 않게 잘못된 방향으로 호도할 수 있다 14.6.2 글이 가지는 우위 14.6.3 내포된 의미가 근사한 그림보다 중요하다 14.6.4 PPT 자료들 14.6.5 PR/선전을 피하라 14.7 문서, 보고서와 템플릿 14.8 핵심 내용 요약 14.9 해야 할 일 요약 15장 사무실 15.1 오픈-플랜 배치 15.1.1 얼마나 개방적으로? 15.1.2 벽 (디스플레이) 공간 15.1.3 고독과 프라이버시 15.1.4 오픈-플랜 배치에 대한 비판들 15.2 인체공학 15.3 원격근무 15.4 핵심 내용 요약 15.5 해야 할 일 요약 16장 마무리 16.1 효과 요약 16.2 적용 순서 16.3 정보 라디에이터 16.4 사례 연습 16.5 IT 서비스 16.5.1 계약 16.5.2 엔드 유저에 대한 접근 16.5.3 고객이 관여하도록 유도하기 16.5.4 내재적 동기부여 16.5.5 앞으로 나아가야 할 길 16.6 GIC들 16.6.1 사업 부문의 사람들이 가지는 태도 16.6.2 문화적 차이 16.6.3 구식 관리자들 16.6.4 CMM에서 시작되는 여정 16.6.5 16.7 IT 그 이상을 넘어서