최근에 Scrum으로 이사 한 6 명의 팀을 관리하고 있습니다.
우리는 Scrum Master (팀의 개발자 중 한 명)와 제품 소유자가 있습니다.
나는 많은 자유 시간을 가지고 있기 때문에 (내가했던 많은 관리 작업이 Scrum Master와 Product Owner에 의해 수행 되었기 때문에) 기술적으로 관련성을 유지하기 위해 기술 개발 작업을하고 있습니다.
저는 개발 팀의 일원으로 활동하고 각 스프린트의 일부 스토리에 전념하며 모든 회의에 팀의 일원으로 참여합니다.
좋은 생각이라고 생각하십니까? 팀의 "자체 조직"과 모순 될 수 있습니까?
답변:
a는에서 민첩한 세계에서 팀 리더십에 로이 Osherove의 개발의 생각을 읽고 5whys.com
그는 팀이 폭포에서 스크럼으로 진화함에 따라 팀이 진행하는 3 가지 주요 단계에 대해 많은 이야기를합니다.
생존 단계 (내가 볼 수있는 대부분의 팀이있는 곳) (팀이 배울 시간이 없음)는 아무 것도 아닌 학습 시간을 만들기 위해 더 많은 명령 및 제어 유형의 리더십이 필요합니다.
팀이 배울 시간이 있고 그것을 사용하는 학습 단계 는 어려운 길을 배우기에는 너무 오래 걸릴 때 (예를 들어, 소스 제어를 선택하지 않는 경우) 버스트가 많은 리더와 같은 코치가 필요합니다.
자체 조직 단계 -팀이 자신의 문제를 해결할 수있는 경우-사람들에게 무엇을해야 하는지를 알려주지 않고 단순히 제약과 최종 목표를 제공하는 촉진자 유형의 리더가 더 필요합니다. 팀은 저절로 거기에 도착할 것입니다.
OpenVolcano '10 에서 Roy의 아이디어를 접했 을 때 팀이 개선을 중단 한 이유에 대해 완전히 상실했습니다. 그런 다음 팀이 생존에서 학습으로 넘어간 것을 알았고 경영 스타일을 전혀 바꾸지 않았습니다. 나는 그렇게했고 그것은 많은 도움이되었습니다.
따라서 세 단계 중 어느 단계에 있는지 파악하고 적절하게 관리하는 것이 좋습니다.
또한 지금 결정을 내리고 리더 또는 개발자가 되십시오. 자기 조직 단계에 빠질 때까지 여가 시간이 있다고 생각하지 마십시오. 그리고 만약 당신이 거기에 도착하면, 당신이 좋은 팀 리더라는 것을 깨닫고 ( 어려워요 ) 스스로를 통합하지 않고 다른 팀으로 넘어갑니다.
pdr의 의견은 유효하며 동의합니다. 그러나 나는 그들이 모든 경우에 보편적이라고 믿지 않습니다.
관리 스타일에 따라 두 가지 역할을 수행하는 방법을 고려해야합니다.
팀 관리자는 직원의 성과 및 경력 유형 결정에 대한 권한을 갖습니다. 잘못 생각하면, 당신과 당신의 고용주 사이의 힘의 불균형은 개발 팀의 일원이 되려는 당신의 시도를 망칠 수 있습니다.
이러한 차이를 인식하고 역할을 명확하게 설명하는 한 관리자 및 개발자가 될 수 있다고 생각합니다. 나는 그것이 여러 번 성공적으로 수행되는 것을 보았고 현재 같은 상황에서 팀에서 일하고 있습니다.
시차의 모든 영향을 제거 할 수는 없습니다. 당신의 혀를 물고 활기찬 토론에서 물러나야 할 때가있을 것입니다. 트럼프 카드를 뽑아 내야 할 때 다른 사람들이있을 것입니다. 팀에 대한 궁극적 인 책임은 당신에게 달려 있기 때문에 당신은 딕 터트를 만들고 있습니다.
정치적으로 안전한 팀에는 적어도 두 명의 강력하고 경험이 풍부한 개발자가 필요합니다. 이들의 역할은 전력 불균형을 확인하고 균형이 맞지 않을 경우 사용자를 불러내는 것입니다. 다른 강력한 개발자 한 명과 만날 수는 있지만 두 번째 문제는 두 사람이 문제로 교착 상태에 빠질 경우 객관성을 제공합니다.
직속 상사가 기술적으로 관련성을 유지할 때 솔직히 좋아합니다. 그것은 나의 어려움에 대한 그들의 이해를 촉진시키고, 우리가 더 나은 성과를내는 팀으로 끝날 것이라고 생각합니다.
나는 비슷한 경험을 겪어 스크럼 팀에서 6 명의 개발자로 구성된 팀을 이끌었습니다. pdr과 GlenH7이 언급 한 것 외에도 다음과 같은 것들이 도움이되었습니다.