비생산적인 스크럼 팀을 어떻게 처리합니까?

Backstory :
저는 지난 3 년 동안이 팀의 일원으로 일해 왔으며, 이번에는 모든 것을 다르게 운영하는 세 가지 다른 Scrum Master가있었습니다.

Scrum Masters의 이러한 변화와 쇼를 운영하는 방식으로 인해 원칙이 일관되게 시행되지 않았고 Scrum Masters 중 하나가 민첩성을 믿지 않는 사람이기 때문에 팀이 Scrum에 대한 생각을 마비 시켰습니다. 회사의 의사 결정을 준수하기 위해 초보자로서 이벤트와 유물을 개발했습니다.

스크럼 이벤트를 할 때 팀원들은 짜증이 나고 지루하며 특히 한 사람이 이것에 대해 매우 구두로 말합니다.

현재 :
2 개월 전에 회사는 민첩성 및 그 원칙에 대한 헌신으로 인해 팀의 스크럼 마스터를 임명했습니다.

나는 팀원들이 스크럼을 원하지 않는 대기압으로 인해 크게 고통 받고 있습니다.

언급했듯이 그들은 전체 프로세스에 대해 화가 났으므로 계획, 회고 및 일일 스크럼을 효과적으로 만드는 데 필요한 대화에 참여하지 않기 때문에 매우 어려워졌습니다.

그들에게 계획은 시간 낭비 일뿐입니다. 우리는 새로운 스프린트로 오버플로를 옮기고 어쨌든 작업을 완료하지 않기 때문에 귀찮게합니다.

회고하는 동안 나는 그들이 "스크럼 중지"라고 말하고 싶다고 느낄 수 있습니다. 한 사람은하지만 다른 사람은 조용하고 매번이 문제를 처리해야합니다.

데일리 스크럼은 다시 말하고 계획하지 않아도되기 때문에 시간 낭비입니다. 그들은 "어제 작업 X에서 작업했으며 오늘 다시 작업 할 것"이라고 말합니다. 그리고 대부분의 시간은 내가 더 선미를 얻을 때까지 농담을합니다.

나는 그들이이 사건들 동안 그들의 시간을 어떻게 보냈는지에 관해 매우 컸다. 그러나 나는 이것에 대한 열정이 있고 더 이상 신경 쓰지 않기 때문에 내부에서 죽어 가고 있습니다.

오늘 날 항상 반대하는 사람은 나에게 "그들이이 스프린트를 위해 최선을 다했다"고 말하지 말라고 말했다. 다음 스프린트는 할당량을 채 웁니다. 우리는 실제로 KanBan을합니다.

나는 그가 왜 이런 말을하는지 이해하지만, 이것이 팀원과 그 밖의 모든 사람들이 관심을 갖지 않기 때문에 이것이 어떻게되는지 깨닫지 못하는 것 같습니다. 그들은 단지 장애를 다루는 대신 일을합니다. 그들은 장애에 대해 불평하지만 그들에 대해서는 아무 것도하지 않습니다. 내가 도와 주려고하면 그냥 으 rug 거립니다.

그들은 지독한 일을했지만 지난 2 년 동안 그들의 의지는 거의 바닥으로 떨어졌습니다.

이 회의에서 농담을하고 시간을 낭비하면 회사에 많은 비용이 든다는 것을 어떻게 알 수 있습니까?

실패한 소프트웨어 프로젝트에 대한 많은 통계를 듣고 실패가 기술적 인 것이 아니라는 결론에 도달했습니다. 수백 가지 기술 솔루션을 통해 기술 문제를 해결할 수 있지만 Scrum을 사용하여 작업장 분위기의 문제를 해결하는 것은 효과가 없습니다.

나의 제안은 이것을 기술적 인 문제로 보는 것을 완전히 멈추는 것입니다. 스크럼에 관한 것이 아니라 매일 스탠드 업, 스프린트, 회고 또는 그와 비슷한 것이 아닙니다. 팀과 연락을 취하고 자신과 상사뿐만 아니라 팀을 만족시키는 효과적인 작업 방법을 찾아야합니다.

그들이 데일리가 나쁜 생각이라고 생각하면 데일리를하라고 말하지 말고 추론을하도록 노력하십시오. 데일리가 당신에게 제공하는 것이 무엇인지 스스로 생각하십시오. 팀이 이러한 장점을 중시하는지 여부를 확인하십시오. 그들이 자신의 견해를 이해하고 설득하는 것이 아니라 자신의 견해를 이해하지 못하는 이유를 알아보십시오. 그런 다음 데일리가 실제로 팀에 도움이되는지 또는 다른 메커니즘으로 더 많은 것을 달성 할 수 있는지 확인하십시오. 스크럼 마스터에 대한 재미있는 점은 그들이 팀의 종이라는 것입니다. 스크럼을 완전히 폐지하여 가장 잘 봉사 할 수 있습니다.

요약하면 Scrum에 집중하지 말고 민첩성의 기본 사항으로 돌아가십시오. 애자일 매니페스트로 시작하는 것이 좋을 것입니다 . 프로세스와 도구에 대한 개인 및 상호 작용에 가치를 둡니다 .

내 경험상 환멸에 빠진 팀은 효과적인 회고를 시작해야합니다. 이것이 제 생각에는 회고가 민첩한 프로세스의 유일한 필수 부분 인 이유입니다. 그 밖의 모든 사항은 회고를 통해 변경 될 수 있습니다.

효과적인 회고에서는 단지 문제에 대해 불평하는 것이 아니라 그 문제 중 하나 이상을 선택하고 가능한 해결책을 찾은 다음 다음 반복에서 그 해결책을 시도하십시오. 다음 회고에서는 해당 솔루션의 작동 방식에 대해 이야기하고 필요한 경우 추가 조정을 수행하거나 다른 문제를 선택하십시오.

팀원들이 프로세스의 실제 변화에 영향을 줄 수있는 힘이 있음을 알게되면 더 기꺼이 참여하게됩니다.

회고 과정은 민첩한 회사의 모든 팀을 방문하면 모두 다르게 수행하는 이유입니다. 우리는 Kanban을 수행하는 팀과 XP를 수행하는 팀, 월요일 수요일 금요일에 스탠드 업 만하는 팀을 보유하고 있습니다.

팀이 숙취를 다루는 방식이 마음에 들지 않으면 다른 접근 방식을 브레인 스토밍하십시오. 나는 회고를 끊임없이 듣고 해결책을 시도함으로써 매우 꺼려하는 개발자 들을 이겼습니다 .

좋아, 시작하자-문제의 큰 부분은 당신과 함께-당신은 들리지만, 당신은 듣지 않습니다. 팀에서 문제가 무엇인지 명확하게 알려줍니다. 팀을 비난하지 말고 해결해야합니다.

계획

그들에게 계획은 시간 낭비 일뿐입니다. 우리는 새로운 스프린트로 오버플로를 옮기고 어쨌든 작업을 완료하지 않기 때문에 귀찮게합니다.

바로 그거죠. 작업에 올바른 시간을 할당하지 못하고 일관되게 과소 평가되는 경우 다음과 같은 부정적인 영향을 미칩니다.

• 개발자는 끊임없이 압박을 받고있는 것 같습니다.
• "시간 내에 아무것도 할 수 없습니다".
• 프로세스가 작동하지 않기 때문에 프로세스를 시간 낭비로 간주합니다.

솔루션 : 다음 조합을 사용하여 추정값을 수정하십시오.

• 스토리 포인트 (시간과 위험의 조합).
• 55 SP보다 큰 스프린트에 작업을 허용하지 마십시오
• 비교 추정
• 증거 기반 일정

이를위한 기초로서, 테스트, 문서 작성, 테스트 작성, 최종 사용자 교육, 통합 노력, 배포를 포함하여 이전 작업을 완료 하는 데 실제로 걸린 시간을 반드시 추적해야 합니다. 기타

주어진 작업에 대한 총 시간이 있으면 이전 작업을 기반으로 예상 시간을 지정할 수 있습니다.

모든 구성원에게 주어진 작업이 이전 작업을 선택하는 것보다 더 복잡하거나 쉬운 지 물어보고이를 기반으로 할당 된 작업 수를 조정하십시오.

SP를 사용해 본 적이 없다면, 나의 조언은 1H의 진정한 정직한 일부터 시작하는 것입니다. 일반적인 개발 환경에서는 하루에 6 개를 얻을 수 있으므로 30SP / day max가 됩니다. 보드에 타는 데 2 ​​일 이상 걸리는 작업을 절대로 허용하지 마십시오. 이상적으로는 내 경험상 하루에 2 개의 작업이 있어야합니다.

계획을 올바르게 수행하지 않으면 나머지 Scrum 활동은 계획을 포함하여 시간 낭비처럼 보입니다.

회고

회고하는 동안 나는 그들이 "스크럼 중지"라고 말하고 싶다고 느낄 수 있습니다. 한 사람은하지만 다른 사람은 조용하고 매번이 문제를 처리해야합니다.

생각 나는 Daily beatings will continue until morale improves!과거 작업의 두 가지. 장애를 제거하지 않으면 이것이 시간 낭비라는 것이 맞습니다.

사람들이 실제로 무엇을 말하는지 다시 들어보십시오. 소급 중 제기 된 불만 사항이 해결되지 않으면 왜 불만을 제기합니까?

그래서:

• 커뮤니케이션을 향상시키기 위해 Six Thinking Hats 기술을 고려하십시오.
• Retrospective에 소요되는 시간을 최대 30 분 줄입니다.
• 회고 중 제기 된 불만이 다음 문제보다 먼저 해결되도록하십시오.

일일 스크럼

데일리 스크럼은 다시 말하고 계획하지 않아도되기 때문에 시간 낭비입니다. 그들은 "어제 작업 X에서 작업했으며 오늘 다시 작업 할 것"이라고 말합니다. 그리고 대부분의 시간은 내가 더 선미를 얻을 때까지 농담을합니다.

두 가지 문제가있는 것 같습니다. 스크럼 회의가 너무 길고 계획 및 작업 생성이 짜증납니다.

스크럼 회의처럼 시간을 낭비하는 것처럼 소리를 낼 수 있습니다.

스크럼 길이의 경우 :

• 최대 15 분을 시도하십시오.
• 모두 서보세요.
• 고정식 :
  • 어제 뭐하고 있었어?
  • 오늘 무엇을 계획하고 있습니까?
  • 팀 구성원 (귀하가 아닌)이 작업에 대해 알아야 할 사항, 그 영향에 미치는 영향
• 당신이 그들을 해결하지 않을 경우 장애를 귀찮게하지 마십시오.

이것은 당신의 계획이 당신의 상황을 손상 시킨다는 두 번째 증거입니다. 만약 당신이보고 할 특정 내용이 없다면, 그것은 일반적으로 과제가 너무 커서 당신이 말할 수있는 모든 것이 : 나는 그 일을하고있었습니다.

• 작업을 글 머리 기호로 분류하십시오.
• 작업이 하루보다 적게 걸리도록 작게하십시오. 이상적으로, IMO 작업은 ~ 3 시간 지속되며 약 13SP에 해당하므로 대부분의 조건에서 하루에 2 번을 수행 할 수 있습니다.

팀 다루기

오늘 날 항상 반대하는 사람은 나에게 "그들이이 스프린트를 위해 최선을 다했다"고 말하지 말라고 말했다. 다음 스프린트는 할당량을 채 웁니다. 우리는 실제로 KanBan을합니다.

그가 맞아. 당신은 잘못. Kanban에서 나쁜 놈 및 / 또는 변형을하고 있습니다. 그들의 잘못이 아닙니다.

나는 그가 왜 이런 말을하는지 이해하지만, 이것이 팀원과 그 밖의 모든 사람들이 관심을 갖지 않기 때문에 이것이 어떻게되는지 깨닫지 못하는 것 같습니다.

나는 당신이 전혀 이해하지 못한다고 생각합니다. 그들은 예전보다 덜 돌 보았을지도 모르지만, 그들을 비난하는 것은 아무것도 개선하지 않을뿐만 아니라 상황을 악화시킬 수 있습니다. 바닥이지면 실제로 파기 시작할 수 있습니다.

그들은 단지 장애를 다루는 대신 일을합니다.

그리고 여기서 나는 일을하는 것이 그들의 일에 관한 것이라고 생각했습니다. 누가 장애를 다루어야했는지 궁금합니다. 스크럼 마스터. 그건 당신의 일. 그들은 무엇이 잘못되었는지 알려줍니다. 고치세요 다른 방법은 아닙니다.

이것이 아마도 회고전에서 많은 문제가있는 이유 일 것입니다.

이러한 회의에서 농담과 서클 저크가 회사에 많은 비용이 든다는 것을 어떻게 알 수 있습니까?

쓸모없는 만남을 멈 추면 대신 수 랭기 주변에서 농담을합니다. 또한 사기 개선을위한 구타에 관한 단락도 참조하십시오. 그들이 유머를 방어 메커니즘으로 사용하고 있다면 몇 가지 심각한 문제가 있습니다!

팀과 일할 때와는 달리 농담을하십시오. (후 푸욱이 회사의 돈을 걱정하는 사람은 누구입니까? 지금 주주입니까?)

요약

당신의 나쁜 계획은 스크럼의 다른 부분들과 실패한 사람들을 비참하게 만들고 있습니다. 그들은 변화가없고, 해결 된 것이 없으며, 불만이 듣지 않는 것을 본다.

계획을 개선하면 흐름과 사기를 향상시킬 수 있습니다.

장애를 제거하는 일을하면 팀이 더 빨리 발전 할 것입니다. 무엇을 물어 그들은 당신이 그들을 도와 줄한다고 생각한다.

가장 중요한 것은 : 사람들의 말을 잘 들으십시오. 그들은 이미 문제가 무엇인지 말해주었습니다.

행운을 빕니다!

주요 민첩한 원칙 중 하나는 돌아가서 잘못된 것을 정정하는 것입니다. 여기에는 코드 리팩토링 및 버그 수정뿐만 아니라 개발 프로세스 수정도 포함됩니다.

그렇다면 팀과 회의를하고 개발 프로세스를 어떻게 개선 할 수 있습니까? 즉, 스크럼이나 스탠드 업 회의가 없다는 의미입니다.

또한 민첩한 선언문 에서 "프로세스와 도구에 대한 개인과 상호 작용" 의 원칙 중 하나를 위반 하고 있습니다.

반면, 팀에서 반복 개발이 잘못되었다고 생각하면 잘못하고있는 것일 수 있습니다. 한 번의 반복에 대해 계획 한 모든 것을 마치지 않아도 상관 없습니다. 항상 다음 반복으로 물건을 옮길 수 있습니다. 그렇기 때문에 사물을 "포함해야 함", "좋은 것"등으로 표시하는 이유도 있습니다. 새로운 기능을 제공하는 한 잘하고 있습니다.

단지 작은 전리품 : 이전과 현재 회사에서 우리는 여전히 회의를하고 있습니다. 내 경험상, 그들은 30 분 이상 상태 보고서 회의로 바뀔 때마다 정보를 거의 또는 전혀 제공하지 않기 때문에 엄청난 시간 낭비입니다. 사람들은 자신의 문제에 대해 이야기하지만, 솔직히 신경 쓰지 않습니다.
저의 이전 회사에서는 똑똑했고,이 문제를 스탠드 업으로 인식하고 사람들이 불평을 시작하자마자 중단했습니다.

스크럼에 대한 훌륭한 비디오를보고 싶다면 " Robert C. Martin-스크럼이 잊어 버린 땅 "을 참조하십시오 .

우선 순위를 정하면서 계속해서 수행되는 작업을 살펴 ​​보겠습니다. 목표를 달성하지 못하는 것은 엄청나게 치명적입니다. 너무 많이 헌신하고 있습니까? 분류해야하는 로그가 있습니까? 컨트롤 외부에 병목 현상이 있습니까? "완료"에 대한 명확한 정의가 있습니까? 요구 사항이 명확합니까? 개발자 당 시간이 합리적입니까 (예 : 관리자, 스탠드 업, 계획, 회고, 키보드 나누기, 프로젝트 이외의 작업을 고려).

다음으로 작동하지 않는 것을 버립니다. 가치없는 프로세스는 시간 도둑 일뿐입니다. 스탠드 업은 초점이 맞지 않고 팀에 가치를 제공하지 않으면 막대한 시간을 소비 할 수 있습니다. 다른 곳에서 시간을 더 잘 보낼 수 있습니다. 팀이 너무 크면 팀을 나눌 수도 있습니다.

팀에게 동기를 부여하는 것에 대한 핸들을 얻으십시오. 회고하고 더 중요한 것은 결과물에 대해 행동하십시오. 성공을 축하하고 실패를 보는 것도 마찬가지로 중요합니다.

마지막으로, 누가 브랜드를 손상시킬 수 있었는지에 앞서 스크럼 마스터의 접근 방식을 평가할 수 있습니다. 나는 유독 한 스크럼 마스터 밑에서 일을 해왔는데, 그 전에 발생한 모든 문제가 당신이 알고 있든 없든 워크로드에 추가되었습니다. 최종 결과 : 문제는 무시되었고 모든 사람은 팀워크가 거의없이 작은 영역에서 작업했습니다.

스프린트를 통해 팀이 스프린트를 효과적으로 닫을 수있게하는 것 (최소한 스토리의 80 % 정도) 스프린트에 대한 스프린트는 당신이 할 수있는 가장 중요한 일이라고 생각합니다. 팀이 지속적으로 누락 된 경우 추정값을 조정해야한다는 것이 분명합니다.

팀은 이것을 수용해야하지만 개발자가 견적을보다 현실적으로 이해하기는 매우 어려울 수 있습니다. 스프린트를 1 년 동안 닫지 않은 팀에서 일했습니다 (일관된 스프린트의 50 % 미만) , 항상 추정하고 모든 계획 / 회고에서 나는 그들에게 당신의 견적이 짜증나고, 당신이 어리석게 지나치게 자신감을 가지고, 당신이 견적을하지 못하게 한 것에 대한 변명을 멈추고 대신 현실을 반영하도록 추정을 조정하는 외로운 목소리였습니다 ( 아마도 그보다 외교적이지만 그것은 기본 정서였습니다.)-당신이 그 위치에있을 때, 나는 당신이 실제로 KonBon을 수행하고 있기 때문에 프로세스가 시간 낭비라고 말하는 팀의 curmudgeon에 완전히 동의 할 것입니다 당신이 부르는 것. 특정 시점에서 그의 의견은 상황에 따라 검증됩니다. 그것'

어떤 시점에서 상황을 재설정해야 할 때, 팀이 시스템을 가동시키기 위해서는 추정치에 대해 과도하게 보상해야합니다. 팀이 지속적으로 스토리를 마무리하기 시작하면 애자일 프로세스는 일반적으로 상식이며 어떤 방식으로 프로세스를 구체화하지 못하면 생산성에 해 롭습니다. 그러나 '약속'과 '스프린트 목표'가 진지하게 받아 들여지지 않는 한, 일관된 성과를 달성하지 못하면 모든 일이 허구이며 팀의 생산성을 떨어 뜨립니다.

사람들이 상당히 다른 스프린트 (견적, 계획, 약속 등의 측면에서)를 구매하게하는 것은 어려운 일입니다. 그 팀에서는 결국 두 가지 요소로 인해이를 달성했습니다. 하나는 단지 JIRA에서 데이터를 수집하고 "이것에 대한 변명은없고, 숫자는 벗어난 것입니다. 그들은 항상 한 방향으로 꺼져 있습니다, 우리는 그것을 수정해야합니다, 나는 변명을 복고풍으로 원하지 않습니다. 추가해야 할 숫자 "-다른 하나는 경영진의 압력이 높아 결국 결국 그들에게 다음과 같이 설명했습니다."이 과정의 핵심은 개발 일정을 예측 가능하게 만드는 것입니다. 스프린트 (Sprint)는 그것과 상관없이 훌륭합니다. 이사회는 우리가 한 일을 정확하게 반영해야합니다. 경영진은 실제 결과보다 약속에 비해 우리의 성공을 더 잘 알고 있습니다. 자신을 위해 모든 스프린트의 절반을 소비하는 대신 작업을 마치는 것처럼 보이도록 프로젝션 라인을 출력과 일치시킵니다. 아무것도하지 않고. 더 이상 제거 된 사람들이이 시대에서 멀어 질수록 그들은 단지 당신이 실패하는 것을 더 많이 볼 수 있고, 당신이 복고풍으로 만든 변명은 그들의 견해에있는 것이 아니라 단지 당신이 실패하는 것을 본다. "

결국 우리 팀은 견인력을 얻었고 상황이 훨씬 부드럽고 낮아지기 시작했습니다. 프로세스가 실제로 시작되면 더 높은 출력을 얻기 시작했습니다. 따라서 tl; dr-비교적 높은 성공률로 스프린트를 닫는 데 필요한 모든 것을 수행하십시오. 당신이하지 않으면 팀의 curmudgeon은 결과에 의해 스크럼에 대한 그의 저항을 계속 유지할 것이며 궁극적으로 당신의 프로세스는 실제로 모든 시간을 허비하고 낭비하는 것이 옳을 것입니다.

스크럼 마스터로서 팀의 생산성을 높이고지도합니다. Scrum 프레임 워크는 강력한 도구이지만 Scrum 프레임 워크는 절대 스스로 목표가되어서는 안됩니다. 그렇지 않으면 Cargo Cult를 수행하는 것 입니다.

3 년 동안 카고 컬트를 해왔 던 것 같습니다. 사람들은 그것이 끔찍한 프로젝트 관리 방법론이라는 것을 깨달았습니다. 좋은 소식은 똑똑한 사람들 이 있다는 것입니다. 불행히도 회사의 일부 사람들은 그것을 Scrum이라고 부르지 만, 똑똑한 사람들이 있습니다 . 그들은 팀이하는 일을 Scrum이라고하지 않습니다.

오버플로를 새로운 스프린트로 옮기고 어쨌든 작업을 완료하지 않기 때문에 계획은 시간 낭비입니다.

바로 그거죠. 왜 귀찮게? 답을 찾아야합니다. 또는 계획과 스프린트 자체를 변경해야 계획의 요점이 있습니다. 무의미한 스프린트 계획으로 모든 사람의 시간을 낭비하지 마십시오. 훌륭한 스프린트 계획을 실행하는 것이 사소한 것이 아니기 때문에 회사에 스크럼 마스터 교육을 보내도록 요청할 수 있습니다.

회고하는 동안 [...] 다른 사람들은 조용하고 매번이 문제를 해결해야합니다.

회고전마다 같은 문제를 다루고 있다면 회고전 중에 사람들이 더 이상 말하지 않아도되므로 시간 낭비 일뿐입니다. 귀하 또는 팀이 회고에서 제기 된 문제를 어떻게 든 해결할 수 없다면 회의는 단순히 팀을 강등시킵니다. 회고에서 제기 된 문제를 해결해야하며 다음 회고에서 진전이 있어야합니다.

데일리 스크럼은 다시 말하고 계획하지 않아도되기 때문에 시간 낭비입니다. 그들은 "어제 작업 X에서 작업했으며 오늘 다시 작업 할 것"이라고 말합니다.

사실, 며칠 동안 같은 일을한다면 모든 사람의 시간을 낭비하는 이유는 무엇입니까? 데일리 스탠드 업은 실제로 무의미합니다. Standup은 반나절 이내에 완료 될 수있는 많은 작업에 대한 긴밀한 협업을 지원합니다. Sprint Planning이 고장 나서 실제로 작업이 스크럼에 적합하지 않기 때문에 작업을 그런 식으로 분류 할 수없는 경우 5 분 일일 스탠드 업 미팅을 개최 할 필요는 없습니다. 5 분을 넘지 않아야합니다.)

"우리는 스프린트를 완료하지 않습니다. 우리는 스쿼트를 채우기 위해 작업을 진행하고 다음 스프린트에서 새로운 작업을 수행합니다. 실제로 KanBan을 수행합니다. 그러니 그만 말하십시오."

나는 그가 왜 이런 말을하는지 이해하지만, 이것이 팀원과 그 밖의 모든 사람들이 관심을 갖지 않기 때문에 이것이 어떻게되는지 깨닫지 못하는 것 같습니다.

아니, 당신은 그가 왜 이런 말을하는지 이해하지 못합니다 . 해결해야 할 장애의 근본 원인이 잘못되었습니다. 팀의 프로젝트 관리 관행이 빨라서 신경 쓰지 않습니다. Cargo Cult와 Cargo Cult를 더 열심히하는 것이 현존하는 최악의 프로젝트 관리 방법 중 하나 인 Cargo Cult가되는 것을 막지는 못합니다 (방어 : 가장 널리 사용됨).

이것에 대해 무엇을 할 수 있습니까?

1. 그들의 걱정을 들어라. 다시 한 번, 당신은 똑똑한 사람들이 있다는 축복을 받았습니다 .

2. 그들이 장애를 해결하도록 도와주십시오.

그게 다야. Sprint Planning, Daily Scrum 및 Retrospectives를 변경하여 팀에 가치를 부여하는 방법을 실험해야합니다. Scrum 레이블을 삭제하려는 경우에도 서로 비슷한 빈도와 유사한 목적으로이 3 개의 회의가 있습니다. 프로젝트 관리 방법론. 실험 방법 (빈도, 콘텐츠, 회의 주최자, 시간, 기간 등)은 놀라 울 정도로 쉽습니다. 팀에 문의하십시오. 아이디어를 강요 할 수있는 경우 아이디어를 강요하지 마십시오 (일부 의견에 동의 할 수 있다고 가정).

통제력을 잃을 까봐 두려워하는 경우 미리 경계를 설정하십시오.

• 회의 레이블은 동일하게 유지됩니다.
• 회의는 계속 진행되며 회의 빈도는 2 배 이상 변경 될 수 없습니다.
• 현재 실험 중이므로 모든 스프린트는 2 스프린트 동안 만 지속되며, 그 후 이전 패턴으로 되돌립니다 (스프린트 지속 시간을 두 배로 늘리고 싶을 때 모호성을 피하기 위해 몇 주 안에 시간을주는 것이 가장 좋습니다).

나는 모든 사람들이 애자일 선언문 에서 같은 줄을 인용하고 있다고 생각합니다 . "프로세스와 도구에 대한 개인과 상호 작용"도 마찬가지입니다.

SCRUM 마스터로서 SCRUM을 사용하여 작업을 수행하려는 경우 한 개인이 다른 사람과 상호 작용할 때 이들을 접근해야합니다. 프로세스 개선 방법을 브레인 스토밍하십시오. 아마도 당신은 그들이 스크럼을 좋아하도록 설득 할 수 있습니다. 아마도 그들은 당신이 다른 과정을 사용하도록 설득 할 수 있습니다. 알아 보자!

팀이 현재 시스템이 작업을 수행하지 않음을 이미 인식하고있는 것 같습니다. 그들이 일을 할 수 있다고 믿도록 격려해 줄 수 있습니까? 몇 가지 예를 언급했습니다. Sprint가 항상 넘치도록 Sprint를 너무 많이 채우는 경우 ... 중지하십시오. 당신의 스크럼 팀입니다. 초과 커밋을 중지하도록 도와주세요. 호흡 실을 확보하기 위해 경영진을 다시 추진하십시오. 좋은 것을 위해 스크럼을 사용하십시오. 이를 사용하여 프로세스에서 가치를 잃어 버릴 정도로 열심히 노력하고 있다는 경영진에게 데이터를 제공하십시오. 경영진이 SCRUM을 프로세스로 원할 경우이를 해결하는 데 필요한 공간과 에너지를 구축하도록 도와주십시오. SCRUM 마스터로서 귀하의 임무는 팀의 생산성을 높이기 위해 문제를 해결하는 것입니다.

또 다른 유용한 접근 방식은 기존 프로세스 내에 새로운 프로세스를 생성하는 것입니다. SCRUM을 같은 쓸모없는 방식으로 계속 실행하되 일정의 일부를 중단하고 "이 일정에서는 도구를 올바르게 사용하는 방법을 알아낼 것입니다"라고 말합니다. 지나치게 커밋하지 마십시오. 측정 항목을 사용하십시오. 모든 회의에 집중하십시오. "SCRUM"프로젝트의 나머지 부분은 관리를 행복하게 유지하기위한 보호막 역할을합니다. "귀하와 팀이 소프트웨어를 개발하고 다른 사람들이 소프트웨어를 개발하여 더 나은 방법으로 소프트웨어를 개발할 수있는 방법을 찾아냅니다." 시간이 지남에 따라이 버킷에 점점 더 많은 귀중한 작업을 넣고 싶을 것이고, 이전 버킷은 천천히 죽을 것입니다. 곧, 당신은 활기찬 소프트웨어 개발 환경을 가지고 있으며 더 현명한 사람은 없습니다.

또는 그것들을 혼합하고 일치시킵니다. 나는 안티 스크럼 프로그램을 작업했습니다. 고객은 프로세스 중 언제든지 새로운 작업을 추가하고 즉시 작업을 수행 할 수 있기를 원했습니다. (이것은 실제적인 요청이었다 : 그들의 작업은 매우 변동 적이었고 그들은 종종 빠른 지원이 필요했다. 물론, 우리는 "스프린트에서 약속했을 때 왜 X를하지 않는가"문제를 다루는 방법을 찾아야했습니다. 우리의 솔루션은 실제로 2 단계 프로세스를 구축하는 것이 었습니다. 적절한 우선 순위를 정하기 위해 장기 작업을 스크럼에 넣었습니다. 단기 과제는 고객과 개발자 간의 긴밀한 상호 작용에 중점을 둔 자체 제작 프로세스로 진행되었습니다. 고객은이 단기 프로세스를 사용하여 우리를 밀어 붙이는 것을 환영했지만, 그렇게하면 스프린트가 타임 라인과 동시에 발생하는 일정 문제를 듣고 해결하지 않고도 요청을 추가 할 수 없었습니다. 결과? 효과가있었습니다. 대부분의 작업은 원래와 같이 SCRUM 프로세스에 투입되었으며 비상 사태는 작업과 원활하게 상호 작용했습니다. "고객이되고 싶다면 SCRUM 이야기를 들으십시오. 파트너가 되려면 언제든지 귀사와 협력하여이 제품을 작동 시키십시오. ! "

나는 정말로 알고 있기 때문에 이것을 말한다. 오버 스케줄링, 우선 순위를 설정할 수 없음, 더 많은 항목을 추가하지만 릴리스 날짜를 되 돌리지 않겠다는 상위 관리에 문제가 있습니다.

나는 이런 식으로 작동 할 수있는 방법론이 없다고 말했지만 지금은 Kanban을 볼 수 있었지만 Kanban은 신경 쓸 필요가 없기 때문에 가능하다고 말합니다. 오버 커밋 된 경우에도 계속 작동합니다. 결과를 더 빨리 가져올 수는 없지만 대기열의 백업은 개인에게 배치 할 수 없으므로 관리 문제는 관리에 달려 있습니다. 피드백 보고서에 과부하가 표시됩니다.

Scrum Masters의 이러한 변화와 쇼를 운영하는 방식 때문에

글쎄, 이것은 당신의 문제 일 수 있습니다. 스크럼 마스터는 쇼를 진행하지 않고 프로젝트 리더가 아닙니다. 그는 모든 이해 당사자들이 의사 소통을하고 운영이 투명하도록하기 위해 존재합니다.

팀이 어디에서 왔는지 궁금합니다. 스크럼 (피할 수없는 스크럼 마스터 포함)을 떨어 뜨리기 전에 자율적 이었을까요? 스크럼이 처음 소개 된 이유는 무엇입니까? 무엇을 해결하기로되어 있었습니까?

스크럼은 지침을 제공해야하며 팀은 어떤 식 으로든 도움이되지 않는다는 것을 분명히하고 있습니다. 그들은지도를 신경 쓰지 않고, 그것을 시간 낭비라고 생각합니다. 어쨌든 적어도 한 명의 의사 결정자는 그들이 안내를 받아야한다고 생각합니다. 누구? 왜? 그들은 요점이 있습니까?

이것은 소프트웨어에만 국한되지 않는 문제입니다.

모든 업무 환경에는 성격과 능력이 다른 사람들이있을 것입니다. 스크럼이 완벽한 방법 이었지만 개성과 능력으로 인해 여전히 반대하는 사람들이있을 것입니다.

개발자는 어려운 작업을 합리적인 방식으로 처리합니다. 이를 위해 각 개발자는 스크럼과 같은 것들에 대한 혐오로 나타날 수있는 것들을 처리 할 수있는 방법을 갖게 될 것입니다. 모든 개발자가 완전히 동일한 방식으로 처음부터 훈련을 받았다면 한 패턴을 사용하는 것이 훨씬 쉬울 수 있지만 그렇지 않은 경우 개발자 측이나 관리 측에 적응해야합니다.

또한 독립적 인 사상가 (개발자 및 기타 전문가)는 종종 자신의 일이기 때문에 어떻게해야하는지 말하는 것을 좋아하지 않으며, 의견 충돌이 발생하기 쉽습니다. 스크럼은 일반적으로 당면한 각 문제에 따라 분석하고 행동하는 논리적 사상가에게 무의미한 의식처럼 보일 수 있습니다.

아래는 문제가 어디에 있지만 문제가 아닌 것을 제안하는 것 같습니다. 이보다 더 많은 것이 있습니다. 나는 개발자가 시도했지만 예방 된 것으로 만 경험이 부족하다고 가정 할 수 있습니다. 개발자가 무언가를 고치려고하지만 시스템 적 (관리, 회사 정책 등)이 불가능한 경우가 많으므로 포기하는 경우가 많습니다. 그들은 실제로 도움이되지 않을 것으로 생각되는 일 (경험이 없을 것) 만 신경 쓰지 않거나 신경 쓰지 않습니다.

나는 그가 왜 이런 말을하는지 이해하지만, 이것이 팀원과 그 밖의 모든 사람들이 관심을 갖지 않기 때문에 이것이 어떻게되는지 깨닫지 못하는 것 같습니다. 그들은 단지 장애를 다루는 대신 일을합니다. 그들은 장애에 대해 불평하지만 그들에 대해서는 아무 것도하지 않습니다. 내가 도와 주려고하면 그냥 으 rug 거립니다.

그들은 지독한 일을했지만 지난 2 년 동안 그들의 의지는 거의 바닥으로 떨어졌습니다.

이러한 회의에서 농담과 서클 저크가 회사에 많은 비용이 든다는 것을 어떻게 알 수 있습니까?

다른 사람들에게 무언가를 강요하고 있다면, 사람들에게 혜택을 확신시키는 방법을 강요하는 것은 사람들에게 달려 있습니다. 나는 사람들이 일을하도록 강요하는 것을 믿지는 않지만 어떤 상황에서든 모든 사람들의 말을 듣고 현재 환경에 적합한 방법을 개발할 것을 제안합니다.

스크럼에는 약점이 없습니다. 물론 말할 수는 있지만 개발자가 정당한 이유로 싫어한다고 생각 합니다. 그것이 시도되어서는 안된다는 것이 나의 정직한 의견입니다 .

이유를 이해하려면 모든 스크럼 마스터가 스크럼에 대해 알아야 할 내용을 읽으십시오 . 그것은 나에 의해 작성, 아직 모든 나는 단지로 요약 할 수 있습니다 내 경험의 대표가되지 깎아 지른듯한 공포 .

필자의 경우 특히 5 점 미만으로 어려움을 겪었습니다. 기본적으로 스크럼은 나를 어린 아이와 패자로 취급했습니다. 이제 저는 동료를 돕는 풍부한 공동 개발자입니다. 제가 무엇을 선호하는지 궁금하지 않습니다!

나는 지금 (스크럼이 아닌) 새로운 보스가 있는데, 그냥 걸어 다니고 사람들과 대화를 나눕니다. 정말 감사 합니다! 이것이 작동하는 이유 중 하나는 개발자 간 커뮤니케이션을위한 대화방 (가장 중요 함)이 있다는 것입니다. 누군가 의제를 가지고 있다면, 우리는 그것을 의제로 삼습니다. 회의는 임시 개발자 토론만을위한 것이며, 인공적인 마감일을 스스로에게 부과하지는 않습니다.

당신은 훌륭한 답변을 많이 받았습니다. 다음은 도움이 될만한 몇 가지 사항입니다.

방법론 변경이 어렵다

"이것은 우리가하는 일입니다"라는 관성 아래서 마감일과 비즈니스 요구의 압력에 맞서고 있기 때문에 작업 공간에서 큰 도전입니다.

팀이 계획에 더 많은 시간 을 할애해야 한다고 결론을 내릴 수 있습니다 . 계획은 현재 귀하의 시간이 좋지 않고 개선해야 할 사항입니다. 문제는 단순히 새로운 규칙을 지시하는 것만으로는 얻을 수 없다는 것입니다. 새로운 규칙은 큰 도움이되기 전에 새로운 부담입니다. 그리고 그들이 즉시 큰 가치를 제공하지 않는다면 , 당신은 협력보다는 회피를 얻게 될 것입니다.

이 주제에 대해 Roy Osherove를 강력히 추천합니다. 회사에서 변경을 계획하고 적용하는 방법에 대한 간략한 요약을 얻었으며이 비디오 에서 훨씬 더 깊이있는 주제를 다루게됩니다 .

Osherove의 기본 관찰은 다음과 같은 모든 문제를 해결해야한다는 것입니다.

개인적인 동기 부여 : 왜 누군가가 특정한 방식으로 행동해야합니까?
개인 능력 : 말 그대로 할 수 있습니까?
사회적 동기 부여 : 이 행동에 대해 또래의 압력이 있습니까?
사회적 능력 : 주변 사람들이 내 행동을 지원하고 도움이 필요할 때 도와 주나요?
구조적 동기 부여 : 좋은 행동에 대한 보상 / 처벌이 있습니까?
구조적 능력 : 물리적 환경이이 행동을 지원합니까?

작업을 분류하는 법을 배워야합니다

귀하의 팀은 "어제 작업 X에서 작업 한 후 오늘 다시 작업 할 것"이라고 생각하고 작업이 일주일 동안 계속 진행되고 있다는 의미에서 옳은 것 같습니다.

여기서 가장 유용한 것은 작업을 작은 구성 요소로 나누는 방법을 배우는 것입니다. 당신이 찾고있는 것은 "OK, 당신은 작업 X에서 작업하고 있지만 작업 X에서 무엇을 현재 작업하고 있습니까?"라는 질문에 대한 답 입니다 .

일부 답변은 다음과 같습니다.

• 이 클래스의 레거시 코드를 배우고 있습니다.
• 증상이 (현상) 인 버그를 수정하고 있습니다.
  • 이것이 현재 진행중인 버그 인 경우 : "오늘 시도 할 것은 ... (PLAN)"
• 이 인터페이스를 변경해야합니다.
• 나는 시험을 쓰고있다.
• 테스트되지 않은 코드를 통합하고 있습니다.

... 등 등등. 하루 또는 일주일 동안 실제로 수행 할 수있는 작업을 관찰 할 수 있다는 것은 애자일의 큰 이점 중 하나입니다. 그러나 이는 실제로 준비가 될 때마다 준비 될 모 놀리 식 작업 X가 아니라 개별 요일의 해결을 실제로 볼 필요가 있음을 의미합니다.

완료 대 전달

하나의 일반적인 문제 (애자일 및 일반적으로 작업 공간 계획의 경우)는 마감 시간이 개발자가 아닌 경영진에서 오는 경향이 있다는 것입니다. 마감일은 실제 작업과 이혼 할 수 있으며, 특히 물건 을 가능한 빨리 배송 하기를 원할 것 입니다.

문제는 "제공된 최대한 빨리"는 매우 혼란스러운 과정입니다. 코너를 자르도록 권장합니다. "빠르고 더러운"코딩; 지침을 무시하고; 자신을 청소하지 마십시오. 그것은 "시도하고, 작동하는지 확인하십시오. 그렇다면, 전달하십시오. 그렇지 않으면 다른 것을 시도하십시오"라는 사고 방식을 장려합니다.

체계적 으로 작업 하는 경우 계획 및 테스트 등을 엄격하게 수행하는 경우 많은 이정표와 안전망을 설정해야합니다. 시간이 더 오래 걸릴 수 있습니다. 즉각 전달하지 않는 일에 많은 시간을 할애하고 있으며 이러한 종류의 워크 플로는 아직 잘하지 못할 수도 있지만 변동성이 훨씬 적습니다.

따라서 스스로에게 물어봐야 할 것은 : 개발자 들이 실제로 보는 요구와 필요성에 따라 스프린트 목표를 설정하는 것입니까? 아니면 경영진 이 마감일을 정하고 있습니까?

개발자가 계획을 세우거나 신뢰할 수있는 계획에 따라 작업 할 시간이 없다면, 유용한 추정을 할 수 없다는 것은 놀라운 일이 아닙니다. :)

이것은 인기가없는 의견 일 수도 있지만 그것에 대해 아무 것도 할 수 없을 수도 있습니다.

나는 수년간 팀의 존재와 리더의 흐름에 대해 진정으로 팀에 불만을 가진 사람들이 떠났다고 상상할 수 있습니다. 당신이 가진 것은 불만을 제기 할 수있는 사람들의 유물이지만 실제로 상황을 개선하기 위해 노력하는 데에는 관심이 없습니다. 그들은 단지 8 시간의 해킹 코드를 보내고 싶어합니다. 누군가에게 방해받지 않고 하루 종일 집으로 돌아갑니다. 여기있는 것은 심각한 동기 부여 문제인 것 같습니다. 그리고 그 문제를 해결하는 것은 스크럼 마스터의 일이 아닙니다. 누가 그 사람들에게 돈을 지불하는지는 문제입니다.

이것이 사실이라면 실제 옵션 만 현재 팀을 제거하고 처음부터 다시 시작합니다. 아마도 팀에서 가장 잘 생각하는 한두 사람을 남겨두고 나머지 팀을 해고하거나 다른 팀으로 옮길 수 있습니다. 적어도이 가능성에 대해 상사와상의해야합니다.