프로젝트 회고.

회고를 하기 전에, KerthPrimeDirective를 점검하는 것이 좋다.

김창준님은 이런 의견

• 김창준 저는 개인적으로는 Prime Directive의 사용을 반대합니다. 현실적으로는 오히려 psychological safety를 낮출 수 있다고 봐요. 회의하기 전에 기도하고 시작하는 것도 (종교를 떠나) 비슷하게 생각합니다.
• 박준표 김창준 와, 신기하네요! 어떤 경우에 심리적 안정감을 낮추게되나요? 호기심이 생기네요. 저는 심리적 안정감을 높이는 방향으로 사용했었고, 적어도 제가 퍼실리테이션 했던 팀에게는 긍정적 영향을 줬거든요. "Prime Directive" 사용을 반대하시는게 아니라, 그것이 안정감을 낮추는 방향으로 가는 것을 우려하시는 모양입니다.
• 김창준 저는 Prime Directive의 사용을 반대합니다.
• 예를 들어, 우리 평소의 삶에서 늘 일어나듯, 이미 나는 누군가가 최선을 다하지 못했다고 믿고 있다고 칩시다. 당연히 이 문구를 소리 내어 읽는 것이 내 믿음을 바꿔주지는 못할 것입니다. 그러나 이걸 소리내어 읽는 과정에서 내 마음 속에서는 자기모순과 거짓을 경험하게 됩니다. 그리고 당연히 그 이후 회의/회고에서 모두들 자신의 말을 조심하는 모습을 보일 것이고, 나는 내 속마음을 온전히 이야기하지 못하는 상황에서 내가 안전하지 못하다고 느낄 것입니다. 그리고 다른 사람들이 하는 말이 진심인지 아닌지 혼동스럽거나, 아니면 적어도 사람들이 회고에서 하는 말과 그 이후 다른 자리에서 하게 될 말이 다를 수 있다는 의구심이 들 수 있습니다.
• 켄트벡은 2007년도 XP 메일링 리스트에 Prime Directive의 문제를 제기하면서 이렇게 쓴 바 있습니다.
• This directive is telling me to change my understanding of negative events and my beliefs (which are based on my observations and experience) about others for the sake of the feelings of retrospective participants. I often do less than the best job I could. False affirmation (even of me) does nothing to promote safe, honest working relationships. I do not believe people are capable of denying so much of their knowledge. Pretending to do so does not seem to have any advantage. As soon as the retrospective is over the finger-pointing or worse will come out again.
• ..... Each person in the meeting has the responsibility hold himself, to not dump his own negative feelings on others, and to communicate as clearly as he can. But, to pretend that everyone did their very best just to avoid a statement that could appear negative or protect someone from embarrassment doesn't make sense to me.

간단하게는 TemperatureReading을 하면서 회고를 시작할 수 있다.

Excercises

NormKerth의 ProjectRetrospectives 책에 나와있는 예제 활동들

Norm Kerth's Project Retrospectives

NormKerth가 지은, 프로젝트 회고에 대한 책.

Preface

but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.

If we would only take a moment to stop and think of alternative ways to proceed, I'm sure we could find better ways to do our work.

The reason for this is that a well-run retrospective can help members of a community understand the need for improvement, and motivate them to change how they go about their work. The community designs the changes, since it knows best how to identify, organize, and give priority to the problems to be solved. Owning the changes helps the community become the master of its software process.

Chapter 1. Introduction to Retrospectives

"(Humans,) They hope that even if they do things that didn't succeed before, that by doing them the same way twice, they will get different results."

Owl is wise, but the pigs do not share his wisdom - the learning that comes from experience. Without this type of learning, most creatures are in danger of reliving earlier experiences - landing back in the swamp time after time.

경험은 중요한 학습의 재료이다. 하지만 잠시 멈춰서서 그것을 숙고해보지 않는다면, 재료가 저절로 숙성되지는 않는다.

Instead, they believe that what worked so well in one situation is the perfect technology to use in all their engineering efforts, whether they are building a house or an ark.

The pigs, like so many of us in the software engineering field, are missing the bigger picture.

I call this The Law of Wisdom Acquisition: 'It is much easier to identify another's foolishness than to recognize one's own'

This law suggests that it is not natural for us to stop, reflect, and learn from our software projects.

The act of reflecting on my just-finished project is not naturally a high priority.

회고하는 것은 자연스럽게 되지 않는다. 다른 할 일도 많기 때문에 우선순위가 밀린다. 때문에 일종의 '의식'으로 미리 정해놓는 것이 좋다.

The Need for Ritual

It should involve everyone associated with the project. One person can not know the whole story of the project; one individual's reflection can only bring about small-picture learning.

This big-picture wisdom comes from our ability to understand the relationship between an individual's work and that of the entire team. We need to tell our piece and see how it helps make up the whole story.

Prime Directive for a Retrospective

For a retrospective to be effective and successful, it needs to be safe. By "safe," I mean that the participants must feel secure within their community - to discuss their work, to admit that there may have been better ways to perform the work, and to learn from the retrospective exercise itself. Safety must be developed and maintained.

Part of being safe means knowing that there will be no retribution for being honest (such as being given a negative evaluation during the next performance review). Trust must be established and maintained during a retrospective.

반드시 회고 이전에는 사람들이 회고 공간을 안전하게 느끼도록 관리해야 한다. 그래야 사람들이 솔직해지고, 회고를 통해 배울 수 있다.

A method for expressing "unsafe" ideas during the retrospective needs to be established. To begin building safety and trust, the facilitator must communicate the prime directive for all retrospective rituals: KerthPrimeDirective

Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources availables, and the situation at hand.

The Darker Side of Retrospectives

Complaint energy is tricky to handle. The message in the complaint is worth listening to, but the packaging of the complaint can harm the learning process.

사람들은 비난에 익숙하다. 또한 한 번 비난의 분위기가 형성되면, 정직하게 자신을 돌아보고 그 분위기를 깨닫고 빠져나오는 사람도 적다. 안전하지 않은 상태에서 진행된 회고는, 상어떼에 물어뜯기는 상황이 된다.

Chapter 2. Anatomy of a Retrospective: A Case Study

이 장은 프로젝트 회고의 실제 사례를 살펴보면서 회고가 어떤 것인지 알아본다. 이 장은 저자인 NormKerth의 홈페이지에도 공개되어 있다.

회고를 준비하기 위해서, 각 참가자를 미리 인터뷰했다. 그 결과로, 매니저 그룹과 개발자 그룹이 각자 걱정스러워하는 부분이 어떤 것인지 파악했다. 회고 계획을 짜기 시작했다. 계획은 짜지만, 현장 상황에 따라서 얼마든지 바꿀 수 있다. 그리고 그렇게 하기 위해서 일부러 촘촘한 계획은 짜지 않는다. 일단은 다음과 같이 계획을 짰다.

• 도입
  • 목표: 공동체가 진행자를 편안히 느낄 수 있도록 돕고, 프로젝트를 리뷰한다는 것을 편안히 느낄 수 있게 한다. 참가자들이 중요하다고 생각하는 것을 표현할 수 있도록 환경을 조성한다. 프로젝트가 성공적이었음을 일깨운다. 왜냐면 여러 장애물들이 있었지만 제품을 무사히 공급했기 때문이다.
  • 접근법: 도입에 적절한 활동을 한다 - ex. "Define Success" Exercise, "Create Safety" Exercise, "Artifacts Contest" Exercise
• 중간
  • 목표: 중요한 것들을 학습할 수 있도록 프로젝트를 리뷰한다. 팀 멤버들간에 손상된 관계를 복구한다. 이처럼 대단한 일을 해내는데 들여야 하는 대가를 인식한다.
  • 접근법: 적절한 활동을 한다 - ex. "Develop a Time Line" Exercise, "Mining the Time Line for Gold" Activity, "Passive Analogy" Exercise, "Repair Damage Through Play" Exercise
• 마무리
  • 목표: 다음 프로젝트가 더 성공적이기 위해서는 어떤 장기적인 활동이 필요한지 결정한다. 이 조직이 리서치 중심보다는 제품 중심으로 옮겨가기 위해서는 어떤 대안 행동을 해야 하는지 확인한다.
  • 접근법: 마무리에 적절한 활동을 한다 - ex. "Cross Affinity Teams" Exercise, "Making the Magic Happen" Exercise

인상적이었던 부분은, Artifacts Contest Exercise였다. 각자에게 이번 프로젝트에서 중요한 유물이라고 생각되는 것을 가져오라고 해서 그것을 모아놓고 이야기를 하는 것인데, 다양한 이야기가 나올 수 있을 것 같다. 예제에서는 바퀴벌레 살충제를 가져온 한 엔지니어의 이야기가 나온다. 한참 버그를 잡고 있을 때였는데, 누가 자기 책상에 살충제 통을 놨단다. '이게 뭐지?' 하고 집어들었는데, 그 한쪽에 "고맙습니다"라는 쪽지가 붙어있었다더라. 그 사람이 살충제 통을 들고 그 에피소드를 이야기하자, 청중 중에서 누군가가, "내가 줬던 것은 아니지만, 지금 이 말을 해주고 싶네요. 정말 수고했어요."라고 말을 꺼내자, 다른 사람들도 맞장구를 치며, 갑자기 전체 그룹이 그에게 박수를 쳐줬다고 한다.

AppreciativeInquiry에서도 서로가 에피소드를 이야기하면서 다양한 사례들, 각자가 바라보거나 경험했던 다양한 면면들이 끄집어내어지는 것을 중요하게 이야기하는데, 여기서도 이런 저런 에피소드들이 나오게 하는 것이 좀 비슷하다. 도입 부분은 이런 저런 에피소드로 시작하는 것이 좋은 것 같다.

중간 활동으로는 타임라인을 그리고, 프로젝트를 4개의 계절로 큼직하게 구분하여, 각 시기에 있었던 일들을 적게 했다. 그걸 또 작은 그룹으로 나누어서 그룹별로 논의해서 적게 했다.

첫째날과 둘째날의 활동들을 거치면서 사람들은 피곤하지만 자신의 의견을 솔직하게 이야기하는데는 편안해졌다. 마지막 활동을 하면서 사람들은 진심에서 우러나오는 말로, "다시는 그렇게는 하지 않겠어! (Never again!)"라는 다짐을 한다.

회고는 구성원들이 갈 필요가 있다고 하는 곳은 어디든지 간다. 퍼실리테이터의 역할은 그들이 그곳에 도착할 수 있도록 돕는 것이다. 다음 것들을 활용해서 말이다:

• 과정을 관찰하고 인도하는 것을 통해
• 모두의 의견을 들을 수 있도록 기회를 제공하는 것을 통해
• 모든 사람의 의견과 프라이버시를 존중하는 것을 통해
• 건강한 상호작용을 위한 가이드라인이 무엇인지 구성원들이 발견할 수 있도록 돕는 것을 통해
• 그들이 반응할 때에는 기꺼이 감정을 다루는 것을 통해

어떤 퍼실리테이터는 회고에서 감정을 다루는 것을 꺼려하는데, 그렇게 해서는 마법이 일어나게 하기가 어렵고, 효과가 낮아서 회고가 끝난 후에 시간낭비였다는 인상을 받기 쉽다.

숙련된 퍼실리테이터는 많은 목표를 달성해야 한다.

• 커뮤니티 내에 신뢰를 구축한다.
• 어려운(difficult) 이슈를 탐색하도록, 인도적이고, 돌보고, 효과적인 방법으로 돕는다.
• 반드시 관리자가, 지배하기보다는 참여하고 기여하고 배우도록 확실히 한다.
• 무엇이 진짜 이슈인지를 그룹이 이해하도록 돕는다.
• 팀 멤버들이 합께 일하는 더 나은 방법을 찾도록 돕는다.

Chapter 3. Engineering a Retrospective: Makeing Choices

모든 회고는 다르다. 하나의 유니버설한 해답은 없다.

One size does not fit all. The perfect fit for one type of client may be entirely wrong for another. Bee decided that he needed to better understand what his clients wanted, and to control his enthusiasm for what he himself considered desirable.

각각의 회고는 그 독특한 환경적 조건과 팀 역동에 따라 알맞게 engineering될 필요가 있다.

Engineering a Retrospective

비록 모든 회고는 독특하게 맞춤해야 할 필요가 있지만, 공통적으로 결정해야 할 사항들도 있다.

First Consideration: What is the purpose of this retrospective?

When I'm first contacted to help a team perform a retrospective, I always ask, "Why do you want it?"

At this point in the planning stage, I need to understand what will be accomplished by holding this retrospective. I try to find out for whom the learning is intended - management, developers, or the whole team?

Each organization has different retrospective goals, and until those are understood, I can't engineer a retrospective that will meet the team's need. Likewise, team members won't know if the retrospective has been successful unless they know what their goals were. A comment such as "You're the expert - don't you know?" reveals something important - that the organization doesn't know what it wants from a retrospective.

회고를 하려는 목적을 정해놓지 않으면, 회고 동안에 일어난 것들을 배움으로 소화하지 못할 가능성이 크다.

To uncover the real goals, I usually need to speak with a number of people from the project. I often start by saying, "Tell me about the project - just the really important stuff."

다음은 회고의 목표들의 예이다:

• 활동 데이터 수집하기 Capture effort data: 프로젝트를 위해서 실제로 어떤 노력들이 있었는지 계량한다.

• 이야기 끌어내기 Get the story out: 프로젝트 수행 과정에서, 모두가 알지는 못하는 여러 일들이 발생한다. 어느 누구도 모든 이야기들을 알지는 못하고 전체를 알지는 못한다. 각자가 알고 있는 부분들을 합쳐서 프로젝트에 있었던 전체 일들을 재구성해낼 수 있다. 그렇게 함으로써 그룹 전체가 무슨 일이 있었으며 왜 그런 일이 일어났는지 이해할 수 있다.

• 프로세스, 절차, 관리, 문화적인 부분의 개선 Improve upon the process, procedures, management, and culture: 무엇이 일어났는지 성찰함으로써 다음번에는 어떻게 하면 좋을지 생각해볼 수 있다. 개인적인 성찰 대신 공동체로서 성찰함으로서 배움이 더 커질 수 있다. 각 조각들만이 아니라 전체를 볼 수 있다. 가끔 '아무개가 문제야'라는 경우가 발생하기도 한다. 하지만 팀 전체가 모여서 조각을 맞추다보면, 아무개의 문제는 팀 차원의 문제의 일부분에 불과하다는 것을 발견하는 경우도 많았다.

• 집합적 지혜를 수집하기 Capture collective wisdom

• 팀의 상처 회복하기 Repair damage to the team

• 성취를 즐기기 Enjoy the accomplishment

Second Consideration: How healthy is this organization?

The less functional an organization, the more effort you will need to put into ensuring that the retrospective stays focused in a heatly direction - on learning rather than on fault-finding.

The greater the dysfunction, the fewer retrospective design choices you have. With highly dysfunctional organizations, either you need to be skilled at dealing with personal interations and antagonism or you need to lower the goals of the retrospective to avoid serious conflict.

Third Consideration: Do I have the skills to lead this retrospective?

• 퍼실리테이터는 조직 외부 사람이어야 한다.
• 퍼실리테이터는 기술적인(s/w) 능력이 있어야 한다.
• 퍼실리테이터는 Betazoid여야 한다.

Armed with knowledge about the three areas of consideration (goals, organizational health, and your own skills as faciltator), you now can finalize details about your retrospective design.

Who should attend the Retrospective?

Where should the Retrospective be held?

• on-site
• off-site local
• off-site residential

When should the Retrospective be held?

How long should a Retrospective be?

When Eric reported this conversation to me, I knew why Ron had so many emergencies: He didn't take time to plan.

Chapter 6. Retrospective Exercises

The "Introduction" Excercise

간단한 질문으로 시작. '지혜'란 무엇일까요? 라던지.

참석자들이 서로 다 아는지, 그렇지 않으면 서로 소개하도록 하기.

스케쥴과 회고의 목표에 대해 논의.

그룹들에게 즉석 카메라를 나눠주기.

The "I'm too Busy" Exercise

사람들이 회고에 참석하기에는 너무 바쁘다고 생각하는 경우가 종종 있다. 과거에 대해 이야기하는 것보다 내게는 더 중요한 일이 있다는 것이다.

사람들이 회고를 꺼리는 이유에는 다음과 같은 몇 가지 이유들이 있다:

1. 회고가 마녀 사냥이 될 것에 대한 두려움을 가지고 있다.
2. 과거에 어설프게 진행된 회고에 대한 안좋은 기억을 가지고 있다.
3. 이전 회고들의 결과로 일터에서의 긍정적인 변화를 경험하지 못했다.
4. 일이 너무 많다고 느끼고 중압감을 느낀다.

The "Artifacts Contest" Exercise

이거 재미있는 활동인듯. 회고 전에 사람들에게 공지해서, 프로젝트 과정에서 파생된 결과물을 준비해오도록 한다. 결과물의 종류는, 1) 가장 많은 결과물 , 2) 가장 희귀한(unusale) 결과물, 3) 가장 중요한 결과물로 구분하여 종류당 하나씩 가져오게 한다. 회고라는 활동에 들어가기 전에 이미 사람들은 물건을 찾으면서 무슨 결과물이 가장 많은지, 희귀한지, 중요한지를 판단내리게 되고, 프로젝트에 대해 되돌아 생각하게 된다. 인위적인 퍼실리테이션 없이 스스로 성찰해볼수 있도록 하는 점이 흥미롭다.

붓다가 했다는 즉문즉설과 비슷한 면이 있다.

어느날 붓다에게 아들을 잃은 여인이 찾아와서, 너무 원망스럽다고 아들을 살려달라고 애원했다. 붓다는, 우선 이웃에게 가서 소금 한 줌씩 다섯 집에서 얻어오라고, 그러면 답을 주겠다고 했다. 단, 우환이 없는 집에서 얻어와야 한다는 단서를 달았다. 여인은 쉬운 과제로 생각하고 이집 저집 다니기 시작했다. 소금 한 줌을 얻고, '이 집에 우환은 있느냐'고 묻는데, 금새 끝날 줄 알았던 과제가 하루종일 돌아다녀도 완수할 수 없게 되었다. 결국 이 여인은 우환이 없는 집은 없다는 것을 문득 깨닫게 된다. 는 이야기. 출처와 사실 여부는 확인해봐야.

CategoryBook