10.7 애자일

개요와 동기

애자일은 소프트웨어(그리고 가치)를 반복적이고 점진적으로, 그것을 쓸 사람들과 긴밀히 협업하며 전달하는 마인드셋입니다. 2001년 애자일 소프트웨어 개발 선언에 성문화되었으며, 프로세스가 아니라 가치와 원칙의 집합으로 이해하는 것이 가장 좋습니다. 이전의 계획 중심, 계약 중심, 문서 중심 기본값보다 개인과 상호작용, 동작하는 소프트웨어, 고객과의 협업, 변화에 대한 대응을 우선합니다. 스크럼, 칸반, 익스트림 프로그래밍(XP) 같은 프레임워크는 그 마인드셋의 구현입니다. 유용한 출발점이지만 마인드셋 자체는 아닙니다. 이 장은 방법을 폭넓게 조망하는 1.4장(일하는 방식)을 보완해 애자일을 구체적으로 깊이 다룹니다.

애자일은 디스커버리 및 전달 파이프라인(11.1장, 11.2장)을 움직이는 것과 같은 힘에 이끌립니다. 소프트웨어의 요구 사항은 처음부터 완전히 알려져 있지 않고 발견되며, 세상은 긴 계획이 흡수할 수 있는 것보다 빨리 변합니다. 일괄적이고 모든 것을 먼저 계획하는 전달은 늦고, 예산을 초과하고, 무엇보다 틀린 시스템을 거듭 만들어 냅니다. 모든 학습이 끝에, 행동하기 가장 비쌀 때 도착하기 때문입니다. 애자일의 핵심 내기는 단순합니다. 진짜 동작하는 소프트웨어를 만들고 진짜 피드백을 받는 짧은 주기가 긴 추측의 주기를 이깁니다. 잘하면 위험을 미루는 대신 지속적으로 줄입니다.

큰 팀, 기업, 정부에서 애자일은 강력하면서 자주 망가집니다. 기업은 수백 개 팀에 걸쳐 도입하면서 결정이 내려지는 방식이나 가치가 측정되는 방식을 바꾸지 않은 채 의례로 축소하곤 합니다(“이제 스탠드업을 합니다”). 정부는 의도적으로 애자일을 받아들였습니다. 반복적이고 사용자 중심의 전달이 대규모 공공 프로그램의 위험을 입증된 대로 줄이기 때문입니다. 미국 디지털 서비스와 그 디지털 서비스 플레이북, 영국의 정부 디지털 서비스와 서비스 표준, 애자일 조달 개혁은 모두 눈에 띄는 폭포수 실패에 대응하며 부분적으로 생겨났습니다. 보상은 실제입니다. “이름뿐인 애자일”이라는 실패 모드도 그렇습니다.

핵심 원칙

선언의 네 가지 가치(사람, 동작하는 소프트웨어, 협업, 대응성)를 프로세스 산출물보다 중시하십시오.
동작하는 소프트웨어를 자주 작은 증분으로 전달하십시오. 동작하는 소프트웨어가 진행의 일차 척도입니다.
변화를 환영하십시오. 늦어도 마찬가지입니다. 적응성은 실패가 아니라 기능입니다.
동기 부여되고, 권한이 있고, 자기 조직화하는 팀을 중심으로 구축하십시오.
사용자 및 이해관계자와 지속적으로 협업하십시오.
정기적인 주기로 되돌아보고 개선하십시오.
인간적인 속도를 유지하고 기술적 탁월함을 지키십시오. 장인 정신 없는 속도는 무너집니다.

권장 사항

의례가 아니라 가치와 원칙에 닻을 내린다

가장 중요한 단일 애자일 권장 사항은 왜로 이끄는 것입니다. 매일 스탠드업, 스프린트 리뷰, 회고를 하면서도 고정된 날짜에 고정된 범위를 약속하고, 나쁜 소식을 숨기고, 계획을 결코 바꾸지 않는 팀은 애자일이 아닙니다. 회의가 있는 폭포수입니다. 12개 원칙을 진짜 민첩성의 체크리스트로 쓰십시오. 동작하는 소프트웨어를 자주 전달하고 있습니까? 다음 반복에 변화를 환영할 수 있습니까? 팀이 일을 어떻게 할지 결정합니까? 고객이 실제로 루프에 있습니까? 의례가 그런 결과를 만들어 내지 않는다면 의례가 아니라 결과를 고치십시오.

프레임워크를 종교가 아니라 출발점으로 고른다

일에 맞는 프레임워크를 골라 적응시키십시오.

스크럼: 시간 제한이 있는 스프린트, 우선순위가 정해진 백로그, 정의된 역할(프로덕트 오너, 스크럼 마스터, 개발자). 분명한 프로덕트 오너가 있는 기능 전달에 좋고, 일이 끼어들기 주도적일 때는 약합니다.
칸반: 명시적 진행 중 작업(WIP) 한도와 당기기 시스템이 있는 지속적 흐름. 지원, 운영, 예측할 수 없는 도착에 좋습니다(흐름과 대기열 이론에 직접 근거합니다. 11.2장, 11.3장 참조). WIP를 제한하면 리드 타임이 짧아집니다(리틀의 법칙).
익스트림 프로그래밍(XP): 테스트 주도 개발, 짝 프로그래밍, 지속적 통합, 리팩터링, 작은 릴리스를 포함한 엔지니어링 실천. 어떤 프레임워크든 지속 가능하게 만드는 기술적 뼈대입니다.
스크럼반과 혼합: 많은 성숙한 팀이 수렴하는 실용적 조합.

프레임워크는 비계입니다. 도움이 되는 것은 유지하고 그렇지 않은 것은 버리며, “프레임워크가 그렇게 말합니다”가 “원칙이 이유를 말합니다”를 앞서게 두지 마십시오.

기술적 탁월함을 고집한다

엔지니어링 규율 없는 애자일은 빠르게 유지할 수 없는 코드를 빨리 생산하는 것으로 퇴화하는 “다크 스크럼”이 됩니다. 팀이 결함과 기술 부채의 타르 구덩이로 스스로 스프린트해 들어갑니다. XP 실천은 선택적 부가물이 아닙니다. 지속적 통합(8.1장), 자동화된 테스트(2.4장), 리팩터링, 트렁크 기반 개발(2.6장), 깔끔한 설계(2.2장)가 팀이 소프트웨어를 싸게 계속 바꿀 수 있게 하며, 이것이 민첩성의 전체 전제입니다. 지속 가능한 속도도 같은 이유로 중요합니다. 소진된 팀은 품질이나 대응성을 유지할 수 없습니다.

조심스럽게 확장하고, 축소를 선호한다

SAFe(확장형 애자일 프레임워크), LeSS, Nexus, Scrum@Scale 같은 확장 프레임워크는 많은 팀을 공유된 목표로 조율합니다. 도움이 될 수 있지만 (1.4장을 되풀이하는) 경고가 따릅니다. 무거운 확장 프레임워크는 애자일이 없애려던 바로 그 명령 통제식, 계획 중심의 오버헤드를 다시 들여오는 경우가 많습니다. 큰 프레임워크를 도입하기 전에 축소를 시도하십시오. 분명한 소유권과 최소한의 팀 간 의존성을 가진 독립적이고 스트림 정렬된 팀을 중심으로 조직해(1.2장), 애초에 필요한 조율 장치를 줄이십시오. 조율이 정말 필요한 곳에서는 통하는 가장 가벼운 구조를 더하고, 산출이 아니라 성과(OKR, 목표와 핵심 결과, 11.1장)에 연결하십시오.

기업과 정부에서 민첩성을 현실로 만든다

적응적 전달과 제도적 제약은 공존할 수 있지만 의도적 설계가 필요합니다.

하이브리드 거버넌스: 예측형 자금/컴플라이언스 껍질 안의 적응형 전달 핵심(10.6장)으로, 반복이 감독과 싸우지 않고 만족시킵니다.
애자일 조달: 하나의 고정 범위 초대형 계약 대신 모듈식 성과 기반 계약과 더 짧은 증분. 공공 부문 애자일이 가장 자주 성공하거나 실패하는 곳입니다.
하면서 컴플라이언스: 감사, 접근성(5.3장), 보안(4.1장)을 늦은 관문이 아니라 자동화와 적합성 함수(아키텍처와 품질 속성을 지속적으로 검증하는 자동 점검, 8.5장, 1.6장)를 통해 증분에 구축합니다.
실제 사용자 접근: 가장 어렵고 가장 중요합니다. 팀은 시민이나 고객과 진짜 접촉이 필요한데, 조달과 보안 규칙이 이를 가로막는 경우가 많습니다.

지속적으로 개선하고, 진심으로 한다

회고는 애자일의 개선 엔진이며, 변화를 낳지 않으면 가치가 없습니다. 구체적이고 소유자가 있는 소수의 행동을 생성하는 회고를 운영하고, 다음 회고 전에 실제로 완료하십시오. 성과(변화가 핵심 결과를 움직였는가? 11.1장 참조)와 흐름(리드 타임이 줄고 있는가? 11.2장, 11.3장 참조)을 측정하십시오. 속도(velocity)는 측정하지 마십시오. 생산성 목표로 쓰는 순간 거짓말이 되는 용량 신호입니다.

장단점

결정	장점	단점
애자일(적응형)	빠른 피드백. 변화를 흡수. 이르고 지속적인 가치	범위/비용을 앞서 고정하기 어려움. 참여하는 고객과 규율 요구
폭포수(예측형)	예측 가능한 범위. 계약/감사에 친화적	늦은 피드백. 일괄 위험. 불확실한 요구 사항에 부적합
스크럼	주기, 역할, 집중. 널리 이해됨	의례 오버헤드. 끼어들기 주도적인 일에 고전
칸반	흐름, WIP 한도, 유연. 운영에 훌륭	구조가 적음. 한도를 지키는 규율 필요
무거운 확장(SAFe)	많은 팀을 조율. 큰 조직에 익숙	명령 통제를 다시 들여올 수 있음. 의례가 무거움
축소 / 팀 자율	적은 조율 오버헤드. 빠른 팀	낮은 결합과 강한 플랫폼/소유권 필요

결정적 긴장은 적응성 대 예측 가능성이며, 고전적인 오해는 애자일이 “계획 없음”을 뜻한다는 것입니다. 그렇지 않습니다. 지속적으로 계획하고 성과와 주기를 약속하면서 범위를 유연하게 둔다는 뜻입니다. 또 하나의 반복되는 덫은 애자일을 오직 프로세스(의례)나 오직 엔지니어링(XP)으로만 보는 것입니다. 둘 다 필요합니다.

팀과 논의할 질문

기업이나 정부 맥락에서 계약은 모듈식이고 성과 기반입니까, 아니면 전달이 하나의 고정 범위 초대형 계약에 갇혀 있습니까? 애자일 조달은 공공 부문 민첩성이 가장 자주 성공하거나 실패하는 곳입니다. 하나의 고정 가격, 고정 범위 계약은 전달 팀이 회의를 뭐라고 부르든 폭포수를 강제하기 때문입니다. 더 짧은 증분이 있는 모듈식 성과 기반 계약은 고정된 자금 안에서 범위를 가치 있는 핵심으로 유연하게 해 주며, 이것이 바로 현대 공공 부문 성공의 패턴이자 과거 일괄 실패의 해독제입니다. 증거를 가져오십시오. 현재 계약을 보고, 벤더가 입증된 동작하는 소프트웨어에 대해 대가를 받는지, 수년 전에 승인된 고정 범위에 대해 받는지 물으십시오. 답은 팀이 내부적으로 어떤 프레임워크를 채택하는지보다 다음 조달을 어떻게 구조화할지를 훨씬 많이 형성해야 합니다. 계약이 먼 전부 아니면 전무의 가동을 명령하는 동안에는 전달에서 적응적일 수 없습니다.
감사, 접근성, 보안은 자동화를 통해 각 증분에 내장됩니까, 늦은 관문으로 덧붙여집니까? 하면서 컴플라이언스는 적응적 전달이 제도적 제약과 공존하게 해 주는 것입니다. 출시 전 허둥지둥에 점검을 몰아두는 대신 자동화와 적합성 함수를 통해 증분에 점검을 내장하십시오. 늦은 컴플라이언스 관문은 애자일이 없애려는 일괄 위험을 다시 들여옵니다. 비싼 문제가 끝에, 고치기 가장 어려울 때 드러나기 때문입니다. 증거를 가져오십시오. 마지막 증분에서 접근성, 보안, 감사 증거가 파이프라인에서 자동으로 검증되었는지, 출시 전 수동 리뷰로 미뤄졌는지 확인하십시오. 답은 이런 속성을 지속적인 자동 점검으로 밀어 넣어 감독이 별도 단계가 아니라 만드는 행위로 충족되게 해야 합니다. 이것이 규제 대상 프로그램을 감사 직전 몇 주만이 아니라 감사 사이에도 정직하게 유지하는 방법입니다.
팀이 기술 부채 속으로 스프린트하고 있는지 어떻게 알며, 출시 압박 아래서 지속 가능한 속도를 지키는 것은 무엇입니까? 엔지니어링 규율 없는 애자일은 팀이 결함과 유지할 수 없는 코드의 타르 구덩이로 빠르게 스프린트하는 다크 스크럼으로 퇴화하고, 소진된 팀은 품질이나 대응성을 유지할 수 없습니다. XP 실천(지속적 통합, 자동화된 테스트, 리팩터링, 트렁크 기반 개발)은 팀이 소프트웨어를 싸게 계속 바꿀 수 있게 하는 것으로 민첩성의 전체 전제이므로, 날짜가 닥칠 때 맞바꿀 선택적 부가물이 아닙니다. 증거를 가져오십시오. 리드 타임이 줄고 있는지 늘고 있는지, 결함률이 오르고 있는지, 팀이 각 스프린트를 맞추려고 조용히 더 오래 일하고 있는지 추적하십시오. 답은 기술적 탁월함과 인간적인 속도를 협상 불가로 만들어야 합니다. 장인 정신을 희생해 산 속도는 몇 번의 반복 안에 무너지기 때문입니다. 흐름과 성과를 측정하되 속도를 목표로 삼지 마십시오. 용량 신호를 생산성 목표로 만드는 순간 거짓말이 되기 때문입니다.
무거운 확장 프레임워크에 손을 뻗기 전에, 애초에 조율의 필요를 만드는 팀 간 의존성을 줄이려고 해 보았습니까? 이것은 큰 조직에서 가장 중요합니다. 많은 팀이 함께 출하해야 할 때의 반사는 SAFe, LeSS, Scrum@Scale 같은 프레임워크를 사는 것인데, 무거운 확장 장치는 애자일이 없애려는 명령 통제식, 계획 중심의 오버헤드를 슬그머니 되들여오는 경우가 많기 때문입니다. 경쟁하는 고려는 실제입니다. 일부 조율은 정말 필요하며, 독립적이고 스트림 정렬된 팀으로의 축소는 낮은 결합, 분명한 소유권, 팀이 셀프서비스할 만큼 성숙한 플랫폼을 요구하고, 아직 없을 수 있습니다. 논의에 증거를 가져오십시오. 팀이 서로를 기다리게 하는 실제 의존성을 지도화하고, 팀 경계와 서비스 소유권의 의도적 재설계에서 몇 개가 살아남을지 물으십시오. 수십 개 팀의 조직도가 흔한 기업과 정부 프로그램에서 정직한 질문은, 단순화할 수 있는 아키텍처와 팀 설계를 보완하려고 조율 구조를 더하고 있는지, 그래서 조율이 아예 덜 필요하게 할 수 있는지입니다.
팀이 만드는 대상인 시민이나 고객과 진짜로 반복되는 접촉이 있습니까, 아니면 피드백이 대리인을 거쳐 걸러져 도착합니까? 고객과의 협업은 선언의 네 가지 가치 중 하나이며, 진짜 사용자 접촉이 없는 반복은 엉뚱한 것을 조용히 최적화하는데 이것이 애자일이 막아야 하는 가장 비싼 실패입니다. 긴장은 직접 접근을 규모에서 마련하기가 어렵고, 큰 조직과 공공 조직이 지켜야 하는 바로 그 조달, 프라이버시, 보안 규칙이 흔히 가로막는다는 것이라, 쉬운 길은 대리인으로 대체하는 것입니다. 비즈니스 분석가, 이해관계자 위원회, 지난 분기의 연구 자료입니다. 증거를 가져오십시오. 최근 몇 번의 증분에 대해 실제 사용자가 소프트웨어를 쓰는 것으로 검증된 것이 몇 개이고 사용자가 원하는 것에 대한 누군가의 의견에 기댄 것이 몇 개인지 세어 보십시오. 정부 서비스에서는 사용성 테스트가 보조 기술 사용자와 낮은 디지털 자신감을 가진 사람들을 포함해 가장 영향받는 사람들에게 닿았는지 더하십시오. 자신 있는 다수에게만 동작하는 공공 서비스는 모든 의례가 일정대로 돌았더라도 책임 의무를 저버린 것이기 때문입니다.
팀은 성과와 주기를 중심으로 자금을 받고 다스려집니까, 아니면 의례 뒤에서 조용히 폭포수를 강제하는 고정 범위를 중심으로 합니까? 이것이 진짜 민첩성과 가짜 애자일의 차이이며, 팀 위에서, 돈이 풀리는 방식과 성공이 보고되는 방식에서 결정되지 스탠드업이 일어나는지에서 결정되지 않습니다. 경쟁하는 끌림은 재무, 포트폴리오, 감독 기능이 수년 앞서 고정 예산에 대해 고정 범위를 승인하도록 만들어져 있어, 유연한 범위의 성과에 자금을 대 달라는 요청이 그들이 저항할 통제의 상실처럼 느껴진다는 것입니다. 증거를 가져오십시오. 현재 이니셔티브가 어떻게 자금을 받았고 무엇을 보고하는지 추적하고, 팀이 전달된 성과와 흐름으로 측정되는지, 스토리 포인트와 오래전에 승인된 범위의 준수로 측정되는지 확인하십시오. 기업과 정부 환경에서는 이를 자금 및 컴플라이언스 껍질(10.6장)에 직접 연결하십시오. 돈이 먼 전부 아니면 전무의 가동에 약정되어 있다면, 팀이 의식을 아무리 충실히 수행해도 적응적일 수 없으며, 수정은 전달 팀이 아니라 거버넌스 모델에 속합니다.

분야별 관점

스타트업. 가치를 살고 프레임워크 논쟁은 건너뛰십시오. 매주 진짜 사용자에게 동작하는 조각을 출하하고, 피드백이 매일 도착할 만큼 창업자와 초기 고객 가까이에 앉고, 증거가 현재의 내기가 틀렸다고 말하는 순간 방향 전환을 환영하십시오. 가장 희소한 자원은 엔지니어링 주의이므로, 출시 압박 아래서도 기술적 탁월함(지속적 통합, 자동화된 테스트, 트렁크 기반 개발)을 지키십시오. 그 규율이 다음 주에 싸게 방향을 틀 수 있게 해 주기 때문입니다.

소기업. 애자일 코치도 없고 예산도 빠듯하니, 애자일을 인력을 둬야 하는 전환 프로그램이 아니라 몇 가지 습관으로 다루십시오. 짧은 주간 주기, WIP 한도가 있는 보이는 보드, 매주 실제로 끝내는 구체적 개선 하나입니다. 의례가 적고 끼어들기 주도적인 일에 맞는 칸반에 기대고, 무거운 프로세스를 세우는 대신 이미 사는 도구에 내장된 실천을 채택하십시오. 스크럼을 얼마나 흉내 냈는지가 아니라 고객에게 쓸모 있는 소프트웨어를 더 자주 출하하고 있는지로 노력을 판단하십시오.

대기업. 문제는 명령 통제를 다시 들여오지 않으면서 많은 팀을 조율하는 것입니다. 무거운 확장 프레임워크를 도입하기 전에 스트림 정렬된 팀 설계와 탄탄한 플랫폼으로 팀 간 의존성을 줄이는 축소를 선호하십시오. 고정된 연간 범위와 스토리 포인트가 아니라 성과(OKR)와 주기를 중심으로 자금을 대고 다스리며, XP식 엔지니어링 실천을 팀 전반에서 협상 불가로 만들고, 전달을 흐름 지표와 성과 척도가 있는 포트폴리오로 관리해 집단이 의례가 아니라 증거로 개선하게 하십시오.

정부. 조달 규칙, 투명성, 공적 책무가 모든 선택을 형성합니다. 하나의 고정 범위 초대형 계약 대신 더 짧은 증분이 있는 모듈식 성과 기반 계약을 구성하십시오. 애자일 조달이 공공 부문 민첩성이 가장 자주 성공하거나 실패하는 곳이기 때문입니다. 감독이 만드는 행위로 충족되도록 자동화를 통해 감사, 접근성, 보안을 각 증분에 내장하고, 진행과 공공 가치의 증거를 감독 기관에 공개하고, 가장 자주 협상으로 사라지는 제약인 시민(보조 기술 사용자 포함)에 대한 진짜 접근을 매 반복 싸워 얻으십시오.

사례

스타트업. 다섯 명의 스타트업이 의례 논쟁을 건너뛰고 애자일 가치를 직접 삽니다. 매주 진짜 사용자에게 동작하는 조각을 출하하고, 피드백이 매일 도착할 만큼 창업자와 초기 고객 가까이에 앉고, 증거가 현재의 내기가 틀렸다고 말하면 다음 주 방향 전환을 환영합니다. 팀은 속도를 위해 기술적 탁월함을 맞바꾸기를 거부해, 출시 압박 아래서도 지속적 통합, 자동화된 테스트, 트렁크 기반 개발은 협상 불가이고, 매주 금요일 회고는 팀이 다음 회고 전에 실제로 끝내는 구체적 변화 하나를 낳습니다. 속도를 목표로 추적하지 않고, 출하한 일이 활성화를 움직였는지와 리드 타임이 줄고 있는지를 측정합니다.

기업. 60개 팀의 한 통신사 전환은 처음에 “스크럼을 하지만” 개선이 없습니다. 팀은 여전히 고정된 연간 범위를 받고 속도를 보고합니다. 재설정이 원칙에 다시 초점을 맞춥니다. 분기별 OKR이 기능 지시를 대체하고, 팀 간 의존성을 줄이도록 팀이 재편되며(축소), XP 실천(CI, TDD, 트렁크 기반 개발)이 협상 불가가 됩니다. 리드 타임이 줄고 결함이 떨어지며, 결정적으로 비즈니스가 스토리 포인트가 아니라 성과를 측정하기 시작해 애자일 전달을 디스커버리 파이프라인(11.1장)에 연결합니다.

정부. 한 디지털 서비스 팀이 하이브리드 거버넌스 껍질 안에서 애자일로 시민 대면 급여 신청을 다시 만듭니다. 동작하고 사용자 테스트를 거친 소프트웨어를 전달하는 2주 증분, 모든 증분에 내장된 접근성과 보안, 단일 고정 가격 계약을 대체하는 모듈식 조달입니다. 매 반복 시민(보조 기술 사용자 포함)과 하는 실제 사용성 테스트가 옛 폭포수 프로세스라면 출하했을 문제를 잡아냅니다. 프로그램은 쓸 수 있는 서비스를 일찍 전달하고 감독 기관에 측정 가능한 공공 가치를 보입니다. 이것이 현대 공공 부문 성공의 패턴이자 과거 일괄 실패의 해독제입니다.

비즈니스 사례: 동기, ROI, TCO

애자일의 수익은 위험 감소와 더 빠른 가치 실현에서 옵니다. 동작하는 소프트웨어를 일찍 자주 전달함으로써 팀은 불확실성을 지속적으로 증거로 바꾸고, 멀고 비싼 가동이 아니라 쌀 때 잘못된 것과 동작하지 않을 것의 실패를 잡습니다. 현대 전달의 연구(11.2장의 DORA, DevOps 리서치 및 평가 결과)는 애자일이 촉진하는 실천(작은 배치, 잦은 릴리스, 빠른 피드백, 기술적 탁월함)이 더 나은 전달 그리고 안정성 그리고 조직 성과와 상관됨을 보여 줍니다. 이른 증분도 가치를 더 일찍 돌려주기 시작해, 끝까지 아무것도 돌려주지 않는 일괄 릴리스에 비해 ROI의 시기와 전체 크기를 개선합니다.

총소유비용 측면에서 애자일은 엔지니어링 규율이 실제인 한 시스템 수명 동안 변경의 비용을 낮춥니다. 지배적 위험은 가짜 애자일입니다. 원칙이나 장인 정신 없는 의례는 회의 오버헤드를 더하면서 이점은 전혀 전달하지 않으며 정직한 폭포수보다 나쁠 수 있습니다. 그래서 비즈니스 사례는 조건부입니다. 애자일을 마인드셋에 엔지니어링을 더한 것으로 채택하면 ROI가 높고, 의례로 채택하면 대략 영(또는 음)입니다. 애자일을 “더 빨리 가는 것”이 아니라 지속적 위험 감소와 성과 측정으로 구성하고, 투자에 새 회의만이 아니라 기술 실천이 포함되도록 고집해 리더십을 설득하십시오.

안티패턴과 함정

가짜 / 화물 숭배 애자일: 결정, 자금, 마인드셋은 폭포수로 남은 채 의례만 수행하는 것.
생산성으로서의 속도: 용량 추정을 목표로 바꿔 왜곡하는 것(굿하트의 법칙).
다크 스크럼: 기술적 탁월함 없이 유지할 수 없고 결함투성이인 코드로 스프린트하는 것.
변화 없는 회고: 완료된 행동을 낳지 않는 성찰.
범위 그리고 날짜 그리고 비용 고정: 품질이 조용히 압박을 흡수하는데 그것을 애자일이라 부르는 것.
부재한 고객: 진짜 사용자 피드백이 없어 반복이 엉뚱한 것을 최적화하는 것.
프레임워크 숭배: “SAFe/스크럼이 그렇게 말합니다”가 원칙과 팀의 판단을 앞서는 것.
축소 전 확장: 의존성을 줄이는 대신 무거운 조율 프레임워크를 더하는 것.

성숙도 모델

1단계, 시작. 폭포수 또는 임시 전달. 일괄 릴리스. 일은 반응적이고 계획 중심이며, 반복적 피드백도 애자일이 왜 도움이 될지에 대한 공유된 감각도 없습니다.
2단계, 발전. 몇몇 팀이 애자일 의례(스탠드업, 스프린트, 회고)를 채택하지만 조직 전체에서 실천이 일관되지 않습니다. 마인드셋과 엔지니어링 규율이 의식에 뒤처지고, 속도가 산출로 다뤄지며, 범위는 여전히 앞서 고정됩니다.
3단계, 표준화. 가치와 원칙이 조직 전체에서 진짜로 일을 이끌고, 문서화되어 모든 팀에 기대됩니다. XP식 기술적 탁월함(CI, 자동화된 테스트, 리팩터링, 트렁크 기반 개발)이 표준 실천이고, 팀은 자기 조직화하고, 고객은 매 반복 참여하며, 회고는 구체적이고 완료된 변화를 낳습니다.
4단계, 관리. 전달이 기준선에 대해 측정되고 통제됩니다. 팀은 리드 타임, 배포 빈도, 변경 실패율, 결함 유출률(DORA식 흐름 및 안정성 지표)을 핵심 결과에 묶인 성과 척도와 함께 추적하고 각각을 알려진 기준선과 비교합니다. 회고 행동은 완료까지 추적되고, 초과 근무와 소진 같은 지속 가능한 속도 신호가 모니터링되며, 속도는 결코 생산성 목표로 쓰이지 않습니다. 진행과 중단 결정은 의견이 아니라 이 증거에 근거합니다.
5단계, 오케스트레이션. 적응적 전달이 조직 전체의 비즈니스 및 위험 계획과 통합됩니다. 성과(OKR)가 자금과 주기를 이끌고, 낮은 의존성의 팀 설계(축소)가 조율 오버헤드를 최소화하며, 하이브리드 거버넌스가 전달을 늦추지 않으면서 감독을 만족시킵니다. 지속적 개선은 의례적이 아니라 문화적이며, 조직은 증거와 위험 상황이 이동함에 따라 일상적으로 범위를 다시 정하고, 팀을 다시 꾸리고, 포트폴리오를 재균형합니다.

논의를 위한 아이디어

12개 애자일 원칙에 대해 팀의 점수를 매겨 보십시오. 의례에서는 애자일하지만 실질에서는 그렇지 않은 곳은 어디입니까?
팀에서 속도는 예측으로 쓰입니까 목표로 쓰입니까? 그것이 행동에 무엇을 했습니까?
어떤 XP 기술 실천이 빠져 있으며, 그 부재가 결함이나 느린 변경으로 어떻게 나타납니까?
확장 프레임워크를 채택하기 전에 팀 간 의존성을 대신 줄일 수 있습니까?
여러분의 맥락에서 매 반복 진짜 사용자 접근을 구체적으로 막는 것은 무엇이며, 어떻게 제거할 수 있습니까?
회고가 실제로 낳은 마지막 구체적 변화는 무엇이었습니까?

핵심 요점

애자일은 의례의 집합이 아니라 가치와 원칙의 마인드셋입니다. 프레임워크는 목표가 아니라 출발점입니다.
동작하는 소프트웨어를 자주 전달하고, 변화를 환영하고, 자기 조직화하는 팀에게 권한을 주십시오.
기술적 탁월함(XP 실천)은 협상 불가입니다. 그것 없는 민첩성은 빠른 부식이 됩니다.
조심스럽게 확장하고 축소를 선호하십시오. 조율 프레임워크를 더하기 전에 의존성을 줄이십시오.
기업/정부에서는 적응적 전달을 하이브리드 거버넌스와 애자일 조달에 결합하고 실제 사용자 접근을 위해 싸우십시오.
ROI는 지속적 위험 감소와 더 이른 가치이지만, 애자일이 의례가 아니라 실제일 때만 그렇습니다. 1.4장, 11.1장, 11.2장, 10.6장, 11.3장을 보십시오.

참고 문헌과 더 읽을거리

Kent Beck et al., Manifesto for Agile Software Development and its twelve principles (agilemanifesto.org, 2001).
Ken Schwaber and Jeff Sutherland, The Scrum Guide.
Kent Beck, Extreme Programming Explained: Embrace Change.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
Mike Cohn, User Stories Applied and Succeeding with Agile.
Jeff Patton, User Story Mapping.
Stephen Denning, The Age of Agile.
Matthew Skelton and Manuel Pais, Team Topologies (team design and descaling).
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (evidence for agile/DevOps practices).
U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.