스크럼 마스터로서 개발 관리자의 부정적인 점은 무엇입니까?

팀 관리자가 스크럼 마스터가되어서는 안된다는 데 일반적으로 동의하지만, 그 이유를 확인하기 위해 고심하고 있습니다. 문맥 상, 저는 스크럼 팀에 4 명의 개발자가있는 응용 프로그램 개발 관리자입니다. 저는 스크럼 마스터 (Scrum Master) 배경 출신이며 조직에 스크럼을 도입했습니다. 나는 팀을 처음부터 구축했으며 내가하는 모든 일은 팀을 용이하게하고 결정을 내리는 것임을 분명히했습니다. 팀으로서 우리는 매우 개방적입니다. 그들은 심지어 우리가 시작하기 시작한 '보고'느낌을 없애기 위해 잠시 동안 스탠딩에서 침묵했습니다. 개방성 부족은 일반적으로 관리자에 대한 스크럼 마스터로서 가장 큰 논쟁이지만, 잘 처리되면 올바른 문화로 쉽게 극복 할 수 있습니다.

나는 경험이 풍부한 스크럼 코치들에게 이것이 위험한 상황이며 '일이 잘못되면'위험이 있다는 경고를 받았습니다. 제가보기에 두 가지 입장이 충돌하지 않습니다. 두 역할 모두 팀과 개인에 대해 동일한 목표를 가지고 있습니다. Scrum은 전통적으로 관리자 역할을 할 수있는 팀 내의 충돌을 해결합니다. 스프린트의 자체 관리 특성은 관리자가 전통적으로 수행 한 작업의 할당을 제거합니다.

개발 관리자가 개인의 요구 사항, 경력 목표, 작업장 등을 충족시키기 위해 항상 왼쪽으로보아야 할 것은 매주 각 팀원과 함께 문제를 제기하고 관리 작업을 처리하는 것입니다. 이 중 많은 부분이 팀이나 직접 스크럼 마스터로서의 역할과 관련이 있습니다.

나는 대규모 조직에서 이것이 어떻게 관리 할 수없고 별도의 역할이 될 수 있는지 이해하지만 소규모 조직의 경우 다른 Scrum Master 또는 Development Manager를 정당화 할 수는 없습니다.

위에서 제기하고 이미 극복 한 점을 제외하고 개발 관리자가 스크럼 마스터로서의 함정에 대해 알려주십시오.

본질적으로, 이해 상충이 있습니다. 관리자의 임무는 마감일을 맞추는 것입니다. 스크럼 마스터의 임무는 추정이 가능한 한 정확하고 지속 가능한 속도로 작동하는 것입니다. 관리자는 스프린트로 더 많은 작업을 수행하려는 경향이 있으며 스크럼 마스터는 외부 마감일에 관계없이 현실적으로 완료 할 수있는 금액을 원합니다. 훌륭한 관리자는 그러한 갈등의 균형을 맞출 수 있지만, 작업이 두 사람으로 나뉘면 훨씬 쉽습니다. 일반적으로 관리자는 제품 소유자 역할에 훨씬 적합합니다.

팀원 중 누구도 익숙하지 않은 경우 스크럼 마스터로 활동하는 데 아무런 문제가 없지만 몇 개월 후에 해당 역할을 수행하면 팀에 혜택이 표시됩니다. 그 역할을 동료로 보는 것이 중요합니다. 비 관리 스크럼 마스터조차도 팀이 관리자처럼 너무 많이 취급하기 시작하기 때문에 잠시 후에 회전해야하는 경우가 종종 있습니다.

가장 큰 문제는 관리자로서 팀원들에게 무엇을해야 할 지에 대한 권한이 있다는 것입니다. 스크럼 마스터는 스크럼의 원칙을 시행하는 것 외에는이 권한이 없습니다.

이것은 무엇을 의미 하는가? 관리자의 의견은 내재적으로 더 많은 가중치를 부여합니다. 당신은 그것을 의미하거나 원하지 않을 수도 있지만, 하루가 끝나면 팀원의 경력과 월급은 당신에게 어떤 방식으로 달려 있습니다. 그리고 그들은 그것을 알고 있습니다. 그리고 이것은 관계를 오염시킵니다.

아직도 할 수 있습니까? 당연하지. 당신은 당신이 하인 지도자이고 하향식이 날지 않을 것을 강화하기 위해 열심히 노력해야합니다.

저는 "기술 관리자"가 일상적인 프로젝트 역학에 너무 많이 관여 할 때 어떤 일이 발생하는지 보았습니다. 우리의 경우, 문제의 매니저였다 되지 스크럼 마스터하지만 공동 옵트 그 결정의 일부 시도하고 있었다; 우리가 실제로하지 않았다면 한 후 방어를 재생하기 위해 별도의 스크럼 마스터는 훨씬 더 고통스러운했을 것이다.

(실수로 이것은 내 관리자 가 아니기 때문에이 시점에서 상당히 객관적이라고 생각합니다.)

주요 이해 상충으로 본 내용을 살펴 보겠습니다. 이 중 하나라도 자신의 상황에 적용되지 않는다고 생각되면 두 가지를 모두 수행 할 수 있습니다. 그러나 이러한 함정에 빠지지 않도록 이러한 가정을 정기적으로 다시 확인하십시오.

1. 기술 관리자는 일반적으로 여러 팀 내에서 특정 역할을 담당합니다. 팀이 하나 뿐인 경우 "관리자"보다 "리드"에 가깝습니다. 이러한 책임의 확산은 팀과의 시간이 줄고 프로젝트 / 제품과의 시간이 줄어드는 것을 의미하며 "히트 앤 런"스타일 관리로 이어지는 경향이 있습니다.

2. 기술 관리자는 비즈니스에 대한 다른 많은 관리 업무를 수행합니다. 코칭 / 훈련, 성과 검토, 인터뷰 / 채용, 장기 인프라 / 자원 계획 등을 수행해야합니다. 이것은 쉽게 풀 타임 직업이 될 수 있으며 촉진에 소비 할 여지가 거의 없습니다.

3. 바쁜 일정도 팀에 영향을 줄 수 있습니다. 기술 관리자는 팀이 부적절한 시간으로 간주되는 시점에서 팀 구성원을 회의에 끌어 들이기를 원하거나 원할 수 있습니다. 일반적으로 장애를 관리하고 제거하는 것은 스크럼 마스터의 임무이지만 걱정할 일정이 있으면 객관적으로 생각하는 것은 불가능합니다. 스크럼 마스터는 모든 회의가 이미 사전 예약되어 있기 때문에 (스탠드 업, 회고전 등) 팀원과 별도로 회의를 할 필요가 거의 없습니다.

4. 기술 관리자는 교차 절단 프로젝트 문제를 처리해야하며 라이브러리, 소스 제어, 알고리즘, 레이아웃, 색상 등 모든 것을 표준화하려고 노력해야합니다. 이것이 실제로 회사에 좋은 일이기는하지만, 궁극적으로 팀이하고 싶은 일을하려고하지 않을 것이며, 다른 일을하고 싶은 아주 좋은 이유가있을 수 있습니다. 이것은 스크럼과 그와 유사한 방법론의 "지속적인 개선"이상에 반합니다.

5. 자신이 관리하는 역할의 전문가 배경에서 온 관리자는 작업 수행 방법 및 소요 시간에 대한 상당히 강력한 아이디어를 갖게됩니다. 이것은 관리자로서 나쁜 것은 아니지만 스크럼 마스터로서 팀 구성원을 동의하지 않은 디자인이나 견적으로 편향시키는 것을 의미하며, 당면한 문제에 대해 아마도 당신보다 더 많이 알고있을 것입니다.

6. 팀원은 항상 요청과 주문을 구별하는 데 어려움을 겪을 것입니다. 그들은 당신에게 이것을 말하지 않고 그것을 스스로 깨닫지 못할 수도 있습니다. 당신이 단순히 질문하고 말하지 않고 있음을 분명히하더라도, 당신은 여전히 ​​그들의 관리자이며 "아니오"라고 말하면 직업 수준의 위험이 있습니다. 때문에 아마 문제가 모두의 가장 교활한 당신이 그것에 대해 할 수있는 아무것도 - 그것의 자신의 태도가 아니라 당신 중요한 것은.

이 함정에 빠지지 않을 것이라고 확신 한다면 그저 가십시오 ...하지만 반복 합니다. 팀 (및 다른 팀 / 관리자)과 대화하여 가정 을 자주 확인 하십시오! 그것들이 당신이 알지 못하는 미묘하거나 무의식적으로 일어나지 않도록하십시오.

긍정적 인 점으로, 귀하가 실제로 질문을하기에 충분히 중요한 문제라고 생각한다는 사실은 귀하가 두 역할 모두에 능숙하다는 것을 의미합니다. 자신의 경력에 ​​대한 야심이 아닌 팀에 대한 관심은 아마도 저의 저서에서 좋은 경영진의 절반 이상을 차지할 것입니다.

...하지만 모두 잘되는 것은 반드시 둘 다 잘 할 수있는 것을 의미하지 않는다 동시에, 모든 시간 . 조심해

이것은 종교가 아니며 스크럼의 규칙은 독단적이지 않습니다. 통합 된 HR 관리자 / Srum Master 역할에 대한 사례가 있다면 좋은 역할을했습니다. 언급 한 함정에주의를 기울이십시오. 그러나 모든 상황에 완벽하게 맞는 단일 규칙 집합은 없을 것입니다.

팀이 두 가지 역할을 모두 수행하는 데 익숙하다면 책의 규칙에 맞게 물건을 흔들 필요가 없습니다.

내가 볼 수있는 가장 큰 문제는 팀에 관리자와 관련된 문제가있는 상황입니다. 그들이 주니어이거나 자신감이 없으면 회고 중에 연설을 두려워 할 수 있습니다. 이것은 회고의 효과를 제한 할 수 있습니다. 많은 사람들은 관리자가있을 때 "관리자가 비현실적이라고 생각합니다"라고 말하기를 두려워합니다.

따라서이 문제를 해결하기 위해 회고에서 자신을 변명 할 수 있습니다. 이제 팀은 스크럼 마스터없이 회고를하고 있으며, 회고의 효과도 잠재적으로 제한합니다.

두 경우 모두 팀에 부정적인 영향을 미칩니다.

내가 볼 수있는 주요 문제는 팀의 조직에 대해 충돌하는 메시지를 팀에 보내는 것입니다.

다음은 가능한 두 개의 팀 조직입니다. 둘 다 성공할 수 있습니다. 그들은 달라요. (유일한 가능한 옵션은 아닙니다.)

1. 팀에는 공식적으로 지정된 리더가 있습니다. 팀 리더는 궁극적으로 팀의 전반적인 성과를 책임집니다. 팀장은 모든 결정을 내릴 수는 없지만 모든 결정에 대해 최종 결정을 내립니다.
2. 이 팀은 자체 구성되어 있으며 공식적으로 지정된 리더가 없습니다. 팀의 모든 사람은 자신과 팀의 전반적인 성능에 대해 책임을집니다. Scrum Master는 Scrum 프로세스를 용이하게하지만 팀을 위해 일방적 인 결정을 내릴 수는 없습니다.

실제 팀 구조가 1 위인 것처럼 들리지만 용어와 스크럼의 여러 프로세스를 사용하면 구조가 2 위임을 암시합니다. 제 의견은 # 1이 스크럼이 아니라는 것입니다.

다음은 충돌을 해결하는 방법에 대한 두 가지 제안입니다.

1. 당신이 일을 계속하고 있지만, 당신이 팀 리더이며 스크럼 100 %를 따르지 않는다는 것을 분명히하십시오. 관리자와 스크럼 마스터의 의무를 분리하는 데있어 가치는 있지만 회사에는 적합하지 않다고 설명하는 것이 도움이 될 것입니다.
2. 가능한 한 많은 사람에게 스크럼 마스터의 책임을 전하십시오. 로드 블록을 지우고 조직의 다른 부분에서 방해 요소를 제거하는 것과 같은 일부 책임을 계속 유지해야하더라도 여전히 동료가 수행하는 많은 Scrum Master 작업을 유지하는 데 도움이됩니다.

스크럼 마스터로서 개발 관리자의 부정적인 점은 무엇입니까?

개발 관리자는 다음을 위해 고용됩니다.

• 개발 문제를 해결하십시오 .
• 기술 부채를 모니터링하고 줄입니다.
• 기술 직원을 키우십시오.

그들의 배경과 전문 지식은 기술적 인 문제 에 초점을 두어야 합니다 .

반면에 프로젝트 관리자 / 스크럼 마스터는 고용됩니다.

• 프로젝트 성공을 보장하십시오.
• 작업 및 심사 버그 / 질문을 적절한 개발 리소스에 할당하십시오.
• 개발팀과 협력하여 프로젝트 완료를 지연시킬 수있는 모든 장애물을 제거하십시오.
• 프로젝트 상태를 상위 관리로 릴레이합니다.

• 프로젝트 또는 회사가 특정 규모로 성장하면 개발 관리자에게 두 가지 임무를 모두 수행하도록 요청하는 것은 비효율적이며 현명하지 않습니다.

• 개발 관리자는 "심층 다이빙"을 코드 및 / 또는 아키텍처로 가져 오는 경향이있는 반면, 프로젝트 관리자 / 스크럼 마스터는 항상 "50,000 피트"의 사안에 대해 관심을 가져야합니다.

• 대부분의 개발 관리자는 수년간 코드를 개발했습니다. 개발 문제는 그들에게 매우 친숙합니다.

  • 따라서 기술적 인 문제를 해결할 때 가장 유용합니다.
• 프로젝트 관리자 / 스크럼 마스터 역할을 수행하려면 매우 체계적이고 세부적인 자세를 취하지 만 기술적 인 사람은 필요하지 않습니다.
• 이 사람들이 자신이 잘하는 것을 전문화 할 수 있으면 비즈니스가 가장 효율적입니다.
• 또한 개발 관리자의 판에서 스크럼 관련 책임을 분담 할 수 있으면 기술 문제에 더 많은 시간을 할애하고 기술 부채를 줄일 수 있습니다.

숙련 된 스크럼 코치의 말을 듣습니다. 99 %의 시간 동안 잘 작동 할 수 있습니다. 그러나 그 두려운 일이 발생하고 역할이 충돌하면 개인과의 관계뿐만 아니라 팀 전체의 건강을 악화시킬 수 있습니다. 그리고 한 번의 실패로 스크럼 마스터와 관리자로서의 역할이 손상 될 것입니다.

내가 당신이라면 스크럼 마스터가 될 가능성이있는 팀의 개인을 식별하고 그와 함께 갈 것입니다. 저는 항상 스크럼 마스터를 팀이 신뢰하고 프로세스, 비즈니스 및 무서운 기술을 이해하는 사람으로 보았습니다. 유능한 사람을 선택했다면, 스크럼 마스터 역할은 정규직이 아닙니다.