데이터 조직이 일하는 방법: 칸반과 스크럼의 이해

TLDR:

"애자일 선언문"과 "애자일 선언 이면의 원칙"을 통해 애자일이 추구하는 가치와 원칙을 공유합니다. 애자일의 대표적인 프레임워크인 스크럼과 칸반이 어떤 가치와 원칙을 통해 애자일을 추구하며 일하는지 알아봅니다. 마지막으로 스크럼과 칸반의 이론적 경험적 차이를 공유합니다.

애자일(Agile)

What is Agile?
Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a "big bang" launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly.
https://www.atlassian.com/agile

애자일의 선언문.

https://agilemanifesto.org/

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

애자일의 선언 이면의 원칙

https://agilemanifesto.org/principles.html

• 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
• 개발의 후반부일지라도 요구 사항 변경을 환영해라. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
• 더 짧은 기간을 선호하여 몇 주에서 몇 달 사이에 작동하는 소프트웨어를 자주 제공합니다.
• 비즈니스 쪽 사람과 개발자는 프로젝트 전체에서 날마다 함께 작업해야 합니다.
• 의욕이 있는 개인을 중심으로 프로젝트를 구축합니다. 그들에게 필요한 환경과 지원을 제공하고 그들이 일을 완수할 것이라고 믿으십시오.
• 개발 팀에게 또는 개발 팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
• 작동하는 소프트웨어는 진행 상황의 주요 척도입니다.
• 애자일 프로세스는 지속 가능한 개발을 촉진합니다. 스폰서, 개발자 및 사용자는 일정한 속도를 계속 유지할 수 있어야 합니다.
• 기술 우수성과 좋은 설계에 대한 지속적인 관심은 민첩성을 향상 시킵니다.
• 단순성(안 하는 일의 양을 최대화하는 기술)이 필수적 입니다.
• 최고의 아키텍처, 요구 사항 및 디자인은 자기 조직적인 팀에서 나옵니다.
• 정기적으로 팀은 효율성을 높이는 방법에 대해 숙고한 다음 그에 따라 행동을 조정하고 조정합니다.

Waterfall과 대비되는 Agile은 개발조직에 있다면 이제는 익숙한 방법론이라고 생각합니다. 시간이 지나면서 해석이 달라지기도 하고 새로운 규칙들이 생기기도 하지만, 애자일에 대한 배경을 통해 가치와 원칙을 공유합니다.

Agile is a mindset. Scrum and Kanban are Agile Frameworks.

애자일과 스크럼, 칸반의 관계를 한 마디로 정리해주신 우주최강 SM 카페인님께 감사의 인사를 전합니다. ( 카페인님의 스크럼 교육자료에서 발췌 )

스크럼(Scrum)

스크럼은 역할을 규정하며 스프린트(Sprint)라고 불리는 고정된 시간 이터레이션을 통해 경험적으로 프로젝트를 관리해 나가는 방법입니다.

스크럼의 어원.

Scrum은 럭비에서 반칙이 있을 때, 양편 선수가 밀집하여 서로 팔을 꼭 끼고 뭉치는 일을 의미합니다.
즉 소프트웨어 개발에서 각 단계별로 작업을 마친 후 다음으로 전달하는 계주 형태 보다는 모든 팀원들이 하나로 뭉쳐 함께 밀고 나가는 방법론을 의미합니다.

스크럼의 3가지 기둥 (Three Pillars of Scrum)

• Transparency (투명성)
  • 업무를 실행하거나 일의 결과물을 받는 사람들에게 일이 무엇인지는 반드시 가시적이어야 한다.
• Inspection (점검)
  • 잠재적으로 바람직하지 않은 변화와 문제점을 발견하기 위해서는 스크럼 산출물과 달성하기로 한 목표에 대한 진척을 반드시 자주 부지런하게 점검해야 한다.
• Adaptation (조정)
  • 프로세스의 어떤 측면이 수용 가능한 범위를 벗어나거나 그 결과물이 받아들일 수 있는 수준이 아닌 경우, 진행하는 프로세스와 생산하고 있는 것들을 반드시 조정해야 한다.

스크럼은 예측 최적화와 리스크 통제를 위해 반복적이고 점진적인 방식을 사용합니다. 스크럼 이벤트들을 통해 위 스크럼의 기둥을 현실로 실천하려고 노력해야 합니다.

스크럼 팀 구성

• Product Owner
  • 제품 백로그를 소유한다.
  • 제품 백로그 아이템을 생성하고 분명하게 소통한다.
  • 제품 백로그 아이템을 우선순위에 따라 정렬한다.
  • 제품 백로그를 투명하고 가시적이며 이해가 잘 되도록 만든다.
• Scrum Master
  • 팀원들이 자율관리를 하고 교차기능적이 되도록 코칭한다.
  • 스크럼 팀이 완료의 정의를 충족하여 높은 가치를 갖는 증가분을 만드는 데에 집중하도록 돕는다.
  • 스크럼 팀의 진척에 방해가 되는 장애물을 제거한다.
  • 모든 스크럼 이벤트가 발생하고 긍정적이고 생산적이며 시간 제한 내에 유지되도록 한다.
• Developers
  • 자율 관리를 한다.
  • 스프린트 동안의 계획을 세운다. (스프린트 백로그)
  • 완료의 정의를 준수하여 품질을 높여간다.
  • 스프린트 목표를 위해 그들의 계획을 매일마다 조정한다.
  • 전문가로서 서로 책임진다.

스크럼의 기본 단위는 작은 규모의 팀으로, 제품 목표(Product Goal)에 집중하는 응집력을 가진 전문가들의 모임입니다. 스크럼 팀은 1명의 SM, 1명의 PO, 그리고 개발자들로 구성됩니다. (여기서 말하는 개발자는 기획자, 개발자, 테스터 등 개발에 참여하는 모든 구성원을 의미합니다.)

스크럼의 5가지 가치 (Scrum Values)

• Commitment (약속)
• Courage (용기)
• Openness (열린 마음)
• Focus (집중)
• Respect (존중)

스크럼 팀은 목표를 달성하는 것과 서로 협력할것을 약속한다. 팀원들은 이러한 약속을 지키기 위해 스프린트 동안 최상으로 가능한 진전을 만드는 일에 최우선적으로 집중한다. 스크럼 팀과 이해당사자들은 일과 도전에 열린 마음을 가져야 한다. 스크럼 팀원들은 팀원 개개인이 능력을 갖춘 독립적인 존재임을 서로 존중해야 한다. 스크럼 팀과 함께 일하는 외부인들도 스크럼 팀을 존중해야 한다. 스크럼 팀은 힘든 문제를 해결할 때 올바른 일을 하는 용기를 가져야 한다.

스크럼 이벤트 (Scrum Event)

• Sprint
  • 아이디어를 가치로 만들어 내는 이벤트로 스크럼의 심장 박동과 같다.
  • 한달 또는 그보다 작은 기간으로 고정된 길이의 이벤트이다.
  • 새로운 스프린트는 직전의 스프린트가 끝나는 즉시 시작한다.
• Sprint Planning
  • 이 스프린트가 왜 가치가 있는가? (스프린트 목표 정의)
  • 이 스프린트의 완료는 무엇인가? (완료의 정의에 대한 이해)
  • 선정한 일을 어떻게 완료할 것인가? (백로그 아이템을 하루안에 완료할 수 있는 크기로 세분화)
• Daily Scrums
  • 개발자들만 참여하는 15분 길이의 이벤트이다.
  • 스프린트 목표 대비 진척을 점검하고, 필요하면 다음 업무 진행 계획을 변경하여 스프린트 백로그를 조정한다.
• Sprint Review
  • 스프린트의 결과물을 점검하고 향후에 적응할 것들을 결정하는 것이다.
  • 이번 스프린트에 성취한 것과 그동안 비즈니스 환경에서 변한 것이 무엇인지를 검토한다.
  • 새로운 기회를 창출하기 위해 프로덕트 백로그를 수정할 수도 있다.
• Sprint Retrospective
  • 품질과 효율을 높이기 위한 방법들을 계획하는 이벤트이다.
  • 팀이 잘못된 방향으로 가게 된 가정들을 확인하고, 그것들의 근본 원인을 찾아낸다.
  • 무엇이 잘 진행되었는지에 대해서도 논의한다.
  • 효율을 향상시키기 위해 가장 도움이 되는 변화를 찾아야 한다.

칸반(Kanban)

칸반의 어원

kanban은 본래 간판이라는 일본어이며, 신호 카드(Signal card)를 의미합니다.

“도요타 생산 시스템을 떠받치는 두 개의 기둥은 적시 생산(Just-In-Time, JIT)과 사람이라는 요소가 포함된 자동화(Automation)입니다. 그리고 도요타 생산 시스템 운영에 사용하는 도구가 칸반입니다.”

칸반은 도요타의 카이젠(지속적 개선) 프로세스의 핵심으로 제 시간에 완성하기 위한 스케쥴링 시스템입니다. 철저하게 낭비적 요소를 배제하는 시스템이며, 핵심 목적은 생산성을 희생하지 않으면서 불필요한 업무를 최소화하는 것이었습니다.

대문자료 표시된 Kanban은 2007년에 처음 정의된 “Kanban Method”의 출현과 관련이 있습니다.

칸반의 2가지 원칙과 실행 방법

1. Change Management Principles

• Start with What You Do Now (지금 하는 일부터 시작.)
• Agree to Pursue Incremental, Evolutionary Change (점진적이고 진화적인 변화 추구에 동의.)
• Encourage Acts of Leadership at All Levels (모든 수준에서 리더십 행위를 장려.)

2. Service Delivery Principles

• Focus on Customer’s Needs And Expectations (고객의 요구와 기대에 집중.)
• Manage the Work, not the workers (작업자가 아닌 작업 관리)
• Regularly Review the Network of Services (서비스 네트워크를 정기적으로 검토.)

칸반의 특성

• Visualize the workflow (업무 흐름 시각화)
  
  • 칸반 시스템으로 프로세스를 시각화하려면 카드와 열이 있는 보드가 필요합니다.
  • 보드의 각 열은 워크플로우의 단계를 나타냅니다.
  • To do, In progress, Done 으로 구성 가능하고 경우에 따라 추가 가능합니다.
  • 칸반 카드는 작업 항목을 나타냅니다.
• Limit work in progress (진행 중 업무 제한)
  • workflow에 pull system을 구현하는 것을 의미합니다.
  • 흐름의 문제 영역을 신속하게 밝혀주므로 문제를 식별하고 해결할 수 있습니다.
  • 멀티태스킹은 낭비와 비효율을 발생시키는 확실한 경로입니다.
• Manage flow (흐름 관리)
  • 흐름을 관리하는 것은 작업을 관리하는 것이지 사람을 관리하는 것은 아닙니다.
  • 흐름이란 예측 가능하고 지속 가능한 속도로 생산 프로세스를 통해 작업항목의 이동을 의미합니다.
  • 작업 프로세스를 관리하고 시스템을 통해 작업을 더 빠르게 수행하는 방법을 이해하는데 집중해야 합니다.
• Make process policies explicit (명시적 프로세스 정책 수립)
  • 이해하지 못하는 것은 개선할 수 없습니다.
  • 모든 사람이 공동의 목표에 익숙해지면 긍정적인 영향에 대해 작업하고 결정을 내릴 수 있습니다.
• Implement feedback loops (피드백 루프 구현)
  • 보다 민첩해지고자 하는 팀과 회사의 경우 피드백 루프를 구현하는 것은 필수 단계입니다.
  • 팀 수준의 피드백 루프
    • Daily meeting, Kanban review, Team retrospective
• Improve collaboratively (공동으로 개선)
  • 지속적인 개선과 지속 가능한 변화를 달성하는 방법은 과학적으로 입증된 방법, 피드백 및 메트릭을 기반으로 공동 구현하는 것입니다.

성공 레시피

https://djaa.com/kanban-recipe-success/
(David Anderson의 The Recipe for Success는 기존 팀을 채택하는 새로운 관리자를 위한 지침을 제시합니다.)

1. Focus on Quality (품질에 집중한다.)

• 낮은 품질은 소프트웨어 개발에서 가장 큰 낭비를 나타낸다.
• 품질 개선 방법
• code inspection은 품질을 개선한다.
• 협력적 분석 및 설계는 품질을 개선한다.
• 디자인 패턴의 사용은 품질을 개선한다.
• 최신 개발 도구의 사용은 품질을 개선한다.
• 진행 중인 설계의 양을 줄이면 소프트웨어 품질이 향상된다.

2. Reduce Work-in-Progress (진행 중 업무를 줄인다.)

• 진행 중 업무를 줄이면 품질을 개선할 수 있다.

3. Deliver Often (자주 출시한다.)

• 릴리스를 자주하면 마케팅 부서 같은 상류 파트너의 신뢰를 개선할 수 있다.

4. Balance Demand Against Throughput (요구량을 처리량에 맞춘다.)

• pull system을 사용하면 요구량을 처리량에 맞출 수 있다.
• pull system은 병목 지점을 드러내며 비병목 지점에 잉여 시간을 만든다.
  • 잉여 시간이 있으면 개선 기회를 만들어낼 수 있다.
  • 작은 개선이 또 다른 개선을 이끌면서 팀은 지속적으로 개선하는 모습을 보이게 만든다.

5. Prioritize (우선순위를 부여한다.)

• 개발 조직이 우선순위 부여를 제어해서는 안 된다.
• 우선순위 부여를 개선하려면 제품 책임자나 마케팅 부서 등에서 스스로 그들의 행동을 바꿀 필요가 있다.

6. Attack Source of Variability to Improve Predictability (예측성을 개선하기 위해 변동성의 원인을 공략한다.)

• 변동성이 높아지면 진행 중 업무가 늘어나고 리드 타임이 더 길어진다.
• 변동성을 줄이기 위한 변화를 만들려면 잉여 시간이 필요하다.
• 변동성이 줄어들면 잉여 시간의 필요성이 줄어든다.

칸반을 이용하면 성공 레시피의 6단계 모두가 가능해집니다. 칸반을 실천하면 자연스럽게 성공 레시피를 따르게 되며, 결과적으로 성공 레시피는 칸반이 가치 있는 기법인 이유를 보여줍니다.

스크럼 vs 칸반

스크럼과 칸반의 주요 이론적 차이

www.kanbanize.com 참조.

데이터 팀이 스크럼에서 칸반으로 넘어오면서 느낀 경험적 변화

스크럼으로 업무를 할 때의 어려움.

• Planning
  • 외부의 ASAP 요청 업무로 인해 확정된 계획을 수립하기 어려움.
  • 업무를 스프린트 단위로 쪼개기 어려움
• Task
  • sprint planning에서 정한대로 업무를 수행하기 어려움
  • 유연성이 떨어져 대응이 어려움
  • plan 업무보다 우선순위가 높은 업무가 지속적으로 발생.
• retrospect
  • 회고를 통해 개선이 되기 어려운 이슈가 많아 효과를 느끼지 못함.

칸반으로 전환

• plan 보다는 flexibility가 우선시 됨 (직접적으로 프로덕트를 개발하는 팀이 아니기 때문)
• 지키지 못할 계획 수립에 필요한 무의미한 회의 시간을 절약할 수 있음.

스크럼에서 가능했던 blocker 공유 및 팀간 sync 를 맞추기 위한 미팅의 부재는 변형된 형태로 진행.

• daily meeting
• kanban review
• weekly sync-up meeting
  • 4째주 : monthly retrospective

(칸반에서 겪고 있는 어려움..)

팀원 1명당 wip 제한을 1-2개로 설정하고 있지만, ASAP 업무가 밀려들 때는 현실적으로 어려움을 느낍니다.

단기적

• 과도한 업무 로드 혹은 병목 현상의 징후를 모니터링 하는데 의의를 둔다.

중장기적

• ASAP 업무를 개선할 수 있는 데이터 인프라를 구축한다.

칸반과 스크럼, 어느팀에 더 적합한가?

Kanban과 Scrum은 모두 팀이 효율성과 생산성을 높일 수 있도록 만들어졌습니다. 어떤 것을 채택하느냐는 각 팀에 개별적으로 달려 있지만 조직에서 판단하는데 도움이 될 기준을 정리합니다.

• Scrum
  • 엔지니어링, 제품, 소프트웨어 개발 또는 애자일 기반 팀에 속해 있습니다.
  • 팀이 약간 더 엄격한 구조에서 이점을 얻을 수 있다고 생각합니다.
  • 처리해야 할 작업의 백로그가 많습니다.
  • 귀하의 팀은 빠른 마감일과 결과물에 동기를 부여받습니다.
  • 팀의 누군가가 스크럼 마스터가 되기 위해 최선을 다하고 있습니다.
• Kanban
  • 팀에는 시각적인 프로젝트 관리 시스템이 필요합니다.
  • 프로젝트의 현재 위치를 한 눈에 파악할 수 있는 방법이 필요합니다.
  • 엔지니어링, 제품 또는 소프트웨어 개발 팀에 속해 있지 않습니다.
  • 진행 중인 프로세스와 프로젝트를 실행합니다.
  • 대부분의 작품은 단기간에 제작되지 않습니다.