스크럼 팀의 주요 팀원

팀원이 책임을지는 상황에서 처음에는 그에게 할당되지 않고 스크럼 마스터에게 무엇을 하시겠습니까?

스크럼 팀은 자체 구성되어 있으므로 좀 더 지배적 인 사람을위한 공간이 있습니다. 다른 사람들은 작업중인 작업에 대한 아이디어를 요구해야하지만, 그의 지배력은 통제력을 유지해야합니다.

할 수있는 일 :

• 다른 사람이 독립적이지만 협력 적이되도록 동기를 부여하십시오. 이는 관리자 및 HR 부서와 협력하여 기대치를 설정하고이를 정기적으로 평가하는 경우에 가장 잘 달성 할 수 있습니다.
• 스탠드 업, 계획 및 회고 중; 다른 팀원이 먼저 말하게하십시오. 검토하는 동안 다른 팀 구성원이 자신이 구현 한 사용자 스토리를 발표하게하십시오.
• 지배적 인 개발자가 원하는 작업 만 선택할 수 없도록 다른 사람이 먼저 작업을 선택하도록하십시오.
• 지배적 인 팀원이 다른 개발자와 공동 작업 할 수 있도록 일부 작업에 페어 프로그래밍을 포함시킵니다.
• 민주주의하십시오-한 팀원의 의견으로는 프로세스를 변경하기에 충분하지 않습니다. Scrum은 팀이 명확하게 의사 소통을 할 때만 작동하거나 서로를 막을 수 있습니다.
• 이 중 어느 것도 도움이되지 않으면 지배적 인 팀원과 대화하고 상황을 설명해야하지만 스크럼에는 이유가있는 팀장이 없다는 것을 명심하십시오. 경영진의 지원이 있다면 그의 직무 안정성을 위협 할 수도 있지만 이것이 가장 마지막 옵션이어야합니다.

지배적 인 팀원이 자신의 지배력을 잃고 싶지 않고 수동적 인 팀원이 더 활동 적이기를 원하지 않으면 관리자와 HR의 지원이 필요합니다. 관리에서 스크럼 프로세스를 권장하지 않으면 문제가 될 수 있습니다.

아마도이 질문의 이유는 당신이이 지배적 인 사람 때문에 팀의 성과가 저조하다고 생각하기 때문입니다. 아마도 나머지 팀이 100 % 기여하지 않기 때문일 것입니다.

관리자 인 경우 모든 직원이 자신의 역할을 이해하도록하는 것은 귀하의 책임입니다. 구체적으로, 예상되는 것과 평가 방법. 스크럼 팀의 팀원으로서 각 사람은 팀의 성공에 대한 개인적 책임이 있습니다. 따라서이 지배적 인 팀 구성원은 해당 책임을 수행하지 못하고 이에 따라 평가 될 것임을 알아야합니다.

피드백이 핵심입니다. 팀 회의가 있고이 사람이 토론을 지배하고, 팀의 나머지 부분에 대한 그의 디자인과 접근 방식을 강요하고 나머지 부분을 수동적 인 역할로 푸시 한 경우, 무조건 비공개로 요구 사항을 충족하지 못한다고 알려야합니다. 역할의. 자신의 개인적 업적만을 강조하는 그를 발견한다면, 그는 자신의 개인적인 업적을 불러야하며 팀이 그룹 업적을 달성하는 데 도움이되는 것보다 훨씬 개인적인 가치를 소중하게 생각해야합니다.

모두 힘든 일이지만 관리자와 스크럼 마스터가 필요합니다.

이것에 대해 다른 방법이 있습니다. 팀 문제로 만드십시오. 함께 전화를 걸어 성과가 저조하다고 말하면 그 이유가 있습니다. 그들에게 해결책을 생각해 보라고한다. 당신은 놀라게 될 것입니다.

알파 개발자에게 자신의 의견을 물어보십시오. 그는 자신이 가지고있는 효과에 대해 전혀 모른다. 그를 제쳐두고 당신의 생각을 말 해주세요. "이봐, 당신은 우리의 수석 개발자입니다. 그러나 우리는이 사람들을 당신의 수준으로 끌어 올려야합니다. 어떻게해야합니까?" 그의 지배권을 자산으로 바꾸십시오. 그가 그렇게하는 방법을 볼 수 있는지보십시오.

그가 자신의 팀을 얼마나 잘 지원하고 자신의 수준으로 끌어 올렸는지 측정하면 더 많은 동기 부여가됩니다.

당신은 그가 팀의 이익을 위해 실제로 일하고 있지 않다는 것을 암시합니다 (내 추측). 그는 어떤 식 으로든 악한 것입니다. 그러나 현명한 사람은 한 번 나에게 말했다 : 무능함이나 단순한 무지가 더 가능성이 높을 때 악의를 가정하지 마십시오.

그가 스크럼 마스터가 되려는 것 같습니다.

자신의 입장을 분명히하고 그에 따라 행동하십시오.

스크럼 마스터의 역할은 팀 정신을 가능하게하는 것입니다. 이 사람을 팀원으로 만들 수 없으면 팀에서 팀원을 제거하십시오 .

빠른 참고 사항 : 주요 개발자는 수동 개발자보다 더 이상 문제가되지 않습니다.

현재 스프린트 계획은 팀 전체를 순환하는 역할입니다.

스프린트 계획은 한 번에 한 사람에게만 전달되는 것이 아니라 전체 팀을 포함해야합니다. 이것에 대한 정당한 이유가 없다면 나는 이것을 심각한 문제로 본다.

당신이 말하는 것이 진실되고 객관적이라면, 당신은 당신의 손에 큰 문제가 있습니다 : 참여하지 않는 사람들과 진정으로 민첩한 프로세스를 막는 "지배자". 럼주 마스터로서 행동을 취하는 것은 당신에게 달려 있습니다. 이 상황에 대해 프로젝트 관리자를 신뢰하고 싶을 수도 있습니다.

많은 팀이 민첩성의 핵심에서 벗어나기 때문에 팀을 되 찾는 것이 당신의 임무 입니다. 민첩한 가치를 팀에 가르치고 다시 포함시켜야합니다. 실제로, 당신은 항상 민첩한 가치를 가르치고 있어야 합니다. 민첩한 비전을 유지하고 명확하고 강력하게 만드십시오. 그들에게 "민첩한 일을 잘했다"는 당신의 헌신을 보여주십시오.

이렇게하려면 민첩한 선언문과 스크럼 값을 살펴보십시오. 그들에게 협력이 무엇을 의미하고 왜 중요한지 물어보십시오. 민첩성 에 대한 신뢰 의 역할에 대해 물어보십시오 . Scrum에 팀장 역할과 프로젝트 관리자 역할이없는 이유와 개인이 아닌 훌륭한 소프트웨어를 만드는 것은 전적으로 팀 의 책임 이라는 점에 대해 이야기하기에 좋은시기 입니다.

이 문제에 대한 전체 회고 세션을 계획하십시오. 그들에게 몇 가지 가치를 약속하고 다음 회고 동안 후속 조치를 취하십시오. 손가락을 가리 키지 말고 중립적 인 방법을 사용하십시오.

다른 회원들이 자신의 의견을 안전하게 진술하도록하는 방법을 소개합니다. 5의 주먹 처럼 간단한 것은 팀의 조용한 목소리를 듣는 데 좋습니다. 팀이 지배적 인 사람과 동의하지 않는 것이 고통 스럽습니다. 계획 포커는 잘 작동하지만 핵심은 카드가 표시 되기 전에 어떤 토론도 허용하지 않습니다 . 갈등을 시작하지 않고 다른 사람들의 말을 듣는 데 도움이되는 것은 도움이됩니다.

잘 진행되면 모든 준비가 된 것입니다. 그렇지 않으면 문제에 대해 그와 이야기하십시오. 코칭을 사용하고 문제를 명확하게 깨닫는 데 도움이되는 강력한 질문을하십시오. 왜 그가 지배적 인 역할을했는지 근본 원인을 찾아보십시오. 팀에 대한 신뢰가 부족한 이유는 무엇일까요 (왜?) 성공의 책임이 있다고 생각하는 이유는 무엇입니까? 나는이 역할이 그가 원하는 것이 아니라고 생각하고 그가 그것을 바꾸길 바라고있다. 그는 수 주위에 와서 그것을 실현.

아마도 "주요한"개발자는 팀 성과가 아닌 개인의 성과로 보상을받을 수 있습니까?

과거에 나는 매우 성대하고 명확한 아이디어를 가진 사람들에게 다른 사람들의 기여를 장려함으로써 (목표를 통해) 보상을 받도록했습니다.

일반적으로, 팀 성과보다는 개인의 기여에 대해 스크럼 멤버들에게 확고한 보상을주는 것은 나쁜 생각이라고 생각합니다.

다른 팀 구성원이 자신의 의견에 진실하다고 생각하는 경우에만 모든 팀 구성원에 대해 팀에서 360 피드백 라운드를 수행 할 수도 있습니다.

다음 스프린트에서 스크럼 마스터가 되라고 제안하십시오.

책임을 맡고 자하는 사람들은 문제가되지 않습니다 (독점을 원하지 않는 한), 그것은 우리가 자기 조직화로 달성하고자하는 것입니다.

회전하는 스크럼 마스터 역할을하는 팀은 드물지 않습니다.

스크럼 마스터의 유일한 임무는 모든 사람이 스크럼 북 규칙에 따라 연주하도록하는 것입니다. 스크럼 마스터가 아닌 스크럼 마스터가 스크럼 마스터의 방해없이 스스로 그렇게한다면, 그것은 당신이 훌륭한 (Scrum-) 모양임을 보여줄 것입니다! 스크럼 마스터가해야 할 일이 적을수록 팀이 스크럼 관점에서 더 의미 있고 뛰어납니다. 결국 스크럼 마스터의 역할은 제거 될 수 있고 / 제거 될 수 있습니다. 그는 당신을 시작하고 스크럼을 가르쳐 줄 것입니다.

다시 한 번 스크럼 마스터는 개발 프로세스에 참여하지 않습니다. 그는 모든 이해 관계자들이 올바른 일에 대해 제 시간에 의사 소통 할 수 있도록해야하며, Scrum을 알고 있으며, Scrum을 수행하는 데 지침을 제공하며, 제품 소유자 또는 프로젝트 리더가 아닙니다. 다른 것을 경험하면 민첩한 정신으로 스크럼을 수행하지 않을 수 있습니다. 물론 소규모 환경에서는 스크럼 마스터가 팀 구성원 또는 스테이크 소유자 중 한 명이 역할을 할 수 있습니다. 그런 다음 그것은 형식적인 시간이되었을 때 입는 모자 일뿐입니다. 그것을 지도력 역할과 혼동하지 말고지도 역할입니다.

개인주의와 개인 성과를 포용하고 수동적 개인이 더 참여할 수 있도록 힘을 실어주십시오.

내 경험에 따르면 첫눈에 비슷해 보이지만 공산주의와 민첩성은 동일하지 않습니다. 애자일은 클래스없는 사회 (팀)를 목표로하지 않고 작동하는 소프트웨어를 목표로합니다.

알파 개발자가 항상 먼저 대답하고 개별 성과를 달성하는 대신 질문하고 코칭함으로써 다른 기술을 개발하도록 도울 수 있음을 이해하도록하십시오. 확실히 알파 개발자는 훌륭한 소프트웨어를 염두에두고 있으며 스스로 잃을 수없는 것입니다.