아픔을 참 아름답게 승화시킨 것 같다.
그녀만의 스타일로 재해석한 곡, 앳된 목소리와는 다르게 온몸으로 이를 연주하는 그녀의 모습…
감동이다.
Few weeks ago I was asked to write a blog post for ThoughtWorks studios. It could be pretty much anything related to being a business analyst in agile world. At first it didn’t sound difficult at all. I just needed to think about what I do and write about them. But it was a lot more challenging than I expected. This experience made me look back at what I *really* do and what values I bring to the table.
It also made me realize the brutal reality of how BAs are perceived professionally, and ended up having me had an identity crisis about my profession. It was not a new thing when I hear questions like ‘Do we need a business analyst on an agile team?’, ‘What do they do?’, ‘Do I really need to pay for this role?’ from clients.
Not sure if I can say my crisis is ended, but at least this is where I ended up being with that question.
If you ever wonder what I mean when I say I am an Agile Business Analyst, this will give you some idea.
Of all, what I found special about this particular clip is how it clearly explained that anyone can be a BA in Agile teams. It’s not so different from the idea of everyone in Agile teams should responsible for the quality of their product. It’s not only QAs job to find bugs.
That can also mean that BA can be a tester or product owner or XD designer etc. I think it is actually pretty good attitude for BA to learn about automation testing & XD thinking and techniques.
Yes, becoming a specializing generalist.
For the past 33 years, I have looked in the mirror every morning and asked myself: “If today were the last day of my life, would I want to do what I am about to do today?”
And whenever the answer has been “no” for too many days in a row, I know I need to change something.
~Stanford University, 2005
How am I doing?
A few months ago I wrote a post about Agile Korea 2012 I attended last year. Unlike my first attendance as an organizer/volunteer at 2011 I spoke this time. The official title for this talk was - Addressing the problem Agile practitioners are facing everyday (via personas and communication).
Below is an overall summary of this talk.
I introduced three different cases of various Agile teams. And yes, the answer to address those issues was the communication - of different forms. :) Below is the rough stories about them.
Case 1 - Where are we going?
A BA from a mature Agile team says that her team was almost too good at self-organizing that it was hard to understand what everyone was up to everyday and where the team was going. She found her answer from adopting a ‘visualized’ standup.
The visual communication is the answer.
Case 2 - How do we have tech and biz people on the same page?
A QA from a large enterprise team suffers from having techies and business folks to speak the same language to understand requirements and the vision. He found his answer from adopting BDD using Cucumber.
The communication using a tool is the answer.
Case 3 - Do I really need to pair with him today?
A female developer from an Agile team says that pairing can be a very challenging thing at times. She found her answer from having a daily 1-on-1 feedback session and frequent retrospective as an answer.
The communication in safe and personal environment is the answer.
There is no one who doesn’t know that communication is important. And yet, not a lot of us are good at it. This talk basically want to question you if understanding uniqueness of your situation and apply some equipment to ease your communication can resolve problems you and your team are having.
I also conducted an User Story workshop with JunPyo Park. He is a Scrum Master in Korea and I work as an Agile consultant in San Francisco. Three months prior to this conference, he and I had weekly calls to prepare this workshop. It was quite an experience and we learnt a lot from understanding different ways we work. :) This workshop was to share our learnings and have more hands on story writing practices for a real app called Magic Water.
It’s been already more than six months and looking back at it, I think I can conduct this session a bit differently for the better. Hope to get a chance to run it and discuss about this very topic with more people.
If you want to see the rest of talks presented at Agile Korea 2012, please visit SangChel Hwang’s blog.
I can’t find another way to see about ‘interrupting others’ than this.
What I am saying is more important than what you are saying.
I am more important than you.
~ from ‘Eat, Pray, Love’ by Elizabeth Gilbert
What is defect? When does it become a defect?
Let’s define ‘defect’.
A defect is behavior in a ‘Done’ story that violates valid expectations of the customer.
In short, if you discovered any behavior that does not meet the expected outcome which was agreed on a particular story after it was accepted by a customer already, THAT is when it is raised as a defect. If this story was just ‘development complete’ state, you don’t raise a defect. Rather you go talk to an appropriate developer and fix it as soon as possible.
Often times talking to someone about anything ‘right away’ is not easy to do in Agile team, so I used to make a note about this behavior on a story itself. (normally at the top of the story in CAPITAL so it’s annoying and attention grabbing ;P)
How to log a defect?
I’ve seen various of ways to raise a defect, but below are the essentials that I feel must be captured in defects. Otherwise, the defect becomes meaningless or developers will need to investigate a lot of time to investigate about it before fixing it just to understand what it is.
The reasons for 2 & 3 must be obvious. Why we want to have ‘Steps to reproduce’ is that this information help identify whether this defect is still valid or not. I find that it saves a lot of people’s time investigating and understanding the behavior by following listed steps. This is also often used to check whether it is seen on a certain environment. (e.g. only seen in safari?)
If you’re unhappy, nine times out of ten it’s because you’re clinging onto something.
Nine times out of ten, happiness and letting go are synonymous.
한국 엔지니어분들에게 아쉬점이 하나가 있다면 그건 ‘영어로 소통하는 능력’이다. 개발자에게 가장 중요한 능력이 개발능력이라고 하지만, 좋은 개발자가 되기 위해서는 ‘소통’하는 능력이 중요하고, 평생 한국시장에서만 필요한 소프트웨어를 개발할 생각이 아니시라면, ‘영어로 소통하는 능력’은 옵션이 아니라 필수라고 생각한다.
좀 쑥쓰럽긴 하지만 나이가 들어 외국에 간 것치고는 내가 나름 영어를 구사하는 편이라, 그동안 여러 분들에게 영어에 대한 질문을 받곤 했다. 지금은 생각이 좀 바뀌었지만, 예전에는 정말 Native같이 영어를 구사하고 싶었기 때문에, 그런 질문을 받아도 ‘제가 무슨~’ 하며 어떤 비법(?)도 말해주지 않았다.
헌데 능력있는 엔지니어이면서도, 언어때문에 더 큰 시장에 나갈 생각조차 않는 한국분들을 보면 안타까운 마음이 커진다. 그래도 외국인으로써 소통의 핵심적 역활을 하는 Business Analyst로 활동하게 되기까지, 그리고 나의 세번째 언어인 ‘중국어’ (물론 아직 많이 부족하지만^^)를 공부하면서, 내가 나름 터득한 언어 공부방법을 이 곳에 옮겨보았다.
1. 시트콤 자막활용하기 -
처음에는 한글자막으로, 내용이 다 이해가 되었다면 영어자막으로, 그리고 마지막으로는 자막없이 보기. 우선 시트콤의 내용을 이해하면서 귀를 틔우는 게 중요하다. 아는 만큼 보인다고, 들리는 만큼 이해도 되고, 말(speaking)도 할 수 있다.
Friends, Everybody loves raymond, Will & Grace와 같이 재미있는 생활 시트콤이 좋다. (요즘엔 더 새로운 게 많이 나온거 같다 ^^) 매일 사용할 수 있는 표현을 배우고, 미묘한 미국의 웃음코드 등 사소하지만 중요한 그들의 문화와 생각을 배울 수 있는 그야말로 최적의 방법이다.
여기서 ‘재미있는’이라는 부분을 강조하고 싶은데, 왜냐하면 재미있어야만 반복적으로 보게되고 기억에도 잘 남기때문이다.
2. 들리는 발음대로 대사 외우기
많은 사람들이 계속 보고, 듣다 보면 자연히 많은 표현이 외워진다고 생각한다. 하지만 ‘발음’은 절대 그냥 나아지지 않는다. 발음이야말고 연습하고, 고치는 과정이 필요하다. Native만큼은 아니더라도 엑센트, 억양, 톤을 연습하고 문맥에 맞게 활용해 보는게 중요하다.
실은 의사소통이 되는 수준이라면 ‘발음’보다는 내가 어떤 중요한 말을 하느냐가 더 중요하긴 하다. ‘실력’이 먼저라는 말이다. 하지만 의사소통, 내 의견을 피력할 정도의 실력이 되기까지 제발 ‘발음’을 미리 포기하지 말았으면 한다.
어느 정도 영어를 할 수 있는 분이라면 ‘고급영어’에 대한 욕심도 내라고 하고 싶다. 아는 만큼 부족한 부분이 보이는 것처럼, 내가 굳이 영어 발음 클리닉 수업을 들은 것도 그런 이유었다. 조금 더 세련되게 표현하기 위해 필요했던 주요한 발음의 법칙 및 유의할 점에 대해서 체계적 배울 수 있어서 참 좋았다. 적극 추천한다.
3. 전화 영어
아마 가장 난이도가 높은 소통이 전화영어가 아닌가 싶다. 매일 조금씩이나마 영어로 대화를 나누는 장점 외에 전화 영어 최고의 장점은 바로 내 표현을 ‘고쳐주는’ 사람이 있다는 것이다. 아무리 외국인 친구를 만나 같이 놀아도 영어가 늘지 않는데는 이유가 있다. 계속 같은 표현만 쓰고, 몸짓 발짓 다 사용해서 이야기하다보면, 한국에 호기심 가득한 외국인들은 단어 몇 마디만 이야기해도 대충 다 알아 듣기 때문이다.
새로운 표현을 익히고, 활용하고, 고쳐야 할 부분에 대해 알아가다 보면, 조금씩 발전하는 모습을 발견할 수 있을 것이다.
모든 근본적인 문제에 대한 해결책이 그렇듯이, 지름길은 없다. 꾸준히 오래 하는 걸 이길 장사가 없다는 뜻이다. 그럼 어떻게 무엇인가를 꾸준히 할 수 있나? 이미 언급했지만, ‘재미’ 가 있어야 한다. 새로운 것을 배우는 재미, 점점 안들리던게 들리고, 하지 못했던 말을 하며 느끼는 재미 등.
막상 적어놓고 보니, 그렇게 새로운 방법도 아닌 것같다. 실은 한국에서는 영어구사능력이 너무나 중요시되어 있어, 오히려 부정적인 느낌이 들 정도다. 네이티브가 될 필요는 없다. 하지만, 영어로 의견을 피력할 정도의 능력은 갖추어야 어떤 분야에 종사하던 세상을 ‘와우’하게 만드는 경쟁력있는 서비스, 제품 또한 만들 수 있다고 생각한다.
대한민국, 화이팅! :)
I liked this talk ever since I first watched it. But two years later, I am asking myself again; Am I an artist now?
These are what I don’t want to forget -
A few weeks ago I started a new challenge and joined an Agile Training team at ThoughtWorks.
I’ve been working as a Business Analyst in various consulting and product development teams using Agile since 2006. However lately I’ve been fascinated to learn how to effectively share what I know or struggle with to others who are curious about them.
Having that said, this new role really excites me. I believe this will open up a various of opportunities to share while developing skills I’ve been looking for. But introducing myself as a ‘Trainer’ is already made me quite anxious. To begin with I wasn’t sure what it meant by ‘being a trainer’ and what could be a good quality to become one.
The six hats of trainer in that context gave me a really great insight. However I would like to add one more hat after delivering a TWU format of training at Samsung SDS recently.
Be a friend.
Of all, what was most appreciated and differentiated ThoughtWorkers from the rest of trainers they’ve had was our empathy in embracing their professional and social culture.
Listen. Hear their pain. Don’t be authoritative. Make sure you empower them throughout activities. Don’t give solutions to them as a teacher. Rather sit down with them and discuss together to find the ‘a ha!’ moment. Understand their unique situations. Watch your attitude when act as a teacher. There are reasons why creativity dies in school. Keep in touch. See what attempts were made, what failed and what succeeded. Keep encourage them and show that you care. All of these are possible when you connect with them and be their friend.
Only then, the training is truly effective and successful.
Only then, a trainer can provide a transformative experience.
That’s what I become to believe.
If you are in a large team or your team is not familiar with a concept of standups, then the standup tends to last longer than we intend to. I found that below a great reminder to everyone.
- Say ‘Ditto’ - do not repeat what your pair already said.
- Only share what matters to the team - you don’t need to say everything you need to do today.
- Pass a token and make it as a fun ritual - some people tend to ask questions and interrupt after someone speak which often tends to drag the duration of the standup. Only a person with a token should speak.
Please refer this to understand why standup is NOT just a standup and so much more!
Sheryl Sandberg.
I like how she quietly but effectively remarks her point.
She does not insist that pursing a career is better than being a house wife to take care of family. So we need to love what we do and should feel rewarded at work. Otherwise it’d be hard to leave your kids and family behind everyday.
She gives three advice to women who would like to pursue her career -
There are lots of great things about TED, but of all, I am glad this become a great gateway for me to know about great female role models and speakers.
I’ve listen to many different versions of ‘Passacalia’, but this performance by Julia Fischer and Daniel Muller-Schott moved me by far.
Especially Julia Fischer’s emotional expression is quite out of the ordinary. I could feel that she was immersed into playing this piece even if I listen to this with my eyes closed.
I love it.
You will see what I mean by that especially if you try out different versions of Passacalia yourself.
Julia Fischer (violin) & Daniel Muller-Schott (cello) play Handel-Halvorsen Passacaglia from Zeffiron on Vimeo.
I am one of those people who isn’t great at having a poker face. It’s hard to miss my state of emotions from my facial expressions. I seriously thought how to remove those at work as I believed it was not a professional behavior.
Obviously it was not easy.
But after trying many failed attempts to hide my developed emotions with others, I discovered one rule that can help reduce that probability - Understand their intentions before reacting to it.
Often times, at work, what becomes a problem is that you show your negative emotions to others. (positive emotions never were a problem even if you show them based on wrong information. you can just be a happy goofball). What’s worse is that if your negative reaction was developed from wrong or missing piece of information, it’s really embarrassing - and THAT really is not professional. It will make you blush, or deny your pitfalls unless you are brave enough to admit them.
So now I am trying to react to negative emotions only when I fully understand the situation or that person’s real intention. So how?
Ask.
Can you tell me the intention behind that (question) ?
Do you mean…?
Even if you cannot speak with them in person, do not write emails or give phone calls right away. I found that you can best investigate the situation when you are in neutral state. So„,
Ask before you react.
It will save you from having many uncomfortable conversations.