내가 정말 잘 할 수 있을까? 아니 우리가 정말 자랄 수 있을까?

좋은 책은 다시 읽을때 진가가 드러나는 것 같습니다
애자일 관련 도서로 추천받은 이 책을 다시 읽어봤습니다

가깝게는 팀원들에게
멀리는 K-애자일에 지친 개발자분들에게 찐 애자일을 널리 알리고 싶어
책을 읽으면서 공감했던 부분을 골라서 발췌 및 요약해보고
글의 끝에는 애자일 프로세스로 업무를 하며 느낀점을 적어봤습니다.
원문이 더 훌륭하오니 원문을 꼭 확인해보시는 걸 권합니다

이 책은 크게 자라기, 함께, 애자일 3개 챕터로 구성되어있습니다.

자라기

더글러스 엥겔바트에 따르면 사람이 했던 작업 구분을
A,B,C 작업으로 구분할 수 있습니다

A 작업은 원래 그 조직이 하기로 되어 있는 일,
B 작업은 A 작업을 개선하는 일,
예를 들면 제품을 만드는 사이클에서 시간과 품질을 높이는 일
C 작업은 B 작업을 개선하는 일, 개선하는 능력을 개선하는 일

가장 미묘하고 또 잠재적으로 가장 영향력이 큰 것은 C 작업으로
이는 우리의 사고방식과 상호 작용 방식을 개선합니다.

동일한 조직에서 동일한 제품을 반복적으로 찍어내는 공장과 달리 복리 조직은 첫 주기에 만들어낸 결과물을 계단 삼아서 다음 주기에 조금 더 높은 위치에서 다음 결과물을 만들어냅니다.

더 빨리 자라고 싶다면(복리 조직을 구성하려면)
1) 어떻게 이율을 높일 것인가와
2) 지속적으로 현명한 투자를 하려면 어떻게 할 것인가를 고민해야 합니다

저자가 깨달은 몇가지 힌트

자신이 이미 갖고 있는 것들을 잘 활용하라
외부 물질을 체화하라
자신을 개선하는 프로세스에 대해 생각해 보라
피드백을 자주 받아라
자신의 능력을 높여주는 도구와 환경을 점진적으로 만들어라

—

실력을 높이기 위해선 의도적 수련 (Deliberate Practice) 이 중요하고 나의 실력과 작업의 난이도가 비슷해야 합니다. 하지만 내실력에 맞는 혹은 그보다 약간 어려운 일들만 할수는 없습니다. 여기에 실력과 난이도가 맞지않아 지루함, 불안함을 느끼는 상태에서 몰입할 수 있는 상태로 이동할 수 있는 전략들이 있습니다.

작업 난이도와 실력에 따른 몰입전략 (출처: 김창준, 함께 자라기 애자일로 가는 길)

지루함을 느끼는 경우: a1 실력 낮추기

a1의 경우, 작업의 난이도는 그대로 두고 실력을 낮추는 전략입니다.
프로그래머의 예를 들자면 평상시 즐겨 쓰던 보조 도구를 일부러 안쓰는 겁니다

지루함을 느끼는 경우: a2 난이도 높이기

a2는 실력은 그대로 두고 난이도를 높이는 전략입니다.
흔하게 쓰는 방법은 자기에게 요구되는 수준을 더 높게 여기는 겁니다.
하루 만에 개발하라고 주어진 업무인데 지루한 느낌이 드니 한 시간 만에 할 수 있는 방법 고안해보기. 또 다른 방법으로는 공식적으로 안 해도 되는 업무를 자신의 의지로 추가로 하는 경우도 있습니다. 리팩터링을 하거나 자동화 테스트를 달거나, 혹은 자신만의 도구를 개발하거나 하는 것들이죠.

불안함을 느끼는 경우: b2 실력 높이기

실력을 높여서 몰입 영역으로 들어가는 전략입니다. 나보다 뛰어난 전문가의 도움을 받거나 내 능력을 확장시켜 줄 수 있는 도구들을 찾아 쓰면 됩니다.

불안함을 느끼는 경우: b1 난이도 낮추기

b1은 불안함을 느낄 때 난이도를 낮춰서 몰입 영역으로 들어가는 전략입니다.
간단하면서 효과적인 방법은, 자신이 맡은 일의 가장 간단하면서 핵심적인 결과물, 즉 아기 버전을 첫 번째 목표로 삼는 겁니다.

—

프로그래밍 언어 배우기의 달인

튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다
공부할 때 표준 라이브러리 소스코드를 읽는다
공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다

—

실수는 예방하는 것이 아니라 관리하는 것이다

마이클 프레제는 회사에서의 실수 문화에 대해 연구를 했습니다. 그에 따르면 실수 문화에는 크게 두 가지가 있습니다. 실수 예방과 실수 관리.

실수 예방 문화에서는 실수 한 사람을 비난하고 처벌하고, 따라서 실수를 감추고 그에 대해 논의하기 꺼리며 문제가 생겼을 때 협력도 덜하게 됩니다

반대로 실수 관리 문화에서는 실수가 나쁜 결과를 내기 전에 빨리 회복하도록 돕고, 실수를 공개하고. 실수에 대해 서로 이야기하고 거기에서 배우는 분위기가 생깁니다

함께

소프트웨어 관리자의 개선 우선순위

조엘 테스트, 조엘 스폴스키 라는 사람이 만든 개발팀 평가 테스트 입니다

소프트웨어 개발 비용을 결정하는 요소는 무엇일까요? 다음 네 가지 개발 비용을 주도하는 요소의 분류에서 가장 중요한 것부터 덜 중요한 것으로 나열해보세요.

도구 : 소프트웨어 개발에 사용하는 모든 종류의 도구를 말한다

사람 : 사람들의 능력과 경험을 말한다

시스템 : 제품 자체의 복잡도, 요구되는 신뢰성, DB크기

관리 : 사람을 배정하고 작업 분배를 조정하고 위임하는 것, 작업 모니터링, 동기를 고취하는 것, 작업 조건/환경을 개선하는 것, 리스크를 일찍 확인하고 적절한 조치를 취하는 것, 요구사항과 설계 스펙이 비준되게 돕는 것 등

실제로 프로젝트가 아주 성공하거나 실패하거나 하는 이유는 첫 번째가 관리라는 변수 때문이었습니다.

하지만 각 분류별로 실제로 개선 시도가 얼마나 있었는지 확인해 보니 가장 많은 개선 노력이 있었던 분류는 바로 ‘도구’ 였습니다.

도구 부분에서 상당한 개선을 이뤄내면 비용 면에서 3배정도 개선을 얻을수 있지만, 관리 부분에서 상당한 개선을 이뤄내면 64배 정도의 개선을 얻을 수 있습니다.

—

신뢰를 깎는 공유인가 신뢰를 쌓는 공유인가

신뢰를 쌓는 데에 널리 사용되는 한 가지 방법은 투명성과 공유, 인터랙션입니다
그런데 정말 그렇게 공유하고 소통하면 신뢰가 쌓일까요?

두 명의 디자이너가 각자 공익단체를 위한 광고를 디자인합니다
주어진 시간동안 개별적인 디자인이 끝나면 두 사람은 한 방에 모여서 서로 디자인을 공유하고 피드백을 나누며 인터랙션을 합니다

하나 공유(share one), 최고 공유(share best), 복수 공유 (share multiple) 이 3가지 조건에 따라 공유 전후의 신뢰가 어떻게 바뀌는지 측정했습니다

디자이너들이 하나의 디자인을 만들고 하나를 공유(하나 공유)하거나 여러개의 디자인을 만들고 그중 자신이 가장 잘했다고 생각하는 것을 골라서 공유(최고 공유) 후에 신뢰감이 더 떨어졌습니다. 각자 여러 개의 디자인을 만들고 그걸 모두 공유한 경우에만 신뢰가 유의미하게 증가했습니다

하나 공유나 최고 공유의 경우 우리는 공유 자리에 기대감보다 불안감을 갖고 갈 겁니다.또 상대의 시안을 보고 솔직한 의견을 내는것도 꺼리게 될 겁니다. 나의 작품이 하나밖에 없으니 ‘작업물 = 나’ 가 되는 것이죠

반대로 복수 공유는 여러 개를 준비했으니 그중 하나를 두고 뭐라고 해도 나에 대한 공격은 아닌 겁니다. 또 여러 개이니 상대적으로 이야기를 할 수 있어 말하는 사람도 편하고 듣는 사람도 좋다는 이야기랑 안 좋다는 이야기를 같이 들으니 마음이 좀 더 편합니다.

복수 공유는 (같은 시간을 투자했을 때) 신뢰도 높아지고 성과도 더 좋았습니다. 이렇게 복수 개 아이디어를 프로토타이핑하고 공유했을 경우 팀의 결속이 강화되고 오너십을 느낀다는 연구는 더 있었습니다.

—

객관성의 주관성

결론은, 객관성이라고 하는 것은 상대적이며, 내가 생각하는 객관이 상대의 객관이 아닐 수 있고, 그렇기 때문에 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 한다는 말입니다. 그런 이유로 설득을 하기 위해 ‘객관적’ 자료를 모으는 부분 이상으로 상대를 이해하는 데 많은 시간을 투자해야 합니다

—

이것도 모르세요?

홍춘이가 사수이고 술퍼맨이 부사수라고 칩시다. 홍춘이가 술퍼맨에게 일을 하나 시켰습니다. 사수가 의사소통 및 멘토링, 코치 능력이 떨어지는 경우입니다

술퍼맨 : 이런 문자열을 잡아내려면 패턴을 어떻게 써야하는지 감이 잘 안오네요. 정규식이 익숙하질 않아서…
홍춘이 : 뭔데 그래요? (한 번 보고는) 뭐야, 이런 것도 모르세요?
술퍼맨 : …
홍춘이 : 아니, 이 정도는 기본 아니에요. 요즘은 대학에서 이런 것도 안가르치나. 유닉스 정규식 man 페이지라도 읽어보셨어요?
술퍼맨 : 아니요.
홍춘이 : 그럼 읽어 본 게 도대체 뭐에요?
술퍼맨 : 딱히…
홍춘이 : 그러니, 맨날 이모양이죠. 제가 매일 도와드릴 수는 없잖아요? 저기 회사 서가에 가면 정규식 교과서 하나 있거든요? 그거 좀 읽어보고 나서 그래도 해결 안되면 저한테 오세요. 아셨죠?
술퍼맨 : (기어들어가는 목소리로) 네…
술퍼맨은 이 일 이후로 홍춘이에게 질문을 덜 할 것이고, 어지간해서는 질문을 안 할 겁니다.

십중팔구는 문제가 점점 커지고 있는 상황에서 혼자 문제를 끌어안고 있을 테고, 결국에는 팀 전체에 타격을 주는 상황이 올지도 모릅니다.
공감해주고, 잘 들어주고, 그 사람의 멘탈 모델을 이해하는 코칭이 필요 할 것입니다.

상대가 어떤 멘탈 모델을 갖고 있는 지 파악하려고 하면
어떤 식으로 개념을 이해하고 있는지, 모르는 문제를 만났을 때 어떻게 해결하려고 시도하는지, 자신의 답이 맞는지를 어떻게 확인하는지 등을 알 수 있습니다.

이렇게 머릿속 지도와 사고 흐름을 엿보게 되면 그 사람이 이 상황에서 왜 이런 접근을 할 수 밖에 없었는지 알기 때문에 좀 더 정확하고 효과적인 제안을 해줄 수 있습니다.

—

하향식 접근의 함정

우리가 실생활에서 만나는 대다수의 문제는 잘 정의되지 않은 문제입니다. 사실상 뭔가 만들어내야 하는 문제, 즉 디자인이 개입되는 것은 거의 다 제대로 정의될수 없는 문제입니다.

전문가들은 자신이 자주 접하지 않았던 문제, 어려운 문제, 혹은 잘 정의되지 않은 문제를 접하면 접근법을 바꿉니다. 탑다운과 바텀업을 섞어 씁니다.

페닝턴의 ‘프로그래밍에서의 이해 전략’ 이라는 연구에서는 전문 프로그래머 중, 성과가 높은 사람과 그렇지 못한 사람을 비교했습니다. 연구에 따르면, 고수는 프로그램을 연구하면서, 프로그램에서 이해한 것을 도메인 어휘로 번역합니다. 그러고는 도메인 어휘를 프로그램상의 어휘로 다시 바꿔서 검증합니다.

조직 내에 모든 레이어를 꿰뚫는 전문가가 있으면 좋겠으나 많은 경우 그런 사치를 부릴 여유가 없습니다. 밖에서 어떤 조직을 관찰했을 때 마치 그 속에 모든 층위를 꿰뚫는 전문가가 있는 것 같이 만들 수는 없을까?

이 문제를 해결하기 위해서는 기본적으로 두 가지 접근이 가능합니다.

한 사람이 다기능을 갖추도록
협력이 쉽게 되도록

과거 IBM에서 “돈을 얼마든지 써도 좋으니 전 세계에서 뛰어난 팀들은 어떻게 일하는 조사”한 결과가 흥미롭습니다. 뛰어난 팀이라면 거의 한 팀도 빠지지 않고 공통적으로 갖고 있는 특징이 몇 가지 있었는데, “삼투압적 의사소통”이 거기에 속합니다.

발신, 수신인이 정해져 있고, 화살을 쏘는 방식이 서양의 의사소통 모형이라면 삼투압적 모형에서는 은연중에 서로 간에 정보가 스며드는 겁니다.
그렇게 하려면 사람들이 물리적으로 가까운 거리에 있어야 유리합니다.
누군가 질문을 했을때 다른 직무의 사람이더라도 끼어들어 새롭고 가치 있는 정보를 줄 수 있습니다.

그리고 한번에 처리되는 일의 양을 줄여야합니다. 배치 사이즈를 줄여서 지속적 흐름을 만들고 짧은 시간 내에 탑, 바텀을 오가게 합니다.

흔히들 말하는 개발의 5단계도 비슷합니다. 분석,설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간에 얼마씩 배치할까로 고민하지 말고, 어떻게 해야 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민해야 할 것 입니다.

—

전문가팀이 실패하는 이유

저는 뛰어난 사람을 뽑아두면 어떻게든 잘 할거라는 사고가 지나치게 낙관적인 기대라고 생각합니다. 어떤 식으로 협력할지 계획을 세우지 않고 자기들이 알아서 하게 놔둔 전문가팀은 비전문가로만 구성된 팀보다 훨씬 못한 결과가 나왔습니다. 그 원인은 정보 공유의 차이에 있었습니다. 협력 개입이 된 경우, 팀원들은 정보를 공유해서 더 통합된 해결책을 제시했습니다.

정리하자면,
전문가들 모아서 팀 만든다고 잘하는 것 아니고
오히려 성과가 떨어질 수 있고
정보 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하며
소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움이 된다.

—

구글이 밝힌 탁월한 팀의 비밀

팀에 누가 있는지보다 팀원들이 서로 어떻게 상호작용하고 자신의 일을 어떻게 바라보는지가 훨씬 중요
5가지 성공적 팀의 특징을 찾았는데, 그중 압도적으로 높은 예측력을 보인 변수는 팀의 심리적 안전감 이었다
팀 토론 등 특별히 고안된 활동을 통해 심리적 안전감을 개선할 수 있었다.

여기에서 말하는 심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌하거나 놀림받지 않을 거라는 믿음을 말합니다.

어떤 새로운 프로그램을 도입하기 전에 리더와 관리자가 매일매일 팀원들과 갖는 마이크로 인터랙션에서 다른 행동 양태를 보여줘야 합니다.

팀원이 불편한 문제를 제기하거나, 어리석어 보이는 질문을 하거나, 부족한 의견을 얘기하거나, 어처구니없는 실수를 저지를 때 여러분은 어떤 마이크로 인터랙션을 보여주고 계신가요?

—

쾌속 학습팀

단순히 기술적 탁월함만을 갖춘 사람보다는 학습 환경을 만들 수 있는 리더가 필요하다는 것입니다. 학습이 빠른 팀은 팀원을 뽑을 때부터 달랐습니다. 단순한 업무 수행 능력뿐만 아니라 다른 사람과 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신 있게 의견을 제안할 수 있는지 등을 보고 뽑았습니다.

또한 속도가 빠른 팀은 개개인이 새로운 기술을 획득해야 한다고 보지 않고,
함께 일하는 새로운 방법을 만들어야 한다고 생각했습니다.
팀원들은 모두 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험해 보는 걸 강조했습니다.리더는 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 등을 강조했습니다.

—

프로젝트 확률론

소프트웨어 공학 쪽의 연구에 따르면 사람들이 통상적으로 추정하는 소요시간에 적어도 2~3배를 해야 80% 정도의 확률로 마칠 수 있는 시간이 나온다고 합니다.

어떤 관리자에게 12가지 할 일이 있고 그 일을 할 사람도 12명이 있습니다. 관리자는 어떻게 해야 할까요?

관리자가 12명 모두에게 단지 3가지 일만 주고 서로 협동해서 그 일을 하도록 요청하는 것입니다.

사람들은 작업을 완료하기 위해 자기 조직화할수 있는 권한이 있고, 또 매번 다르게 조직화할 수도 있을 겁니다. 이 방식이 잘 돌아가는 이유는 사람들이 ‘관심사의 섞임’을 통해 서로에 대해 엄청나게 많은 것을 매우 빨리 배울 수 있기 때문입니다.

애자일은 좋은 일은 공유를 해서 한 사람만이라도 중요한 통찰이 있었다면 이걸 공유해서 ‘또는’ 확률로 만들고, 버그 같이 나쁜 일에 대해서는 여러 사람이 중복 검토를 해서(짝 프로그래밍, 코드 공유, 코드 리뷰 등) 모두가 실수해야지 구멍이 나게 ‘그리고’ 확률로 바꾸는 것입니다.

애자일

애자일의 씨앗

고객에게 매일 가치를 전하라.

이 문장의 단어들은 각기 모두 중요합니다. 각 단어에 대해 다음과 같이 여러 가지 질문을 해볼 수 있습니다.

고객에게
우리의 진짜 고객은 누구인가?

매일
어떻게 점진적으로 가치를 전할 것인가?
어떻게 보다 일찍, 그리고 보다 자주 가치를 전할 것인가?

가치를
무엇이 가치인가?
지금 우리가 하고 있는 일이 정말 가치를 만드는 일인가?
지금 가장 높은 가치는 무엇인가?
비슷한 수준의 가치를 더 값싸게 전달하는 방법은?

전하라
가치를 우리가 갖고 있지 않고 고객에게 정말 전달하고 있는가?
고객이 정말 가치를 얻고 있는가

—

애자일 도입 성공 요인 분석

애자일이 프로젝트 성공에 도움이 되었냐는 질문에 매우 그렇다고 답한 그룹에서는 약 60%가 고객 참여를 도움이 된 실천법으로 꼽은 반면 애자일이 프로젝트 성공에 도움이 되었는가에 그저 그렇다, 아니다, 매우 아니다 로 답한 그룹에서 고객 참여를 선택한 조직은 없었습니다.

고객 참여 다음의 세 가지는 성공 기여도가 비슷하고, 리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 순입니다.

그런데 많은 조직들이 고객 참여와 코드 공유를 뒤로 미룹니다. 두 가지 모두 “사람”이 중심이 되기 때문입니다. 고객 참여는 고객을 설득해야 하고, 코드 공유는 개발자를 설득해야 합니다.

전문가팀은 무섭고 두렵더라도 중요한 일이라면 그 일을 안하는 리스크를 인식하고 꾸준히 시도한다는 점에서 초보팀과 다릅니다.

애자일에 대해 어느 정도 이해는 하고, 실험도 좀 해봤다 싶은 조직에서 성공 기여도를 높이려면 짧은 반복 개발 주기, 고객 참여, 코드 공유에 관심을 기울여야 합니다.

고객 참여란 고객 혹은 고객을 대표하는 사람의 참여입니다. 진정 중요한 것은 프로젝트의 성패를 좌우하는 사람과 최대한 가까운 사람을 참여시키려고 우리가 계속 노력하는 것입니다.

신입사원에게 어떤 조언을 해주겠냐는 질문에 대해, 높은 성과를 내는 엔지니어는 ‘다른 사람과의 협력’을 훨씬더 자주 언급했습니다.

리뷰 회의나 다른 사람과 상담하는 등의 의사소통과 협력 활동에서는 전문가가 훨씬 많은 시간을 사용한다는 것이 밝혀졌습니다.

탁월한 엔지니어들은 프로젝트 전반에 대한 큰 그림을 가지려고 하고, 경영진에게 더 적극적인 태도로 다가가고 다른 엔지니어들을 도와줍니다.

—

당신의 조직에 새 방법론이 먹히지 않는 이유

새 프로젝트를 진행할 때에 우리가 어떤 방법론을 쓰느냐는 문제보다도 누가 참여하는가가 훨씬 더 압도적으로 중요한 문제가 아닐까요?

예를 들어 애자일 방법론 도입을 원하는 팀장이라면 “나는 어떤 팀장인가”를 먼저 자문해봐야 하지 않을까 싶습니다. 내가 어떤 팀장인지가 전혀 바뀌지 않으면서 새 방법론만 도입한다고 무슨 효과가 있을까요.

—

애자일을 애자일스럽게 도입하기

“애자일을 진행하는 가운데 가장 빈번히 빚어지는 폐단은 무엇인가?”

예컨대 애자일은 불확실한 상황에 대한 접근법인데, 애자일을 도입할 때 확실성 위에서 진행하려고 한다면 문제가 된다.

현명한 전략은 정해진 수순을 따르는 것이 아니라 곁에 있는 사람들과 함께 주변을 탐색하고 조금 나아가고 확인하고를 반복하면서 우리의 현 맥락에 맞는 좋은 전략들을 스스로 만들어 나가는 것이 아닐까 합니다.

Photo by FORTYTWO on Unsplash

팀이 애자일 프로세스로 일한지 1년 넘는 시간이 되었습니다.
2주 단위의 스프린트는 이제 30회차를 진행중이고
그동안 팀구성원도 많아졌고 애자일 프로세스를 진행하는 방식도 조금씩 바뀌었습니다.

그래도 이정도 진행해왔으면 애자일을 이해할 법한데
항상 애자일을 제대로 적용하고 있는지 스스로에게 질문이 생겼습니다.

우연히 집어 들게 된
이 책 거의 대부분의 챕터에 다시 읽기 위해 표시를 해두고
하이라이팅을 하면서 아! 하는 순간들이 있었습니다.

책을 다시 읽는 시점에 공교롭게도 새롭게 시작하는 TF에 속하게 되었는데
프로젝트 매니저 분이 가장 많이 시간을 들여서 진행하는 부분은 관리였습니다.

TF 내 진행해야할 태스크를 분류하고 역할을 배정하고
일주일단위로 각 분과가 어떻게 일이 진행되고 공유되어야하는지를 정리하셨습니다.
정리가 진행된 툴은 새로운 도구라기보다 우리가 흔히 알고있는
메모장이나 엑셀에서 정리가 되었습니다.

팀이 새롭게 구성되거나 새로운 일이 시작되면 우리는 보통 어떤 툴을 사용할지 의논하는데 생각보다 많은 시간을 사용하는 걸 보게됩니다.

적합한 툴을 찾는 일은 물론 중요하지만 프로젝트 매니저 분은 경험적으로
프로젝트 수행 프로세스를 정의하고 리스크를 관리하는 게
무엇보다 중요함을 알고계신 겁니다.

공유에 있어서도 우리는 공유한다는 것 자체에만 신경을 써서
공유를 했음에도 상대방을 설득하기 어려운 상황에 처하게 됩니다.

공유의 조건을 나눠 실험을 설계해
선택지가 1개인 경우와 선택지를 여러개를 제공하는 부분은 인상깊었습니다.

내가 생각하기에 최고안만 딸랑 한개 공유할 게 아니라
상대방과의 원활한 논의를 위해서 고려했던 다른 안을 함께 제시해서
서로의 생각을 주고받을 수 있는 환경을 마련하는게 중요합니다.

우리가 애타게 찾던 애자일에 성공하는 한가지 정답은 없는 것 같습니다.

변화하는 새로운 환경에서 우리의 고객과 끊임없이 자주 이야기하고
발생한 에러에 숨어있는 팀의 일하는 방식에서 개선할 부분이 없을지 계속 찾고
개인은 주어진 일을 좀더 몰입할 수 없을지 난이도와 실력을 조정하는 일을 실험할 때에

우리는 답을 찾을 것입니다. 늘 그래왔듯이