목차
Why Agile?
애자일을 만나게 되는 순간
•
개발자면 당연히 애자일은 한두번 들어본 이야기
•
출근해보니 애자일을 하고 있던데?
•
스타트업은 원래 애자일 한다고 하던데?
•
스타트업이라 애자일 해야지 투자받을 수 있어서
•
계획을 세울 수 없는 것이 애자일이라고 하던데?
•
현재 프로세스와 업무 구조로는 못 살아남을 것 같아서
•
뭔가 민첩하게 대응해야 할 것 같아서
•
우리의 성장을 위해서는 근본적인 변화가 필요해 보여서
What is Agile?
애자일은 프로젝트를 더 작은 반복주기로 나누는 프로세스다.
각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는데 사용한다.
기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다.
품질은 가능한 한 높게 유지한다.
일정은 주로 범위를 조절하여 관리한다.
이것이 애자일이다. - Clean Agile, Robert C.Martin
Agile Manifesto
Agile을 하면 뭐가 좋아지지?
•
숨겨진 고객의 니즈를 발굴하여 빠르게 시장에 내놓을 수 있음
•
달라지는 고객뿐만 아니라 조직원들의 요구에도 기민하게 반응
•
기존 구조로는 최근의 산업환경에 생존할 수 없기 때문에
•
더 큰 재무적 성과뿐만 아니라 생산성을 증진
•
하나의 목적을 더 깊게 고민하고 협헙하여 성과를 만들어 낼 수 있어서
기민한 조직들이 나타내는 전형적인 특성들
경험적으로 좋아지는 것들
Most Likely
Often
Totally
•
민첩함과 유연함
•
Mind-set shift
•
주도적인 팀
누구나 만나는 애자일의 난관
•
개념적인 이야기들만 하거나
•
구체적이지 않은 방법들만 나열되어있거나
•
스크럼이 쓰라기라고 말을 하거나
•
외국 사례 위주로만 소개
•
뭔가 알려줄 것 같다가 알려주지 않음
•
당장 쓰고 싶은 How to는 왜 안알려주는 것일까
•
생각했던 대로 애자일이 작동하지 않음
•
데일리 스크럼을 하면 우리는 원팀이 될 줄 알았는데 다들 피곤해 함
•
애자일을 하면 일잘러가 될 줄 알았는데, 뭐가 달라졌는지 모르겠음
•
애자일은 얼마 지나지 않아서 짜증나는 프로세스로 바뀜
•
우리가 바뀌거나 성장하는 느낌이 들지 않음
•
쪼는 방식만 바뀐 것 같음
난관에 봉착했을 때 하는 질문 - 왜 애자일을 하는가?
•
애자일이라는 이름을 안써도 이미 애자일을 하는 상황
•
현재 산업 구조와 시장이 애자일을 하기 유리하게 변경
•
Best Practice 를 기반으로 효율적이고 기민하게 움직여야 함
•
작동이 검증된 최소한의 중요한 규칙들과 건강한 문화가 실용적으로 잘 돌아가야 함
•
주도적인 팀이 수평적 조직문화 위에서 서로 협력하고 최고의 성과를 내고 지속성장 해야 함.
Agile 시도
Agile 시도가 번번히 실패하는 이유
•
조직 개편만 하고 더 이상 진행이 없음
•
특별한 비전이나 목표 없이, process 만 바꾸려고 함.
•
Culture 팀을 만든 후 알아서 하라고 함
•
실패에 대해서 엄격한 조직 문화
•
빠르게 결과를 볼 수 있는 단발성 task에만 집중하거나 보여주기식으로 함
•
추진하던 윗 사람이 바뀜
Process & Practice
•
Practice만 하게되면 효과가 오래 가지 않는다.
•
의미와 목적없는 practice들은 초반에만 반짝 효과가 있고, 몇개월 지나면 효과가 사라진다.
•
Process로만 접근하게 되면 잘게 쪼갠 waterfall에 지나지않는다.
•
목적과 의미와 방향성이 없는 단순한 시도는 결국
◦
“하라니까 하지만 ...”
◦
“해봤는데 별로던데?”
◦
“해봤는데 뭐가 좋은지 모르겠던데?”
•
조직 문화가 뒷받침이 되지 않는 애자일의 시도는 practice의 수행에 그친다.
그래서 뭐 어떻게 해야하는건데..?
Doing Agile vs Being Agile
•
Doing Agile - HOW
◦
Scrum
◦
KANBAN
◦
SAFe
◦
Exrtreme Programming
◦
...
•
Being Agile - WHY
◦
Business Value
◦
INCREMENTAL
◦
ITERATIVE
◦
COLLABORATIVE
◦
CONTINUOUS IMPROVEMENT
Being 에서 Doing으로? 어느 한방향으로는 Agile하지않은 방향으로 흐를 가능성이 있다.
Agile Transformation fro Doing + Being Agile
5가지 애자일한 기업의 특징
AgileTransformation
1. Leadership
•
조직이 변화하고 성장하고 유연해지려면 leadership이 바뀌어야 함
•
팬데믹 상호아에 맞춰 많은 리더들이 보다 민첩한 업무 방식을 채택하여 변화하는 상황에 적응해야 함
•
리더들은 실험과 학습의 문화를 조성
◦
팀원들이 비난을 두려워하지 않고 실수를 할 수 있는 환경 조성
•
모든 직급의 직원간의 협업이 중요해지고 있으며 모두가 같은 목표를 위해 노력하는 것이 중요
•
팀이 자율적으로 생각하고 행동할 수 있도록 유도
•
팀에 이유를 제공하고 방법을 발견하여 고객에게 전달할 수 있도록 신뢰
2. Strategy
•
지속적으로 진화하는 요구사항을 충족하기 위해 에자일 조직은 유연한 접근방식을 선택
•
유여한 가치 창출 모델에 초점을 부여하고 align을 맞추기 위해 비전과 목적을 설정하고 공유
•
Fixed된 목표와 전략을 고집하는 것이 아닌 유연하게 Pivoting 추구하고 성장하는 영역으로 신속하게 이동하면서 initiative를 확대하거나 종료
•
OKR with Agile: 비전과 목적으로부터 출발한 OKR의 실행을 위해서 Agile의 유연함이 잘 맞음
•
방향성에 대한 공유이자 일의 의미에 대한 공유 필요
3. Structure
•
Teaming
◦
Empowered and self-organized team
•
End-to-end accountable team
◦
주도적으로 업무하고 결정하고 delivery 할 수 있는 팀
•
기민한 변화를 위한 구조적 고민 필요
◦
squad 조직, 목적 조직, Circle 등
•
무엇보다 상호 협력하는 구조를 만드는게 중요
4. Process
•
규칙을 위한 규칙보다는 효율적인 Way of Working을 만들어야 함
•
팬데믹 시대에는 새로운 형태의 협업을 위한 process 필요
•
Continous Improvement: 빠른 iteration을 통한 경험과 성장
•
Agile practice 들을 그대로 적용하는 것보다 본인 조직에 맞게 tailoring 하는 것이 필요
•
Growth-mindset 이 바탕이 된 learning cycle을 만드는 것이 중요
•
Process with certain tolls
◦
ex) JIRA, Confluence 등
5. People
•
반드시 스크럼 마스터가 필요하진 않지만, Agile leader나 Agile facilitator는 필요
•
Servant Leadership을 지닌 Agile leader의 코칭 역할 중요
◦
Servant leadership은 건강한 조직 문화를 만드는 데 기여
•
Start Small
◦
준비가 안된 팀은 Agile을 바로 시도하는 것보다 잘 작동하는 것이 확인된 최소한의 중요한 규칙들을 먼저 시행해보고 조직문화를 잘 만들고 성장시키는 것에 먼저 힘을 쏟음
•
Engaging with teams
◦
협업과 협력을 이끌어내는 Coaching이 중요
planning poker?
Agile Culture
•
건강한 조직문화가 없이는 어떠한 방법론이나 혁신도 소용 없음
•
애자일이 자랄 수 있는 문화
◦
Way of Working
◦
Way of Collaboration
◦
Way of Commitment
◦
Way of Improvement
◦
Way of Communication
•
주도적이고 협력적이며 함께 성장하는 문화 추구
가상의 애자일 조직 ( 가칭: 라인싸몰 )
DAU ?
•
우선순위 결정에 따라 각 팀은 자신들의 일정을 align 한다.
하나의 Team을 만드는 방법 #1
Agile Inception : 모두가 한 Bus에 같이 타기
Chapter01. 모두가 한 Bus 에 같이 타기
1.
프로젝트가 실패하는 이유
•
사람들이 생각하는 프로젝트 성공의 의미가 서로 다름
•
SW를 Release 할 때 쯤 서로의 생각이 달랐다는 것을 꺠닫는 경우도 있음
•
처음부터 모두 같은 생각을 가지지 않았다는 것이 문제가 아니라 모두의 의견이 일치되지 않은 상태에서 프로젝트가 시작된 것이 문제
•
이루어진 적이 없는 합의가 이루어졌다고 믿는 성급한 가정이 실패 이유
•
아래의 괒어이 필요함
◦
현명한 선택을 하기 위해 목표, 비전, 프로젝트 현재 상태에 대해 팀원과 소통
◦
이해관계자가 적절한 결정을 내릴 수 있도록 프로젝트에 관해 알아야 할 정보 제공
The Inception Deck? 프로젝트를 시작하기 전에 팀원들이 한 버스에 올라타기 위해서 마련하는 자리
함께 출발하기 전에 던져야할 10가지 질문 - by 애자일 마스터(조너선 라스무슨)
1.
우리가 여기 왜 모여있는지 물어봐라
2.
엘리베이터 피치를 만들어라(30초간 2문장으로 프로젝트를 설명)
3.
제품의 광고를 디자인 하라(당신이 고객이면 사겠는가?)
4.
NOT 리스트를 작성하라
5.
프로젝트에 관계된 다양한 사람들과 알고 지내자
6.
해결책을 보여줘라(기술적인 아키텍처를 보며 모두 같은 생각을 하고 있는지)
7.
미리 야근 거리가 될 만한 것을 찾아보자
8.
규모를 정하라(3, 6, 9개월?)
9.
우선순위를 파악하라( Scope, Budget, Time, Quality)
10.
비용과 결과물이 무엇인지 보여줘라
그래,, 좋아보이긴 한다만,,, 어떻게 적용해야 하지?
인셉션 워크샵의 목표
•
컨센서스 만들기 & 목표에 얼라인하기
•
스콥 명확히 하기
•
역할 명확히 하기
Optimized Inception Practices
1.
Elevator Pitch & OKR
a.
Google 도 한다는 Best Practice(이하 BP)
b.
TEAM 목표에 얼라인
2.
Heaven & Hell / Problem Solving
a.
Pre mortem - 미래 회고 / 리스크 사전식별
3.
User Mapping
a.
스콥 명확히 하기, 핵심고객과 전달 가능한 가치, 팀내 업무 식별
4.
RACI
a.
Cross Functional Team 내에서의 R&R 명확히 하기
하나의 Team을 만드는 방법 #2
하나의 팀을 위한 질문 5가지
“최고의 팀은 ‘하나의’ 팀이다.”
1.
우리 팀은 왜 존재하는가?
2.
우리는 무엇을 하는가?
3.
우리는 어떻게 행동해야 하는가?
4.
우리는 어떻게 목표를 이룰 것인가?
5.
누가 무엇을 해야 하는가?
Team Value Proposition
•
Value Proposition 은 주로 비즈니스와 연계하여 프로덕트 / 서비스가 유저에게 제공하는 가치를 명확하게 드러내는 용도로 사용됨
RACI Matrix(목표를 이루기 위한 역할과 책임)
•
RAM(Responsibility Assignment Matrix)로도 불리며 업무에 대해 관련자들이 담당하는 역할과 책임을 매트릭스 형태로 기술한 것
•
RACI
◦
Reponsible(담당): 업무를 진행하는 실무 담당
◦
Accountable(책임): 결과물에 대해 책임을 지는 최종 결정권자
◦
Consulted(조언): 업무가 결정이 되거나 수행되기 전 조언
◦
Informed(통지): 업무의 진행 상황/ 수행결과의 통보 필요
•
DACI
◦
Driver(진행): 최종 결정까지 일을 진행
◦
Approver(승인): 최종 승인
◦
Contributor(기여): 최종 결정/ 결과물을 내는데 기여
◦
Informed(통지): 결정에 대해 통보가 필요