스크럼이 중요한게 아니라, 가치관이 중요한거겠죠

스크럼은 암이라는 글을 사내 슬랙에서 보고 공감되는 부분과 아쉬운 부분이 있어서 댓글을 남겼었는데요. 커리어리 push를 보니 여기도 있어서, 사내 슬랙에 남겼던 글을 여기에도 남겨 봅니다. 전 암이라고 말하는 사람의 입장도, 그리고 스크럼에 대한 효용성을 경험한 사람의 입장도 모두 이해합니다. 왜냐면 조직과 인적자원의 상황이 달랐을 테니까요. --------------------------------------------------------- 해결하려는 문제를 제대로 보지 못하고, 무조건적으로 스크럼의 형태로 애자일하다고 말하는 방식으로 하려는 것에서 '나쁜 경험'이 무수히 나타나는 것 같습니다. 특히 본문은 '계약서'에 대한 이야기가 나오는데 아마도 SI업체일 가능성이 높고, 이런 경우는 요구사항을 내는 '고객'이 스크럼이나 스프린트에 전혀 적합하지 않은 추상적인 요구사항을 낼 것이기에 최악의 경우가 생겨요. 저도 이전 회사에서 그런 경우를 겪어봤었고 불신이 깊었습니다. 몇년간 고민했던 생각인데, 애자일에서 진짜 중요한건 프로세스가 아닌 것 같아요. 애자일 선언의 내용을 다시 살펴봐도 나오듯이 프로덕트매니저는 올바르게 문제를 정의하고 해결하기 위해서 측정가능하고 실행가능한 목표를 제공하는 것이 필요하고, 메이커들이 수행자가 아니라 그 문제에 대해서 자신의 전문성을 더 많이 발휘해서 해결해나가는 마음가짐과 태도가 더 중요한 것 같아요. 이걸 갖추기 위해서 메이커의 HOW에 대한 자유도를 보장해주는 유저스토리가 사용되어야 하고요. 결국은 조직에서 일하는 방식과 태도적 분위기의 문제죠. 스크럼에 무슨 대단한 정석도 없는데 스크럼 적용의 실패와 성공을 따지는 건 무의미한 것 같아요. 이런 이유로, 전혀 개성적 전문성을 드러내거나 굳이 소프트웨어의 성공을 만들 필요도 없고, 그걸 요구받지도 않고 오로지 속도와 납품가만 중요하게 여겨지는 일부 SI프로젝트 상황이라면 스크럼은 애초에 불가능한 이야기인 것 같아요. 요구사항이 'what'으로 보이는 것만 이야기하는데 무엇을 만들어도 만족하지도 못하고 무엇보다 비용(시간*인력*영향범위)을 추정하기도 어려우니까요. 그리고 반대로 고객들이 SI에서 관리방식으로 스크럼을 바라보는 것도 애자일 기본 원칙에 대한 몰이해라고 생각하고요. 저 글에 나오는 '노트북덮고 오프라인에 서서 해야만 잘 되는 스크럼'이나 '스토리 포인트를 일괄적으로 적용해서 개발 속도 관리'는 오히려 형식에 가치가 함몰되고, 뭔가 분명히 잘 못된 나쁜 경험이지 싶어요. 이것도 가스라이팅일까요 ㅋㅋㅋㅋ 좋은 글 공유주셔서 감사합니다. https://news.hada.io/topic?id=10612&utm_source=slack&utm_medium=bot&utm_campaign=T02NKNV5B