티스토리 뷰
애자일 ... ?
개발자로 스타트업에서 처음 커리어를 시작하면서 들었던 협업방식 중 하나였다.
당연히 스타트업에서는 해당 방식으로 일하는걸 추구했고 나도 동의했다.
개념적으로는 알고 있다고 생각했고 이를 현업에 적용하려고 노력했었다.
하지만 돌이켜보면 잘 동작했었나...? 라는 생각이 든다.
그때 그리고 책을 읽기전 최근까지도 애자일을 사실 잘 몰랐다.
그냥 스플린트를 주기적으로 하면서 계획과 회고를 반복하는게 전부였다고
긴급하게 들어오는 일정을 우선순위를 잘 매겨 처리하면 그게 애자일이라고 생각했었다.
책을 읽고 나니 애자일에 대한 정의가 새롭게 나에게 인식되었다.
애자일은 하나의 문화이고 그걸 수행하는 방식은 여러 방법이 있으며
굳이 스플린트라는 형식에 갇혀있지 않아도 된다는걸 이해했다.
그렇다고 이전에 내가 경험한 업무 방식을 매도하는건 아니다.
그때는 그게 최선이었으니까,
내가 하고 싶은대로 하고 싶어도 권한이 거기까지였던,
의견을 내지만 결정을 내가 할 수 없었던 환경이였을뿐이다.
책에서 중요하게 얘기하는건 두가지라고 볼 수 있다.
첫번째, 애자일한 방식에는 피드백이 중요하다.
두번째, 피드백을 빠르게 받기 위해 빠른 실행과 빠른 결과가 중요하다. 그게 성공이든 실패이든.
피드백이 중요하다.
개발자로 일하면 당연히 피드백이 중요하다는걸 알고 있다.
코드리뷰를 받으면 당연하게 인식되기 때문이다.
피드백을 받으면 내가 틀린지 아닌지 알 수 있고
그렇게 결정된 의견은 정답이라고 합리적이라고 생각이 된다.
같이 결정한 내용이라고 생각되어 부담도 적어진다.
하지만 나도 같이 결정한 의견이라고 생각하고
공동의 책임을 가져야하는데
실제로는 결정된 사안이 잘 안되면
티를 내지는 않아도 리더 탓을 했다.
물론 같이 결정한 의견에 내 의견이 항상 포함되었냐?
그건 아니다.
하지만 그래도 나와 팀의 의견이였다.
내가 타당하게 설득하지 못한거였다.
책에서는 말한다.
애자일은 서비스에 대한 가치관을 공유하면
이후에 의견을 내서 바로 실행하고 결과를 빠르게 받아보는것이라고
이전 기억을 떠올리면
실행을 나나 나와 잘 생각이 잘 맞는 사람끼리는 빨리 결정해서 실행했다.
그리고 실행했으니 애자일하다고 생각했었다.
하지만 이는 반쪽짜리다.
피드백이 없었다.
리더의 피드백이 있고 긍정적이여서
다음 스텝을 가면 경영자의 피드백이 기다리고 있다.
그리고 그 이후에 실제 시장의 피드백이 기다리고 있다.
최종 서비스 타겟에 대한 피드백이 올바르고 정확하게
팀내에 공유된적이 많지 않아 더더욱 가짜 피드백에 해매였던거 같다.
매번 실행을 열심히하고 의견을 낸다고 생각하지만
진짜 피드백이 없어 지쳤던거 같다.
그걸 리더를 탓하고 나는 문제 없다고 생각했었다.
그래서 지금은 ... ?
현재는 일을 하다보니 어느정도 권한과 입지가 생겼다.
조금 더 진짜 피드백을 위해 노력할 수 있다고 생각한다.
하지만,
회사라는 조직은 인원이 많아질수록 생각을 일치시키기 힘들다고 생각한다.
당장에 나와 일하는 팀원들까지는 가치관을 공유하고 같은 방향으로 빠르게 움직일 수 있다.
그렇지만 유관부서, 경영진까지 같이 가치관을 공유하고 기민하게 합을 맞추어 동작할 수 있는지는 모르겠다.
그래서 팀에서 결정된 가치관대로 행동하고 유관부서 및 경영진에게 공유하고 전파시키는게
팀내 권한이 있는 사람이 애자일을 그나마 실천할 수 있는 방법이라고 생각한다.
쉽자는 않다고 생각한다.
설득의 연속일 것이다.
또 설득을 당할 수 있다.
우리의 의견이 틀렸을 수 있기 때문이다.
그걸 팀에 알리고 다시 가치관과 의견을 수정하여야한다.
이렇게 한다면 팀 모두가 진짜 피드백을 받는다고 느끼지 않을까 생각한다.
애자일을 온전히 잘 실천할 수 팀 또는 조직을 만드려면
많은 시간과 노력, 그리고 협력이 필요하다는걸 알았다.
애자일이 기민한 조직이라는 뜻이라고
그 조직이 기민하게 만들어지는건 아니다.
오히려 더 그런 조직을 만들기위해 오랜 시간과 공이 들어간다.
그래도 애자일 문화를 너무 공감하고 한번쯤 진짜를 경험하고 싶다.
그렇기 때문에 지금 내가 할 수 있는 범위에서 노력을 해보려 한다.
가치관을 공유하고 우리의 의견을 내고 진짜 피드백을 얻으려 한다.
빠른 실행과 빠른 결과
진짜 피드백을 얻기 위해 부단히 해야하는 행위이다.
그러기 위해서는 팀의 일치된 생각과 의견이 중요하다.
그걸위해서는 팀원간의 신뢰가 가장 중요하다고 생각한다.
신뢰가 없이 같은 생각과 의견을 낸다는건
서로 눈을 감고 젠가를 쌓는다는 것과 같다.
물론 저런 방식으로도 끝까지 쌓아 올릴 수 있다.
하지만 그건 로또 1등에 당첨되는 확률과 같다.
운에 기대서 일할 수 없는것 아닌가.
신뢰를 쌓아서 서로가 눈을 뜨고
젠가를 쌓으면 빠르게 전부 쌓을 수 있고
그 결과에 대해 피드백을 빠르게 받을 수 있지 않은가.
신뢰를 가지기 위해 작은거부터 맞춰가면서 서로간의 공감대를 형성해야한다.
공감대가 가치관으로 이어지고 점점 팀의 의견을 내는데 속도가 붙을 것이다.
팀의 의견이 빠르면 실행도 그에 대한 결과도 그에 따른 피드백도 가속화된다.
그러기 위해서 제일 중요한건
내가 먼저 남을 신뢰를 하는것이다.
먼저 믿어주지 않는데 어찌 상대가 나를 믿어주겠는가.
특히 사회적으로 신뢰 자산이 없다면 더더욱 그렇다.
결국 신뢰를 쌓고 공감대를 얻은 뒤
팀원들과 자율적인 의견을 나누고 피드백을 주고 받으면
자연스럽게 애자일 문화를 가진 조직이 된다고 생각한다.
그래서 지금은 어떻게 하고 있는가
현재는 한 팀에서 어쩌다보니 관리자로 근무하게 되었다.
그냥 지금은 이런 자리를 맡게된 이유가
경영진의 나름의 판단이 작용해서 그런거겠지,
나에 대한 신뢰자산이 경영진에게 쌓였나보다
라고 생각하고 있다.
위에 지금까지 적었던거처럼 신뢰를 주고 받으려 노력하고 있다.
조금 시간이 걸렸지만 현재 빠르게 팀 내에서 의견을 결정하고
실행해보고 있는 단계이다.
더 이상 스플린트라는 족쇄로 계획과 회고를 강제하지 않고 있다.
단지 어떠한 목표와 기간만 정해두고 일들을 각자 정의하고
결과물을 만드려 부단히 노력 중이다.
현재 운이 좋게도 좋은 팀원분들과 좋은 리더를 만나서
덕분에 팀 전체적으로 순항 중에 있다고 느껴진다.
앞으로 현재 팀에서 나온 결과가 진짜 피드백을 받을 수 있게
유관부서, 경영진, 시장에 적극적으로 팀의 가치관을 공유하고 설득할 것이다.
그렇게해서 결과물에 대한 피드백을 우리가 빠르게 흡수하여
더 좋은 문화, 결과물을 만들어내어 이후 서로가 다른 팀, 다른 회사가 되어도
서로 간의 신뢰자본을 이어가는 팀이, 사람이 되었으면 좋겠다고 생각한다.
비고
'독서' 카테고리의 다른 글
'당신은 결국 무엇이든 해내는 사람'을 읽고 쓰는 중심이란 무엇인가 (2) | 2024.02.09 |
---|
- Total
- Today
- Yesterday
- CI
- deploy
- 독서
- node module
- TanStackQuery
- Micro Frontend Architecture
- zero install
- 상태관리전략
- 당신은 결국 무엇이든 해내는 사람
- vue
- test
- 서버상태관리
- Style
- MFA
- subrouting
- vue3
- Flutter
- Module Federation
- error handle
- 프론트엔드아키텍처
- pnpm
- yarn-berry
- defineProps
- DevOps
- Infra
- 프론트엔드최적화
- frontend
- aws
- 독후감
- design system
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |