출판사 서평
‘린’, ‘애자일’ IT 기업이 최신 개발 기법을 도입해 상품(혹은 서비스)를 개발하려는 노력은 계속되고 있다. 그러나 개발팀에게 최신 개발 기법을 사용하라고 종용하면서, 개발 조직은 구태의연한 상명하복식의 위계질서를 유지하고 있지는 않은가? 애자일 방법론을 사용하려면 개발자뿐 아니라 조직이 애자일하게 바뀌어야 한다. 한국식 기업 문화와 신규 IT 기술이 혼재하고 있는 한국의 기업이라면 조직을 애자일하게 만든다는 것이 무엇인지 진지하게 살펴보아야 한다.
애자일한 조직
과연 애자일이란 무엇인가? 영어로 Agile은 민첩하다란 ...
‘린’, ‘애자일’ IT 기업이 최신 개발 기법을 도입해 상품(혹은 서비스)를 개발하려는 노력은 계속되고 있다. 그러나 개발팀에게 최신 개발 기법을 사용하라고 종용하면서, 개발 조직은 구태의연한 상명하복식의 위계질서를 유지하고 있지는 않은가? 애자일 방법론을 사용하려면 개발자뿐 아니라 조직이 애자일하게 바뀌어야 한다. 한국식 기업 문화와 신규 IT 기술이 혼재하고 있는 한국의 기업이라면 조직을 애자일하게 만든다는 것이 무엇인지 진지하게 살펴보아야 한다.
애자일한 조직
과연 애자일이란 무엇인가? 영어로 Agile은 민첩하다란 뜻이 있다. 그런데 이 책에서 말하는 애자일이란 그 의미가 다르다. 조직을 민첩하게 만들라는 뜻이 아니라, 애자일 선언에 맞는 조직을 디자인하라는 뜻이다.
애자일 선언이란 다음과 같다.
- 프로세스나 도구가 아니라 개인과 상호작용을,
- 폭넓은 문서화가 아니라 소프트웨어를 실제 작업하는 일을,
- 계약이나 협상이 아니라 고객과의 협조를 추구하는 일을,
- 지침을 따르는 게 아니라 변화에 대응하는 일을
예를 들어서 소프트웨어를 개발하는 도중에 버그를 발견했다고 치자. 전통적인 기업문화라면 버그 발견 리포트를 만들어서 보고하고, 그 보고서에 따라 버그를 잡는 팀에게 업무가 배정된다. 그러나 애자일 선언에 따르면 버그를 발견한 즉시, 개선할 수 있는 버그라면 개발자가 바로 개선하면 된다. 버그를 개선했다는 것만 가볍게 노트를 해두면 보고 과정 없이도 소프트웨어를 개선할 수 있다.
그러나 보고 문화, 상위팀의 승인이 없으면 특정 업무를 할 수 없는 문화가 만연해 있다면 이런 개선은 일어날 수 없다. 또한 개발과 테스트가 한 팀에서 근무할 수 있도록 조직을 디자인하지 않는다면 버그를 해결할 수 없다.
즉, 조직이 애자일해지지 않으면 애자일 선언이나 방법론은 아무 소용이 없다. 이 책의 목적은 조직 디자인도 IT가 주도할 수 있다는 내용을 담고 있다.
스케줄이 아니라 가치를 추구한다
소프트웨어 개발은 생산 공정이 아니라 디자인 공정이다. 물건이 생산되고 끝나는 것이 아니라 개발은 디자인 과정일 뿐이고, 생산은 소비자의 손에 들어가는 순간 시작된다. 디자인은 그 자체로 이미 딜리버리가 가능한 상태일 뿐만 아니라 지속적으로 개선될 수 있다. 생산이라면 딜리버리는 모든 공정이 끝나고 나서야 가능하다.
이런 개념을 받아들이고 나면, 소프트웨어 개발이 언제까지 끝나야 하는지 스케줄에 영향을 받는 게 아니라, 초기에 설정한 가치가 달성되었는지를 보는 가치 위주로 바라봐야 한다는 것을 이해할 수 있다. 가치를 추구하고, 같이 일하는 사람과 끊임없이 상호작용하며, 변화에 재빨리 대응하는 조직을 우리는 디자인할 수 있다.
따라서 이 책은 다음과 같은 사람들이 봐야 한다.
- IT 조직 디자인이나 IT 거버넌스에 대한 의사결정을 해야 하는 임원
- ISV와 온라인 비즈니스 관련 회사의 상위 경영진
- 제품 개발, 엔지니어링, 소프트웨어 개발 담당 IT 이사, 기타 임원
- 회사의 IT 인력과 (외부의) IT사업 파트너와 업무를 진행하는 담당 임원
- 재무담당자, IT 재무 분석가, 투자담당자
- 디지털 사업 관련 투자자
- 임원 리더십에 관심이 있는 기술 전문가
- ICT(Information Communication Technology) 전략가
- IT 거버넌스 그룹의 멤버들
- 결과품질(Process Quality)과 SEPG(Software Engineering Process Group) 그룹 멤버들, 품질 담당 컨설턴트와 코치들

“애질리티는 더 이상 소프트웨어의 문제가 아니라 회사의 최고 경영진이 심사숙고해야 하는 중요한 문제가 되었다.”
_짐 하이스미스, 『적응력이 뛰어난 리더십(Adaptive Leadership)』의 저자

“조직에게 만병통치약이란 있을 수가 없다. 하지만, 스리람은 조직이 냉엄한 현실을 마주할 수 있도록, 단순히 애자일 소프트웨어 개발을 넘어 조직과 사업 애질리티를 갖추는 요령을 알려준다.”
_레베카 파슨스, 애자일얼라이언스의 이사

“애자일 분야는 끊임없이 변화하고 개선되고 있지만 전사적인 의미에서 이를 활용할 수 있는 가이드가 제공된 적은 없었다. 이 책은 애자일을 전사적으로 적용시키는 데에 대한 완벽한 지침은 물론, 사례와 납득할 만한 조언까지 겸비하고 있다.”
_켄 롭슨, 단스케 은행의 트레이딩 테크놀러지 글로벌 헤드

“우리는 종종 기술적인 관점에서만 지속적 딜리버리(Continuous Delivery)를 다룬다. 지속적 딜리버리란 개념이 기술적인 측면에서 시작된 것은 맞지만, 이 때문에 편협하게 다루어지는 경향이 있다. 지속적 딜리버리는 총체적인 개념이다. 조직 전반에 걸쳐 변화가 일어나야 지속적 딜리버리가 가능해지고, 한번 시작된 지속적 딜리버리는 이를 시행하는 회사를 지속적으로 변화시키고 개선시킨다. 이 책은 바로 이 점을 지적하고 전체 조직의 관점에서 지속적 딜리버리를 살펴본다. 내적, 외적인 동기부여에 대한 댄 핑크(Dan Pink)의 생각을 살펴보고, 제대로 굴러가는 조직을 만들어내는 요령을 상세히 설명해준다. 제대로 짜인 조직은 하부 조직에 동기를 부여하고, 탁월한 성과를 가져다주는 자율, 영향력, 그리고 목적에 집중한다. 이 책은 일상적이고 소소하지만, 뛰어난 변화를 가져오는 조직구조의 다양한 면면을 살펴본다. 이 책의 조언을 따라 한다면, 당신의 회사는 분명히 개선될 것이다.”
_데이브 팔리(Dave Farley), 『지속적 딜리버리(Continuous Delivery)』의 저자

목차
서문
감사의 글
용어설명
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 데브옵스 \u003d 기능횡단 개발 + 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 해야