업데이트 보고서: Basecamp의 'Shape Up' 방법론 시험

작년에 저는 제품 팀을 전통적인 SCRUM 접근 방식에서 Basecamp의 Shape Up 방법론으로 옮기려고 했습니다. 정말 놀라운 경험이었습니다. 나는 그것으로부터 많은 것을 배웠고 내가 발견한 것 중 일부를 여러분과 공유하고 싶다고 생각했습니다.

직접 실험해 본 적이 있다면 어떻게 되었는지 듣고 싶습니다. 그렇지 않다면 왜 자리를 비웠는지 듣고 싶습니다.

1부: 왜 Shape Up을 해야 할까요?

우리 팀은 영원히 SCRUM을 운영해 왔습니다. 스타트업 시절 우리는 빠르게 작업하고, 배송하고, 프로세스에 대해 너무 많이 생각하지 않는 고전적인 기술 사이클을 살고 있었습니다. 그런 다음 우리는 인수되었습니다.

제품 방법론 옵션을 고려할 시간이 조금 더 생긴 후 Shape Up을 사용해 보기로 결정했습니다. 몇 가지 이유가 있었습니다:

1. 그때까지 우리는 2주간의 스프린트를 시도했지만 꽤 지속적으로 완료하지 못했습니다. 매주 마치 결코 끝나지 않을 티켓의 컨베이어 벨트처럼 느껴졌습니다.

   
   

2. 팀은 코드 몽키처럼 느껴졌습니다. 티켓을 선택하세요. 취업 티켓. 티켓을 전달합니다.

   
   

3. 스프린트를 완료하지 못했기 때문에 작업은 항상 다음 작업으로 넘어갔습니다. 결국 댐이 무너집니다.

   
   

4. 우리 모두 집중력이 부족했어요. 각 스프린트는 전체 코드 베이스에 걸쳐 작업할 항목을 선택하고 혼합한 것입니다.

   
   

5. 팀워크가 거의 없습니다. 각 개발자는 파이의 작은 부분에 대해 작업하므로 서로에게서 배울 수 있는 여지가 거의 없으며 솔직히 말해서 공동체 의식도 없습니다.

   
   

6. 고객의 이해가 거의 없습니다. 개발자는 할당된 티켓을 선택하여 완료하고 왜/누가/무엇을 하는지 전혀 알 수 없습니다.

다시 읽어본 후 베이스캠프의 Shape Up , 나는 그것이 대부분의 문제를 해결한다고 주장하므로 시도해 볼 것이라고 생각했습니다.

2부: 내부 피칭

Shape Up으로 전환하면서 가장 어려운 부분 중 하나는 내부적으로 아이디어를 제시하는 것이었습니다.

나는 어떤 질문에도 대비할 수 있도록 Shape Up의 개념 대부분을 내면화하는 데 추가 시간을 보냈습니다. 당연히 개발자들은 이 새로운 접근 방식의 아이디어를 좋아했습니다(더 많은 시간, 더 많은 집중, 더 많은 협업. 왜 그렇지 않겠습니까!).

또한 당연히 계층 구조는 더 과묵했습니다. 결국 나는 다음과 같은 방법으로 그들을 설득할 수 있었습니다.

1. 그것이 단지 재판이라는 것을 확인하십시오. 일이 잘 풀리지 않으면 우리는 '정상'으로 돌아갈 것입니다.

   
   

2. 내가 그들을 돕기 위해 언제나 가능한 한 남아있을 것이라고 확신했습니다. 개발자들은 집중하고 방해받지 않을 것이지만 나는 그렇지 않았습니다.

   
   

3. Shape Up을 강조하면 더 큰 문제를 해결할 수 있으며 이는 더 큰 기회를 의미합니다.

   
   

4. 고통스러운 제품을 고집하는 것은 현재 경험하고 있으며 그것이 각 팀에 어떤 영향을 미치는지.

나는 매우 명확한 슬라이드 자료를 준비하고 이를 통해 각 부서장(고객 서비스, 영업 및 최고 경영진)을 안내했습니다.

3부: 두려움과 우려

창립자, 마케팅 담당자, 제품 관리자로서의 경험을 통해 저는 실험을 시작하기 전에 항상 우려 사항을 적어 두는 것이 중요하다는 것을 깨달았습니다. 나는 Shape Up을 통해 몇 가지를 경험했습니다.

• 방해 요소를 어떻게 처리합니까? 나는 '아니요'라고 대답해야 한다는 것을 알고 있습니다. '우리는 바빠요.' '다음 사이클에서는 그 부분을 조사해 볼 수 있겠네요.' 이것이 이론이고 회사 전체가 이 방법론을 받아들인다면 효과가 있습니다. 첫 번째 사이클 시험 중에 긴급 상황이 발생할까 봐 걱정되었습니다.

• 백로그? Shape Up에서는 백로그를 사용하지 않는 것을 권장합니다(7장). 우리는 이것을 시험해 봤기 때문에 분명히 cmd+a+백로그를 삭제하지는 않았지만 여전히 그렇습니다. 이 방법론을 채택한다면 백로그가 없으면 다소 당황스러울 것입니다.

• '거의 끝났다.' 이건 정말 무서웠어요. 6주 주기의 끝에 도달했는데 잠정적으로 거기에 도달했지만 아직은 그렇지 않다면 어떻게 될까요? 베이스캠프에서는 '다시 시작하세요'라고 말합니다(너무 가깝지 않은 이상). 나는 우리가 짜증나는 20-30% 범위로 인해 목표를 놓칠까 봐 걱정했습니다.

궁극적으로 이러한 두려움/우려 중 어떤 것도 제가 재판을 계속하는 것을 막을 수 없었습니다. 하지만 그것들을 명심할 가치가 있었습니다.

4부: 주기

그리고 우리는 출발합니다!

나는 월요일 아침에 첫 번째 주기를 시작하여 6주간의 집중 집중과 팀워크를 살펴보았습니다. 매주 일어난 일을 요약하면 다음과 같습니다.

• 1주 차 : 시작과... 침묵. 팀을 그대로 두고, 조사하고, 각자의 시간에 코드를 살펴보는 것이 모두 이 방법론의 주요 부분입니다. 첫 주 동안은 포기하고 업데이트를 요청하지 않는 것이 엄청나게 힘들었습니다. 나는 굳건히 버텼다!

• 2주 차 : 팀은 마침내 껍질에서 벗어났습니다. 통신이 수신되었습니다. 작품에 대한 디자인이 나타나기 시작했고 피드백을 주고 함께 작업하게 되었습니다.

• 3주차 : 이론상으로는 3주차가 주기 곡선의 상단이 되어야 합니다. 결국 팀은 구축이 필요한 것을 어떻게 구축할 것인지에 대한 좋은 아이디어를 갖게 됩니다. 통신이 적절하게 증가하기 시작하면서 주기별 Slack 채널을 만들었습니다. 그 주가 끝날 무렵 우리는 프로토타입, 디자인, 코드 조각 등을 보았습니다. 우리는 순조롭게 진행 중이었습니다!

• 4주차 : 다시 조용해졌습니다. 3주차부터 모든 사람이 자신의 작업을 수행하면서 집중된 4주차를 만들었습니다. 우리는 금요일 '쇼 앤 텔'을 시작했습니다.

• 5주차 : 커브볼 주간. 스코프 중 하나에서 꽤 많은 소음이 발생하기 시작했습니다. 범위가 충분히 명확하지 않다는 것이 금방 분명해졌습니다. 내 요구 사항이 충분히 정확하지 않았고 처음에는 훌륭하고 단순해 보였던 것이 나중에는 복잡해졌습니다. 나는 이 범위를 줄이기 위해 어려운 결정을 내려야 했습니다.

• 6주차 : 나머지 범위는 훌륭하게 진행되었습니다. 6주차에는 제가 여기저기서 QA를 진행하면서 강도가 급격히 높아졌고, 개발자들은 제 피드백을 믿을 수 없을 정도로 빠르게 반복했습니다. 우리는 목표를 달성하기 위해 모두 함께 힘을 모았습니다.

  
  

결국 우리는 목표를 달성했습니다. 우리가 해냈어요! 그것은 매우 강렬했고, 스코프 중 하나를 잘라야 했지만 우리는 해냈습니다.

다음주 월요일 오전 10시에 제작에 들어갔습니다.

5부: 몇 가지 교훈

특별한 순서 없이 다음은 몇 가지 교훈과 권장 사항입니다.

1. 성형은 어렵다 . 나는주기의 무서운 부분 대부분을 형성하는 일을 훌륭하게 수행했다고 생각했습니다. 알고 보니 전체 사이클을 거의 탈선시켰던 노골적으로 명백한 것을 놓쳤습니다.

   
   

2. 형성 과정에 팀을 포함시키세요 . 저는 대부분 혼자서, 때로는 개발팀 리더와 함께 형태를 만들었습니다. 다른 개발자를 포함시키는 것이 나에게 가치가 있었을 것입니다.

   
   

3. 사이클 중간에 논의하거나 형성하는 중이라면 뭔가 잘못된 것입니다 . 모든 것을 중지하십시오. 당신의 우선순위는 그것이 다른 모든 것을 완전히 탈선시키기 전에 그 문제를 알아내는 것입니다.

   
   

4. 강도가 고르게 분포되지 않습니다 . 팀 구성원 간이든 주기 전반에 걸쳐 작업 강도는 크게 달라질 수 있습니다. PM으로서 이러한 강렬한 부분을 찾아내고 이를 겪고 있는 개인에게 특별한 주의를 기울이는 것이 귀하의 역할입니다.

   
   

5. 별도의 Slack 채널을 만듭니다 . 의사소통이 훨씬 쉬워졌지만 훨씬 더 재미있어졌습니다. 사이클 팀은 우리가 진행 중인 작업과 관련된 공유 언어, 밈 등을 빠르게 개발했습니다. 기본적으로 팀 내에서 스타트업이 되는 느낌이었어요.

   
   

6. 1주차부터 쇼앤텔 미팅을 시행합니다 . 우리는 이것을 하기 위해 너무 오래 기다렸습니다. 1주말부터 보여주거나 토론할 수 있는 내용이 충분해야 합니다. 만나서 토론하고, 배울 수 있는 기회이기도 합니다.

   
   

7. 쿨다운 기간은 사이클 자체보다 훨씬 더 어려운 것으로 나타났습니다 . 모든 '다른 작업'은 6주 동안 쌓였습니다. SCRUM으로 바로 돌아가는 것 같았습니다. 이것은 제가 아직도 개선하기 위해 노력하고 있는 부분입니다.

당신도 알 수 있듯이 나는 이번 재판으로 인해 마음이 바뀌었습니다.

Shape Up을 구현하고 그 특징을 채택하는 것은 확실히 하루아침에 이루어지는 일이 아닙니다. 나는 그것이 긴 학습 과정이 될 것이라고 생각합니다. 저는 이번 재판을 통해 우리에게 허용된 사고방식의 변화에 특히 감사했습니다. 우리(그리고 다른 팀들도)는 작업이 무엇인지, 즉 우리가 함께 극복할 흥미진진한 도전을 보는 법을 배웠기를 바랍니다.

이것을 시험해 보셨다면(혹은 안 하셔도), 몇 가지 이야기나 피드백을 읽고 싶습니다!

이 게시물이 마음에 드셨다면 제 뉴스레터도 마음에 드실 것입니다. 저는 제품 관리에 관해 글을 쓰고, 실행 가능한 통찰력을 공유하고, 재미를 위해 실제 제품 문제에 도전합니다(알고 있죠?).