https://www.simplethread.com/agile-at-20-the-failed-rebellion/ - Agile Manifesto(애자일 선언문)가 발표된 지 20년이 지난 지금, 명백한 두가지 사실은 ㅤ1. Agile이란 이름 붙이는데는 승리했음. 누구도 non-Agile 이라고 불리기를 원하지 않음 ㅤ2. Agile의 실행에 있어서는, 파운더들의 혁명적인 아이디어에 비해 많이 부족함 - "모두가 Agile을 한다고 얘기하지만, Agile한 사람은 거의 없음" 왜 이런 상황이 되었을까 ?
[ Whence The Manifesto : 선언문은 어떻게 시작되었나 ] - 2001년 2월, 17명의 소프트웨어 전문가 그룹이 유타의 스키리조트에서 미팅 - 며칠간의 토론을 통해 "Agile Software Development Manifesto"를 공동으로 작성
- 중요한 점은 그들이 "Practitioner(실무자)" 였다는것. 그들은 PM이나 CTO, VP Engs 등이 아니었음. 그들은 개발자, 프로그래머, 과학자, 엔지니어 였음. 그들은 그때도 계속 코드를 쓰고, 이해관계자들과 협력하여 문제를 해결하고 있었음. 이게 정말 중요함. - 다른 포인트는 Agile Manifesto가 아무것도 없는 상태에서 만들어지지 않았다는 것. 이들 중 여럿은 다들 자신이 만들었거나 전파중인 방법론을 가지고 있었음. ㅤ→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming
- 그룹의 모든 사람들이 소프트웨어 개발 경력이 많았고, 그들은 그 당시 시장의 주류였던 문서 주도의 무거운 소프트웨어 개발 프로세스를 대체할 것을 찾고 있었음. - 선언문의 핵심은 4가지의 가치에 대한 설명
"우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다: - 공정과 도구(processes and tools)보다 개인과 상호작용(Individuals and interactions)을 - 포괄적인 문서(comprehensive documentation)보다 작동하는 소프트웨어(Working software)를 - 계약 협상(contract negotiation)보다 고객과의 협력(Customer collaboration)을 - 계획을 따르기(following a plan)보다 변화에 대응하기(Responding to change)를 가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다."
[ A New Hope : 새로운 희망 ] - 2021년의 관점에서 보면 현대적인 소프트웨어 개발 관행을 당연한 것처럼 받아들이기 쉽지만, 2001년에는 이런 아이디어들이 매우 급진적이었음. - 요구사항을 모두 수집하고, 모든 기능을 평가하기전에 소프트웨어를 개발하기 시작한다구요? 미쳤군요! - 잊혀져 가는 중요한 점은 Agile이 초기에는 공개적이고 전투적으로 반 관리적(anti-management) 였다는 것
- 예를 들어 Scrum의 공동 창시자인 Ken Schwaber는 모든 프로젝트 매니저를 없애자고 주장하면서 , 프로젝트에서 PM을 빼는 것만이 아니라, 업계 자체에서 해당 직업을 없애야 한다고 했음.
"우린 프로젝트 관리자의 역할이, 복잡하고 창의적인 작업에서는 비생산적이라는 것을 발견했습니다. 프로젝트 계획으로 표출되는 프로젝트 매니저의 생각은, 문제를 가장 잘 해결하기위해 모든 사람의 지능을 모으는 것이 아닌, 계획에 적혀 있는 것으로 모든이의 창의성과 지능을 제한합니다."
- 스크럼 마스터는 거의 권한이 없었고, 이슈에 투표권도 없었습니다. 그들은 서번트 리더*였으며, 팀을 보호하고 장애물을 치워주지만, 팀을 관리하지 않았음. ㅤ→ 서번트 리더 : 부하를 섬기는 자세로 그들의 성장 및 발전을 돕고, 리더와 부하간의 신뢰를 형성시켜 조직 목표 달성에 부하 스스로 기여하도록 만드는 리더 - XP에도 원래 Tracker 와 Coach가 있었는데, 비슷하게 동작했음.
- Crystal과 Hexagonal 아키텍처의 창시자인 Alistair Cockburn은 최근 트윗 쓰레드에서 이런 얘기를 한바 있음 "스크럼은 적대적인 지역에서 엄청난 거래를 성사 시켰음: ㅤ- 경영진들은 1년에 12번, 각 스프린트후에 원하는 방식으로 방향을 바꿀 수 있었음 ㅤ- 팀은 무거운 생각과 작업을 하기 위해 인터럽트나 방향 변경없이 완전히 조용한 한달이라는 기간을 얻었음 ㅤ- 팀은 경영진의 간섭없이, Bid(우선순위를 결정하기 위한)에서 한달동안 할 수 있는 것과 할 수 없는 것을 발표할수 있었음 ㅤ- 어떤 경영진도 이보다 더 나은 거래를 해본 적이 없었음 ㅤ- 어떤 개발팀도 이보다 더 나은 거래를 해본 적이 없었음 " (역자 주: 이 트윗쓰레드는 처음에 "스크럼 팀은 스프린트에 할당된 모든 아이템을 100% 끝내야 한다는 아이디어는 어디서 나온건가요? 이건 말도 안되는데요." 라는 질문에서 시작된 답변입니다. 원문 쓰레드 전체를 보시는 걸 권해드립니다.)
- 15년 이상 Agile 팀에서 일한 공인 스크럼 마스터이고, 이 분야의 인기 있는 책을 많이 있었지만, 스크럼에 대한 아이디어를 이렇게 명확하고 간결하게 설명한 것을 본적이 없음. - 스크럼은 적대적인 환경에서 작동하도록 만들어졌음. 생각하고 탐색할 시간이 필요한 개발자들과 강압적인 관리자들간의 계약임
[ The Empire Strikes Back : 제국의 역습 ] - 어떤 면에서 Agile은 풀뿌리 노동 운동이었음. 실무자에서 시작해서 경영진까지 올라갔음. 이게 어떻게 성공했을까? - 부분적으로는 개발자의 수가 늘고, 비즈니스에 주는 가치가 증가했기 때문 - 더 큰 이유는 전통적인 워터폴 개발방식이 제대로 작동하지 않았기 때문 - 소프트웨어가 더 복잡해지고, 비즈니스의 속도가 빨라지고, 사용자의 수준이 높아지면서 모든 것을 미리 계획하는 것이 불가능 해짐. - 반복적인 개발은 수용하는 것은 논리적이었지만, 모든걸 계획했던 관리자들에게는 약간 두려운 일이 었음.
- 2000년대 중반에는 경영진들이 받아들이지는 않았었음. - 그러다 "엔지니어들이 계속 이야기 하는 이 미친 아이디어를 한번 시도해보자. 우리 지금 데드라인 어차피 못 맞추는데 얼마나 나빠지겠어?" 라는 얘기가 나옴. - 하지만 놀랍게도 워킹하기 시작. 팀은 처음에는 살짝 움츠러 들었지만(느렸지만) 점차 어떤 패턴이 각 팀에 동작하는지 알게 되면서 속도가 붙기 시작했음 - 몇번의 스프린트 후에는 작동하는 소프트웨어, 협업, 검사 및 적응하는데 시간을 들이는 것과, 그외 모든 것들의 우선순위를 정하는 것의 힘을 알게 됨
- 약 5년간은 Agile은 들어봤던 방법론에서 모든 사람이 익숙하지는 않은 것으로 바뀌어 갔음. - 2005년에는 Agile과 TDD가 진정한 차별화 요소였음 - 2010년에는 최신 소프트웨어팀들은 다 어떤 형태로든 Agile을 하고 있었음. - 적어도 컨설팅업계에서는 버블이었음. 대기업은 항상 느리게 움직였지만.
"우리가 해냈어요! 우리가 이겼어요! 모두 축하합시다" 이게 이야기의 끝이고, 브라우저의 탭을 닫아도 됩니다.
"Winning was easy, young man. Governing’s harder." "이기는 건 쉬웠어, 젊은이. 통치가 더 어려워" ㅤ→ 해밀턴(뮤지컬) 에서 묘사된 조지 워싱턴
- 불행하게도 많은 혁명과 마찬가지로, 애자일의 역사는 창시자들이 구상한 방식으로 전개되지 않았음. ㅤ→ "개인과 상호작용"을 우선시 하는 것은 Sell하기 어려운 개념이라는 것이 밝혀졌음. 프로세스와 도구를 Sell하는 것이 훨씬 쉬움 ㅤㅤ(역자 주 : 여기서 Sell 은 판매라기 보다는 남들에게 이해시킨다는 의미여서 그대로 뒀습니다.) ㅤ→ "작동하는 소프트웨어"는 비현실적인 계획과 많은 문서보다 더 만들기가 어렵다는 것이 밝혀졌음. ㅤ→ "고객과의 협업"은 신뢰와 취약성(vulnerability)이 필요하지만, 비즈니스에서 항상 존재하지는 않음. ㅤ→ "변경에 대응하기"는 종종 장기계획을 세우고 통제해야하는 경영진들에게 더 무게가 실렸습니다.
"Agile이 제대로 수행되지 않으면 종종 혼돈처럼 느껴진다는 것이 밝혀졌음"
- 하지만 이 4가지 가치가 잘못된 것은 아님 - 이 모든 것이 제대로 되려면 약간의 노력이 필요하고, 소프트웨어가 본질적으로 어지럽고 혼란스럽다는 것을 받아들이는 용기가 필요하다는 것을 의미함 - 계속 배우고 적응하고 개선하고 출시하다보면 결국에는 폭포수보다 훨씬 더 나은 곳, 훨씬 더 정직하고 현실적이고 생산적인 곳으로 갈 수 있다는 것을 이해하고 믿어야함.
"애자일 운동은 반방법론(Anti-methodology)이 아닙니다. 실제로 우리중 많은 사람들은 "방법론" 이라는 단어에 대한 신뢰가 회복되기를 원합니다. 균형이 회복되기를 원합니다. 모델링을 수용하지만, 먼지쌓인 회사 창고에 다이어그램을 넣어두기 위함이 아닙니다. 문서화를 수용하지만, 유지보수 되지 않고 거의 사용 되지 않는 수백페이지의 책을 수용하는 것은 아닙니다. 계획은 만들지만, 격동적인 환경에서 계획의 한계를 인식합니다. XP, Scrum 또는 기타 애자일 방법론의 지지자들을 'Hacker'로 낙인 찍는 사람들은 "방법론"과 "해커" 용어의 원래 정의에 대해 무지한 것입니다." - Jim Highsmith, History: The Agile Manifesto
- 이게 중요한 포인트들임. 우리는 여전히 계획과 문서를 만들고, Agile에 엄격해야함. 이건 균형에 대한 것임. - 그러나 당신의 조직이 Agile 전환에 어려움을 겪고 있고, 혼돈에 빠져있다면, 누군가가 인증,프로세스,도구 같은 구명정을 제공한다면 그리로 점프하게 됨. - 경영진은 "자기 조직화 팀" 보다 프로세스와 도구를 훨씬 잘 이해함.
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : 로그 원(의 귀환) ] - 여기서 내 3막 구조가 약간 무너짐. 왜냐면 Agile 이름을 달지 않고 돌아오는 용감한 반군은 보이지 않기 때문 (역자 주: 스타워즈 시리즈 이름에 빗대어, Agile이 아닌 다른 무언가는 나오지 않았다는 것)
- 도구 벤더, 프로세스 컨설턴트 및 전문가가 절대 제공할 수 없는 약속을 하는 경우가 많음. - 우리가 SAFe(Scale Agile Framework for Enterprise) 나 Scaled Scrum 및 다른 엔터프라이즈용 Agile 버전을 만들게된 이유 - 이런 프레임워크들은 악의적인 의도로 만들어진게 아니고, 아마도 적절한 맥락에서는 어느정도 가치가 있을 것. - 하지만, 나는 그들을 Agile이라고 부르지 않을 것 - 개인과 상호작용에 중점을 둔 방법론을 확장하려고 하면 필연적으로 문제가 발생하고 방법론의 원래 가치가 손상됨.
- 애자일 선언문 서명자이자, XP 공동 창시자인 Ron Jeffries가 2018년에 쓴 유명한 글
"개발자는 Agile을 포기해야 합니다. 'Agile' 아이디어가 제대로 적용되지 않으면, 개발자에게 더 많은 간섭을 하고, 작업시간을 더 적게 주고, 높은 압력을 주고, '더 빠르게 진행' 하는 것을 요구하게 됩니다. 이건 개발자들에게 좋지 않으며, 궁극적으로는 회사에도 좋지 않습니다. 'Agile'을 제대로 수행하지 않으면 실제 달성할 수 있는 것보다 훨씬 더 많은 결함과 더 느린 진행이 자주 발생하기 때문입니다. 종종 우수한 개발자가 그런 회사를 떠나게 되면서, 결과적으로는 "Agile"을 도입하기 전보다 효율성이 떨어지는 기업이 됩니다."
- 다른 서명자이자, 실용주의 프로그래밍의 공동 창시자인 Dave Thomas가 2014년에 쓴 유명한 글
"Agile 은 죽었다. (Agility여 영원하라) 'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다. Manifest가 대중화 되면서 Agile 이라는 단어는 지지할 것이 있거나, 청구할 시간 이나 판매할 제품이 있는 모든 것들을 끌어들이는 자석이 되어버려서, 마케팅 용어가 되었습니다.
그래서 'Agile' 이라는 말은 이제 은퇴시켜야할 때라고 생각합니다."
[ Retro : 과거로의 회귀 ] - 정말 슬픈 것은 젊은 개발자가 Agile을 폄하하고, 경영진들이 비현실적인 약속들을 도출하고, 개발자들이 엄청 많은 시간을 일하도록 부추기도록 하는 수단으로 생각하는 것을 보는 것. - 그들이 아는 유일한 Agile은 그들에게 부과된 통제 메커니즘이지, 기쁘게 받아들였던 자기 권한 부여의 도구가 아님. - 하지만, 역사와 원래의 비전에 대해 토론을 시작하는 것이 우리가 앞으로 어떻게 나아가야 할지를 기억하는데 도움이 되길 바람.
- 이럼에도 좋은 소식은 Agile Manifesto의 원칙이 20년 전과 마찬가지로 오늘날에도 현명하고 적절하다는것. 그리고 Jeffreies 나 Thomas 같은 배교자(apostates, 종교를 버린사람) 로 추정되는 사람들도 여전히 그렇게 생각함.
- 위에 언급된 글에서 Jeffries는 이렇게 얘기함 "그러나, Manifesto for Agile Software Development 의 가치와 원칙은 여전히 내가 아는 최고의 소프트웨어 구축 방법을 제공하며, 나의 길고 다양한 경험을 바탕으로 더 큰 조직에서 어떤 방법론을 사용하든 그 가치와 원칙을 따를 것입니다."
- 이 의견에 나는 동의함 - 지금 애자일에 대해 이야기 하는 것은 힙하거나 멋진 일이 아님. 애자일은 지루함. "다들 애자일 하시죠?" - 지금은 지난 20년을 되돌아보고 스스로에게 몇 가지 질문을 던질 수 있는 완벽한 시간 ㅤ→ 무엇이 제대로 되었나요? ㅤ→ 무엇이 잘못되었나요? ㅤ→ 다음번에는 어떻게 다르게 하고 싶은가요? - 다음 몇달간 원래의 12 애자일 원칙을 다시 돌아보고, 원래 의미를 맥락화하고, 현재 소프트웨어 개발환경에서 그 가치를 고려하려고 계획중
"내 희망은 창립 원칙을 연구함으로써, 과거로부터 배우고, Dave Thomas 의 말처럼 'Agile'을 포기하더라도 'Agility(민첩성)'을 유지할 수 있기를 바랍니다." | 
