Plan보다 Planning이 중요한 이유: Legacy IT에서 Agile로의 여정

"Plans are worthless, but planning is everything." — Dwight D. Eisenhower, 1957

20년 넘게 IT 프로젝트를 수행하면서 수많은 프로젝트 계획서를 작성하고, 그 계획이 현실과 충돌하는 모습을 지켜봤습니다. 완벽하게 작성된 WBS(Work Breakdown Structure), 정교한 간트 차트, 상세한 리소스 할당표... 이 모든 것들이 프로젝트 시작 몇 주 만에 무용지물이 되는 경험을 반복했습니다.

이 글에서는 왜 "계획(Plan)"을 지키려는 집착이 오히려 프로젝트를 실패로 이끄는지, 그리고 "계획 활동(Planning)"에 집중하는 것이 왜 더 효과적인지를 Legacy IT 경험과 Agile 실천의 관점에서 깊이 있게 다루겠습니다.

1장: Plan을 지키려는 집착의 배경

1.1 전통적 프로젝트 관리의 유산

전통적인 프로젝트 관리 방법론, 특히 Waterfall 모델은 제조업과 건설업에서 유래했습니다. 이 분야에서는 요구사항이 명확하고, 변경 비용이 매우 높으며, 순차적 진행이 물리적으로 필요합니다. 건물의 기초를 다지기 전에 지붕을 올릴 수 없듯이 말입니다.

이러한 배경에서 "계획을 세우고 그대로 실행한다"는 접근법은 합리적이었습니다. 문제는 이 방식을 소프트웨어 개발에 그대로 적용했다는 것입니다.

1.2 소프트웨어 개발의 본질적 불확실성

소프트웨어 개발은 근본적으로 다릅니다:

요구사항의 불확실성: 고객조차 자신이 원하는 것을 정확히 모릅니다. 실제로 동작하는 소프트웨어를 보기 전까지는 진정한 요구사항을 발견하기 어렵습니다.

기술적 불확실성: 새로운 기술, 예상치 못한 통합 문제, 성능 이슈 등이 프로젝트 중간에 발생합니다.

환경의 변화: 시장 상황, 경쟁사의 움직임, 규제 변화 등 외부 요인이 프로젝트 기간 중에 변합니다.

1.3 Plan 집착이 만드는 악순환

Plan을 지키려는 집착은 다음과 같은 악순환을 만듭니다:

초기 계획 수립 → 현실과의 괴리 발생 → 계획 고수 압박 
    ↓
품질 저하 / 야근 증가 → 팀 사기 저하 → 더 큰 지연
    ↓
결국 계획 실패 → "다음엔 더 정교한 계획을" → 반복

이것이 바로 제가 Legacy IT 프로젝트에서 반복적으로 목격한 패턴입니다.

2장: Eisenhower의 통찰 - Planning의 진정한 가치

2.1 "Plans are worthless, but planning is everything"

1957년, 아이젠하워 대통령은 군사 및 외교 정책에 대해 이야기하며 이 유명한 말을 남겼습니다. 이 역설적인 문장은 소프트웨어 개발에도 깊은 통찰을 제공합니다.

Plan(계획서)이 무가치한 이유:

미래는 예측 불가능합니다
상황은 계속 변합니다
초기 가정은 대부분 틀립니다

Planning(계획 활동)이 모든 것인 이유:

문제 영역에 대한 깊은 이해를 제공합니다
팀 간 공유된 이해(Shared Understanding)를 만듭니다
변화에 대응할 수 있는 역량을 키웁니다
의사결정을 위한 프레임워크를 제공합니다

2.2 Planning이 제공하는 진정한 가치

Planning 활동을 통해 얻는 것은 "완벽한 계획서"가 아닙니다:

1. 맥락의 이해 (Context Understanding) 계획을 세우는 과정에서 우리는 비즈니스 목표, 기술적 제약, 이해관계자의 기대를 깊이 이해하게 됩니다.

2. 위험의 식별 (Risk Identification) "만약 ~라면?"이라는 질문을 던지면서 잠재적 위험을 미리 파악합니다.

3. 팀의 정렬 (Team Alignment) 함께 계획하는 과정에서 팀원들이 같은 방향을 바라보게 됩니다.

4. 적응 역량 (Adaptive Capacity) 다양한 시나리오를 고려하면서 변화에 대응할 수 있는 정신적 준비를 갖추게 됩니다.

3장: Legacy IT 프로젝트의 교훈

3.1 실패한 프로젝트들의 공통점

20년간 경험한 실패 프로젝트들의 공통점을 분석해보면:

과도한 사전 계획: 6개월 이상의 분석/설계 기간을 거친 후 개발 시작

변경 통제의 경직성: 모든 변경에 복잡한 승인 프로세스 적용

계획 대비 실적 관리: 원래 계획과의 차이만 추적, 가치 전달은 무시

빅뱅 배포: 모든 기능을 한 번에 배포하려는 시도

3.2 성공한 프로젝트들의 공통점

반면, 성공한 프로젝트들은:

점진적 계획: 가까운 미래는 상세하게, 먼 미래는 대략적으로

빈번한 피드백: 2-4주 단위로 실제 동작하는 소프트웨어 시연

변화 수용: 변경을 문제가 아닌 학습의 기회로 인식

지속적 개선: 프로세스 자체를 계속 개선

3.3 전환점: Agile의 발견

2001년 Agile Manifesto가 발표되었을 때, 그것은 단순한 새로운 방법론이 아니었습니다. 그것은 소프트웨어 개발의 본질에 대한 근본적인 재인식이었습니다.

"Responding to change over following a plan" — Agile Manifesto

이것은 "계획하지 말라"는 의미가 아닙니다. "계획을 맹목적으로 따르지 말고, 변화에 대응하라"는 의미입니다.

4장: Continuous Planning의 원칙

4.1 Agile Planning의 핵심 개념

Agile에서의 Planning은 일회성 이벤트가 아닌 지속적인 활동입니다:

Rolling Wave Planning: 가까운 미래는 상세하게, 먼 미래는 점진적으로 구체화

Just-in-Time Planning: 필요한 시점에 필요한 만큼만 계획

Empirical Planning: 실제 데이터와 경험을 바탕으로 계획 조정

4.2 Planning의 여러 수준

효과적인 Agile 조직은 여러 수준에서 Planning을 수행합니다:

수준	시간 범위	주기	산출물
Vision	1-3년	분기별 검토	Product Vision
Roadmap	3-12개월	월별 검토	Product Roadmap
Release	1-3개월	격주 검토	Release Plan
Iteration	1-4주	매 Sprint	Sprint Backlog
Daily	1일	매일	Daily Plan

4.3 적응형 계획의 특징

데이터 기반 의사결정: 추측이 아닌 실제 Velocity, Lead Time 등의 데이터 활용

확률적 예측: 단일 날짜가 아닌 범위로 예측 (예: 80% 확률로 3월 중 완료)

옵션 보존: 가능한 한 늦게 결정하여 더 많은 정보를 바탕으로 선택

5장: Scrum에서의 Planning 실천

5.1 Scrum의 Planning 이벤트들

Scrum은 여러 수준의 Planning 이벤트를 제공합니다:

Sprint Planning: 매 Sprint 시작 시 수행

Sprint Goal 설정
Product Backlog에서 Sprint Backlog로 아이템 선택
작업 분해 및 계획

Daily Scrum: 매일 15분

어제 한 일, 오늘 할 일, 장애물 공유
Sprint Goal 달성을 위한 일일 계획 조정

Sprint Review: Sprint 종료 시

완료된 작업 시연
피드백 수집
Product Backlog 조정

Sprint Retrospective: Sprint 종료 시

프로세스 개선점 도출
다음 Sprint에 적용할 개선 사항 결정

5.2 Sprint Planning 깊이 들여다보기

효과적인 Sprint Planning의 핵심 요소:

1. Sprint Goal 먼저 개별 아이템이 아닌 Sprint의 목표를 먼저 정의합니다. 이것이 의사결정의 기준이 됩니다.

2. 팀의 Capacity 고려 휴가, 회의, 기타 업무 등을 고려한 실제 가용 시간을 계산합니다.

3. 과거 데이터 활용 이전 Sprint의 Velocity를 참고하되, 맹신하지 않습니다.

4. 불확실성 인정 모든 것을 미리 알 수 없음을 인정하고, Sprint 중 조정할 여지를 남깁니다.

5.3 Scrum에서 흔한 Planning 실수

실수 1: Sprint Planning을 Commitment로 취급 Sprint Backlog는 예측(Forecast)이지 약속(Commitment)이 아닙니다.

실수 2: 모든 것을 미리 상세화 Sprint 시작 시 모든 Task를 정의하려 하지 마세요. 필요할 때 상세화하세요.

실수 3: Velocity를 목표로 설정 Velocity는 측정 도구이지 목표가 아닙니다. 목표로 설정하면 왜곡됩니다.

6장: Kanban에서의 Planning 실천

6.1 Kanban의 Planning 철학

Kanban은 Scrum과 다른 접근을 취합니다:

연속적 흐름 (Continuous Flow): 고정된 Sprint 없이 작업이 지속적으로 흐름

Pull 시스템: 새 작업은 용량이 생길 때만 시작

WIP 제한: 동시 진행 작업 수를 제한하여 흐름 최적화

6.2 Kanban의 Cadences (주기적 미팅)

Kanban은 7가지 Cadence를 제안합니다:

1. Strategy Review (분기별)

조직의 전략적 방향 검토
서비스의 적합성 평가

2. Operations Review (월별)

여러 서비스/팀 간의 조율
시스템 수준의 개선

3. Risk Review (월별)

블로커와 의존성 검토
리스크 완화 전략 수립

4. Service Delivery Review (격주)

서비스 수준 지표 검토
고객 만족도 평가

5. Replenishment Meeting (주간 또는 필요시)

새로운 작업 아이템 선택
우선순위 조정

6. Kanban Meeting (일일)

흐름의 장애물 식별
블로커 해결

7. Delivery Planning Meeting (필요시)

배포 계획 수립
릴리스 조율

6.3 WIP 제한과 Planning의 관계

WIP(Work In Progress) 제한은 Kanban의 핵심입니다:

왜 WIP를 제한하는가?

멀티태스킹의 비효율 제거
흐름 개선 및 Lead Time 단축
병목 현상 가시화
예측 가능성 향상

WIP 제한이 Planning에 미치는 영향:

높은 WIP → 긴 Lead Time → 예측 어려움 → Planning 무의미
낮은 WIP → 짧은 Lead Time → 예측 가능 → 효과적 Planning

6.4 Kanban에서의 예측

Kanban은 확률적 예측을 사용합니다:

Monte Carlo 시뮬레이션: 과거 데이터를 바탕으로 미래 완료 시점을 확률적으로 예측

예시:

50% 확률: 2월 15일까지 완료
85% 확률: 2월 28일까지 완료
95% 확률: 3월 10일까지 완료

이러한 접근은 단일 날짜 약속보다 훨씬 현실적이고 유용합니다.

7장: Scrumban - 두 세계의 장점 결합

7.1 Scrumban이란?

Scrumban은 Scrum의 구조와 Kanban의 흐름 관리를 결합한 하이브리드 접근법입니다.

Scrum에서 가져온 것:

정기적인 Planning 미팅
Retrospective를 통한 개선
역할 구조 (선택적)

Kanban에서 가져온 것:

WIP 제한
연속적 흐름
시각적 관리
Pull 시스템

7.2 Scrumban에서의 Planning

Scrumban의 Planning은 유연합니다:

On-Demand Planning: 고정된 Sprint 대신, Backlog가 특정 수준 이하로 떨어지면 Planning 트리거

Planning Trigger 예시:

Ready 상태의 아이템이 5개 이하가 되면 Replenishment Meeting 개최
이를 통해 Just-in-Time Planning 실현

7.3 점진적 전환 전략

Legacy 환경에서 Agile로 전환할 때 Scrumban은 좋은 징검다리가 됩니다:

1단계: 시각화

현재 작업을 Kanban 보드에 시각화
기존 프로세스는 유지

2단계: WIP 제한 도입

점진적으로 WIP 제한 적용
병목 현상 관찰 및 해결

3단계: 흐름 측정

Lead Time, Cycle Time 측정 시작
데이터 기반 의사결정 시작

4단계: Planning 개선

데이터를 바탕으로 예측 정확도 향상
점진적으로 Planning 주기 조정

8장: 실행 가이드 - 조직에서 적용하기

8.1 현재 상태 진단

변화를 시작하기 전에 현재 상태를 파악하세요:

질문 체크리스트:

현재 Planning에 얼마나 시간을 투자하는가?
계획 대비 실제 차이가 얼마나 발생하는가?
변경 요청이 얼마나 자주 발생하는가?
팀이 계획 변경에 어떻게 반응하는가?
고객/이해관계자의 만족도는 어떠한가?

8.2 작게 시작하기

파일럿 프로젝트 선정 기준:

중요하지만 치명적이지 않은 프로젝트
변화에 열린 팀
2-3개월 내 결과를 볼 수 있는 규모
경영진의 지원이 있는 영역

8.3 측정 지표 설정

흐름 지표:

Lead Time: 요청부터 완료까지 시간
Cycle Time: 작업 시작부터 완료까지 시간
Throughput: 단위 시간당 완료 아이템 수

품질 지표:

결함 발생률
재작업 비율
고객 만족도

예측 지표:

예측 정확도
계획 변경 빈도

8.4 문화적 변화 관리

기술적 변화보다 문화적 변화가 더 어렵습니다:

리더십의 역할:

실패를 학습의 기회로 프레이밍
계획 변경을 정상적인 것으로 인정
팀의 자율성 존중

팀 수준의 변화:

심리적 안전감 구축
투명한 커뮤니케이션 장려
지속적 학습 문화 조성

9장: 흔한 저항과 대응 방법

변화는 항상 저항을 동반합니다. 20년간 다양한 조직에서 Agile 전환을 시도하면서 만난 저항들과, 그것을 극복한 경험을 공유합니다. 중요한 것은 저항을 "적"으로 보지 않는 것입니다. 저항은 대부분 합리적인 우려에서 비롯되며, 그 우려를 이해하고 해소하는 것이 진정한 변화의 시작입니다.

9.1 "우리는 계획이 필요해"

이 말의 숨은 의미: 이 저항은 보통 과거에 계획 없이 혼란스러웠던 경험에서 비롯됩니다. "Agile = 계획 없음"이라는 오해가 깔려 있는 경우가 많습니다.

실제 우려:

방향성 없이 표류하는 것에 대한 두려움
이해관계자에게 진행 상황을 설명할 수 없을 것이라는 걱정
리소스 할당과 예산 관리의 어려움

효과적인 대응:

"물론입니다. 사실 우리는 더 많이, 더 자주 계획할 것입니다. 차이점은 한 번의 큰 계획 대신 지속적인 작은 계획들로 바꾸는 것입니다."

구체적인 설명:

기존 방식: 6개월 계획 → 6개월 실행 → 결과 확인
새로운 방식: 2주 계획 → 2주 실행 → 결과 확인 → 조정 → 반복

실제 사례로 설득: "지난 프로젝트에서 초기 계획 대비 실제 결과가 얼마나 달랐는지 기억하시나요? 우리가 제안하는 것은 그 차이를 6개월 후가 아니라 2주 후에 발견하고 조정하자는 것입니다."

9.2 "고객이 정확한 일정을 원해"

이 말의 숨은 의미: 계약, 예산 승인, 마케팅 일정 등 비즈니스 현실에서 "언제 완료되나요?"라는 질문은 피할 수 없습니다. 이 저항은 매우 현실적인 비즈니스 요구에서 비롯됩니다.

실제 우려:

계약상 납기 약속
마케팅 캠페인과의 연동
예산 집행 시기
경영진 보고

효과적인 대응:

"고객이 진정으로 원하는 것은 '정확한 날짜'가 아니라 '신뢰할 수 있는 예측'입니다. 확률적 예측과 빈번한 업데이트가 단일 날짜 약속보다 더 신뢰할 수 있습니다."

구체적인 대안 제시:

기존 방식	새로운 방식
"3월 15일에 완료됩니다"	"85% 확률로 3월 중 완료, 95% 확률로 4월 첫째 주 완료"
한 번 약속 후 침묵	매주 진행 상황과 예측 업데이트
마지막에 "지연됩니다" 통보	조기에 리스크 공유 및 대안 논의

고객 커뮤니케이션 스크립트: "저희는 매주 진행 상황을 공유드리고, 완료 예상 시점을 업데이트해 드리겠습니다. 만약 리스크가 발견되면 즉시 알려드리고 함께 대안을 논의하겠습니다. 이렇게 하면 마지막 순간에 놀라실 일이 없습니다."

9.3 "우리 조직은 다르다"

이 말의 숨은 의미: 이것은 가장 흔하면서도 가장 다루기 어려운 저항입니다. 때로는 진짜 특수한 상황이 있고, 때로는 변화를 피하기 위한 핑계이기도 합니다.

실제 우려:

규제 산업의 컴플라이언스 요구사항
레거시 시스템과의 의존성
조직 문화와 정치
과거 실패한 변화 시도의 트라우마

효과적인 대응:

"모든 조직은 고유합니다. 그래서 우리는 프레임워크를 그대로 적용하는 것이 아니라, 우리 상황에 맞게 적응시킬 것입니다."

구체적인 접근:

1단계: 진짜 제약 조건 파악

질문: "구체적으로 어떤 부분이 다른가요?"
- 규제 요구사항? → 어떤 규제인지 구체적으로 파악
- 기술적 제약? → 실제 기술적 한계 확인
- 조직 구조? → 변경 가능한 부분과 불가능한 부분 구분

2단계: 제약 조건 내에서의 적용

규제 산업: 문서화 요구사항을 Sprint 산출물에 포함
레거시 시스템: 점진적 개선과 Strangler Fig 패턴 적용
분산 팀: 비동기 커뮤니케이션 도구 활용

실제 사례: "금융권에서도, 의료 분야에서도, 정부 기관에서도 Agile을 적용한 사례가 있습니다. 물론 각자의 방식으로 적응시켰죠. 우리도 우리만의 방식을 찾을 수 있습니다."

9.4 "경영진이 허락하지 않을 것이다"

이 말의 숨은 의미: 이 저항은 종종 변화에 대한 개인적 두려움을 조직 탓으로 돌리는 경우가 있습니다. 하지만 실제로 경영진의 지원 없이는 변화가 어려운 것도 사실입니다.

실제 우려:

경영진의 기존 방식에 대한 선호
단기 성과 압박
변화 실패 시 책임 문제
기존 보고 체계와의 충돌

효과적인 대응:

"작은 파일럿으로 시작하여 결과를 보여주세요. 데이터는 가장 강력한 설득 도구입니다."

경영진 설득 전략:

1. 비즈니스 언어로 번역

Agile 용어 → 비즈니스 용어
- Sprint → 2주 단위 성과 점검
- Velocity → 팀 생산성 지표
- Retrospective → 프로세스 개선 회의
- WIP 제한 → 집중을 통한 효율성 향상

2. 파일럿 제안서 구성

목표: 구체적이고 측정 가능한 목표
범위: 작고 관리 가능한 범위
기간: 2-3개월의 검증 기간
성공 지표: 경영진이 관심 있는 지표 (비용, 시간, 품질)
리스크: 실패해도 큰 영향 없음을 강조

3. 점진적 확대 로드맵

1분기: 1개 팀 파일럿
2분기: 결과 분석 및 2-3개 팀 확대
3분기: 부서 단위 적용
4분기: 조직 전체 확산 검토

9.5 "지금 너무 바빠서 새로운 것을 시도할 여유가 없어"

이 말의 숨은 의미: 역설적이게도, 가장 변화가 필요한 팀이 가장 바쁩니다. 이 저항은 현재의 비효율적인 방식이 만든 과부하에서 비롯됩니다.

실제 우려:

당장의 납기 압박
새로운 방식 학습에 대한 부담
전환 기간 동안의 생산성 저하 우려

효과적인 대응:

"바쁘기 때문에 더 효율적인 방식이 필요합니다. 작은 것부터 시작해서 부담을 최소화하겠습니다."

즉시 적용 가능한 작은 변화:

오늘부터: 진행 중인 작업을 포스트잇으로 시각화
이번 주부터: 15분 일일 스탠드업 미팅
다음 주부터: 동시 진행 작업 3개로 제한

시간 투자 대비 효과 설명:

투자: 매일 15분 스탠드업 = 주 1.25시간
효과: 불필요한 회의 감소, 블로커 조기 발견
예상 절감: 주 3-5시간

9.6 "전에 해봤는데 안 됐어"

이 말의 숨은 의미: 과거의 실패 경험은 강력한 저항 요인입니다. "Agile 했는데 실패했다"는 경험이 있는 조직은 특히 설득이 어렵습니다.

실제 우려:

과거 실패의 트라우마
"또 유행 따라가기"라는 냉소
변화 피로감

효과적인 대응:

"이전에 어떤 부분이 잘 안 됐는지 함께 분석해보면 좋겠습니다. 같은 실수를 반복하지 않기 위해서요."

과거 실패 분석 프레임워크:

실패 유형	흔한 원인	이번에 다르게 할 것
"Agile 했는데 혼란만 가중"	프레임워크만 도입, 원칙 이해 부족	원칙 먼저, 프랙티스는 점진적으로
"스크럼 마스터만 바빴음"	역할과 책임 불명확	팀 전체의 오너십 강조
"회의만 늘어남"	형식적 이벤트 운영	목적 중심의 시간 제한 미팅
"결국 원래대로 돌아감"	경영진 지원 부족, 지속성 없음	파일럿 성공 후 점진적 확대

9.7 "개발자들이 싫어할 거야" / "PM들이 반대할 거야"

이 말의 숨은 의미: 특정 역할 그룹을 대변하는 것처럼 보이지만, 실제로는 본인의 우려를 투영하는 경우가 많습니다.

역할별 실제 우려:

개발자:

잦은 미팅으로 코딩 시간 감소
추정에 대한 압박
마이크로매니지먼트 우려

PM/기획자:

통제력 상실
장기 계획 수립 어려움
역할 정체성 위기

효과적인 대응:

"각 역할의 우려를 직접 들어보고, 함께 해결책을 찾아보면 어떨까요?"

역할별 이점 강조:

역할	기존 방식의 고통	Agile에서의 이점
개발자	마지막에 몰아치는 야근	지속 가능한 페이스
PM	끊임없는 일정 재조정	현실적인 예측과 조기 리스크 발견
QA	마지막에 몰리는 테스트	지속적 테스트, 품질 내재화
경영진	프로젝트 끝에야 문제 발견	조기 가시성과 조정 기회

9.8 저항을 다루는 일반 원칙

1. 경청 먼저 저항의 표면적 이유가 아닌 근본적 우려를 파악하세요.

2. 공감 표현 "그 우려는 충분히 이해됩니다"로 시작하세요.

3. 강요하지 않기 설득되지 않은 변화는 지속되지 않습니다.

4. 작은 실험 제안 "한 번 해보고 안 되면 돌아가도 됩니다"

5. 성공 사례 공유 비슷한 상황에서 성공한 사례를 보여주세요.

6. 인내심 문화 변화는 시간이 걸립니다. 분기 단위가 아닌 연 단위로 생각하세요.

10장: 결론 - Planning은 여정이다

10.1 핵심 메시지 요약

Plan은 출발점이지 목적지가 아닙니다
- 계획서는 현재 시점의 최선의 추측일 뿐입니다
- 새로운 정보가 들어오면 계획은 바뀌어야 합니다
Planning은 지속적인 활동입니다
- 일회성 이벤트가 아닌 반복적인 프로세스
- 학습과 적응의 기회
프레임워크는 도구일 뿐입니다
- Scrum, Kanban, Scrumban 모두 도구입니다
- 상황에 맞게 선택하고 적응시키세요
문화가 프로세스보다 중요합니다
- 심리적 안전감, 투명성, 지속적 학습
- 이것들이 없으면 어떤 프레임워크도 효과가 없습니다

10.2 실천을 위한 첫 걸음

내일부터 시작할 수 있는 것들:

개인 수준:

자신의 작업을 시각화해보세요
WIP를 3개 이하로 제한해보세요
매일 5분 회고를 해보세요

팀 수준:

현재 작업을 보드에 시각화하세요
주간 회고를 시작하세요
Lead Time을 측정하기 시작하세요

조직 수준:

파일럿 팀을 선정하세요
성공 지표를 정의하세요
학습을 공유할 채널을 만드세요

10.3 마무리

20년간의 Legacy IT 경험에서 배운 가장 중요한 교훈은 이것입니다:

완벽한 계획을 세우려 하지 마세요. 대신, 계획하는 능력을 키우세요.

계획은 변할 것입니다. 그것은 실패가 아니라 학습입니다. 중요한 것은 변화에 얼마나 빠르고 효과적으로 대응할 수 있느냐입니다.

Scrum이든 Kanban이든, 어떤 프레임워크를 선택하든, 핵심은 같습니다: 지속적으로 계획하고, 빠르게 피드백 받고, 끊임없이 적응하세요.

이것이 바로 Agile의 본질이며, Legacy IT에서 현대적 소프트웨어 개발로 전환하는 핵심입니다.

참고 자료

Eisenhower, D. D. (1957). Remarks at the National Defense Executive Reserve Conference
Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business
Schwaber, K., & Sutherland, J. (2020). The Scrum Guide
Reinertsen, D. G. (2009). The Principles of Product Development Flow

이 글이 도움이 되셨다면, 여러분의 Planning 경험도 공유해주세요. 함께 배우고 성장합시다.