---

이행 의지 부족, 변화 관리, 팀워크의 어려움 극복! 놀라실 수도 있습니다!

Scrum 이전에 사용한 프로세스 개선 프레임워크의 가장 큰 약점은 다음과 같았습니다. 주로 리더십의 자기 편의적인 조직 요구에 집중했습니다.

그러한 요구에는 감시, 준수, 예측 가능성이 있습니다. 고객에게 좋은 서비스를 제공하고 직원 사기를 높이는 데는 전혀 집중하지 않았습니다.

따라서 소프트웨어 관리 팀과 다양한 내부 및 외부 이해관계자는 소프트웨어 제공 프로젝트의 마감일을 고정하고 소프트웨어 엔지니어링 단계의 진척을 쉽게 감시하려 했습니다.

계획에서 벗어나는 일이 생기면 사람들에게 불이익을 주었고 예정된 프로젝트 완료일 전에 발생한 문제를 해결하기를 바랐습니다.

또한 독립된 사일로들이 완전히 분리된 소프트웨어 엔지니어링 단계를 수행했습니다. 예를 들어 개발 팀은 소프트웨어 테스트(검증) 팀과 완전히 독립되어 있었습니다. 같은 사업 사명을 위해 일해야 할 사람들 대부분은 서로의 이름조차 몰랐습니다.

조직이 사업 사명과 직원의 직업적·사업적 성숙도에 집중하는 대신 이런 사일로 사고방식을 갖게 된 이유가 무엇인지 짐작하시겠나요?

이유는 간단히 말해 매트릭스 관리입니다 . 매트릭스 관리는 조직의 관리 및 인력 구조로 1970년대부터 기업에 존재해 왔습니다. 얼핏 보면 매트릭스 조직이나 관리의 차별화된 발상은 영리해 보입니다.

리더십은 비슷한 기능 및 기술 역량을 가진 직원들을 같은 사일로 또는 기껏해야 인접한 사일로에 모아 조직 구조를 만듭니다.

매트릭스 조직의 폭포수 프로젝트 제공 모델

당시에는 이른바 “역량 센터”를 회사에서 흔히 볼 수 있었으며 각 역량 센터는 독립적이고 자율적인 사일로였습니다.

C++ 개발자 사일로 하나, 데이터베이스 관리자 사일로 하나, 해외의 완전히 분리된 품질 보증 사일로 하나 등 끝없이 이어졌습니다. 참 이상한 일이죠!

매트릭스 조직 구조의 가장 큰 어려움은 Scrum 프레임워크와 Scrum Master 없이 소프트웨어 프로젝트를 제공하려면 프로젝트 관리자가 사일로에서 직원을 일시적으로 빌려와야 한다는 것이었습니다.

이 직원들은 프로젝트 팀과 물리적으로 함께 있지도 않았습니다. 자신의 역량 센터 공간에 그대로 남아 있었습니다.

프로젝트가 끝나면 임시 프로젝트 팀은 해산하고 참여자는 다른 프로젝트의 다음 업무로 이동했습니다.

따라서 진행 중인 소프트웨어 프로젝트가 목표로 하는 사업 가치는 이 독립된 사일로들의 최우선 과제가 된 적이 없었습니다.

이들은 자신의 일을 여기 프로젝트와 저기 프로젝트에서 체크하는 항목으로 보는 경향이 있었습니다.

리더십과 매트릭스 조직 모델은 전문가들이 매출, 수익, 이익을 포함한 최종 실적 개선을 위해 사업에 어떻게 헌신해야 하는지 가르치지 않았습니다.

McKinsey & Company가 쓴 McKinsey Quarterly 기사도 이러한 매트릭스 조직 이면의 비용 최적화 착각을 명확히 보여 주었습니다 .

Gartner는 전 세계 조직들이 매년 IT 시스템을 복구하는 데 6,000억 USD를 지출한다고 추정했습니다 . 예정되지 않은 유지보수 작업과 결함 때문입니다.

이제 잠시 소프트웨어 프로젝트의 변화 관리와 장애물 대응이 어떻게 진행되었는지 떠올려 보겠습니다. 폭포수 모델과 매트릭스 조직은 있지만 Scrum 프로세스는 없는 프로젝트 구조에서의 모습입니다.

네, 맞습니다.

경영진과 직원은 변화 관리, 장애물, 오류 처리를 애초에 일어나서는 안 되었던 달갑지 않은 예외처럼 취급했습니다.

따라서 소프트웨어 프로젝트의 변화는 지연과 같은 뜻이 되었습니다. 보통 연쇄 지연이라는 도미노 효과를 만들었습니다. 팀은 결함과 장애물의 책임을 돌릴 사람을 찾았습니다.

마지막으로 사일로에는 오류를 처리하고 수정하며 배우는 체계가 없었으므로 같은 실수를 계속 반복했습니다.

게다가 계속 기술 부채의 양을 늘렸습니다 . 문제에 수동적으로 대처하려 했기 때문입니다.