애자일 책들에서 이야기 해주지 않지만
반드시 알아야 하는 일들
책 한권 읽은 사람이 제일 무섭다고, 어디서든 애자일 관련 책 한권 읽고 이래 저래 하시는 분들이 참 다양합니다. 막내사원부터 임원급들까지 '내가 천국의 비법을 알아냈도다!'라며 흥분하며 여기 저기 들이미시는 많은 분들이 있습니다.
이제는 어느 회사나 관리자 서가에 '스크럼과 XP'나 '칸반' 관련 책들이나 팁들을 정리해놓은 책들 한두권 정도 들고 있는 분들이 꼭 있습니다. 적어도 스스로는 애자일을 한다고 하는 회사들도 굉장히 많고요. 그런데 뭔가 그것들을 실천하려고 하는 때마다 자꾸 걸리적 거리고 잘 하는 것인지 모르겠다는 분들도 많으십니다.
왜 그런 걸까요? 사실 그 이유는 이제 '알았기' 때문일지도 모릅니다. 그리고 실천해보자면 또 여러가지 문제점이 있을겁니다. 여러분의 일터가 다 다를 것이고 프로젝트의 구조가, 구성원들이 모두 다르기 때문인거죠. 특히 애자일 방법론에 익숙하지 않은 사람들이 이제 책을 보고 한다고 하면 다들 생각하는 그림이 같을 리가 없기 때문이지요. 그래서 몇가지 체크해볼만 함 점들을 이야기 해보고자 합니다.
출처: Outcome variables
나중에 사고치려 하지 말고 미리 사고쳐라
보통 프로젝트에 대해 사람들이 생각해서 이렇게 보통 생각합니다. "단계 1⇒ 단계 2 ⇒ 단계 3을 거쳐서 하면 될거야"라고 합니다. 그런데 저는 이렇게 말합니다.
"단계3을 먼저 하거나 혹은 이미 만들어진 것처럼 고객에게 우리 프로젝트의 결과물을 보여줄 방법이 없을까요?"
예를 들어서, 앱을 개발을 다 할 수도 있습니다. 그러나 Paper prototype을 통해서 실제 이용하게 될 고객에게 현재 만들 UX가 효과적인지 확인할 수 있습니다. ML의 경우는 어떨까요? 실제 우리가 생각하는 입력-결과값에 대해서 미리 만들어 놓고 내부 혹은 외부 고객에게 보여주고 피드백을 얻을 수 있습니다.
왜 이런 접근을 해야 할까요? 그것은 '우리가 정의한 문제가 정확하지 않을 수 있기 때문'입니다. 대부분의 프로젝트의 초기에 우리는 '아는 것이 없습니다'. 즉 아는 것이 없는 상태에서 '문제를 가정'하고 나가야 하는데 이 '가정'이 '맞을리가 없기' 때문입니다. 그러므로 무슨 짓을 해서든, 그 가설에서 출발한 생각하고 있는 결과물을 노력을 덜하고 혹은 짧은 시간에 고객에게 빠르게 보여줄 수 있는 모든 방법을 찾아야 합니다.
혹은 고객들이 "아니 코드는 언제 나와?"라고 할 수도 있습니다. 제 글 '실패를 관리해야지 성공을 확신하는 일이 아니다'를 다시 인용하자면, 소프트웨어의 실제 성공률이 평균 30%가 안되는 실패하기 쉬운 일이기 때문에 고객과 빠르게 만나고 그들이 원하는 것을 만들어야 성공한다는 것을 잊어선 안됩니다.
회고를 빼먹지 말고, 그 기록을 유심히 봐라
의외로 반복적인 일정 잡기를 실천하는 조직들이 꼭 회고를 잘 안하거나 형식적으로 하는 경우를 봅니다. 나름 한다고 하지만 정직한 이야기가 오가지 않는 경우도 있고, 모두 서로 잘했다고 꽃마을 잔치를 하고 끝내는 경우가 있습니다. 사실 이것은 정직하면 손해보는 조직의 문화 덕이라고 봐야 합니다.
이런 회의실에 들어간다면, 벌써 심장이 멈추는거 같아요...팀 리더가 회고결과를 보고 우리에게 문제가 있는지 아닌지 알려면 다음의 상황을 확인해봐야 합니다.
"회고 해봐야 별거 없어요"라고 하는 사람이 늘어납니다 : 당신에게 조용히 누군가 와서 ‘회고 저거 왜 해요?”라고 말하는 사람이 있을 수도 있습니다. 이것은 정말 뭔가 잘못되가고 있다는 사인입니다. 원인을 찾아 봐야 합니다. 혹은 말은 없지만 회고 내용이 무언가 편향되게 나타날 수 있습니다. 예를 들어 잘한일들의 숫자는 줄어들고 개선한 일들의 숫자만 늘어납니다. 혹은 회고 시간에 비판적인 사람이 이후 비난받는 일이 생길 수도 있습니다. 그러해서 '회고때 말해봤자 별 소용 없다'라는 인식이 조직에 퍼집니다.
회고한 다음에 'Action item'을 정하지 못합니다 : 의외로 이런 경우들이 많았습니다. 정작 무엇을 할지를 정하지 않는 것이지요. 실제 무엇을 할지 정하기가 두렵거나 회고의 과정 자체가 사실 무의미한 것이었는지도 모릅니다.
'Action item'을 정했으나 이를 실행했는지 안했는지 확인하지 않습니다. : 이 부분이 빠지면 정말 '회고는 왜 하는 건지' 모르겠습니다. 무엇을 했는지 혹은 해왔는지 다시 피드백이 들어와야 하는데 이 부분이 빠지면 정말 무엇때문에 회고를 하는지 모르겠네요.
리더만 말하고 있다 : 심각한데요... 정말 이렇다면 팀장이나 리더들은 나가고 나머지 사람들이 회고를 하고 그 결과만 팀장에게 리더에게 보고하고 필요하면 의사결정만 하게 하는게 나을 수 있습니다.
회고한 내용에 정직함이 없어 보인다 : 제일 위험한 상황입니다. 사실 이것은 혼자 혹은 조직내에서 깨닫기가 매우 힘듭니다. 괜찮다면 다른 조직원이나 제3자의 관찰을 부탁해보세요. 대부분 리더들이 많이 깨닫지 못하거나 스스로 현재 상황을 부정하는 경우가 많습니다. 제일 어렵습니다....
소형 폭포수 방법을 쓰고 있는지 확인해 봐라
기존의 폭포수 방법이 맘에 안들어서 반복적인 일정 잡기로 계획을 잡는다고 합시다. 그런데 나눠서 일하는 것이 다일까요? 한번 아래 링크를 봐 보세요.
Your Sprint May Be a Mini Waterfall If... | Agile Velocity
일명 mini waterfall을 하고 있다고 하는 건지 점검해야 한다는 것입니다. 반복적인 일정을 잡는 것은 괜찮습니다. 그런데 “그 반복의 끝에 고객을 만나고 있느냐”는 겁니다. 예컨데 경영진이나 PO, 고객에게 데모를 하고 피드백을 받는 과정이 없이 개발만 일정을 나눠서 맨 마지막에 경영진이나 PO, 고객에게 데모를 하는 경우를 말합니다.
보통 경영진이나 PO, 고객둘은 이렇게 말합니다. ‘우리 너무 바빠요’. 그런데 누군가는 말했지요. 바쁘다는 말은 ‘마음에 없다’라는 말의 다른 버전이라고. 특히나 회사의 사업에 중차대한 제품에 대한 피드백을 줄 시간이 없는 경영진이나 PO, 고객은 결국 모두를 실패하게 만들 가능성이 높습니다.
당신이 좋은 사람인지 먼저 봐라
앞에까지 읽고나서 ‘이래선 안된다’하면서 자리를 박차고 일어나서 나 혼자라도 뭔가 제대로 해보겠다는 분들이 있을지 모르겠습니다. 저는 말리겠습니다. 혼자 할 수 있는 일이 아닙니다. 오히려 문제의식을 공유하고 같이 변화를 만들어 가려는 동료들을 많이 만드시는게 더 나은 변화를 만들고 오래 지속할 수 있는 비결입니다.
그럴려면, 당신이 조직에서 ‘좋은 사람’인지 꼭 생각해 보세요. 사람들이 그냥 말은 안듣지만 ‘좋은 사람’말은 듣더라고요. 주위에 늘 좋은 사람은 되기 힘들지만 부끄럽지 않은 사람이 될 필요가 여기 있습니다.
그럼에도 불구하고 잘 안될 수 있다. 그래도 앞으로 나아가라
이렇게 모든 원리를 골고루 실천하고 해나가기만 하면 100% 성공적으로 프로젝트를 수행할 수 있을까요? 안타깝게도 그런건 없습니다. 결국 일의 성패는 우리의 영역이 아니더라고요. 제품이든 사업이든. 다만 적당한 수준에서 타협하고 마무리 할 수도 있고 아니면 완전히 실패할 수도 있습니다.
겸허해져야 합니다. 그저 부끄럽지 않게 한발 두발 나아갈 뿐. 스크럼 마스터인 제 예전 동료가 저에게 해주었던 이야기가 있습니다.
“사실 애자일은 그냥 앞으로 나아가는 것에 힘쓰지 뒤돌아가는게 아니다. 잘못 결정한게 있다면 이를 수정하고 앞으로 나가는 것이다.”
이것입니다, “지속적으로 바른 방향을 찾아가는 모험을 계속하라” 이 정신만 유지하고 나아간다면 여러분이 원하는 목표를 달성할 수 있을 확률은 크게 올라갈 겁니다.
