애자일이란? 실천을 통해 발전하는 철학

원래 소프트웨어 개발 팀을 위해 고안된 Agile은 이제 전 세계 산업 및 기업을 위한 최고의 프로젝트 관리 접근 방식입니다. 매력은 단순성과 유연성에 있습니다. Agile은 규범적 관행이 없기 때문에 채택 가능성이 높습니다. 그러나 여러 회사에서 애자일 변환을 안내할 때 이러한 유연성이 애자일의 의미에 대한 오해를 불러일으키기도 한다는 사실을 알게 되었습니다. 많은 기업들이 철학 자체를 이해하는 것보다 애자일에서 파생된 프레임워크를 고수하는 것을 우선시합니다.

대신, 애자일 팀을 구성하고 안내하는 프로젝트 관리자와 코치는 애자일 사고 방식을 채택하고 철학의 핵심 가치와 원칙을 본질적으로 내면화하는 훈련을 시작해야 합니다. 그래야만 프로젝트 요구 사항에 가장 적합한 것을 기반으로 Agile 프레임워크의 사례를 결합, 사용자 지정 또는 생략해야 합니다.

Agile의 역사적 발전을 추적하고 창립 원칙을 회사 및 팀의 특정 요구에 연결함으로써 이 기사는 프로젝트 관리자가 Agile 혁신을 위한 최적의 미래를 만드는 데 도움이 될 수 있습니다. 다음 사례에서 알 수 있듯이 Agile은 엄격하게 프로젝트 관리 접근 방식이 아니라 실제로 지속적으로 발전하는 제품 개발 철학으로 간주되어야 합니다.

민첩한 선례

2001년에 처음 컴파일된 "애자일 소프트웨어 개발을 위한 선언문"은 4가지 핵심 가치와 12가지 원칙의 간결한 모음으로, 규칙과 많은 문서로 가득 찬 선형적이고 프로세스가 많은 접근 방식에 대한 급진적인 대응이었습니다. 그러나 애자일의 역사는 수십 년 전에 산업 제조를 합리화하는 방법에서 시작되었습니다.

반복적 개선에 중점을 둔 철학의 선행 모델인 Plan-Do-Study-Act 모델은 Bell 연구소의 물리학자이자 통계학자인 Walter Shewhart가 1930년대에 개발했습니다. 제2차 세계 대전 후 그의 제자 W. Edwards Deming은 이를 Toyota의 기차 관리자에게 적용했습니다. 이 방법은 효율적인 구축-측정-학습 루프를 통해 린 사고 방식의 주요 원천인 Toyota Production System의 개발에 필수적이었습니다.

1970년대에 Barry Boehm이 소프트웨어 개발에 필요한 노동력과 시간을 정확하고 객관적으로 추정하기 위해 반복 프로세스를 사용하여 광대역 델파이 기술을 제안하면서 개념이 더욱 발전했습니다.

1980년대 중반 개인용 컴퓨터의 보급과 함께 제품 및 서비스로서의 소프트웨어가 사람들이 비즈니스를 하는 방식의 초석이 될 것이 분명해졌습니다. 전문가들이 소프트웨어 엔지니어링에 대한 점진적이고 반복적인 접근 방식에 진지한 관심을 갖기 시작하면서 Agile은 우수한 개발 및 관리 접근 방식으로 Waterfall 프로세스를 능가했습니다.

연구원들은 경쟁사보다 더 빠르게 혁신하고 있는 제조업체가 제품의 수명 주기를 통해 제품을 이동시키기 위해 다학제적이고 팀 중심적인 방법을 사용하고 있음을 발견했습니다. 이것은 Jeff Sutherland가 1993년 스크럼 프레임워크를 발명한 데 영감을 준 것으로 널리 알려져 있습니다. 이를 통해 표면상 불가능한 프로젝트를 일정과 예산 내에서 최소한의 버그로 완료할 수 있었습니다.

이러한 선행 사례에서 나온 이론상의 애자일 가치는 반복적인 개발, 협력적인 팀워크 및 정확한 평가에 중점을 두고 실제로 애자일을 사용하면서 입증되었습니다.

애자일이란 무엇인가?

기업이 애자일 작업 방식을 계속 채택함에 따라 철학의 틀이 의도했던 것보다 더 규범적으로 만들 위험이 있습니다. 내 경험에 따르면 애자일을 채택하려는 리더는 프레임워크 또는 특정 관행 및 관련 명명법에 너무 많은 초점을 맞추고 가치와 원칙에는 충분하지 않습니다.

애자일 원칙을 전달하는 데 앞장서고 있는 실무자들이 잘 알고 있듯이 애자일 혁신을 시도하는 모든 조직은 자신에게 적합한 접근 방식을 찾고 적용해야 합니다. 나는 팀에게 선언문의 가치와 원칙을 따르는 방법을 보여주고 스크럼, 칸반, 익스트림 프로그래밍(XP)과 같은 프레임워크에서 영감을 얻어 실제로 구현함으로써 이 학습 과정을 촉진합니다.

매니페스토의 신조는 이제 Agile 프로젝트 관리자에게 제2의 천성입니다.

1. 프로세스 및 도구에 대한 개인 및 상호 작용
2. 포괄적인 문서에 대한 작업 제품
3. 계약 협상을 통한 고객 협업
4. 계획에 따른 변경에 대한 대응

그러나 선언문에서 이러한 원칙을 따르는 경고는 종종 간과됩니다. "즉, 오른쪽 항목에 가치가 있지만 왼쪽 항목에 더 가치가 있습니다." 많은 애자일 실무자들은 결국 오른쪽의 가치를 무시하고 왼쪽의 가치에만 집중하게 됩니다. 결과? 프로세스가 많은 프레임워크를 맹목적으로 따르는 것의 반대: 프로세스가 전혀 없고 똑같이 문제가 있습니다.

오른쪽과 왼쪽에 있는 항목 간의 적절한 균형을 맞추는 것이 Agile 변환을 안내하는 방법의 핵심이 되었습니다. 또한 Apple, Google, Amazon, Facebook 및 Netflix의 관리 접근 방식이 그 예입니다. 이들 중 어느 것도 단일 Agile 프레임워크에 가입하지 않았습니다. 그들은 가장 먼저 선언문의 원칙을 구현했으며, 가장 효과적인 것을 기반으로 다른 프레임워크의 일부를 따르거나 변경했습니다. 그 결과 시장 변화에 적응하고 신제품을 신속하게 제공할 수 있습니다.

애자일이란 무엇인가?

다음 개요에서 나는 선언문 가치의 원래 표현을 수정했습니다. 의미 체계에 대한 변경은 실제로 Agile 값을 적용하는 방법을 명확히 하는 데 도움이 됩니다.

첫 번째 가치에서 저는 "개인"이라는 용어를 "사람"으로 대체했습니다. 민첩하다는 것은 팀 지향적이라는 의미이기 때문입니다. 두 번째는 소프트웨어가 "작동"해야 하는 것이 분명하므로 이제 초점은 성공적이고 시기적절한 "전달"에 있습니다. 세 번째 가치는 단순히 "협업"입니다. 이는 함께 일하는 동료와 고객과 함께 일하는 팀에 동일하게 적용되기 때문입니다. 마지막으로 "프레임워크"는 "계획에 따라"를 대체합니다. 이는 계획을 완전히 포기해야 한다는 오해를 예방하기 때문입니다.

프로세스보다 사람

애자일 변환은 어렵습니다. 주로 대부분의 기업이 프로세스를 엄격하게 따르는 데 너무 익숙하기 때문입니다. 혁신적인 제품을 개발하는 대신 특정 도구 세트로 특정 단계를 완료하는 것이 최종 목표가 됩니다.

저는 이러한 사고방식이 수익성 있는 "애자일 산업"을 낳는 것을 보고 실망했습니다. Agile 설립자인 Ward Cunningham과 Jon Kern이 설명하듯이, 많은 기업이 기업이 "애자일화"하는 데 도움이 될 것이라고 주장하는 소프트웨어를 판매합니다. 그러나 애자일을 한다는 것은 소프트웨어를 사용하지 않고 규정된 프로그램을 따르는 것이 아니라 철학을 채택하는 것을 의미합니다.

올바른 균형을 달성하는 것은 절차를 제거하는 것이 아니라 각 팀의 개발 목표를 가장 잘 지원하는 절차를 찾는 것입니다. 대기업 기술 조직인 고객을 위해 IBM에서 개발한 접근 방식인 Disciplined Agile을 구현했습니다. Scrum 및 Kanban을 비롯한 여러 프레임워크의 많은 사례를 결합합니다. 반복 개발을 활용하지만 Scrum이 남긴 공백을 메우기 위한 것이기 때문에 특히 초기 단계에서 전통적인 Agile보다 프로세스가 조금 더 무겁습니다. Disciplined Agile은 조직이 매우 프로세스 지향적이기 때문에 이 고객을 위해 일했습니다. 이를 통해 팀을 중간에 만나고, 동의를 얻고, 스크럼 워크플로를 채택하도록 설득할 수 있었습니다.

백로그 개선 회의, 검토 회의, 일일 스크럼을 통합하여 팀 내 및 팀 간 협업을 촉진했습니다. 백로그 개선은 스크럼 가이드의 일부이지만 개선 회의는 그렇지 않습니다. 애자일 초보자에게 도움이 되는 향후 스프린트에서 특정 기능을 구현하기로 계획한 이유에 대해 건전한 대화를 나눌 수 있도록 이러한 항목을 추가했습니다. 또한 Waterfall 프로젝트 관리에서 사용되는 용어인 "마일스톤"이라는 명명법을 선택했는데, 클라이언트에게 더 친숙했기 때문입니다. 리뷰와 일일 스크럼 상호 작용은 스크럼 가이드의 기존 요소이지만 일정, 기간 및 흐름 측면에서 더 구조화했습니다.

또한 스크럼을 엄격하게 준수하면 각 사람이 스크럼 가이드에 나열된 역할 중 하나에 완전히 전념하게 되지만 내 고객 팀에는 기술 세트가 한 역할에 깔끔하게 맞지 않는 사람들이 있었습니다. Disciplined Agile 방법을 사용하여 이러한 직책의 책임을 여러 팀 구성원에게 분배하고 관련된 사람들의 강점을 활용하는 프로세스를 만들 수 있었습니다.

문서를 통한 소프트웨어 제공

내가 하나의 프레임워크를 엄격하게 준수하는 것보다 맞춤형 Scrum 또는 Kanban 워크플로를 선호하는 또 다른 이유는 계획에 MVP(Minimum Viable Product)를 목표로 추가할 수 있는 기회를 제공하기 때문입니다. Lean에서 파생된 MVP 생성 방식은 반복적인 개발과 일치하며 애자일 실무자들 사이에서 인기 있는 기술이 되었습니다. 이를 통해 팀은 고품질 소프트웨어 및 기타 제품을 사용자에게 효율적으로 제공한 다음 피드백을 기반으로 개선할 수 있습니다. 주로 Scrum 또는 Kanban을 기반으로 하는 하이브리드 접근 방식의 일부로 이를 적용함으로써 고객의 요구를 충족하는 제품을 만드는 팀의 능력이 향상되었습니다.

저는 현재 미국 기반 스타트업과 함께 일하고 있으며 NFT용 암호화폐 시장을 구축하는 데 이 방법을 사용하고 있습니다. 우리는 MVP를 만드는 데 집중하고 있으므로 현재 필요한 최소한의 문서만 작성하고 있습니다. 이 접근 방식은 다양한 제품에 효과적이지만 빠르게 변화하는 새롭고 실험적인 범주에 속하는 암호화폐 및 NFT에 특히 유용합니다. 완전한 사양과 기능의 초안을 작성하고 릴리스 전에 반복적으로 변경해야 하는 대신 시장 개발을 향상시키기 위해 사용자 피드백을 통합하는 데 시간을 할애할 수 있습니다.

계약을 통한 협업

앞서 언급한 대기업 기술 조직은 많은 고정 비용 프로젝트에 대해 계약에 크게 의존했습니다. 계약서에는 작업을 완료하는 데 사용할 방법과 각 작업을 담당할 특정 개인이 설명되어 있습니다. 일단 서명되면 긴 요청 프로세스 없이는 계약을 변경할 수 없습니다.

변화의 일부로 저는 이러한 엄격한 합의보다 협업을 우선시했습니다. 우리가 구현한 계획은 계약을 한 페이지 문서로 대체했습니다. 각각은 지정된 시작 날짜와 종료 날짜 사이에 Agile을 사용하여 고객은 물론 다른 팀의 팀원 및 동료와 협력하기로 동의했다고 말했습니다. 협업에서 나온 것이 무엇이든 결과가 될 것입니다. 나는 완제품이 무엇인지에 대한 세부 사항을 포함하지 않았습니다. 우리는 고객 피드백을 요청하고 이를 제품 개발에 통합했기 때문에 계획 문서에서 사양을 제거하면 고객의 응답을 더 잘 수용하고 더 적극적으로 협력하도록 장려했습니다.

경영진을 참여시키기 위해 한 소규모 클라이언트와 함께 작업하는 한 소규모 팀과 함께 개념 증명을 이끌도록 요청했습니다. 한 소규모 클라이언트는 필요한 변경 사항이 문제를 악화시키기 전에도 개발 시간이 너무 길다는 우려를 표명했습니다. 이 고객이 제품 소유자와 직접 협력하게 함으로써 개발 도중에 변경 사항을 적용하고 배송 시간을 크게 단축할 수 있었습니다.

이러한 결과는 경영진을 설득하여 더 많은 팀에 계획을 배포할 수 있도록 했습니다. 전반적으로 간소화된 계약과 애자일 워크플로는 제품 기능을 개발하고 시장에 출시하는 데 필요한 시간을 줄였습니다.

프레임워크에 대한 적응성

내 또 다른 고객인 의료 기술 회사도 Agile 가치의 양면, 즉 계획을 따르는 변화에 대응하는 중요성을 인식하는 면에서 균형을 맞추는 데 실패했습니다. 그러나 이 경우 내 기업 기술 고객이 저지른 실수와 정반대였습니다. 프로세스를 너무 엄격하게 따르는 대신 프로세스를 크게 무시하면서 유연성에 대해 과도하게 인덱싱했습니다. 엔지니어들은 우선 순위나 일정이 없었기 때문에 무엇을 작업해야 하는지 거의 알지 못했습니다. 그들은 매일 그것을 파악하기 위해 시간과 생산성을 잃었고 더 중요한 작업보다 덜 중요한 작업을 완료했습니다.

나는 CEO와 CTO에게 스크럼의 구현을 제안하면서 스프린트는 엔지니어들이 매일 무엇을 할 것인지 결정하는 것이 아니라 훈련을 받고 2주 단위로 계획을 세워야 한다고 설명했습니다. 또한 제품 소유자를 고용하면 팀의 제품 책임 부족을 해결할 수 있다고 조언했습니다. 나는 경영진에게 결과를 기대하기 전에 팀과 함께 일할 수 있는 3~4개월의 시간을 달라고 요청했습니다.

그들의 승인을 얻은 후, 저는 먼저 Agile 가치와 원칙을 소개한 다음, 제품 백로그와 에픽 및 사용자 스토리 제작, 하위 작업 생성을 포함하여 제품 백로그를 정리하는 다양한 기술에 대해 팀을 교육했습니다. 워크플로에 포함된 기술과 회의는 스크럼 가이드에 표시되지 않는다는 점에서 기존 스크럼과 다릅니다. 훈련 중에 팀과 공감대를 형성하는 서사시, 스토리 및 하위 작업이 계획에 통합되었고 회의가 생산적인 토론을 촉진했습니다.

또한 각 제품 반복의 모든 사용자 스토리에 대한 총 노력 추정치를 측정하는 XP에 늦게 추가된 속도 개념도 포함했습니다. 그러나 나는 "용량"이라는 용어를 사용했는데, 팀원들이 얼마나 빨리 작업을 완료할 수 있는지보다 얼마나 많은 작업을 수행할 수 있는지를 강조하기 때문에 선호합니다.

추정을 위해 프로젝트와 작업을 소, 중, 대로 측정하는 기술인 티셔츠 크기 조정으로 시작했습니다. 팀이 진행되면서 더 전통적인 추정 기법인 스토리 포인트로 전환했습니다. 스토리 포인트는 애자일에 익숙하지 않은 팀에서 종종 오용됩니다. 팀은 시간을 근무 시간이나 며칠로 변환하려고 하고, 시간 프레임에 지나치게 집중하고 마감 시간을 맞추는 능력에 따라 사람들을 판단합니다.

티셔츠 크기는 더 추상적이어서 팀이 이 함정을 피하기가 더 쉽습니다. 그러나 덜 정확합니다. 따라서 팀이 상대적인 측면에서 추정하는 방법을 이해하면 더 정교한 기술로 전환했습니다.

팀이 두 번의 스프린트를 완료했을 때, 고위 경영진은 직원들이 더 생산적으로 일하고 더 효과적으로 의사 소통하는 것을 볼 수 있었습니다. 개발자들은 처음으로 이해 관계자 및 경영진과 소통했습니다. 그들은 고객 지원 팀을 만났고 구현한 기능이 사용자의 삶을 어떻게 개선하는지 이해했습니다.

이러한 접근 방식은 곧 회사 소프트웨어의 품질을 높이고 새로운 기능의 제공 시간을 몇 달에서 몇 주로 단축했습니다.

애자일의 미래는 무엇입니까?

COVID-19 대유행은 팀이 더 이상 같은 장소에 배치될 수 없는 새로운 현실을 만들었습니다. 이는 애자일을 구상할 당시 애자일 내에서 선호하는 작업 방식이었습니다. 그러나 이 상태를 유지해야 한다는 생각은 신화입니다. 원격 작업이 보편화되면서 화상 회의 소프트웨어로 긴밀한 커뮤니케이션이 완전히 가능하다는 것이 분명해졌습니다. 지금 함께 일하고 있는 팀은 완전히 분산되어 있으며 원격으로 교육을 제공하고 있습니다. 일부 팀은 Notion 및 Loom과 같은 도구와 Standuply와 같은 Slack 플러그인을 사용하여 비동기식 작업을 선택하기도 합니다.

분산형 협업 모델은 민첩성을 중심으로 하는 새로운 작업 세계입니다. 원격 팀에 제공되는 일과 삶의 균형은 생산성과 품질을 향상시키는 사기와 정신 건강에 긍정적인 영향을 미칩니다. 프로세스보다 사람을 우선시하고 유연하고 적응력이 뛰어나 본질적으로 민첩합니다.

애자일 코치, 스크럼 마스터 및 프로젝트 관리자는 철학의 뿌리로 돌아가 선언문의 프레이머가 했던 것처럼 유연하고 역동적인 개발 및 제공 지침을 제시해야 합니다. 그들은 경영진과 팀 리더에게 프로젝트 관리에서 영감을 얻을 수는 있지만 실제로 Agile에서 아무 것도 관리하지 않는다는 것을 가르쳐야 합니다.