스크럼 마스터 면접 질문: 최종 준비 가이드
애자일 프레임워크를 사용하는 조직은 전통적인 프로젝트 관리 접근 방식에 비해 시장 출시 시간이 60% 빠르고 생산성이 25% 높다고 제17차 State of Agile Report에서 보고하고 있습니다 [1]. 스크럼 마스터는 이 변혁의 중심에 있습니다 — 단순히 이름이 바뀐 프로젝트 매니저가 아니라, 고성과 팀을 가능하게 하는 서번트 리더로서입니다. 스크럼 마스터 후보자를 평가하는 면접관들은 특정한 조합을 찾습니다: 깊은 프레임워크 지식, 코칭 본능, 갈등 해결 능력, 그리고 팀의 의존성을 만들지 않으면서 팀을 보호하는 능력입니다.
이 가이드는 네 가지 범주 — 프레임워크와 프로세스 지식, 행동과 리더십, 상황과 시나리오, 그리고 고급 애자일 개념 — 에 걸쳐 가장 자주 출제되는 스크럼 마스터 면접 질문을 상세한 답변 프레임워크와 면접관이 실제로 평가하는 내용과 함께 다룹니다.
핵심 요약
- 스크럼 마스터 면접은 스크럼 이론에 대한 이해뿐 아니라 복잡한 현실 상황에서 이를 적용하는 능력을 시험합니다
- 프로세스 강제자인지 진정한 서번트 리더인지를 확인하는 질문이 출제될 것을 예상하십시오
- 행동 질문은 코칭 능력, 갈등 해결, 이해관계자 관리를 평가합니다
- 팀 벨로시티를 향상시키고, 장애물을 제거하고, 조직 변화를 촉진한 구체적인 사례를 준비하십시오
- 스케일링 프레임워크(SAFe, LeSS, Nexus)에 대한 지식이 점점 더 기대되고 있습니다
프레임워크와 프로세스 지식 질문
1. 스크럼에서 경험적 프로세스 제어의 세 가지 기둥은 무엇이며, 실제로 어떻게 적용합니까?
면접관이 찾는 것: 스크럼이 세레모니가 아닌 경험주의에 근거하고 있음을 이해하는 것.
답변 프레임워크: 세 가지 기둥은 투명성, 검사, 적응입니다 [2]. 투명성은 작업 상태를 가시화하는 것입니다 — 스프린트 백로그와 번다운 차트뿐만 아니라 데일리 스크럼에서 팀원들이 상태 보고 대신 차단 요소를 제기하는 솔직한 대화를 통해서입니다. 검사는 산출물과 진행 상황을 정기적으로 검토하는 것입니다 — 스프린트 리뷰는 제품 증분의 검사이고, 레트로스펙티브는 프로세스의 검사입니다. 적응은 배운 것에 따라 조정하는 것입니다 — 여기서 많은 팀이 실패하며, 레트로스펙티브 액션 아이템을 약속이 아닌 제안으로 취급합니다. 구체적인 예를 제시하십시오: "테스팅이 병목이었던 3개 스프린트 후, 개발 시작 전에 테스트 케이스를 요구하는 '테스트 우선' Definition of Done을 도입하여 적응했습니다. 다음 분기에 결함 유출률이 40% 감소했습니다."
2. 스크럼 마스터 역할을 프로젝트 매니저와 어떻게 구분합니까?
면접관이 찾는 것: 이것이 단순히 다른 직함이 아니라 근본적으로 다른 역할이라는 명확한 이해.
답변 프레임워크: 프로젝트 매니저는 계획을 소유하고, 작업을 할당하고, 진행 상황을 추적하며, 납품에 책임집니다. 스크럼 마스터는 프로세스를 소유하고, 팀의 자기 관리를 코칭하며, 장애물을 제거하고, 팀 효과성에 책임집니다 [3]. 스크럼 마스터는 작업을 할당하지 않습니다 — 개발 팀이 스프린트 백로그에서 작업을 가져옵니다. 스크럼 마스터는 경영진을 위한 상태 보고서를 만들지 않습니다 — 팀의 산출물(스프린트 백로그, 증분, 번다운)이 투명성을 제공합니다. 프로젝트 매니저가 "기한을 맞추려면 인력을 추가해야 합니다"라고 말하는 반면, 스크럼 마스터는 "벨로시티가 떨어진 이유를 조사하고 근본 원인을 해결합시다"라고 말할 수 있습니다. 많은 조직이 스크럼 마스터를 애자일 프로젝트 매니저로 잘못 채용하며, 역할의 일부는 리더십에 이 차이를 교육하는 것임을 강조하십시오.
3. Definition of Done은 무엇이며, 왜 중요합니까?
면접관이 찾는 것: DoD를 속일 수 있는 체크리스트가 아닌 품질 약속으로 보는 것.
답변 프레임워크: Definition of Done은 모든 제품 백로그 항목에 대해 "완료"가 의미하는 바에 대한 팀의 공유된 이해입니다. 일반적으로 코드 리뷰 완료, 최소 커버리지 임계값의 단위 테스트 통과, 통합 테스트 통과, 문서 업데이트, 성능 벤치마크 충족, 스테이징에 배포 완료 등의 기준이 포함됩니다 [4]. DoD가 중요한 이유는 이것이 없으면 "완료"가 주관적이기 때문입니다 — 한 개발자의 "완료"는 "내 컴퓨터에서 작동한다"일 수 있고 다른 개발자의 "완료"는 "프로덕션 준비 완료"를 의미할 수 있습니다. 약한 DoD는 기술 부채로 축적되는 미완료 작업을 만들어, 팀이 부분적으로 완료된 작업을 세기 때문에 벨로시티 지표를 무의미하게 만듭니다. 팀의 DoD를 시간에 걸쳐 어떻게 발전시켰는지 공유하십시오: "합류했을 때 DoD는 3개 항목이었습니다. 6개월에 걸쳐 점진적으로 12개 기준으로 강화했으며, 초기에 벨로시티가 20% 감소했지만 회귀 버그 문제를 완전히 해결했습니다."
4. 팀이 지속적으로 과다 약속하는 경우 스프린트 플래닝을 어떻게 처리합니까?
면접관이 찾는 것: 제약을 부과하지 않고 팀의 주인의식을 구축하는 코칭 접근법.
답변 프레임워크: 먼저 과다 약속이 발생하는 이유를 진단합니다 — 이해관계자의 외부 압력인지, 팀 내부의 낙관주의 편향인지, 잘못된 추정 관행인지? 그런 다음 근본 원인을 해결합니다. 팀이 압력에 반응하고 있다면, 제품 소유자와 지속 가능한 속도와 미완료 작업이 이월될 때의 컨텍스트 스위칭 비용에 대한 대화를 촉진하십시오 [5]. 추정이 문제라면 스토리 포인트 보정 세션, 참조 스토리, 또는 과거 벨로시티를 가드레일로 한 플래닝 포커와 같은 기법을 도입하십시오. 핵심 코칭 동작은 패턴을 가시화하는 것입니다: "스프린트별 약속 대 완료를 간단한 차트로 추적하기 시작했습니다. 3개 스프린트 후 팀은 스스로 패턴을 볼 수 있었고 자기 수정을 시작했습니다. 스프린트 약속을 15% 줄이고 계획된 작업의 95%를 완료하기 시작했으며, 이는 실제로 총 처리량을 증가시켰습니다."
5. 각 스크럼 이벤트의 목적과 생략했을 때 어떤 일이 일어나는지 설명하십시오.
면접관이 찾는 것: 각 이벤트를 필수 회의가 아닌 고유한 기여로 이해하는 것.
답변 프레임워크: 스프린트 플래닝은 스프린트 목표와 분해 전략에 대해 팀을 정렬합니다 — 생략하면 팀은 통합적 목표 없이 개별 항목에 작업하여 협업이 감소합니다. 데일리 스크럼은 스프린트 내에서 스프린트 계획의 검사와 적응을 가능하게 합니다 — 생략하면 장애물이 방치되고 작업이 중복되며 동기화가 무너집니다. 스프린트 리뷰는 이해관계자와 함께 증분을 검사합니다 — 생략하면 피드백 루프가 끊어져 제품이 사용자 요구에서 벗어납니다. 스프린트 레트로스펙티브는 팀의 프로세스를 검사합니다 — 생략하면 개선이 정체되고 불만이 쌓이며 팀이 정체됩니다 [6]. 스프린트 자체는 컨테이너 이벤트이며 다른 모든 이벤트는 스프린트 목표를 지원하기 위해 존재한다는 점에 유의하십시오. "레트로스펙티브가 '시간 낭비 같다'고 해서 중단한 팀을 본 적이 있습니다. 3개 스프린트 만에 간헐적 CI 장애와 같은 반복적 문제가 제기되지도 해결되지도 않아 사이클 타임이 2배가 되었습니다."
행동과 리더십 질문
6. 개발 팀 내의 갈등을 해결한 경험에 대해 말씀해 주십시오.
면접관이 찾는 것: 중재 능력, 감정적 지능, 그리고 갈등을 다루는지 회피하는지.
답변 프레임워크: 퍼실리테이션 접근법에 중점을 두고 STAR 기법을 사용하십시오. 단순한 기술적 이견이 아닌 진정한 대인 갈등을 선택하십시오. 두 명의 시니어 엔지니어가 상충하는 아키텍처 철학으로 인해 소극적 공격적 코드 리뷰와 풀 리퀘스트 차단을 일으킨 경우를 들 수 있습니다. (1) 리뷰 지표와 팀 사기 신호를 통해 패턴을 관찰하고, (2) 개별 대화로 각 사람의 관점과 근본적인 우려를 이해하고, (3) 객관적 평가 기준으로 양측이 자신의 접근법을 발표할 수 있는 구조화된 세션을 퍼실리테이트하고, (4) 팀이 재사용 가능한 의사결정 프레임워크에 도달하도록 안내한 방법을 설명하십시오. 영향을 정량화하십시오: "머지 리퀘스트 사이클 타임이 4.2일에서 1.8일로 감소했고, 두 엔지니어는 결국 팀 아키텍처 결정 기록 프로세스를 공동 작성했습니다."
7. 모호한 사용자 스토리를 작성하는 제품 소유자를 어떻게 코칭합니까?
면접관이 찾는 것: 코칭 능력과 권한 없이 영향력을 행사하는 능력.
답변 프레임워크: 스토리를 직접 다시 쓰려는 유혹을 피하십시오 — 그것은 의존성을 만듭니다. 대신 백로그 리파인먼트 중에 소크라테스식 질문을 사용하십시오: "사용자는 어떤 문제를 해결하려 합니까? 이것이 완료되었음을 어떻게 알 수 있습니까? 가치를 전달하는 가장 작은 버전은 무엇입니까?" [7]. INVEST 기준(Independent, Negotiable, Valuable, Estimable, Small, Testable)을 판단 도구가 아닌 공유 언어로 도입하십시오. 작업을 수행하기 위해서가 아니라 사고 과정을 모델링하기 위해 몇 차례 세션 동안 제품 소유자와 페어로 스토리를 작성할 것을 제안하십시오. "'대시보드 개선'과 같은 스토리를 쓰는 PO와 함께 일했습니다. 리파인먼트 퍼실리테이션을 통해 명확한 인수 기준이 있는 6개의 구체적 스토리로 분해했습니다. 한 달 만에 PO는 그 수준에서 독립적으로 작성하게 되었습니다."
8. 스프린트 중에 외부 간섭으로부터 팀을 보호해야 했던 경험을 설명하십시오.
면접관이 찾는 것: 서번트 리더십의 실천 — 이해관계자 관계를 유지하면서 팀을 보호하는 것.
답변 프레임워크: 이것은 스크럼 마스터의 전형적인 책임입니다. 이해관계자 — 아마도 VP나 영업 리더 — 가 스프린트 중간에 긴급 작업을 추가하려 한 상황을 설명하십시오. (1) 긴급성을 인정하고, (2) 중단 비용(컨텍스트 스위칭 부담, 스프린트 목표 실패 가능성)을 설명하고, (3) 대안을 제시하고(다음 스프린트까지 기다릴 수 있는지? 동일 크기의 항목을 교환할 수 있는지?), (4) 직접 결정하지 않고 제품 소유자에게 우선순위 결정을 에스컬레이션한 방법을 설명하십시오 [8]. "영업 담당 VP가 이사회 프레젠테이션을 위한 대시보드 변경을 스프린트 중에 강행하려 했습니다. 일방적 거부 대신, VP와 제품 소유자 간의 15분 대화를 퍼실리테이트하여 트레이드오프를 논의했습니다. 수동 데이터 내보내기를 임시 방편으로 합의하고, 대시보드 변경은 다음 스프린트로 우선순위가 매겨졌습니다."
9. 스크럼 마스터로서의 효과성을 어떻게 측정합니까?
면접관이 찾는 것: 자기 인식과 허영 지표를 넘어선 성과 지향적 사고.
답변 프레임워크: 팀의 산출물이 아닌 스크럼 마스터의 효과성을 반영하는 지표에 집중하십시오: (1) 팀 안정성과 참여도 — 사람들이 남아 있는지, 레트로스펙티브 참여율이 높은지, (2) 프로세스 개선 속도 — 팀이 얼마나 빨리 장애물을 식별하고 해결하는지, (3) 스프린트 목표 달성률 — 스토리 완료가 아닌 목표 달성, (4) 이해관계자 만족도 추세, (5) 팀의 성장하는 자립성 — 훌륭한 스크럼 마스터는 일상적인 퍼실리테이션에서 점차 덜 필요해져야 합니다 [9]. "저는 '코칭 졸업률'이라고 부르는 것을 추적합니다 — 팀이 제 개입 없이 해결하는 장애물의 비율입니다. 시작했을 때는 30%였습니다. 1년 후에는 75%였습니다. 이는 의존성이 아닌 역량을 구축하고 있음을 보여줍니다."
상황과 시나리오 기반 질문
10. 개발자가 비공개로 테크 리드가 팀과 상의 없이 일방적 기술 결정을 내리고 있다고 생각한다고 말합니다. 어떻게 대처합니까?
면접관이 찾는 것: 위계를 탐색하고, 비밀을 유지하고, 시스템적 문제를 해결하는 능력.
답변 프레임워크: 먼저 개발자가 우려를 제기해 준 것에 감사하고, 그에게 귀속시키지 않고 패턴을 해결할 것임을 보장하십시오. 그런 다음 관찰하십시오 — 기술 논의에 참석하고, 결정이 어떻게 문서화되는지 확인하고, 패턴의 증거를 찾으십시오. 확인되면 레트로스펙티브에서 프로세스 관찰로 제기하십시오: "일부 기술 결정이 팀 논의 외부에서 내려지고 있음을 알게 되었습니다. 모든 사람의 의견이 포함되는 프로세스를 어떻게 만들 수 있을까요?" [10]. 패턴이 지속되면 테크 리드와 자기 조직화 원칙에 대한 비공개 코칭 대화를 하십시오. 목표는 권위를 처벌하는 것이 아니라 협력적 의사결정 구조를 만드는 것입니다.
11. 팀의 벨로시티가 최근 3개 스프린트에서 30% 하락했습니다. 어떤 조치를 취합니까?
면접관이 찾는 것: 반응적 개입이 아닌 진단적 사고.
답변 프레임워크: 벨로시티 하락에는 많은 잠재적 원인이 있습니다 — 성급한 결론을 내리지 마십시오. 체계적으로 조사하십시오: (1) 외부 요인 확인 — 팀원 이탈, 프로덕션 지원 부하 증가, 환경 불안정, 조직적 방해. (2) 작업 자체 검토 — 복잡성이 증가했는가? 최근 스토리가 과소 추정되었는가? 기술 부채가 개발을 지연시키고 있는가? (3) 팀 역학 검토 — 미해결 갈등, 번아웃, 참여도 저하가 있는가? (4) 프로세스 변경 검토 — 새로운 도구, 정책, 의존성이 도입되었는가? 조사 데이터로 보완하면서 레트로스펙티브를 통해 팀 자체의 진단을 이끌어내십시오. "팀이 벨로시티 하락을 경험했을 때, 데이터는 최근 인프라 변경으로 프로덕션 인시던트가 3배로 증가했음을 보여주었습니다. DevOps 팀과 협력하여 환경을 안정화한 결과, 벨로시티는 2개 스프린트 내에 회복되었습니다."
12. 비즈니스 우선순위가 극적으로 변했기 때문에 제품 소유자가 스프린트를 취소하고 싶어 합니다. 어떻게 합니까?
면접관이 찾는 것: 스프린트 취소가 적절한 시기와 해당 결정에서 스크럼 마스터의 역할에 대한 이해.
답변 프레임워크: 스크럼 가이드에 따르면, 제품 소유자만이 스프린트를 취소할 수 있으며, 스프린트 목표가 무용해졌을 때 이루어져야 합니다 [11]. 귀하의 역할은 결정이 충분한 정보에 기반하고 프로세스가 준수되도록 보장하는 것입니다. 대화를 퍼실리테이트하십시오: 구체적으로 무엇이 변했는가? 현재 스프린트 목표가 정말로 무용해졌는가, 아니면 적응할 수 있는가? 취소 비용은 무엇인가(완료된 작업 검토, 재계획 노력, 팀 사기에 대한 영향)? 취소가 진행되면 완료된 작업의 검토를 퍼실리테이트한 다음 새로운 스프린트를 위한 스프린트 플래닝을 실시하십시오. "경력에서 1회의 스프린트 취소를 경험했습니다. 규제 변경이 스프린트 목표를 완전히 무효화했습니다. 완료된 작업의 미니 리뷰를 실시하고, 축약된 스프린트 플래닝을 진행했으며, 팀은 가치 없는 작업을 계속하도록 강요받는 것이 아니라 결정의 투명성을 높이 평가했습니다."
13. 3개 팀의 스크럼 마스터를 동시에 담당하고 있습니다. 시간과 관심을 어떻게 관리합니까?
면접관이 찾는 것: 실용적인 멀티 팀 퍼실리테이션 전략과 우선순위 설정.
답변 프레임워크: 도전을 인정하십시오 — 스크럼 가이드는 1팀을 권장하지만, 조직의 현실은 종종 다릅니다 [12]. 전략을 설명하십시오: (1) 세레모니가 겹치지 않도록 스프린트 주기를 엇갈리게 하고, (2) 각 팀 내에서 데일리 스크럼과 일부 리파인먼트 세션을 독립적으로 운영할 수 있는 퍼실리테이션 리더를 육성하고, (3) 가장 시급한 장애물이 있거나 애자일 성숙도가 가장 낮은 팀에 시간을 우선 배분하고, (4) 공유된 레트로스펙티브 테마를 활용하여 팀 간 시스템적 문제를 식별하고, (5) 팀이 매일 귀하의 가용 시간을 기다리지 않고 비동기적으로 장애물을 보고할 수 있는 명확한 커뮤니케이션 채널을 설정합니다. "주간 일정을 타임박스로 구성했습니다: 월요일과 목요일은 팀 A의 세레모니에, 화요일과 금요일은 팀 B에 할당하고, 팀 C와는 주간 로테이션을 했습니다. 세 팀 모두 데일리 스탠드업을 위한 훈련된 퍼실리테이터가 있었습니다."
고급 애자일 개념 질문
14. 조직의 워터폴에서 스크럼으로의 전환을 어떻게 퍼실리테이트하겠습니까?
면접관이 찾는 것: 변화 관리 역량과 애자일 변혁에 대한 현실적 기대.
답변 프레임워크: 파일럿으로 시작하십시오 — 이해관계자의 지지와 적절한 복잡성을 가진 팀과 프로젝트를 선택하십시오. 빅뱅 변혁을 시도하지 마십시오. 파일럿 팀에 대해: (1) 팀과 주요 이해관계자에게 스크럼 교육을 제공하고, (2) 모든 이벤트와 산출물을 포함한 스크럼 프레임워크를 확립하고, (3) 현실적 기대를 설정하고 — 처음 몇 개 스프린트는 혼란스러울 것이며, (4) 변화에 저항하는 조직의 항체로부터 파일럿을 보호하십시오 [13]. 결과를 보여줌으로써 확대하십시오: 파일럿 팀이 향상된 납품 예측 가능성과 이해관계자 만족도를 보이면, 다른 팀들이 강제되지 않고 자발적으로 프레임워크를 채택하려 할 것입니다. 조직적 장애물을 해결하십시오: 포트폴리오 계획 프로세스, 자금 모델, 성과 평가 시스템, 거버넌스 구조 모두가 애자일 팀을 지원하도록 적응해야 합니다.
15. SAFe, LeSS, Nexus와 같은 스케일링 프레임워크에 대한 경험은? 각각의 트레이드오프는 무엇입니까?
면접관이 찾는 것: 폭넓은 지식과 의견이 있되 정보에 기반한 관점.
답변 프레임워크: SAFe(Scaled Agile Framework)는 대기업을 위한 포괄적 구조를 제공하지만 무겁고 규범적으로 느껴질 수 있습니다 — 비평가들은 문화적 변화 없이 구현되면 "애자일 옷을 입은 워터폴"이라고 부릅니다 [14]. LeSS(Large-Scale Scrum)는 최소한의 추가 구조로 스크럼 원칙에 더 가깝게 유지되지만, 강한 조직적 헌신과 상당한 구조조정이 필요합니다. Nexus는 단일 제품에 작업하는 3~9개 스크럼 팀에 특화되어 Nexus Integration Team과 공유 Definition of Done을 추가합니다 [15]. 실제 경험을 공유하십시오: 어떤 프레임워크를 사용했는지, 무엇이 효과가 있었는지, 무엇을 다르게 하겠는지. 최선의 답변은 어떤 프레임워크도 만능이 아님을 인정합니다 — 조직의 문화, 규모, 제품 아키텍처가 어떤 스케일링 접근법이 적합한지 결정합니다.
16. 스크럼 프레임워크 내에서 기술 부채를 어떻게 다룹니까?
면접관이 찾는 것: 납품 압력과 장기적 지속 가능성 사이의 균형.
답변 프레임워크: 기술 부채는 숨기지 않고 가시화해야 합니다. 제품 백로그에서 일급 시민으로 만들어 영향을 정량화하십시오 — "인증 모듈 리팩토링"이 아니라 "인증 모듈은 평균 3배의 버그율이 있으며 사용자 관리에 관련된 모든 기능에 2일을 추가한다" [16]. 제품 소유자와 지속 가능한 할당을 협상하십시오 — 많은 팀이 스프린트 용량의 20%를 기술 부채와 플랫폼 개선에 할당하는 "20% 규칙"을 사용합니다. Definition of Done을 강화하여 새로운 부채 축적을 방지하십시오. 레트로스펙티브를 활용하여 팀을 늦추고 있는 부채를 표면화하십시오. "'기술 건강' 지표를 도입했습니다 — 스프린트당 기능 대 버그 수정 및 유지보수 작업의 비율입니다. 60/40 이하로 떨어지면 부채 감소 할당을 늘리는 신호로 취급했습니다."
17. 팀원이 더 이상 레트로스펙티브의 가치를 모르겠다고 합니다. 어떻게 대응합니까?
면접관이 찾는 것: 퍼실리테이션의 창의성과 정체된 프로세스를 활성화하는 능력.
답변 프레임워크: 피드백을 진지하게 받아들이십시오 — 레트로스펙티브가 무의미하게 느껴진다면, 문제는 보통 진부해진 퍼실리테이션, 미해결 액션 아이템, 또는 둘 다입니다. 먼저 진단하십시오: 이전 레트로스펙티브의 액션 아이템이 추적되고 완료되고 있습니까? 그렇지 않다면 그것이 근본 원인입니다 — 팀은 레트로스펙티브가 변화로 이어지지 않는다고 학습해 버렸습니다. 퍼실리테이션이 진부해졌다면 다양성을 도입하십시오: "범선"(바람, 닻, 바위, 섬), "시작/중지/계속", "타임라인", 또는 협업, 도구, 기술적 관행과 같은 특정 측면에 초점을 맞춘 테마별 레트로스펙티브와 같은 형식을 시도하십시오 [17]. 참여도가 낮은 팀원에게 다음 레트로스펙티브의 공동 퍼실리테이션을 요청하십시오 — 주인의식이 참여를 만듭니다. "팀원이 레트로스펙티브가 '그냥 불평 시간'이라고 했습니다. 두 가지 변경을 시행했습니다: 액션 아이템에 담당자와 기한을 정하여 보드에서 추적하고, 퍼실리테이션을 로테이션으로 전환했습니다. 2개 스프린트 만에 불평했던 팀원이 가장 활발한 레트로스펙티브 참여자 중 한 명이 되었습니다."
면접관에게 할 질문
사려 깊은 질문은 깊이와 진정한 관심을 보여줍니다:
- "몇 개의 스크럼 팀을 지원하게 됩니까? 현재 성숙도 수준은 어떻습니까?" — 역할의 범위와 도전을 평가하는 데 도움이 됩니다.
- "스크럼 마스터 역할 외에 애자일 코칭 지원은 어떤 형태입니까? 애자일 센터 오브 엑셀런스나 코칭 팀이 있습니까?" — 조직적 지원 구조에 대해 생각하고 있음을 보여줍니다.
- "팀이 팀 수준에서 해결할 수 없는 가장 큰 장애물은 무엇입니까?" — 첫 대화부터 서번트 리더십 지향을 보여줍니다.
- "리더십은 스크럼 마스터 역할을 어떻게 봅니까 — 퍼실리테이터, 코치, 아니면 프로젝트 조정자?" — 조직이 정말로 스크럼 마스터를 원하는지 이름만 바꾼 PM을 원하는지 이해하는 데 도움이 됩니다.
준비 체크리스트
- 스크럼 가이드를 다시 읽으십시오. 2020년 버전은 13페이지입니다. 철저히 숙지하십시오 — 면접관은 프레임워크가 실제로 무엇을 말하는지와 일반적인 오해를 구분할 수 있는지 시험할 것입니다 [18].
- 3개의 강력한 STAR 스토리를 준비하십시오. 갈등 해결 1개, 장애물 제거 1개, 팀의 성과 향상 코칭 1개. 각각 정량화된 결과가 있어야 합니다.
- 지표를 파악하십시오. 코칭한 팀의 구체적인 벨로시티 추세, 스프린트 목표 달성률, 개선 지표에 대해 논의할 준비를 하십시오.
- 시나리오 질문을 소리 내어 연습하십시오. 상황 질문은 즉석에서 생각할 것을 요구합니다 — 진단 접근법을 연습하면 자연스럽게 느껴집니다.
- 회사의 애자일 성숙도를 조사하십시오. 채용 공고, 엔지니어링 블로그, Glassdoor 리뷰에서 애자일 문화의 신호를 확인하십시오.
참고 문헌
[1] Digital.ai, "17th Annual State of Agile Report," Digital.ai, 2023. [2] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020. [3] Scrum Alliance, "Scrum Master vs. Project Manager," Scrum Alliance Resources, 2024. [4] Scrum.org, "Definition of Done," Scrum.org Professional Resources, 2024. [5] Rubin, K., "Essential Scrum: A Practical Guide to the Most Popular Agile Process," Addison-Wesley, 2012. [6] Schwaber, K. & Sutherland, J., "The Scrum Guide — Scrum Events," ScrumGuides.org, 2020. [7] Cohn, M., "User Stories Applied: For Agile Software Development," Addison-Wesley, 2004. [8] Adkins, L., "Coaching Agile Teams," Addison-Wesley Professional, 2010. [9] Scrum.org, "Evidence-Based Management Guide," Scrum.org, 2024. [10] Derby, E. & Larsen, D., "Agile Retrospectives: Making Good Teams Great," Pragmatic Bookshelf, 2006. [11] Schwaber, K. & Sutherland, J., "The Scrum Guide — Sprint Cancellation," ScrumGuides.org, 2020. [12] Scrum.org, "Scrum Master Focus Areas," Scrum.org Professional Resources, 2024. [13] Kotter, J., "Leading Change," Harvard Business Review Press, 2012. [14] Scaled Agile, Inc., "SAFe 6.0 Framework," ScaledAgileFramework.com, 2024. [15] Scrum.org, "The Nexus Guide," Scrum.org, 2021. [16] Fowler, M., "Technical Debt," MartinFowler.com, 2019. [17] Retromat, "Retrospective Activities," Retromat.org, 2024. [18] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020.
