Show Cover Slide

우리는 Scrum하지 않는다. 우리는 Pre-Snap한다

1. Agile Manifesto (애자일 선언문)

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

우리는 소프트웨어를 개발하는 더 나은 방법을 실천하고, 그것을 돕는 과정에서 발견하고 있습니다.
우리는 이 일을 통해 다음의 가치를 더 중시하게 되었습니다:

• [개인과의 상호작용]를 프로세스나 도구보다 우선하여
• [작동하는 소프트웨어]를 포괄적인 문서보다 우선하여
• [고객과의 협업] 계약 협상보다 우선하여
• [변화에 대응]하는 것을 계획을 따르기보다 우선하여

즉, 오른쪽 항목에도 가치가 있지만, 우리는 왼쪽 항목을 더 가치 있게 여깁니다.

2. 우리는 스크럼하지 않습니다. 우리는 Pre-snap을 합니다.

2-1. 스크럼은 실행을 방해하는 형식이 되었습니다

Scrum은 본래 민첩함을 추구하는 방법이었지만,
현실에서의 스크럼은 회의와 계획 중심의 형식으로 굳어졌습니다.
‘정보 공유’를 명목으로 한 정례 회의들은 실행을 늦추고,
실행보다 회의가 우선되는 구조로 변질되었습니다.

계획이 많아질수록 민첩성은 사라집니다.

2-2. 스프린트는 Lock-in되지 못합니다

“Once a Sprint begins, no one is allowed to interfere with the work of the Scrum Team.”
“Requirements are frozen during a Sprint, allowing a team to focus on implementation and reach a stable product increment.”
(Ken Schwaber & Jeff Sutherland, SCRUM Development Process, OOPSLA 1995)

현실의 스프린트는 요구사항의 잦은 변경과 외부 요청으로 인해
집중된 실행을 보장하지 못하는 형식적 장치가 되어버렸습니다.
결국, 스크럼은 이상만 남고 실행은 무너진 구조가 됩니다.

2-3. Pre-snap은 실행 직전, 전략을 재확인하는 정렬입니다

우리는 미식축구에서 배웁니다.
Pre-snap은 공격이 시작되기 전,
쿼터백이 수비 진형을 읽고, 전략을 확인하고, 팀 전체를 정렬하는 순간입니다.

우리 팀의 Pre-snap도 마찬가지입니다:

• 매일 1회, 인당 1분
• 포맷은 간단합니다: 한 일 / 할 일 / 요청 (Did / Doing / Need)
• 질문은 Pre-snap 이후, 피드백은 비동기로 진행합니다

Pre-snap은 회의가 아닙니다.
그것은 팀 전체가 전략적 방향을 확인하고, 실행 흐름을 재정렬하는 순간입니다.
우리는 매일 전략을 짧게 되짚고, 불확실한 플레이를 줄입니다.

우리는 실행 전에 묻습니다:
“지금 이 방향이 맞는가?”
Pre-snap은 그 질문을 매일 반복하게 하는 구조입니다.

3. 우리는 스프린트를 하지 않습니다. Check-Point를 세웁니다.

우리는 시간을 고정해 계획을 밀어넣기 위한 스프린트는 하지 않습니다.
대신, 실행의 흐름 안에 자연스러운 정렬 지점(checkpoint)을 세웁니다.

• 스프린트는 종종 실행보다 계획과 형식을 위한 주기로 변질됩니다.
• 우리는 계획 중심이 아니라 실행 중심의 팀입니다.
• 하지만 실행에도 대화와 점검을 위한 리듬은 필요합니다.

우리는 체크포인트를 일정 관리가 아니라,
“대화를 설계하기 위한 수단”으로 사용합니다.

체크포인트란

• 이 문제는 충분히 작았는가
• 해결 흐름은 명확했는가
• 기록은 공유 가능한가
• 고객과 연결되는가
  를 점검하며, 팀이 다시 정렬하고 대화할 수 있게 만드는 시점입니다.

외부와 일할 때도, 우리는 체크포인트를 기준으로 설명합니다

우리의 방식은 모든 조직에 익숙하지 않을 수 있습니다.
많은 외부 팀은 “일정”, “기한”, “계획” 중심으로 일합니다.
우리는 그들과 충돌하지 않기 위해,
체크포인트를 일정처럼 설명하는 커뮤니케이션 브릿지를 사용합니다.

• 내부에선 체크포인트를 실행 흐름의 정렬 도구로 쓰고,
• 외부에겐 그것을 예측 가능한 공유 시점으로 설명합니다.

우리는 다르다고 주장하지 않습니다.
우리는 다리를 놓습니다.
체크포인트는 우리의 실행 리듬을 외부 언어로 연결해주는 실천적 커뮤니케이션 구조입니다.

우리는 달리지 않습니다.
우리는 정렬하고, 점검하고, 다시 움직입니다.
일정은 대화를 위한 구조이고,
체크포인트는 그 리듬을 위한 구조입니다.

4. 우리가 따르는 Agile 원칙

1. 고객의 문제 해결이 최우선입니다

• 고객이 누구인지 정의되지 않으면, 우리는 일하지 않습니다.
• 고객은 바뀔 수는 있어도, 없어서는 안 됩니다.
• 우리가 푸는 문제는 반드시 고객의 맥락 안에 있어야 합니다.

2. 짧은 단위의 문제 해결이 곧 혁신입니다

• 우리는 문제를 작게 나누고, 빠르게 해결하며,
  그것을 기록 가능한 산출물(output)로 남깁니다.
• 작은 실행이 쌓이면 혁신이 됩니다.

여기서 ‘짧은 단위’란 단지 시간이 아니라,
작동하는 소프트웨어(working software)를 도구로 사용해 문제를 검증하고 기록할 수 있는 실행 단위를 뜻합니다.

우리는 결과가 아닌 흐름을 보여주는 것을 더 신뢰하며,
실행과 기록이 가능한 단위로 나누는 훈련 자체가 애자일입니다.

3. 산출물은 기록입니다

• 산출물이란 곧 기록된 흔적(trace)입니다.
• 코드(code), 문서(document), 미디어(media)는
  우리가 어떤 문제를 어떻게 해결했는지를 설명합니다.

4. 도구는 최소한으로, 생각은 집중적으로

• 도구(tool)는 필요할 때만 씁니다.
• 너무 많은 도구는 사고(thinking)를 분산시킵니다.
• 우리는 중요한 도구 몇 개만으로 정렬과 실행을 유지합니다.

5. 용어 정의

6. 우리의 선언

우리는 더 이상 스크럼하지 않습니다.
우리는 Pre-snap 합니다.
우리는 정렬하고(align), 전진합니다.
우리는 문제를 풀며, 작은 실행을 쌓아 혁신을 만듭니다.
우리는 Pre-snap하는, 다시 정렬된 Agile을 실행합니다.

Q&A: 우리 팀이 자주 던지는 질문들

Q1. 아직 제대로 된 결과물이 없는데, 뭘 공유해야 하죠?

Pre-snap은 완성 보고가 아니라, 실행의 흐름을 공유하는 시간입니다.
아직 결과물이 없더라도,

• 어떤 문제를 풀고 있었는지
• 어떤 시도를 했는지
• 어디서 막혔는지

이런 내용만으로도 충분합니다.

우리는 실패도 산출물이라고 생각합니다.
정리된 흔적이 있으면, 그것은 의미 있는 공유입니다.

Q2. 스크럼하다 보면 1분 넘길 때도 있는데요?

넘길 수도 있죠. 중요한 건 반복적으로 길어지지 않는 것이에요.
자주 1분을 넘긴다면,

• 문제를 너무 크게 가져왔거나
• 요청이 불명확하거나
• 피드백을 스크럼 중에 처리하려는 시도일 수 있습니다.

Pre-snap은 정렬의 순간입니다.
피드백은 따로, 스크럼은 짧게.

Q3. 수정이 자주 생기는데, 배포는 언제 하죠?

우리는 항상 배포할 수 있는 상태를 유지하는 것을 중요하게 생각합니다.
배포란 “끝났다”는 의미가 아니라,
문제가 해결되었고, 정리되었으며 공유할 수 있게 된 상태를 뜻합니다.

• 하루 만에 끝났다면? 잘게 나눈 문제를 잘 실행한 겁니다.
• 배포는 계획된 이벤트가 아니라, 흐름의 일부입니다.

문제 해결 → 정리 → 공유 → 배포
이게 우리 팀의 기본 사이클입니다.

Q4. 피드백은 언제 어떻게 받는 게 좋아요?

Pre-snap에서는 피드백을 하지 않습니다.
요청만 짧게 정리하고,

• 슬랙
• PR 코멘트
• 필요 시 짧은 sync 대화

이런 방식으로 따로 피드백을 진행합니다.

정렬은 지금,
피드백은 나중.
이게 우리 리듬입니다.

Q5. 문서로 안 남기고 그냥 말로만 하면 안 되나요?

말도 좋지만, 기록이 남아야 다시 쓸 수 있습니다.
꼭 정제된 문서일 필요는 없어요.
슬랙 메시지, PR 코멘트, 간단한 노션 메모도 괜찮습니다.

“말했습니다.”보다 “남겼습니다.”를 중시합니다.

Q6. 외부랑 같이 일할 땐 이 방식으로 괜찮을까요?

우리는 외부에 보여도 문제 없는 수준의 정렬을 기본으로 합니다.
Pre-snap 공유는 언제든

“이걸 왜 했는가?”
“이게 왜 필요한가?”
에 대해 설명이 가능해야 합니다.

공유는 시간 낭비가 아니라,
우리가 왜 이 일을 했는지를 구조화해 전달하는 행위입니다.

Q7. 실수나 실패도 공유해도 되나요?

그럼요. 우리는 두려움 없는 실행 조직을 지향합니다.
실패는 감추는 게 아니라,
기록하고 다음 사람에게 넘겨주는 자산입니다.

애자일은 계획을 지키는 게 아니라,
실험을 반복하며 배우는 문화입니다.

Q8. 글을 쓰려니까 쓸 게 없어요. 뭘 적어야 하죠?

그럴 땐 이렇게 물어보세요:

“내가 한 일이 어떤 고객 문제를 해결했지?”

Pre-snap에는 그날의 감상이나 노력보다,
누구의 문제를 어떤 방식으로 풀고 있었는가를 쓰면 됩니다.

• 아직 해결이 안 됐어도 좋아요.
• 왜 이걸 하고 있는지, 어디서 막혔는지만 정리해도 충분합니다.

핵심은 “일을 했느냐”보다 “누구를 위해 왜 했느냐”예요.
고객 중심으로 생각하면, 쓸 이야기는 반드시 생깁니다.

Q9. 진도가 안 나가요. 계속 같은 자리인데, 이거 기록하면 안 좋게 보이지 않을까요?

그런 생각, 정말 자연스럽고 많이들 합니다.
하지만 애자일의 진짜 핵심은 결과보다 실행의 흐름을 드러내는 것입니다.

• 진도가 더디다는 건 이슈입니다.
• 그런데 그건 곧 좋은 피드백입니다.
  → “이 문제는 크기가 너무 컸다”
  → “우리가 문제 정의를 잘못했을 수도 있다”
  → “지금 방식이 맞지 않다”
  라는 신호를 준 거예요.

중요한 건 “진도를 감추지 않는 것”입니다.
숨기면 문제고, 드러내면 피드백입니다.

그리고 이렇게 말할 수 있어야 합니다:

“이건 내가 더딘 게 아니라, 팀이 이 문제를 더 작게 나눠야 했다는 걸 보여주는 사례예요.”

그걸 드러내고 있는 팀은, 애자일을 잘하고 있는 팀입니다.

Q10. 다른 사람보다 뒤처지는 기분이에요. 괜찮은 건가요?

당연히 그런 기분 들 수 있어요.
하지만 애자일은 속도를 비교하는 방식이 아니라, 방향을 맞추는 구조입니다.

• 지금 멈춰 서서 고민하고 있다면,
  그건 실행이 느린 게 아니라 정렬을 하고 있다는 증거예요.
• 오히려 그 멈춤이 팀 전체를 지키는 중요한 피드백이 될 수 있어요.

우리는 빨리 달리는 사람보다,
멈춰야 할 때 멈출 수 있는 사람을 더 신뢰합니다.

Q11. 이 일이 왜 중요한지 모르겠어요.

그럴 땐 꼭 질문해야 해요.
“이게 누구의 문제를 해결하는가?”
“이걸 하지 않으면, 어떤 고객이 곤란해질까?”

• 일 자체가 아니라 문제에 집중하면,
  왜 중요한지가 보이기 시작해요.
• 만약 아무리 봐도 고객 연결이 없다면,
  그건 정말 다시 정의해봐야 할 작업일 수 있어요.

우리가 애자일하게 일한다는 건,
항상 ‘왜 이걸 하는가’를 스스로 점검하는 것이에요.

Q12. 내가 하는 일이 너무 작아서 공유하기 민망해요.

작아 보인다면, 잘 나눈 거예요.
우리는 일부러 일을 작게 나눠서 공유할 수 있게 만들고 있어요.

• 작게 나눈 문제는 빠르게 해결되고,
  빠르게 공유되고,
  빠르게 피드백을 받을 수 있어요.

민망한 게 아니라, 정확하게 팀 흐름에 올라와 있다는 증거입니다.
작고 빠른 실행이 쌓여야 진짜 변화가 생깁니다.

Q13. 요청이 많아지면 방해 아닐까요?

절대 아닙니다. 요청이 많다는 건
문제가 더 잘 드러나고 있다는 뜻이에요.

• 비동기로 요청하면, 누구의 리듬도 방해하지 않아요.
• 오히려 반복적으로 요청이 몰리면,
  그건 우리가 자동화할 수 있거나 도구를 개선해야 할 부분이 드러난 거예요.

질문은 방해가 아니라, 구조 개선의 시그널입니다.
요청은 조직을 더 좋게 만드는 출발점입니다.

Q14. 애자일인데 왜 이렇게 정해진 루틴이 많죠?

애자일은 무계획이 아니라, 계획을 조정할 수 있는 구조예요.
Pre-snap은 정렬을 위한 리듬이고,
그 리듬이 있어야 실험이 자유로워질 수 있어요.

• 고정된 시간과 포맷이 있어서
  우리는 서로의 흐름을 예상하고,
  방해 없이 협력할 수 있어요.

진짜 자유는 구조 속에서 만들어집니다.
Pre-snap은 우리에게 그 구조를 만들어주는 리듬입니다.

Q15. 비동기 피드백이 너무 많아서 일에 집중할 수 없어요.

맞아요. 비동기라고 해서 집중이 안 깨지는 건 아니에요.
메시지가 계속 오면 오히려 더 산만해질 수도 있어요.

그래서 우리는 이렇게 정리합니다:

• 피드백은 즉시 처리하지 않아도 괜찮습니다.
  중요한 건 언제든 꺼내서 응답할 수 있도록 흐름을 보존하는 것이에요.
  → Slack, PR, Notion 등 정해진 채널을 씁니다.

• 집중 시간은 서로가 지켜주는 약속입니다.
  피드백은 바로 처리하는 게 아니라, 처리할 수 있을 때 하는 것이에요.

• 요청이 쌓이고 있다면, 그 사실을 공유합니다.
  “지금 요청이 3건 밀려 있고, 오늘 중엔 하나만 처리할 수 있습니다”
  → 이렇게 공유하면, 팀은 기다릴 수 있고 구조적으로 조정할 수 있어요.

요청은 감추는 게 아니라, 투명하게 공유하는 신호입니다.
우리는 서로의 집중과 응답 모두를 존중하는 팀입니다.

부록: 왜 우리는 소프트웨어로 문제를 해결하는가

우리는 단순히 소프트웨어(SW)를 좋아해서 사용하는 것이 아닙니다.
소프트웨어는 우리가 사용할 수 있는 문제 해결 도구 중
가장 짧은 피드백 루프(feedback loop)를 제공하기 때문입니다.

1. 짧은 피드백 루프는 곧 실행과 학습의 속도입니다.

• 워드프레스는 웹 페이지를 출력하기 전에 바로 미리 보기로 확인할 수 있습니다.
• 포토샵은 필터나 레이어를 적용했을 때 결과를 실시간으로 프리뷰할 수 있습니다.
• 개발자는 코드를 저장하고 바로 실행시켜 결과를 확인할 수 있습니다.

이 모든 구조는 우리가
실행 → 확인 → 수정 → 반복이라는 학습 사이클을 빠르게 돌릴 수 있게 도와줍니다.

2. 우리가 사용하는 소프트웨어는 단지 구현 도구가 아닙니다.

소프트웨어는
생각을 표현하고 검증하며 개선할 수 있는 실행 기반의 설계 도구입니다.

아이디어를 빠르게 실현해보고,
사용자의 피드백을 반영하고,
실패한 시도를 기록할 수 있습니다.

이것이
우리가 짧은 단위의 실행을 문제 해결의 기본 구조로 삼는 이유이며, 바로 그 구조를 가능하게 하는 도구가 소프트웨어입니다.

3. 그래서 우리는 ‘실행 가능한 단위’를 만들고 공유합니다.

• 작동하는 버튼
• 실제로 처리된 입력값
• 테스트 가능한 흐름
• 눈에 보이는 미디어 결과물

이런 것들이 곧
우리 팀의 산출물(output)이며, 빠르게 나누고, 빠르게 확인하며, 기록될 수 있는 단위입니다.

소프트웨어는 가장 빠르게 실험하고, 가장 작게 실패하고, 가장 명확하게 공유할 수 있는 구조입니다.
그래서 우리는 소프트웨어를 도구로 사용합니다.