팀 건강체크 모델 – 무엇을 개선해야 하는지 시각화하기

원문 : https://labs.spotify.com/2014/09/16/squad-health-check-model/

저자 : Henrik Kniberg

[]와 강조는 역자가 추가한 것입니다. Spotify는 squad라는 팀 모델을 중심으로 조직이 구성되어있고, 이  Squad 내부에 기획, 개발, 테스트, 배포 등이 가능한 모든 기술과 자원을 갖추고 있습니다. 한 Squad는 하나의 작은 스타트업 처럼 구성되어있습니다. 조승빈 님의 “spotify의 조직 문화” 을 읽어보시길. 이 글에서 Squad는 편의상 팀으로 번역합니다.

팀(squad) 건강체크 모델이란 무엇인가

많은 회사들이 팀이 어떻게 일을 하는지 측정하고 시각화하는 실험을 합니다. 이것들을 보통 “성숙도 모델maturity model”이라고 부르고 다양한 레벨의 단계별 과정들을 포함하고 있습니다.

보통 이런 종류의 모델들이 가진 의도는 좋습니다. — 예를 들어 큰 조직의 관리자나 코치들은 개선을 집중해야할 곳을 감지하고 시스템 문제점을 찾아내려고 합니다. 또한 그들은 팀 스스로가 개선노력을 할 수 있도록 더 자기인식적일 수 있도록 도움을 주고자 합니다.

우리는 “건강 체크 모델”과 같이 조금 다른 용어를 사용하길 좋아합니다. 왜냐하면 ‘maturity’라는 말은 좀… 잘난체하는 것처럼 들립니다. 더해서 우리의 모델들은 다양한 레벨의 단계별 과정을 포함하지 않으며, 관리가 아니라 팀 그 자신을 위해서 필요합니다.

조직의 개선 과정은 매우 추측성 게임입니다.(개선을 위해 필요한 것이 무엇인지, 어떻게 그것이 개선중이라는것을 알 수 있을까요?) 명확한 시각화로 체계적인 접근방법을 통해 우리는 ‘추측’을 줄일 수 있습니다.

좋아, 그런데 모델이 정말 잘 동작할까?

답은 다양합니다. 어떨때는 모델이 정말 도움이 될 수 있지만 어떨 때는 좀 지루합니다. — 사람들은 워크샵이든 설문조사든 성실하게 임하지만 데이터를 무시하게 되면 그럴 수 있습니다.

조심해야 합니다. 어떤 회사에서 모델이 괴물처럼 되는것을 본적이 있습니다. 관리자가 팀을 심판하기 위해 “성숙도 모델”을 사용함으로서 두려움을 야기하는 억압의 도구로 변하고 서로를 구덩이로 밀어넣으며 팀은 문제를 숨김니다. 전혀 좋은 그림이 아닙니다!

아래 극닥적으로 일반화한 파이-차트가 있습니다. 우리가 지금까지 다양한 회사들을 통해 경험한 것들을 기반으로 만들었습니다.

여러분이 적용해본 모델이 잠재적으로 이득보다 손실이 더 많을지도 모릅니다. 하지만 거기엔 어쨋든 이득이 있고 우리는 손실이 많은 재앙적인 시나리오를 피할 수 있는 방법을 알고 있습니다.

Spotify에서 우리는 지난 몇 년 동안 매우 조심스럽게 실험을 해왔고 잘 운영되는(손실보다 이득이 더 많도록 하는)방법들을 찾았습니다. 우리는 팀 건강체크 모델을 몇몇 회사들에게 소개해왔고 비슷한 결과를 얻을 수 있었습니다. 그래서 우리는 이 글을 써야할 때라고 생각했지요.

팀 건강체크 모델은 누구를 위한 것인가?

팀(squad)의 건강을 체크할때는 아래 두 종류의 이해관계자가 있습니다.

  1. 팀 자신. 건강을 체크하는 기준들에 대해 토론하는 동안 팀은 무엇이 잘 작동하고 무엇이 그렇지 못하는지 스스로 인식하게됩니다. 질문[기준]을 넓게 선택하는 것이 관점의 확장에 도움이 됩니다. 아마 팀원들은 코드 품질에 대해서는 잘알겠지만 고객 가치의 관점에 대해서는 그다지 잘 모를 수 있습니다. 폭이 넓어야 균형감이 있는 관점을 제공할 수 있습니다.
  2. 팀을 돕는 사람들. 팀의 바깥에서(혹은 부분적으로만 바깥에서) 일하는 관리자와 코치는 팀이 무엇을 잘하고 무엇을 못하는지에 대해 매우 높은 수준의 요약된 결과를 얻을 수 있습니다. 그들은 여러 팀들을 관통하는 패턴을 볼 수 도 있겠지요. 만약 당신에게 12개의 팀이 있다면 그들 모두와 모든것에 대해 얘기해볼 수 없을 것입니다. 이 시각화된 결과물은 여러분이 무엇을 해야하는지 무엇에 대해 누구와 이야기해야 하는지에 대해 도움을 줄 것입니다.

문제를 해결하기 위한 첫 번째 단계는 문제를 인식하는 것입니다. 이런 시각화된 결과물은 모두로 하여금 문제를 무시할 수 없도록 만들것입니다.

Spotify 우리는 어떻게 했는가

우리는 기본적으로 아래 세 가지를 했습니다.

  1. 워크샵을 통해 팀 멤버들과 다양한 관점(품질, 재미, 가치 등)에 기반하여 현재 상황에 대해 토론하고 가늠합니다.
  2. 결과물을 시각적으로 요약합니다.
  3. 팀의 개선을 돕기 위해 데이터를 사용합니다.

우리는 여러가지 버전을 가지고 있습니다. 그 중 하나는 “팀 건강 체크 모델”이라고 부르고, 다른 것은 “fluent@agile game”과 “quarterly reflection”이라고 부르는 것이 있습니다(아마 나중에 이에 대해 글을 쓸것 같네요). 팀 건강 체크 모델은 2012년 Scaling Agile @ spotify 에서 언급했었던 분기별 설문지라 할 수 있는 “autonomous squads”의 개선된 버전이라고 할 수 있습니다.

아래는 팀 건강체크의 실제 예시입니다.

위 예시는 7개의 서로다른 팀의 상황을 보여주고 있습니다. 색상은 현재 상태(녹색 = 좋음, 노랑 = 몇 가지 문제가 있음, 빨강 = 매우 나쁨)를 나타냅니다. 화살표는 경향(개선되고 있거나 나빠지고 있음)을 나타냅니다.

위 예시를 보고 있으면 여러분은 몇 가지 흥미로운 것을 발견하실 수 있습니다.

  • 각 열을 보면, 팀간의 중요한 차이점이 보입니다. 팀4는 모든 면에서 좋게 보입니다. 팀2는 많은 문제를 안고 있는것 같지만, 대부분 개선되고 있습니다.
  • 각 행을 보면, 전체적인 패턴을 볼 수 있습니다. 모든 팀은 즐거워하고 있네요.(그리고 심지어 개선되고 있습니다.) 동기부여는 확실히 나빠보이지 않습니다. 하지만 릴리즈 프로세스는 문제가 있어보이며 코드 베이스 건강도는 전체적으로 나빠보입니다. 시간이 지나면 즐거움도 아마 감소할 것입니다.
  • 전체적인 그림을 보면, 모든 화살표가 위로 향하고 있음을 알 수 있습니다. 오직 두 개의 화살표만 아래로 향하고 있네요. 그것은 개선 프로세스가 잘 동작하고 있다는것을 보여줍니다.

물론 이것은 단지 실제의 근사치일 뿐입니다(“모든 모델은 틀렸다. 하지만 몇몇은 쓸모있다” — George Box). 그래서 액션을 취하기 전에 신중하게 체크해봐야 할 것입니다.

팀4는 정말 훌륭해 보입니다. 아니면 그들은 단지 낙관적인 사람들이거나 그들 자신의 문제를 보지 못하는 것일 수 있지요. 대부분의 팀들은 자신이 그들의 고객들에게 좋은 가치를 전달하고 있다고 여깁니다 — 그러나 그들이 무엇을 근거로 그렇게 알고 있는걸까요? 희망적인 사고에 근거한 것일까요? 아니면 실제 고객들의 피드백에 근거한 것일까요?

특이하게도 실제 팀4는 건강 체크 불과 1주일 전에 결성된 팀입니다. 이제 형태를 갖춰가는 단계이거나 “허니문”입니다. 그래서 팀2 뿐만 아니라 팀4도 도움을 많이 필요로 할 것입니다.

Easy to release”는 분명하게도 중요한 이슈입니다. 이것은 ‘지속적인 배포’와 같은 이슈에 더 집중할 수 있도록 리드하며, 우리는 긍정적인 진보를 경험한 적이 있습니다.

이것이 정직함과 팀원들의 주관적인 의견에 기반한 자기 평가 모델이라는 것에 주의하세요. 그래서 이 모델은 팀원들이 관리자와 동료들을 신뢰하는 환경에서만 제대로 기능합니다. 

다행이도 Spotify는 매우 높은 신뢰도를 갖춘 환경이며 관리자와 코치들이 매우 조심스럽게, 이것이 심판 도구가 아니라 지원도구라는 것을 보여주었습니다.

데이터를 얻기

우리는 이런 종류의 일에는 온라인 설문이 매우 좋지 않다는 것을 발견해왔습니다. 그렇게 하면 커뮤니케이션이 단절됩니다. 커뮤니케이션은 모델의 가치 중 가장 큰 부분입니다. 팀 멤버들은 토론을 하는 동안 인사이트를 얻고, 코치는 어떻게 팀을 도울 수 있을지에 대한 인사이트를 얻습니다. 데이터는 단지 그 인사이트들의 작은 부분을 제공합니다. 그것에만 의존하면 잘못된 길로 빠질 수 있습니다.

그래서 우리(보통 애자일 코치들을 말함)는 팀들과 워크샵을 열고 건강을 나타내는 여러 기준들을 가지고 얼굴을 맞대어 대화합니다. 보통 한 두 시간 정도면 충분합니다.

이것을 용이하게 하기위해 우리는 “Awesome Cards”라는 카드를 사용합니다. 각 카드는 팀 건강의 기준 중 하나입니다.

(Download the cards as PDF or PPTX thx Martin Österberg for designing the card layout)

보통 카드 한 벌은 10개의 카드로 이루어저있습니다. 아래는 완전한 한 벌의 카드 예시입니다:

카드 예시 Table

구분 : 매우 좋음 / 형편없는
쉬운 릴리즈 : 릴리즈가 단순하고, 안전하고, 쉽고, 자동화되어있다. / 릴리즈가 불안하고, 쉽지 않고, 수동으로 해야하는 부분이 많고, 오래 걸린다.
알맞은 프로세스 : 프로세스가 현재 우리에게 완벽하게 맞다. / 현재 프로세스가 완전 별로다.
기술 품질(코드 베이스 건강도) : 우리는 우리 자신의 코드가 자랑스럽다! 매우 분명하고, 읽기 쉽다. / 테스트 커버리지도 높다.우리의 코드는 똥더미이며 기술부채가 통제 불가능하다.
가치 : 우리는 고객에게 훌륭한 결과물을 전달한다. 우리는 그것을 자랑스러워하고 이해당사자들이 정말 행복해하고 있다. / 우리는 쓰레기같은 것들을 전달한다. 우리는 그것을 수치스러워하며 이해당사자들은 우리를 싫어한다.
속도 : 우리는 결과물을 정말 빠르게 만들어낸다. 기다림과 지연이 거의 없다. / 우리는 제대로 끝내본적이 없다. 우리는 지연되고 있거나 방해받고 있다. 스토리에는 계속 부가적 요소들이 붙어 지연되고 있다.
목표 : 우리는 우리가 왜 여기에 있는지 정확히 알고 있고 그것이 우리를 정말이지 흥분케 한다.우리는 우리가 왜 여기에 있는지 모르겠다. 우리의 미션은 불분명하고 영감을 주지 못한다.
즐거움 : 우리는 일하러 가는것을 좋아하고, 동료들과 함께 일하는 것이 즐겁다. / 지루ㅜㅜㅜㅜㅜㅜㅜㅜ하다.
배움 : 우리는 항상 많은 것을 배우고 있다! / 우리는 결코 뭔가를 배울 시간이 없다.
지원 : 우리의 요청에 대해 항상 지원과 도움을 받고 있다. / 우리의 요청에 대해 아무런 지원과 도움을 받지 못해 점점 더 나아가지 못하고 꽉 막혀있다.
주체성 : 우리는 스스로 우리의 운명을 통제한다! 무엇을 만들고 어떻게 만들건지 우리가 결정한다. / 우리는 단지 체스판의 말에 불과하다. 무엇을 만들고 어떻게 만들건지에 대해 아무런 영향을 끼치지 못한다.

각 질문에 대해 각 팀은 “아주 좋음”에 가까운지 혹은 “형편없는”에 가까운지 질문하고 토론합니다. 그리고 dot voting 등과 같은 방법으로 그 질문에 대해 색상(녹색, 노랑색, 붉은색)과 경향(안정정, 개선중, 더 나빠지는중)에 대한 합의를 도출합니다.

우리는 녹색/노랑색/붉은색 세 가지 레벨로 단순하게 하는 것을 좋아합니다. 이 세가지 단계의 정확한 정의는 변경될 수 있지만 대략 다음과 같습니다.

  • 녹색은 완벽을 의미하지 않습니다. 팀이 해당 항목에 대해서 행복하고 지금 당장 개선을 필요로 하는 이슈가 없는 것을 의미할 수 도 있습니다.
  • 노랑색은 해당 항목에 대해 재앙 까지는 아니지만, 중요한 문제가 있음을 의미합니다. Yellow means there are some important problems that need addressing, but it’s not a disaster.
  • 붉은색은 매우 안좋은 상황이며 개선을 필요로 함을 의미합니다.

네, 이것은 주관적인 데이터입니다. 이상적으로는 팀은 객관적인 데이터(cycle time, defect count, velocity, etc)를 선택할지도 모르지만 실제로는 거의 그렇게 하지 않습니다. 왜냐하면 객관적인 데이터라고 하더라도 팀은 그것이 문제인지 아닌지를 판단하기위해 해석해야하기 때문입니다. 결국에는 모든것은 주관적인 것으로 나아갑니다. 만약 무언가가 문제라고 느껴진다면, 그것이 문제인 것입니다.

때로 우리는 회고에 이런 방식을 포함시킵니다. 어떤 문제를 개선하기위한 액션을 도출하기 위해 위처럼 투표를 하지요.

어떤 질문이 좋을까?

이제 위 예제들을 바탕으로 여러분이 실제 사용할 질문들을 만들어야 할텐데, 다음 가이드를 참고하길 바랍니다:

  • 질문은 다양한 관점의 넓은 범위를 포괄할 수 있도록 디자인 합니다.[코드품질, 팀원간 신뢰, 서비스 가치 등등 다양한 질문들을 사용하라는 의미]
  • 이 질문은 단지 시작에 불과합니다. 팀은 자유롭게 제거하고 추가하고 변경합니다.
  • 질문 개수는 10개 정도로 제한하는 것이 좋습니다. 다른 질문을 추가하려면 몇몇은 합쳐지거나 삭제될 수 있습니다.

우리가 확실히 해야할 것은, 이 질문들이 팀을 운영하는 환경에 대한 것이어야하지 팀의 생산성(예컨대 속도)에 대한것이어서는 안된다는 것입니다. 그렇게 해야 이 과정이 심판하려는 것이 아니라 우리에게 도움과 개선을 준다는 관점을 강화시켜줍니다.

우리의 가정은(맞든 틀리든) 팀은 본질적으로 성공을 원하고, and will perform as well as it can under given circumstances.

팀 건강체크를 얼마나 자주 해야하나?

언급한대로 다양한 모델들이 존재하고 그것들은 계속 변화한다. 결국 우리는 완벽한 주기를 나타내는 숫자를 얻을 수 없다(아마 앞으로도 그럴 것이다).

처음에는 분기별로 하는 것이 좋아 보인다. 매 월 하는 것은 너무 짧다.(데이터가 그만큼 빨리 변하지 않는다.) 반년에 한 번씩 하는것은 너무 길다(그 안에 너무 많은 일들이 일어난다). 다시한번 말하지만 최적의 정해진 주기는 없다 다양하다.

결론 – 진행하기 전에 염두해야 할 것들

이 모델은 여러분의 개선노력을 가속화시키고 그것에 집중할 수 있게 도와줍니다. 하지만 부적절하게 사용하면 여러분의 문화를 완전히 망칠 수도 있습니다. 그래서 조심스럽게 진행해야 합니다.

아래는 성공가능성을 높일 수 있는 가이드입니다:

  • 모델을 소개할때 여러분의 도입 목적(동기)를 분명히 하십시요. 그 목적은 ‘심판’이 아니라 ‘개선’이 되야합니다.
  • 데이터를 수집할때는 온라인 설문이 아니라 면대면 대화를 통해 하는 것이 중요합니다. 데이터를 모으는 과정에는 흥미과 재미요소가 필요합니다.
  • 모델을 어떻게 적용할지 결정하는데에 팀을 참여시키고 그들이 직접 수정할 수 있도록 하십시요.
  • 팀원들의 결정이 데이터 일관성보다 중요합니다. 만약 팀A가 팀B와 좀 다르게 질문 세트를 선택했다 하더라도 괜찮습니다(나중에 결과를 그리기에 좀 지저분해질 지라도 말입니다).
  • 이 모델의 결과에 따라 어떠한 인센티브도 없다는 것을 확실히 해야합니다. 자신의 팀이 좋아 보이길 바라는 어떠한 동기도 없어야 한다.
  • 데이터를 시각화할 수 있는 간단한 방법을 찾으십시요. 더 분명하고 직관적으로 시각화한 데이터가 더 잘 사용될 가능성이 높습니다.
  • 팀간에 서로 비교되는 것을 조심하십시요. 만약 팀A가 초록색이고 팀B가 붉은 색일 경우, 그것이 팀A가 더 “나은”것을 위미하지 않습니다. 팀A가 더 단순한 상황에 있거나 더 낙관적인 전망을 가지고 있는것일 수도 있습니다. 혹은 팀B가 그들 자신의 문제에 대해 더 솔직한 것일 수도 있지요. 어느쪽이든 팀B은 도움이 필요한 상황일 것입니다. 관리자의 태도는 “내가 어떻게 도와줄 수 있을까요?”가 되야하지, “왜 여러분은 다른 팀보다 나쁜거지요?”가 되어서는 안될 것입니다.
  • 후속조치를 하십시요. 사람들에게 다음과 같은 질문을 해보세요. “이 모델이 정말 여러분에게 도움이 되고 있습니까?”, “만약 건강체크를 지금 중단한다면, 여러분이 그것들[건강의 기준들]을 놓치게 될까요?” , “우리가 어떻게 이 모델을 더 유용하게 만들 수 있을까요?”, 모델 스스로가 지속적으로 개선될 필요가 있습니다.

매우 인사이트가 넘치는 마틴 파울러의 기사도 꼭 보시길 바랍니다.

자 이게 전부예요. 이 글이 도움이 되길 바랍니다! 여러분도 이와 비슷한 종류의 경험이 있으신가요? 그렇다면 여러분의 경험을 댓글을 통해 공유해주십시요!

– Henrik Kniberg & Kristian Lindwall, Sep 2014.

원문 : https://labs.spotify.com/2014/09/16/squad-health-check-model/

(Download the cards & instructions as PDF or PPTX)

글쓴이

joel ahn

굿닥 프론트엔드 개발자 https://medium.com/@jeongwooahn