Agile하게 BM혁신 개발 여정

기획자(현업)들과 함께 Design Thing하고, Agile로 BM 혁신 과제 프로젝트를 구체화하고 승인 받은 여정을 소개합니다.

SK 관계사 중 한 회사로 부터 요청을 받아, BM을 혁신하는 팀의 5개 과제에 대 해 Agile Coaching을 했었습니다. 주로 개발팀과 일을 했지 이렇게 현업 중심의 팀에서 Coaching은 제게도 도전이였습니다. 제가 조직 문화를 잘 변화시키고 있는지 설문을 했었던 내용, 그리고 그 과정들을 공유합니다. 단지 Scrum을 잘 실행했는지?라는 Doing Agile 관점보다는 우리가 왜 Agile을 하지? 라는 Being Agile에 초점을 맞춰서 일하려고 노력했습니다.

1. 프로젝트 투입 전

좋은건 알겠는데 어떻게 보여줄 수가 없네~ T_T;

• 고객사 : Full time 상주로 3개월간 뭘 해주실건데요?
• 나 : 어떤 문제점이 있으며, 제가 뭘 해드려야하는지요?
• 고객사 : WBS나 뭐 이런것 없는지요?
• 나 : 아직 어디가 아프신지 말씀도 안하셨는데, 제가 어떻게 처방을?
  그리고 팀원간 협업을 위해 JIRA/Confluence 사주세요.

2. 프로젝트 초

2.1. CEO 지원사항

• Why 본 과제를 Design Thinking, Agile로 해야하는지? 구성원 당부 말씀
• 사내에서 PPT만 만들면서 보고 및 성과를 만들지 않았으면 좋겠음
  (필드에 나가서 뭐라도 만들어봤으면 좋겠음)
• 사내에 있으면 눈치보고 관성처럼 일할까봐 외부 공유 오피스로 나가라
• 내 눈치 보지 말고 내 의견도 Focus Group 설문자 중 하나로 생각하라.
• (최종 결과물 수준을 질문한 팀원에게) 3개월동안 어떤 수준으로 할 수 있을지는 아무도 모르므로 결론부터 정해놓고 일하지 말것

2.2. 구성원

• 디자인 씽킹으로 어디까지 미친 생각을 해 볼 수 있는지 뽐내기
• 디자인 씽킹하면서 작성한 포스트잇을 사무실로 그대로 옮겨서 자주 보기
  - PPT로 정리만 해놓으면 나중에 안보게 되고, 벽에 있으면 일이 진행 안되고 답답할때 마다 볼 수 있음
  - 자주 안보면 해결해야 할 문제나 Goal이 아닌 숙제를 위한 숙제로 변질됨
• 현장의 문제를 설문/인터뷰로 직접 받고, 문제 해결/구현 할 수 있는 수준으로 문제를 구체화
  (반면에, 장기간 PPT로 기획한 프로젝트일수록 사용자 인터뷰를 통해 번복될까봐 두려워하게됨)

2.3. Coaching

• Agile Coach는 Post It만 있으면 뭐든 다 할 수 있음…
• 혁신은 작은 불편함의 개선부터…
  - 팀원들이 출입할때마다 문 열리는 방향을 헷갈려한다. 그래서 포스트잇으로 표현 했다. → 공유 오피스측에서 이쁘게 해줬다.
  - 코칭때 실제로 써 먹었다. 포스트잇이 빠르게 검증할 수 있는 MVP임

• 혁신은 개선의 개선…
  - 아래 버튼이 문여는 버튼이지만 팀원들이 위의 형광등 버튼과 헷갈려 자주 불을 끈다.
  - 그래서 형광등이라고 써 놨다.(그래도 헷갈리는 분이 있다.)
  - 시간이 지나자 어떤 팀원이 X로 바꿨다. (Simple is the Best!!!)

3.프로젝트 수행

• 3개월간의 전체 일정 수립
• 2주 Sprint 동안 달성해야 할 Goal 정의
  - Output과 Outcome 구분하기
  - 모든 의사결정은 Why, Value 중심으로 하기
• Sprint 동안 할 Task 정의, 작업 할당
  (보통은 개발자분들이 짠 일정에 따라 현업분들이 움직였지만, 이번에는 현업들이 주도로 직접 Task 수립을 해야 하므로 처음에는 어려워 하셨음)

• UX Designer와 함께 설문지 작성하고 현장에서 인터뷰
• Idea를 Figma로 직접 기획/그려 보기
  - 직접 최종 화면 수준으로 그려보니, 모호한 요건(이쁘게, 간결하게, 명확하게)을 냈을 때 개발자들이 왜 힘들어했는지 이해 할 수 있다고 하심
• Figma로 작성된 결과를 임원께 SMS로 링크 보내기
  - 임원은 문자 링크로 바로 결과물 확인과 버튼 등 사용해 볼 수 있어서 바로 의견 가능
  - 팀원은 문자이므로 별도 보고 일정 잡지 않고 부담감 적게 공유 가능
  - 임원은 본인 의견이 반영된 결과를 빠르게 다시 확인 되니 관심도 증가
  (과거에는 가끔 PPT로 수십장의 화면과 진행사항을 한번에 공유를 받았지만, 지금은 바로 확인하고 의사결정 가능
  - 옆 조직 임원분께 우리 애들이 직접 만든거라고 자랑하기
• 개발자는 최종 완료된 기획안을 구현
  - Figma를 통해 기획이 구체화되어 이해도 증가
  - 현업 조직내에서 어느정도 검증 된 결과를 구현하므로 재작업 감소
• 가설과 실제 사용자 Data 비교/검증
  - 프로토타입(Web App)에 Google Anlytics를 반영하여 사용자 반응 보기
  - 기획때 생각한 사용자 선호 우선순위 기능과 실제 반응보며 성장하기
• Sprint별 Retrospective
  - 잘한점, 개산할점 작성하고 간단히 점투표
  - 별것 없지만, 이런 기회를 통해 개선/서운한점, 서로 존중하고, 이해하며, 사랑(?)하기

4.프로젝트 마무리

4.1. Doing Agile하게 따라하기

3개월 동안 Scrum의 기본 실천법을 따라하며, 가시적으로 Agile하게 일하는 문화 형성하기

4.2. Being Agile하게 일하는지 점검

우선 목표의식을 가지고 일 할 수 있었으며, 전반적으로 Being Agile하게 일할 수 있게 된 것 같다. Sprint마다 결과를 내야해서 Hard Work이였겠지만 무엇보다 구성원의 “행복”도 상승한것에 만족한다. 행복하지 않으면 지속적인 culture로 자리 잡을 수 없다.

5개 과제의 팀원들 대상으로 Agile 설문 조사