[Agile] Scrum vs Kanban. 우리 팀에 더 적합한 방식은?

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

Scrum

Scrum이란?

Iteraton기반의 Project 관리 Framework

Scrum의 가치

1. courage: cross team이 되어 그 팀 안에서 어떤 것을 완수하는 것을 지향하기 때문에 assign된 채로가 아니라 open에서 자율적으로 자신을 assign 해서 진행하는 것을 지향함. 이렇게 하는 용기. 등.. 많은 용기가 필요함 방식임.
2. focus: sprint 기간에 어떤 것에 집중함으로서 생산성 향상에 직결되고
3. commitment: 팀이 ‘이것 만큼은 완수하겠다’ 라는 약속
4. respect: 과정과 결과에 대해서 회고하고 이를 통해서 앞으로 우리가 나아가야할 방향을 조정하는 것을 추구함
5. openness: 우리가 하고 있는 모든 일들에 대해서 현재 지금 어떤 상태인지, 어떤 risk를 가지고 있는지를 투명하게 오픈하는 것.

Scrum 적용시 고려사항

Doing scrum 시 고려해야 할 것은

1. scrum 환경을 만드는데 적절한가. 적절하지 않으면 도입해도 괜찮은 시점인가? 그 시점이라면 환경 구축에 힘 쏟기!
2. Definition of Done 정의하기
3. sprint 주기 찾기
4. 적정한 story point 찾기
5. velocity(이번 sprint에 완료된 업무의 총합) 을 추적하고 측정하는 것

Being scrum 시에 고려해야 할 것은

1. 팀을 보호한다는 것의 의미, 어떻게 고객과 팀과 stackholder들과 원만한 관계를 유지하면서 우리 팀을 보호할 것인가? (우리 팀에서는 CAO님이 많이 걱정하고 신경써주시고 있는 이 부분.)
2. 고객과의 협력이 의미하는게 뭔지 생각해보기
   1. 누가 고객인가?
   2. 의료 B2B인 우리 회사, 우린 고객을 만나기가 어려운데?
3. 주변과의 신뢰를 어떻게 만들 것인가
4. 우리의 우선순위는 존중받고 있는가
5. 팀멤버의 피로도 관리

Scrum의 전체적인 프로세스

• sprint(단거리 질주)를 도입해서 sprint로 iteration을 돌리는데
  • sprint는 30일 이내
  • sprint 기간에 어떤 것에 집중함으로서 생산성 향상에 직결되고
  • sprint 보호도 중요하지만 긴급한 대응을 외면하지는 않음

Scrum시 필요한 역할

1. Product Owner: 팀이 만들어내야 하는 Product의 요구사항을 관리하는 사람
   1. Product Vision제시
   2. Product Backlogs 들 중에서 우선순위 설정
   3. 릴리즈 일자 결정
   4. 팀이 가치있는 일을 할 수 있도록 함
2. Scrum Master
   1. 팀을 위해 일하는 Servant 리더
   2. ‘이건 이렇게 하는게 좋겠다. 저건 저렇게 하는게 좋겠다’ 식의 가이드를 줘서 팀의 방해 요소를 팀원들이 해결할 수 있도록 도움을 주는 사람
3. Scrum Team
   1. self organizing
   2. cross functional

Scrum Event

 

1. (단거리 질주 시작 전) Sprint Planning meeting
   1. Product Owner가 최신의 우선순위가 반영된 product backlog들을 scrum team에게 이해시키고, 전달한다.
   2. Product backlog들은 소비자의 언어로 명시되어있는데, 이걸 구현의 언어로 전환한다.
      1. 그래서 scrum team을 이루는 cross functional 멤버(기획자, 개발자, 디자이너.. 등)은 모여서 아 백로그를 처리하려면 이런 작업이 필요하겠네, 저런 작업이 필요하겠네.. 등을 정리하고, task로 바꾸고, 일정 예측하는 시간.
   → 이 1, 2 과정을 통해 이번 sprint기간 동안 할 일인 task들을 확정을 하고, 팅이 확정한 task 목록의 업무는 반드시 완료하겠다는 commitment(다짐)을 한다. → 이걸로 ready to run & tension up!!!
2. (단거리 질주 중간 중간 매일) Daily scrum meeting
   1. Quick Review
      1. 이전 Daily scrum meeting 이후로 진행된 일
      2. 이후 Daily scrum meeting 이후로 진행 할 일
      3. 내가 이 일들을 진행하는데 발생한 혹은 예상 가능한 blocker 공유
   2. 팀의 업무 진행 현황을 매일 sync-up
3. Sprint review meeting
   1. 내가 요구한 요구 사항이 잘 구현이 되었는지를 확인하는 과정임. 이게 ‘너 개발 잘했네 못했네’ 등의 개인의 능력치를 공개적으로 평가하는 자리가 아니라. PO가 요구한 요구사항과 실제 구현된 것이 일치하는지 그런 것들을 확인하고, 유연하고 빠른 요구사항 반영을 위한 장치이다.
   2. 요구사항을 더 정확하고 세밀하게 만드는 장치
   3. 중요한 것에 더 집중하게 만들 수도 있다.
4. sprint retrospective meeting
   1. sprint과정 평가 및 개선점 도출
   2. 지속적인 발전과 개선을 촉진할 수 있는 장치
   3. sprint 기간 종료와 tension release

---

Kanban

Kanban이란?

Kan(visiual) Ban (card or board).

(이전 글에서 계속 Scrum에서 해야 할 것으로 Sprint 를 말했던 것처럼 Kanban에서도 Doing kanban을 위해 해야할게 있다면)

Kanban의 가치

1. Just in Time (JIT): 요구사항을 바로바로 반영하고, 그때마다 우선순위도 바로바로 바뀌고..Visualize what you do today.
2. Limit the work in process (WIP): 컨테이너 벨트를 생각해보면 어느 흐름에서 병목이 생기면 다른 일들은 다 막혀있을 수 밖에 없기 때문에 ‘할 수 있는 만큼만 가져가’야 한다는 것.
3. Manage flow: 계속 workflow는 모니터링해서 LEAD time을 줄이기 위해 개선하고, 튜닝해야 한다.

Kanban의 프로세스

그리고 이 때 task는 push방식이 아니라 pull 방식이다.

여기서 Scrum과 Kanban의 차이!

• Scrum에서는 Product Backlog에서 팀이 이번 sprint에 할 수 있는 만큼 할당해서 진행하는데
• Kanban은 항상 최신 우선순위에 따라서 중요한 것을 Selected column에 넣고 진행함. 그래서 바뀌는 우선순위에 just in time으로 대응할 수 있게 함.

Kanban의 장점

1. 더 짧은 주기로 feature을 더 빠르게 제공할 수 있음. ↔ Scrum은 sprint기간에 의해서 WIP limit이 통제가 되는데, Kanban은 그냥 들어오는 순서대로 우선순위 높은것순서대로 계속 달리는 말 같기 때문.
2. 우선순위가 아주 자주 바뀐다면, Kanban이 이상적.
3. WIP limit과 workflow 의 LEAD time에 대한 데이터가 쌓이면 어느정도 팀의 처리 속도를 예측 할 수 있음 (내가 이런 일을 줬더니 LEAD TIme이 이정도 걸리는 구나. 그럼 다음에도 이정도 규모의 일은 이정도 걸리겠구나)

Kanban 적용시 고려사항

1. 팀의 workflow를 정의해야한다. (우리는 어떤 workflow로 일을 처리해야 효율적일지.. 등)
2. WIP limit의 초기값을 어떻게 정할 것인지. (initial n-1,2 items per person…)
3. item 간에 유사한 크기로 분할해야하는데, 이 크기를 어떻게 잡을 것일지
4. 회고 를 통해 Manage flow

Being Kanban에 대해 고려사항

1. 생산라인인가 개발팀인가 라는 불만
2. Scrum 처럼 Role이 분명하지 않은데 ‘누군가가’ Lead Time, WIP 모니터링, .. 등을 일을 해 줘야함.

---

Scrum vs Kanban. 우리 팀에 더 적합한 방식은?