Agile 문화를 방해하는 요소들
애자일을 방해하는 요소들
TLDR
Agile 문화를 방해하는 요소들을 ‘Sabotage’라 정의하고, 이를 억제하는 방법에 대해 설명합니다. Sabotage는 종종 무지에서 비롯되며, 의도하지 않게 발생할 수 있습니다.
애자일 문화를 방해하는 요소들.
애자일 관련 강연 영상을 시청후 작성한 글입니다. 오역이 있을 수 있으며 사설이 포함되어 있습니다. 해당 강연에서는 애자일 문화를 방해하는 요소들을 Sabotage 라 정의하고 이를 억제하는 방법을 소개하고 있습니다.
“Sabotage” 의 단어는 주로 고의적으로 손상시키거나 파괴하는 행위를 의미합니다. 이는 기계, 시스템, 계획, 과정 등을 대상으로 할 수 있으며, 목적은 보통 어떤 활동이나 목표를 방해하거나 실패하게 만들기 위함입니다.
애자일 Sabotage 는 무지함에서 발생하기 쉽습니다. 따라서 의도하지 않았음에도 발생할 수 있습니다.
애자일 문화의 효율
Agile 문화 도입한 팀에서도 어떻게 문화를 형성하느냐에 따라 효율의 차이는 날 수 있습니다. 상황에 따라 생산성은 최대 4배 까지 차이날 수 있다고 말합니다.
위 그림은 task 작업을 시작하고 완료하기까지의 cycle 을 간략히 그린 그림입니다. Task, Design 을 단계를 거치고 Code, Test 를 반복하며 개선해나갑니다. Integrate 과정을 마치면 이 Task 의 배포를 선택하는 비지니스 룰만 남게 됩니다.
“이 과정에서 걸리는 시간은 얼마나 될까요??” 라는 질문에 Fred 는 15분 ~ 2시간이라고 이면 적절하다고 대답합니다. 물론 모든 Task 에 이런 cycle 을 적용할 수 없으며 규모나 Task, 프로젝트마다 다른 성격을 가질 것이라 생각합니다. 이 부분에 대해서는 개체마다 다를 수 있기에 상황에 따
cycle 을 빠르게 순환하여 진행할 때 다른 조직들과 다른 점이 드러나게 되고 cycle 진행을 방해하는 Sabotage 가 드러나게 됩니다. Sabotage 는 프로세스, 툴 등 다양하게 존재하며 사람 그 자체가 Sabotage 가 될 수 있습니다.
Sabotage 종류 (Saboteurs)
실질적인 Sabotage 에 대해서 알아봅시다
Individuals Losing Powers
Agile 문화에서 Sabotage 는 조직에서 힘을 잃을 수 있는, 위신을 잃을 수 있는 사람에서부터 시작될 수 있다고 합니다. 이는 Task 나 일을 진행하기 위해 권한, 결정을 부여할 수 있는 사람으로서 시니어 개발자를 예시로 볼 수 있습니다.
어떤 일을 하기 위해 결재가 필요한 경우 (상위 권한자의 결정이 필요한 경우)는 가장 최악의 Sabotage 라고 판단합니다.
예를 들어 소프트웨어 배포 임무를 맡은 개발자가 배포 임무를 진행하기 위해 더 상급자의 동의가 필요하다면 이 상급자는 실질적인 Saboteurs 가 될 수 있습니다. 상급자는 업무 진행을 같이하는 사람부터 업무와 상관은 없지만 업무 진행을 결정할 수 있는 모든 사람을 말합니다.
따라서 특정 업무를 진행하기 위해 추가적인 결재사항이 필요한 것은 Agile 을 방해하는 요소로 판단하여 과감하게 없애는 것이 좋습니다.
Process Impedance mismatch
Agile 문화를 채택하고 있는 조직과 다른 조직간에는 개발 속도에서부터 차이가 날 수 있습니다. 이 개발 속도의 차이 또한 Agile 문화를 방해할 수 있습니다.
예를 들어 어떤 조직은 디자인을 시작하고 이미지를 완성한 후에 개발자에게 전달한 후에야 개발을 시작합니다. 어떤 조직은 이미지가 완성하기 까지 기다릴 여유가 없을 수 있습니다. 후자의 경우는 개발 속도가 Sabotage 가 될 수 있습니다.
개발속도로 인한 Sabotage 의 예시입니다.
- Our process requires… : 이거 하기 위해서는 이게 필요한데…
- Also DB, Architecture boards : Task 에 필요한 데이터 저장을 하기 위해서 DB 구조에 대한 승인이 필요한 경우
- Other “approval” processes : 다른 동의, 권한 프로세스들
Jealousy of success
다른 누군가의 성공, 성취를 질투하여 “그것은 안 돼” 라는 행위는 팀의 문화에 전혀 도움되지 않습니다. 다른 팀원이 잘했지만 질투심 또는 자신을 뽐내기위해 “지금을 잘 동작하지만 일반적으로는 잘 안 될 거야” 라고 말하는 것은 팀의 성장을 위한 것이 아닙니다. 팀을 위한다면 “잘 동작한다면 뭐가 문제냐” 는 식으로 먼저 사고하는 것이 좋다고 합니다.
물론 저는 어느정도의 구조는 필요하다고 생각합니다.
호손효과 (Hawthorne effect) 라는 것이 있습니다. 사회적인 효과에 의해 그 사람의 행동이 바뀔 수 있다는 내용입니다. 팀에서 누군가를 특별하게 취급하여 그가 잘하고 있다 특별한 사람이라는 것을 지속적으로 인지시킨다면 그 사람은 진실로 특별한 사람처럼 일을 잘하게 될 것입니다. 반대로 만약 누군가를 잘 못하고 있다는 인식을 계속 심어주게 된다면 오히려 역효과가 날 수 있습니다.
Jealousy of success 의 예시입니다.
- Tends to passive-aggressive : 수동적 공격성으로 자세한 사항은 위키를 보시면 좋을 것 같습니다.
- Minimize accomplishments : 성공을 최소화하는 것은 안 좋다.
- Reverse Hawthorne Effect : 호손 효과를 기반으로 부정적인 인식을 심어주지 마라.
Saboteurs 완화에 대하여
Agile 문화를 방해하는 Active Saboteurs 를 억제하는 방법을 소개합니다.
스탈린 전략 (Stalin Strategy)
Stalin Strategy 이라는 것은 흔한 개념은 아니고 Fred 가 강연에서 사용한 개념입니다.
누군가와 의견이 다르다면 굳이 논쟁하지 말고 팀원과 컨센서스를 맞춰 팀의 말을 따르게 하라는 뜻 입니다. 개인과 개인간의 의견에 집중하기 보다는 팀 전체의 의견을 통합하라는 의미로 해석됩니다.
샌드위치 전략 (Sandwich Strategy)
피드백을 할 때는 긍정적인 피드백 사이에 부정적인 피드백을 끼워넣어라는 개념입니다. 예를 들어 긍정적인 피드백을 한 후 개선의 여지가 있는 피드백을 합니다. 필요에 따라 추가적인 긍정적 피드백이 있으면 더 좋습니다.
유능한 상급자를 투입해라 (Inject Superior Competent)
사람이 Sabotage 인 경우 이를 팀에서 무력화하기 위해서는 Sabotage 보다 더 뛰어난 사람을 같은 팀에 배치하는 것이 도움이 될 수 있습니다. 팀은 유능한 사람과 더 협력적이게 되고 점진적으로 Sabotage 는 영향을 미치지 못하게 될 것압니다.
Organizational Sabotage
조직, 또는 사회구조적으로 Agile 문화를 방해하는 것이 있습니다.
내팀우선주의 Sabotage (Success Conservatism)
이미 할당받은 작업을 모두 다 했다고 해서 다른작업을 하지 말아야한다는 것은 아닙니다. “완료” 에만 집착한다면 나의 팀만 생각하게 되고 나의 상한선을 내가 직접 긋게 됩니다. 다른 팀을 개선하는 것은 우리팀에게도 좋은 작업임을 명심해야합니다.
직책 Sabotage (Titles)
Title 은 사람에게 적용하면 그 사람이 무엇을 할 수 있음과 할 수 없음을 정의하게 됩니다. 예를 들어 프로그래머는 리더십을 발휘할 수 없다고 단정지을 수 있을까요 ??
나의 능력을 Title 에 한정짓게 된다면 마찬가지로 나의 상한선을 내가 직접 긋게 됩니다.
자리 Sabotage (Seating of Employee)
사람들은 굉장히 자주 소통합니다. 같은 취미에 대해 이야기를 나누며 같은 관심사에 이야기를 나눕니다. 거리가 가까우면 더 자주 이야기를 합니다.
같은 부서끼리 사람을 나누지 말고 같은 일을 하는 사람끼리 같이 앉는 것이 좋습니다. 같은 일을 하지 않는 사람과 같이 있다면 불필요한 대화에 자주 참여하게 될 수 있습니다.
고용 우선 전략 Sabotage (Hiring Experts over Empowering Developers)
개발자가 2배 늘어난다고 해서 업무가 2배 늘어나지 않습니다. 오히려 개인의 역량강화를 우선으로 하는 것이 생산성에 더 큰 도움이 될 수 있습니다. 개인이 성취감을 느낄 수 있도록 적극적으로 개입해야합니다.
팀의 핵심전략 (Pod as a Mitigation Strategy)
팀의 가장 근본적인 임무는 단순히 소프트웨어를 작성하는 것이 아니라. 그 소프트웨어가 사용자 스스로에게 도움이되어야 한다는 것입니다.
후기
더 많은 내용들이 있지만 해당 내용은 정리하기보다는 영상을 보며 이해하는 것이 더 좋을 것 같습니다. 평소에 Agile 문화는 한국에 그대로 정착하기보다는 입맛에 맞게 개조되어 적용되고 있다는 느낌을 많이 받았습니다. 어떤 분은 KAgile 이라고도 하시더군요. 물론 100% 그대로 받아들이는 것이 힘들 수 있고 그게 맞다는 보장은 없지만, Agile 문화의 존재 목적과 방법을 알아가는 것은 생산력을 향상시키는 것에 도움이 될 것이라 생각합니다.