kooboy blog

Ron Lichty - How to Get Your Development Team to Love You

February 23, 2020

LECTUREAGILE

Thoughts

그룹3을 맡고 계신 동료(엄상규님)가 추천한 영상 시청 후 후기를 남겨야겠다는 생각이 들었다. 영상은 아래에서 시청할 수 있다.

44분 길이의 영상이며 Ron Lichty 라는 분이 개발팀을 리드하는 컨텍스트 안에서 PO 혹은 매니저의 역할에 대해 집중적으로 이야기하고 있다. 애자일 이야기에 대해선 꾸준히 연구하고 있던터라 엄청 새로운 내용이 있거나 하진 않았지만, 좀 더 매니저의 역할에 대해 집중해서 들었던 것이 굉장히 흡입력이 있었다. 애자일 방법론에서 항상 개발자들의 입장에서만 생각을 했지, 매니저가 어때야 한다에 대한 내용에 대해선 깊게 논의해본 적이 없기 때문이다. 굳이 했다면, 좀 더 추상적인 레벨에서의 애자일 조직 리더 스터디를 했던 정도?

강의에서 다뤄진 내용 모두를 다루기보다는 나 스스로가 이후 바로 실천할 수 있는 나만의 key takeaway 식으로 짧게 정리해 보기로 한다. 또한 이 강의 컨텐츠는 애자일 개발 방법론 안에서 개발자와 PO로 제한해서 이야기하고 있으나, 나는 개발팀이 아닌 곳에서의 적용점을 포괄적으로 정리해보고자 한다. 또한 PO라는 말이 아직 익숙지 않거나 타이핑이 귀찮으므로 리더라고 부르기로 한다.

PO 의 역할

  • 대부분의 팀원들은 멀티 태스킹을 한다. 리더는 팀원들의 멀티태스킹이 빈번하게 일어나지 않도록 막아주고, 집중할 수 있게 도와주어야 한다. 리더는 멀티태스킹을 해야 하는 사람이다.
  • 리더는 팀 안에서의 모든 것을 알고 있어야하며 항상 available 해야 한다. (개인적으로 제일 어렵다고 생각하는 부분)

    • 여기서 모든 것이란 모든 세부 내용이 아니라, 배경과 목적, 방향, 요구사항, why 에 대한 내용이다.
    • 이런 부분이 불명확하고, 리더가 없거나 (NOT available) 아니면 리더가 모를 때 실무진 팀원들은 가정(assumption)을 하거나 직접 요구사항을 작성하며 만들게 된다. 이래서는 안 된다.
  • 리더는 How가 아니라 What + Why 를 항상 공유해야 한다.How 는 실무진에 맡기자.
  • 실무진이 분석까지 못 할 수 있다. 분석 + 예측을 리더는 해 주어야 한다.

    • 구체적인 분석 및 예측의 개념이 아니라, 더 큰 방향, 그림에서의 분석, 예측이 필요하다.
    • 구체적인 분석은 실무진에 요청한다.
  • 유저와 지속적으로 스킨쉽을 유지해야 한다.

    • 우리의 경우 잠재 학생, 학생, 졸업 학생들과의 컨택을 계속 유지하며 실제 user experience, 그들이 생각하는 value 에 대해 가장 책임감을 가지고 있어야 한다.
  • 두 번 듣고 한 번 말하라.

    • 리더의 말만 다 끝나고 가 버리면 아무 소용이 없다.
    • 많이 들으라는 말이다.

위에도 표시했지만, 가장 어려운 부분이 바로 Availability 다. 팀원 모두가 리더를 찾을 때, 쉽게 닿을 수 있는 곳에 있어야 한다. 빌게이츠도 아니고 닿을 수 있는 곳에 없으면서 회사의, 그룹의, 팀의 장기적, 단기적 미션을 팀 크루에 전달할 수가 없다. 아니, 빌게이츠라고 그것이 가능하겠는가. 최소한 적어도 나와 함게 engaged 되어 있는 동료들과는 최대한 loss 없이 contents, context 가 유지되어야 한다. 그래서 그 컨텍스트가 실무진에 내려갔을 때, 충분히 동기부여된 상태로 How 를 프로페셔널하게 구현, 진행이 가능하다고 생각한다.

이 모든 것을 가능케하는 매개체는 커뮤니케이션이다. 지속적이고 적극적인 커뮤니케이션 아래 이런 이상적인 내용들이 가능해진다. 그러나 그 동안 내가 착각했던 것은 이 지속적이고 적극적인 커뮤니케이션이 모든 수평조직 모두가 함으로서 모두가 동일 컨텐츠, 동일 컨텍스트를 유지할 수 있다고 생각한 것이다. 20명이 매일 스탠드업으로 모이고 컨텍스트 유지하는 것은 불가능하다. 그래서 리더가 필요하며, 리더는 압도적으로 현명하고 민첩하며 수용의 범위가 넓은 사람이어야만 한다. 반대로 또한 의견이 어지러울 때, 결정을 하고 책임질 줄 알아야한다. 동료들끼리 오해가 생기고, 같은 말을 두 번하게 만든다면, 해당 동료들의 문제가 아니라 리더의 문제가 크다. 어떤 것들이 잘못되어 이런 현상이 벌어졌는지 리더는 회고하고 분석하고 개선해야 한다.

아래 노트는 영상을 시청하며 키워드를 잃지 않기 위해 다소 트리 구조를 조금 무시하며 적은 내용이다. 워낙 발표자가 depth를 불분명하게 프레젠테이션 자료에서 언급해서 나 역시 적어가며 헷갈렸지만, 주제별 depth 가 핵심은 아니라고 생각했기에 그냥 draft 인채로 두기로 한다.

Lecture Note

  1. Delight Your Customers

    1. In the beginning, everyone will talk about scope, and budget, and schedule, but in the end, nobody really cares about any of those things
    2. The only thing they care about is this:
    3. People will love your software(product), or they won’t. So that’s the only criterion to which you should truly manage.
    4. By Joseph Kleinschmidt, CTO
  2. Prioritize
  3. Be the source of Clarity! (people, developers come to you and ask you, you must answer them)
  4. Share hte What no the How

    • As a
    • I want to

      • in order to
    • Who
    • What

      • Why
    • Never How
  5. Share the Big Picture

    1. We don’t need a roadmap, vision because we are AGILE (X)
    2. Connect the dots

      1. the big picture
      2. What each team member is contributing
  6. Block the Noise

    1. Be a damper to the noise
  7. Study Product Team Performance
  8. Make Trade-Offs

    1. scope, quality, speed
    2. Honor Velocity
    3. Focus on fomenting amazing teamwork
    4. on supporting the team becoming high performance
  9. Definition of Product Owner

    1. Always in the room (avaialable)
    2. knows everything
    3. clear the ambiguity
    4. If PO dose not know, then developers start assumptino and they start writing the requirements
  10. Be Available
  11. Let Developers Focus

    1. do your best to eliminate multi-tasking for developers
    2. Managers do multi-task
    3. but our job is to keep our developers away from multi-tasks
  12. Bugs happen when

    1. developers get interrupted every 30 min
    2. developers need at least 20-30min to get sync with the code
  13. Have the Data

    1. “If you don’t have time to calculate the value, we don’t have time to calculate the cost” by Jim Highsmith
    2. it’s because we don’t expect developers do the analytics
  14. Engage Users

    1. on the behalf of the team
    2. be the connecting point between users and developers
  15. Listen

    1. Support a culture of communication

      1. at every level
      2. with everyone
      3. up, down, within and across
    2. “We have two ears and one mouth. Use them in this ratio” by Kimberly Wiefling
  16. Incorporate Engieering’s Stories

    1. opportunities in the code
    2. techinical risk
    3. reducing technical debt
    4. refactoring
    5. automation
  17. Be Tech Savvy
  18. Agile

    1. Do Standups -> very effective
    2. Give Agile Values instead of methodologies

      1. Being Agile vs practicing Agile
    3. Agile Manifesto

      1. We value
      2. individual and interactions over process and tools
      3. working software over comprehensive documentation
      4. customer collaborataion over contract negotation
      5. responding to change over following a plan
  19. make self-organizing team

    1. it’s about shared leadership
  20. Project Not Suitable for Agile?

    1. Micromanagement
    2. 2.

Johnny Ilmo Koo

Welcome to Johnny Ilmo Koo's blog

...