스크럼에 대한 5가지 잘못된 희망과 해결 방법

많은 고전적이고 끝나지 않는 갈등과 마찬가지로 개발 팀이 조직을 구성하고 자치를 관리하는 방법에 대한 논쟁이 계속되고 있습니다. 현재는 거의 스크럼 팬보다 비평가가 더 많은 것 같습니다. 가장 일반적인 세 ​​가지 불만 사항은 다음과 같습니다.

1. 프로세스는 작업에 중점을 둘 수 있습니다.
2. 마이크로 관리와 다른 이름으로 쉽게 혼동될 수 있습니다.
3. 일상의 스탠드업은 존재를 정당화해야 하는 회의처럼 느껴질 수 있습니다.

다른 경우에는 Scrum의 역할이 적절하게 표현되지 않습니다. 때때로 제품 소유자는 스프린트 내부에 너무 많은 것을 원하거나 스프린트 중간에 우선순위를 변경하기를 원합니다. 즉, 속도를 유지하고 그들이 배우는 모든 새로운 스크럼 의식을 채택하는 데 집착하는 스크럼 마스터입니다. 프레임워크를 사용하고 얼마 후 "우리입니까, 아니면 방법론입니까?"라는 일반적인 질문이 떠오른 것 같습니다.

스크럼의 잘못된 희망

위에 설명된 것과 같은 기능 장애가 많이 있지만 대부분의 간단한 근본 원인은 스크럼이 단순히 프로세스를 따라 조직 내의 근본적인 문제를 해결하도록 설계되지 않았기 때문입니다. 이를 인식하지 못하면 새 팀이 시작하자마자 위험에 처할 수 있습니다.

잘못된 희망 #1: 스크럼은 팀의 작업 속도를 높입니다.

스크럼은 추가 리소스를 추가하지 않고 프로세스를 가속화하려는 것처럼 외부인에게 들리는 용어를 사용합니다. 스크럼의 새로운 팀으로서 용어에 얽매이기 쉽습니다(예: 스크럼 마스터란 무엇입니까? 제품 소유자와 제품 관리자의 차이점은 무엇입니까? 스토리 포인트는 무엇이며 어떻게 할당됩니까?)

더 문제는 많은 사람들이 속도와 전력 질주와 같은 용어를 보고 "속도"라고 생각한다는 것입니다. 그러나 Scrum을 포함한 모든 Agile 방법론의 목적은 완제품을 제공하는 것입니다. 결국 팀이 Scrum에 대해 더 능숙해지면 새로운 기능을 더 빨리 제공할 수 있습니다. 그러나 속도가 반드시 주요 목표는 아닙니다. 이러한 구분은 스크럼 팀 내에서 그리고 스크럼 방법론을 지원하기 위해 회사 내에서 인지도를 구축할 때도 명확히 해야 합니다.

당신은 속도를 파는 것이 아닙니다. 완성품을 판매하고 있습니다.

잘못된 희망 #2: 스크럼을 엄격하게 준수하면 회사 문화 문제가 해결됩니다.

사람마다 일하는 스타일이 다릅니다. 어떤 사람들은 회의를 좋아합니다. 다른 사람들은 "열심히 일하고 열심히 놀아"와 같은 문구를 사용합니다. 당신의 회사가 어떤 근무 스타일을 가치 있게 여기든 간에 당신은 장점과 단점을 모두 수용하고 있다는 사실을 인식하는 것이 중요합니다. 회의를 중시하는 회사는 일상적인 일에 어려움을 겪을 가능성이 높습니다. 공격적이며 속도 지향적인 팀은 스프린트 내부의 범위 크리프 문제를 겪을 것입니다.

특히 최근에 결성된 팀의 경우 큰 그림을 놓치기 쉽습니다. 중요한 것은 프로세스의 모든 마지막 부분을 따르는 대신 완제품을 제공하는 것입니다. 방법론을 비난하기보다는 항상 목표를 달성하기 위해 작업 스타일을 개선하는 방법을 찾으십시오.

잘못된 희망 #3: 중요한 기여자는 대표자를 회의에 보낼 수 있습니다.

일단 방법론을 시작하면 대리인이 아닌 원래 팀이 참여하는 것이 중요합니다. 개발자로부터 거의 보편적인 불만이 하나 있다면 필요할 때 스크럼 마스터와 제품 소유자가 없었고 대리인에게 권한이 부여되지 않았다는 것입니다. 결정을 내릴 수 있는 사람이 부재중이라는 말만 듣고 결정을 기대하고 회의에 참석하는 것을 좋아하는 사람은 없습니다.

위임은 일반적인 관행일 수 있지만 스크럼에서는 참가자에게도 권한을 부여해야 합니다.

잘못된 희망 #4: 매일의 스탠드업은 모든 사람을 더 집중하게 만들 것입니다

일일 스탠드업 회의는 지난 24시간 동안 모든 사람이 한 일에만 초점을 맞추어서는 안 됩니다. 장애물을 드러내거나 문제를 해결하기 위한 새로운 접근 방식을 우선시하는 것이 훨씬 더 중요합니다.

스크럼은 특정 역할, 특히 스크럼 마스터가 독단적이면서도 압도적이지 않도록 요구합니다. 스크럼 마스터는 완제품으로 이어지는 긍정적인 환경을 만드는 것이 중요합니다.

잘못된 희망 #5: 첫 번째 시도에서 성공할 것입니다

스크럼에는 추측, 연역적 사고 및 실수가 포함됩니다. 사람들은 첫 번째 시도에서 거의 성공하지 못합니다. 스크럼은 완제품에 도달하는 방법뿐만 아니라 프로세스를 관리하고 운영하는 방법에 있어서도 모든 면에서 반복적입니다. 스크럼은 팀이 채택할 수 있는 진입 장벽이 낮도록 설계되었지만 프레임워크에 대한 참여를 반복하고 지속적으로 개선하려는 노력도 필요합니다.

깨진 스크럼 프로세스를 수정하는 방법

스크럼은 매몰 비용 오류에 저항합니다. 스크럼의 반복적인 특성은 비효율적인 프로세스를 조정하거나 폐기할 기회를 만듭니다. 스크럼 프로세스가 예상만큼 효과적이지 않은 경우 다음 제안을 고려하십시오.

기대치를 조정하십시오

출시 시간을 단축하거나, 매력적인 제품을 만들거나, 팀이 협업할 수 있도록 지원하는 것이 무엇이든 성공에는 헌신과 시간이 필요합니다. 새로운 팀의 경우 달성해야 할 합리적인 이정표는 각 스프린트 후에 프로덕션 환경에 작동하고 테스트 가능한 코드를 도입할 수 있는지 여부입니다.

고급 팀은 주문형 빌드, 테스트 및 배포 능력으로 성공을 측정할 수 있습니다. 새로운 기능에 대한 사용자 반응을 계측하고 정량화할 수 있습니까? 더 광범위한 조직이 팀이 제품에 적용하는 변경 사항을 지원할 준비가 되어 있습니까?

참가자에게 권한 부여

팀 구성원의 가치를 높일 수 있는 방법에 대해 오프라인에서 팀 구성원을 멘토링하는 것이 중요합니다. 결정을 내려야 하는 경우 다른 팀원을 언제, 어떻게 포함해야 하는지 코칭하여 자신감을 높이십시오. 관리자는 장애물을 제거하고 필요할 때 팀을 지원할 준비가 되어 있어야 합니다.

문제를 사전에 해결

스크럼은 회사를 개조하기 위해 설계되지 않았습니다. 문제가 해결되지 않은 상태로 방치된 경우 제품 개발 프로세스에서 이러한 문제가 나타날 가능성이 더 큽니다. 스크럼 마스터는 팀원들이 갈등의 느낌을 줄이기 위해 피드백을 구성할 수 있는 긍정적인 방법을 만들도록 설계된 프레임워크를 도입할 수 있습니다.

그러한 예 중 하나는 "I Wish, I wonder, What if" 프레임워크입니다. 팀 토론이나 회고 중에 팀 구성원은 이 세 가지 문구 중 하나로 자신의 진술을 시작하여 피드백을 제공할 수 있습니다. 예를 들어, “직접 회의에서 내가 그날 인지해야 할 장애물에 더 집중할 수 있기를 바랍니다.”라고 말할 수 있습니다. "I like..."와 같은 고유한 오프너를 사용할 수도 있습니다.

회의 중에 도움이 될 수 있는 또 다른 구조화된 피드백 솔루션은 Brian Robertson이 만들고 Zappos와 같은 회사에서 사용하는 Holocracy의 Triage 방법입니다. 예를 들어, 참가자들은 토론할 "긴장"의 의제를 만듭니다. 각 참가자는 "긴장이 있습니다"라고 말하면서 문제를 설명한 다음 문제를 해결하는 데 필요한 사람과 리소스를 나열합니다. 참가자들이 문제를 "긴장"으로 직접 해결하도록 독려함으로써 홀로크라시는 참가자들이 갈등의 분위기를 조성하지 않고 자유롭게 의사 소통할 수 있도록 합니다.

회고를 사용하여 문제 해결 및 프로세스 반복

많은 기업에서 회고전은 적절한 주의를 기울이지 않습니다. 이것은 주로 회고전이 오래된 논쟁, 갈등 및 불만의 장소라는 것에 대한 많은 사람들의 두려움 때문입니다. 팀이 팀의 가치와 회사 문화를 반영하는 기본 규칙을 개발하는 것이 중요합니다.

정적 프로세스에 대한 투자를 피해야 할 필요성도 중요합니다. 한 번 효과가 있었던 것이 영원히 작동하지 않을 수 있습니다. 많은 팀이 참가자 이직으로 어려움을 겪고 있습니다. 이것은 참가자가 다른 팀으로 재배치되거나 승진하거나 회사를 완전히 떠날 때 많은 회사에서 일반적입니다. 팀 구성이 발전함에 따라 Scrum에서 모든 것이 반복적이라는 약속을 유지하지 않는 것이 중요합니다. 실수가 발생할 수 있지만 반복하면서 일시적인 오류가 발생하기를 바랍니다.

스크럼은 교장이 있을 때 가장 잘 작동합니다.

팀에 속해 있으면 참석할 수 있어야 합니다. 제품 개발은 아마도 회사가 장기적인 성장을 개선하기 위해 착수할 수 있는 가장 중요한 프로세스일 것입니다. 따라서 신제품 개발의 주요 경로인 스크럼 프로세스가 그에 상응하는 관심을 받는 것이 중요합니다. 많은 환경에서 개발자 팀은 회사의 목표를 이끄는 결정과 토론에서 분리되어 작업하는 경우가 많습니다. 스크럼은 다릅니다. 스크럼은 결정, 방향 및 개발이 단일 프로세스로 결합되는 곳입니다. 대리인을 보내거나 스크럼 방법론 내에서 진행되는 회의에서 팀원을 제외하는 것은 프로세스에서 너무 중요합니다.

요약: 깨진 스크럼 프로세스를 수정할 수 있습니다.

반복적인 특성으로 인해 Scrum은 비즈니스가 너무 멀리 나아가 나쁜 아이디어나 제대로 구현되지 않은 프로세스로 끝날 수 있는 일에 전념하는 것을 보호하는 데 도움이 됩니다. 이 원칙을 고수하면 과거의 실수로부터 긴장을 풀고 스크럼 프로세스를 반복적으로 개선하는 데 도움이 될 수 있습니다.

개인과 팀에 집중하는 것이 중요합니다. 팀원이 바뀝니다. 모든 프로젝트는 다릅니다. 프로세스를 엄격하게 준수한다고 해서 항상 최상의 결과를 얻을 수 있는 것은 아닙니다. 프로세스 외부에서 팀 구성원에게 투자하는 것은 프로세스 내에서 자신을 수행하는 방법만큼 중요합니다.

스크럼은 유연할 수 있습니다. 무언가가 작동하지 않으면 Agile 내부와 외부 모두에서 다른 프레임워크의 요소를 통합하는 것을 고려하십시오. 대립적인 토론을 하는 구조화된 커뮤니케이션 스타일을 식별하고 채택합니다.

스크럼은 팀이 변화하는 클라이언트 요구 사항에 대응하여 완전한 제품을 구축할 수 있도록 함으로써 장기적인 ROI에 도움이 됩니다. 스크럼은 좋은 아이디어가 더 발전할 수 있는 여지를 주는 동시에 나쁜 아이디어에 지나치게 집착하지 않도록 하는 가장 좋은 방법일 것입니다.