성숙한 애자일 팀에는 관리가 필요합니까?

최근 스크럼에 대한 격렬한 토론 끝에 저는 문제가 경영 팀이 민첩한 팀에서 매우 불필요하고 중복되는 활동이라고 생각한다는 것을 깨달았습니다. 성숙한 애자일 팀에는 경영진이나 비 기술적 의사 결정 과정이 필요하지 않다고 생각합니다. 성숙한 개발 팀 을 관리 할 수있는 유일한 사람은 코치 (적절한 의사 소통 기술을 보유한 가장 기술적으로 유능한 동료) 라는 것이 명백합니다 . 나는 스크럼 마스터가 어떻게 그러한 팀에 기여할 수 있는지 상상할 수 없다.

나는 베테랑 개발자가 아니지만 코치가 팀에있을 때 생산주기를 계획하는 데 능숙한 사람으로서 Scrum과 관리자 의 가치를 깨닫고 이해하는 데 큰 어려움을 겪고 있습니다. 그게 무슨 뜻입니까? 첨단 기술이없는 사람이 어떻게 고도로 기술적 인 팀을 관리 할 수 ​​있습니까? 여기에 관리가 다른 의미가 있습니까?

나는 경영을 총 낭비와 미숙의 부산물로 본다. 내 이해에 따르면 성숙한 팀은 완전히 자기 관리입니다. 많은 위대한 사람들이 그 반대를 말하고 있기 때문에 나는 분명히 자신을 설득 할 수 없습니다.

여기서 많은 실수를 저지르고 있습니다.

첫 번째는 스크럼 마스터가 관리자라고 가정합니다. 그들은 아니야. 그들은 기본적으로 관리자 겸 촉진자입니다. 그들은 스크럼 일정에 따라 일을 처리하지만, 당신이 완전히 성숙한 애자일 팀이라면 어떻게해야하는지 말할 필요가 없습니다. 대부분 발생합니다.

그러나 그들은 업무의 질을 모니터링하거나 휴일이나 그와 비슷한 것을 서명하지 않습니다. 제품이나 프로젝트를 관리하지도 않습니다. 그것은 다른 사람들에 의해 이루어집니다.

더 큰 실수는 다른 질문에서 설명한 상황에서 벗어날 수 있다고 가정하는 것입니다 ( "개발자는 현재 민첩한 프로그래밍 방식을 수행 할 수 없습니다. 단위 테스트, 페어 프로그래밍, CI 없음 ( "무엇입니까?) ..."아이디어를 얻습니다. ")"완전히 성숙한 애자일 팀 "에게 하룻밤. 그것은 단순히 불가능합니다. 잊어 버려. 시도조차하지 마십시오.

하룻밤 사이에 원하는 결과를 얻으려면보다 체계적인 프로젝트 관리 방법을 찾으십시오. 그리고 일부 관리자를 고용하십시오.

비즈니스가 당신이 민첩 해지기를 원한다면 시간이 걸리고 문화가 변화합니다. 그렇습니다. 처음에는 혼돈의 개선 단계에 있을 때 관리가 필요합니다. 그것이 개인이든 집단이든, 누군가는 어떤 결정을 내려야 할 것입니다.

더 큰 그림을보고, 개발자와 비즈니스 모두에게 현재 상황을 설명하고, 개선을위한 옵션을 설명하고, 비즈니스에 필요한 사항을 파악한 다음 사람들을 안내 할 책임이있는 개인 또는 그룹이 필요합니다. 그것.

완전히 민첩한 민첩한 팀과 자기 관리를하기까지는 오랜 시간이 걸릴 것입니다. 대부분의 팀은 거기에 도착하지 않습니다.

내 이해에 따르면 성숙한 팀은 완전히 자기 관리입니다.

당신이 맞다고 가정 해 봅시다. 나는 한 가지 방법을 모르므로 논의하지 마십시오.

문제는 자체 관리 팀조차도 다른 부서에 팀을 대표 할 수있는 좋은 사회적 및 정치적 기술을 가진 사람으로 끝납니다. HR 휴가 및 예산 책정을 처리하는 사람. QA 및 PM 그룹과 논의하여 팀의 나머지 구성원이 필요하지 않은 사람. 개발자 사이의 불가피한 대인 관계 문제를 중재하는 사람. 회의 일정을 잡고 사기를 꾸미는 사람.

이 사람은 관리자입니다.

• 언젠가는 집에 도착하지만 수표를 지불하지 않습니다 ...
• 휴가를 떠나고 싶지만 팀이 너무 바빠서 1 년이 지났습니다 ...
• 아내 나 아이가 아프므로
  6 개월 동안 일주일 에 20 시간으로 줄여야 합니다.
• 재무 부서에서 예산 삭감을 요청했으며 누군가가 가야합니다.
• 커피 머신이 고장 나서 아무도 그것을 고칠 수 없습니다.
• 팀이 너무 좋아서 고칠 결함이없고 추가 할 기능이 없으며 작업이 부족합니다. 지금해야 할 일.
• 고객은 수행 한 작업에 대해 비용을 지불하지 않습니다
• 고객은 달성 할 수있는 것보다 더 많은 작업을 원하고 비용을 지불 할 준비가되어 있습니다.

나는이 목록에서 내 경력에 없었던 것을 전혀 보지 못했다. 이 목록에서 고도의 기술 능력이 필요한 것은 없습니다. 솔직히 말해서, 과거에 무엇을 관리했는지에 상관없이 대부분의 개발자가 가지고 있지 않은 훌륭한 기술이 필요합니다.

배깅 관리자 중지-기술이 있고 다른 세트를 가지고 있음을 인식하십시오. 이러한 기술은 모든 조직에 필요합니다. 그들은 당신뿐만 아니라 그들의 일을 할 것입니다. 두 가지 일을 모두 잘하는 것은 드문 일이며, 두 가지 일을 동시에 잘 할 수있는 사람을 두는 일이 거의 없습니다. 구유없이 일어나는 일은 천천히 장애 상태로 침식됩니다. 운이 좋으면 조기에 충분히 인정 받고 관리자를 고용하고 갑자기 모든 문제가 마치 마술처럼 사라지고 바보 같은 사무실 정치를하지 않고 돈을받는 일에 착수해야합니다. 여기에서 경험하십시오).

나는 경영을 총 낭비와 미숙의 부산물로 본다.

와. 요즘 좋은 관리자와 일한 적이 없습니까? (우리는 모두 나쁜 것들과 협력했습니다).

나는 사람들이 때때로 완전히 이해하지 못하는 것은 쉽다고 가정하는 실수를하는 것을 보았다.

(비즈니스맨은 특히 유죄입니다. 품질 사양이 좋지 않고 마감일이 정해져 있습니까?)

대부분의 비즈니스에서 개발 팀은 더 큰 전체의 일부로 존재합니다. 관리자는 팀과 나머지 회사 간의 인터페이스로 존재합니다. 훌륭한 관리자는 양 방향으로 관계를 맺어 팀이 필요한 것을 얻도록 (요구 사항, 사무실 공간, 새 컴퓨터, 인식, 보너스 등) 코너 사무실에서 나오는 (가변하는) 우선 순위를 전달합니다. .

모퉁이 사무실은 여러 가지 이유로 존재하며 대부분이 게시물과 관련이 없습니다.

대부분의 관리자는 사용 가능한 정보와 일치 하지 않는 정보를 사용하여 최선의 결정 을 내 립니다.

완전히 성숙한 고객이었고 완전히 변한 회사의 일부인 완전히 발전된 개발 팀이 있다면 대부분의 관리가 필요 하지 않을 수 있습니다 . 그 용어는 유토피아 입니다.

좋은 성과 있길 바래요.

ps-read 프로그래머에게 전화하지 마십시오. 훌륭한 조언이며 나머지 비즈니스 세계가 우리를 어떻게 보는지보다 잘 설명합니다.

스크럼 마스터 또는 일반적으로 관리자의 역할은 독재 적 대군 주로 행동하지 않습니다. 관리자의 임무는 그의 팀이 사업 내에서 성공할 수 있도록 설정하는 것입니다. 여기에는 올바른 직원을 고용하고, 올바른 장비를 확보하고, 제품에 대한 전략적 관점을 유지하는 것이 포함됩니다. 관리자는 팀의 성공에 방해가되지 않는 세부 사항과 세부 사항을 유지하면서 라인 맨과 같아야합니다.

문제의 일부는 "Scrum Master"가 모든 역사에서 가장 정확하지 않은 제목의 역할 일 가능성이 있다는 것입니다. "Scrum Facilitator"는 약간 더 정확할 것이지만, 다른 사람이 이전에 지적한 것처럼 SM 작업은 팀을 관리하는 것이 아니라 문제를 해결하여 (자체 관리) 팀이 작업을 수행 할 수 있도록합니다. 예, 스크럼 마스터는 또한 스크럼이 발생하는지 확인해야합니다. 작업이 남은 시간으로 업데이트되고, 스탠드 업이 유지되고 값을 추가하며, 번 다운이 업데이트되고 속도가 추적되는 등 여전히 코칭입니다. 관리 역할이 아닌 촉진 역할.

문제의 또 다른 부분은 모퉁이 사무실에있는 사람들이 "언제 소프트웨어를 배송 할 수 있습니까?"와 같은 질문에 대한 답변을 알고 싶어한다는 것입니다. "어떤 기능이 포함됩니까?" 그들은 "프로젝트 관리자"에게 그 질문을하고 인상적인 모양의 간트 차트와 불확실성의 원뿔과 같은 불편한 것들에 대한 언급이 거의 없거나 전혀없는 답변을 얻을 수있었습니다.

스크럼에서, 주어진 선적 날짜에 대한 "의지", "권한"및 "하지 않는"기능의 대략적이고 준비된 목록으로 시작하는 것이 가능하지만, 누군가에게는 아마도 역할이 있습니다-아마도 스크럼 마스터- 시간이 지남에 따라 이러한 목록의 불가피한 변경 사항으로 코너 사무실을 최신 상태로 유지합니다. 그 결과 피드백을 처리하고 새로운 기능 요청을 "관리"로 관리하는 것과 함께 그 활동을 생각하고 싶습니다. 비록 많은 프로젝트 관리자들이 과거에 수행했던 것과는 다른 관리이지만 말입니다.

관리가 필요하지 않다고 생각되면 누가 다음과 같은 조직 작업을 수행하고 누가 다음과 같은 상황에 대응합니까?

• 새로운 고객을 찾아야합니다. 제품을 어떻게 판매합니까? 당신은 어떻게 광고합니까?
• 자재를 구매해야하며 공급 업체를 찾아야합니다.
• 다른 회사 나 은행 또는 관공서와의 외교 토론을 주도해야합니다

관리자가없는 소규모 팀에 근무하고 있습니다. 왜? 나는 솔직히 모른다.

가장 좋은 추측은 그것이 당신의 타입에 달려 있다는 것입니다. 어떤 사람들은 "컴퓨터"이므로 프로세스를 받아야합니다. 다른 사람들은 "프로그래머"이며 자신 만의 세계와 구조를 만들 수 있습니다.

나는 시스템을 만들거나 다른 사람에 의해 노예가되어야합니다. 나는 추론하고 비교하지 않을 것이다 : 나의 사업은 창조하는 것이다. -윌리엄 블레이크

glenatron의 의견에 대한 답변 편집 :
단순한 개발 팀 이상입니다. 우리는 CEO, 전화를받는 접수 원, IT 담당자가 있습니다. 우리는 이메일, 전화 또는 회의를 통해 고객과 직접 커뮤니케이션합니다. 우리의 주요 사업은 계약을 파기하지 않고 자체 제품을 만들어 판매하는 것입니다. 그러나 계약도 있습니다.

나는 그것에 대해 더 많이 생각했고 이것이 내가 생각하는 이유입니다.
1. 우리는 주로 다른 사람을 만드는 것이 아니라 우리 자신의 제품을 만듭니다.
2. 우리는 감독없이 독립적 인 일 윤리를 유지합니다.
3. 우리는 도메인 지식이 있습니다.
4. 행운. 함께 일하고 함께 일하는 소수의 사람들.

누군가 밸브 회사도 관리가 없다고 언급했습니다. Valve는 다른 사람을 만드는 대신 자신의 제품을 만듭니다. 제품 회사가 자체 관리에 더 적합하다고 생각합니다. 당신이 클라이언트이기 때문에 클라이언트가 기대하는 것과 다른 경로를 따라갈 위험은 없습니다. 게임 회사에서는 특히 그렇습니다. 게임을 재미있게 만드십시오.

당신은 재미로가는 길을 관리 할 수 ​​없습니다. 독창적 인 예술 작품으로가는 길을 관리 할 수 ​​없습니다.