🙅‍♂️ 우리가 하는 것은 스크럼이 아니다? 🎈 한 줄 요약 - 모두가 결과만을 중요시한다면 진정한 스크럼은 불가능하다. ✔️ 스타트업에서 애자일 방식을 많이 사용하고 있어요. 애자일을 대표

🙅‍♂️ 우리가 하는 것은 스크럼이 아니다? 🎈 한 줄 요약 - 모두가 결과만을 중요시한다면 진정한 스크럼은 불가능하다. ✔️ 스타트업에서 애자일 방식을 많이 사용하고 있어요. 애자일을 대표한다는 형태로 스크럼 방법론이 있고요. 그래서 스크럼을 도입한 스타트업은 모두 '애자일 조직'이라고 주장을 하곤 해요. ✔️ 하지만 우리가 도입한 애자일 프레임워크가 제대로 굴러가고 있느냐에 대해 물어볼 필요가 있어요. 과연 우리는 '얼마나' 올바른 방법으로 스크럼을 사용하고 있었을까요? 스스로에게 아니, 조직 모두에게 물어봐야 해요. 그 방법에 대해서 말이죠. ✔️ 그럼 우리는 '어떻게' 스크럼을 잘못사용하고 있을까요? 대표적으로 '결과물'에 치중하는 일련의 과정이죠. 스프린트는 우리가 추구하는 목표를 설정하는 것인데, 구체적인 '기능 구현'에만 집중하는 모습들이 많이 보여요. ✔️ 왜 그럴까요? 우리는 달성할 목표를 추상적으로 설정하기 때문이라 생각해요. '스프린트 마지막에 100% 성장을 달성하자!'가 데이터나 수치적으로는 구체적일지 모르지만, 스프린트를 통해 내놓는 결과물과는 결이 좀 다르죠. ✔️ 그래서 우린 구체적으로 표현할 수 있고, 산출물로 내놓을 수 있는 '기능 구현'에 초점을 두곤 하죠. 즉, 구체적인 결과로 표현할 수 있는 대상을 중요시 여기게 돼요. 그에 따라 프레임워크의 의도와 다른 방향으로 흘러가죠. 어떻게 아냐고요? 많이 겪어봐서요.🤣 ✔️ 여튼 잡설은 여기까지하고, 아티클의 상세내용을 함께 살펴보도록 하시죠. __________________ ✅우리가 하는 것이 스크럼이 아닌 이유 1. 제품 백로그 = 이해관계자의 위시리스트 ✔️ 백로그가 다음 기준에 부합한다면, 이해관계자를 기쁘게 하는 것이 목적일 뿐이다. - 방대한 제품 백로그(수백 또는 수천 개의 항목) - 모든 것이 제품 백로그에 들어갈 수 있다(기준 없음, 제품 목표와 관계없음). - 백로그의 항목들이 영원히 유지된다. 한 번 추가되면 절대 사라지지 않는다. - 해결해야 할 문제를 설명하기보다 구현해야 할 기능 요구사항을 담고 있다(희망사항 vs 니즈). 2. 스프린트 계획 = 기능 구혀 계획 ✔️ 스프린트 계획은 추구하는 목표를 확실히 정하는 일이지 기능 구현이 목표가 아니다. 아래 기준에 부합하면 문제가 있다. - 스프린트의 목표가 아예 없거나, 스프린트가 끝날 때까지 모든 기능을 개발하는 것을 목표로 한다. - 무엇을 달성했는지보다 결과물에 집중한다. - 창의성을 위한 여지가 없음. 팀은 해결할 문제를 정의하는 대신, 일련의 기능을 구현하는 데 집중하고 있다. 3. 일일 스크럼 = 일일 상태 보고서 ✔️ 일일 스크럼은 개발자가 작업을 정리해 스프린트의 목표에 더 가까이 다가가는 시간이다. 제품 관리자가 이해 관계자에게 잘 보이기 위해 개발자에게 책임을 전가하는 시간이 아니다. 4. 스프린트 리뷰 = 진행 상태 검토 회의 "스프린트 리뷰의 목적은 스프린트를 통해 무엇을 달성했는지 검토하고 앞으로 적용할 내용을 결정하는 것이다. 스크럼 팀은 주요 이해 관계자에게 작업 결과를 제시하고 제품 목표를 달성을 위한 진행 상황을 논의한다." - 스크럼 가이드 - ✔️ 하지만 현실은 스크럼 가이드와 동떨어져 있다. - 이해 관계자는 스프린트 리뷰의 가치를 느끼지 못하며 스프린트 리뷰에 참석하기를 꺼린다. - 이해 관계자가 참석하더라도 스크럼 팀이 앞으로 적용할 부분이 무엇인지 찾는 데 도움이 될 만한 피드백을 거의 제공하지 않는다. - 스프린트 산출물이 폭포수 모델의 다음 단계로 나아가기 위한 것으로 간주한다. 이 때문에 많은 스프린트 리뷰가 최종 사용자(end user)의 삶을 더 나은 방향으로 변화시키는 방법보다 결과물을 제시하는 데 초점을 맞추고 있습니다. 5. 스프린트 회고 = 기계적인 검토 ✔️ 의미 없는 회고는 기계적으로 반복하며, 다음 스프린트에 대한 계획없이 마무리 한다. 의미 있는 회고는 건전한 검토로 시작하여 다음 스프린트에 대한 건설적인 계획으로 마무리해야 한다. 6. 스크럼 팀 = 기능 개발 공장 ✔️ 스크럼 팀은 단지 기능을 찍어내는 공장이 아니다. ✅ 잘못 사용하는 스크럼은 스크럼이라 부를 수 없다. ✔️ 스크럼은 기계적인 방식으로 운용되는 것을 멀리해야 한다. 또한, 기능 구현에 집착하여 실질적인 목표를 잊어도 안 된다. '진정한 스크럼은 가치를 더 빠르게 제공하는 방법을 찾아내도록 도와'준다.