Agile Conference 2019.10.18

** Agile Conference https://agilekorea.kr/

 

[Lean Coffee]

• Design&UX Session 참여
• 디자이너와의 협업, 디자인팀의 스크럼 구성

=> case1) 디자인 프로젝트, 개발 프로젝트 나눠져서 서로 비난하다가 파기됨, 디자인 나올때까지 기다릴 수 없으니 개발먼저해라 했더니 달라, 디자이랑 개발 같이가려니 디자인안됬는데 어떻게 개발해

=> case2) ux 포함 한팀으로 했다가, ux 분리했다가한다. 개인적으로는 포함 한팀으로했다가 문제가 생길쯤에 UX 분리했다가 다시 합쳤다가 반복한다.

스크럼팀에 포함되어있을때는 ux 입장에서 너무 silo해짐, 같은 사람들이랑 얘기하고 시야를 넓힐 기회가 적어짐

=> case3) 가구 회사, 기획팀 별도로 있음, 가구1나의 프로젝트 밑에 디자인,개발팀, 알아서 디자인하고 최상위에서 look&feel을 맞춰주는 이사님이 있음

=> 느낀점 / 구성이 그때그때 상황에 맞게 유연해야할 것 같다. 그래도 우리회사가 잘 가고 있는 것 같다.

=> 다른 회사도 디자인팀이 따로 구성되어있고 스크럼에 디자이너가 간다고한다, 자리배치를 가까이에해서 소통을 많이하는게 도움이되었다고 한다.

 

 

[key note]

페라리 cio, 듀카티 cio&cto

Play Agile like an Adult - A story of mistakes from formulas1

Piergiorgio.grossi@gmail.com

Insta : PierG

 

1. 학습경험및태도가 2가지로 나뉘어짐
1. 수직적 - 심도있는 학습을 하게됨, 해당 분야에 대해서만 공부함, 다른 분야에 무관심함, 
2. 수평적 - 프로세스, 관리에 더 흥미를가지고 활동적이고 관계지향적임
3. 좋은 design thinker가 되기 위해서는 T 모양의 성향을 가져야함, 전문적인 지식을 가지고 다분야에 대한 공감능력과 호기심
1. Depth of Expertise / Empathy + Curiosity
4. 수직성향만을 가지고있는 것은 충분하지 않음 - 역할 분열, 분할
5. 수평성향은 sns를 통해서 더 확장 가능해짐, 동료뿐만아니라 다른 나라까지도 우리의 네트워크에 끌여들일 수 있음

 

Digital transtorm…? - 애자일..!?

 

회고적인 일관성 ( retrospective coherence) - 모든 것이 끝났을 때 회고하는것, 내가 믿고서 끝까지 밀고나갔을때 나중에 되돌아보면 내가 한방향으로 왔구나 알 수 있는것..?

 

애자일 선언 - manifesto for agile software development

 

애자일하지만 페라리입장에서 실패는 없었어 ㅋ, 2주에 한번씩 계속 소프트웨어를 업데이트하고 해야했음, 그래서 개발자들 집에 안가고, 밤새고 막 그랬음

(우리랑 똑같당 ㅎ)

 

What happens in between?

Conceptual design(simulation)-> Design(CAD)->Manufacturing->Testing->Race

 

다음 레이스를 위해서 차량 준비, 어떤 팀은 다음 시즌의 차량을 준비

서로 다른 접근법이 필요함 / 애자일이 맞을 수도 있고 아닐 수도 있음

다음 레이스를 준비할때는 굉장히 빠르게 개발해야함, 다음 시즌은 상대적으로 좀더 빠르게

둘 사이를 연결하는 사람이있음, 처음에는 다음 시즌을 예상할 수 없지만 다여섯번 후에는 다음 시즌에 대해 좀 더 예측을 할 수 있게됨,

두 활동 사이에서 자원을 어떻게 배분할지 판단해야해

모든 팀에는 스토리가 필요하다. ( every team need a story more than a scrum master) - 내가 팀으로 함께할 것, 그 팀의 목적과 왜 하는지 내가하는일이 연결되어야함

애자일의 그림은 정해진게 아니기때문에 데일리 미팅을 못하고, 백로그를 작성 잘 하지 않았다고 실패한 애자일이아니다.

Martin Luther King said “I have a dream” and not “I have a plan”

우리의 최종 목표가 무엇인지가 중요하다!!!!!

 

이런 절차를따라야하는게 아니다, 이런 코드를 짜야한다라고 누가 정해준게 아니라 자기가 주도해서 했다.

 

관리에서 애자일은 절차나 관리방식에 대해서 얘기하는게 아니라 팀의 에너지에 대해서 얘기해야한다.

As a manager I do have a responsibility into the energy level of the team

각자의 동기부여로 일을 할 수 있게 하는것

 

Values first and then make what’s necessary

• 툴에 대한 의존도가 높다 ㅋ?
• 툴에 마냥 의지하지말고 구체적으로 원하는게 뭔지 알아야해, 툴이 있으면 커뮤니케이션이 잘될거야!! 이렇게 생각하면 안됨 ㅋㅋ

 

드라이버드를 두고 외부와 내부의 커낵션, 내가 할 수 있으면 내가 하고 아니면 내부 인력간의 커뮤니케이션, 매일매일바뀜 (driver = non code ownership)

신규직원들의 경우 아무것도 몰라도 2주동안 강제로 드라이버 시킴 - 내가 무슨일을 해야하는지, 내부인력관의 커뮤니케이션, 프로세스 등을 강제로 익힐 수 밖에없었다

(은혜 - 좋은거같다, are manager 처럼 스크럼 매니저 만드는것도 좋을 것 같다)

 

Adapt according to the Feedback Loop (when do you want to know you have a problem?)

문제가 있다는걸 언제 알고싶음?

• 다음 레이스를 준비하는 팀은 피드백을 빠르게 받아야함, 다음 시즌을 준비하는 팀은 매일 stand meeting을 할 필요 없음

 

Learn how to make money with it

 

Emergent design - db 설계하다가 떠오르는걸 반영?

DevOps -> DevDB 로 변경될거..?

 

Everyone is a marketing and sales person - 사람들이 원하는 것과 개발자가 생각에 간극이 생김, 대기업에서는 사용자와 개발자 사이에 사람들이 하나식 추가됨, 

 

being efficient in running the business / 비즈니스의 효율성 50%

Giving more agile it / 비용을 줄이지만 속또 올려줘

Help the company to transform 

 

고전적인 애자일방식을 은행에 적용하지는 않음, 실제 사업에 애자일을 적용해보면서 조금씩 규모를 늘림, 애자일이 모든 문제의 해결책이 될 수는 없기때문

 

Q&A

임베디드소프트웨어에서 금융업으로 업을 완전히 변했는데 어떻게 가능했는지?
-> T자형의 사람이라서, 다른 분야에도 충분히 연결될 수 있기때문,

 

배포주기가 짧은데 다른 분야와 어떻게 소통을 잘했는지?

-> 실패가 굉장히 많음, 

 

실패한 케이스, 어떻게하면 성공할 수 있을까

-> 처음엔 애자일이 모두 해법일거고 모두가 애자일하고싶을거라 생각했음, 어떤 사람이 팀을 떠나도 팀 전체가 강해지기 위해서는 보내야됨..!?!?! 애자일이 모든 곳에 잘 맞는게 아니라 애자일을하기위한 팀이 구성되어잇ㅁ어야해

-> 애자일에 대한 경험,

——————————————————————————————————————————————————————————————————

[ㄴㅏ만 찌질한거 같은 이유]

같이 일하기 힘든 연구자를 끌고가야하는 pm 입장

 

product = pm

User = 디자이너

implementation = 개발자

 

AI 프로젝트에서 연구자를 추가함

• 몸값이 비싸서 여기 아니더라도 갈곳이 많음, 자기 개인 연구

 

Servant leadership / tyrant 

 

칸반

• 일의 단위가 너무 큼
• 풀리지 않은 문제는 모든 이슈
• 풀리지 않은 문제는 모든게 낫 이슈

스크럼

• 타이트한 타인의 관리보다는 본인과의 싸움이 중요함
• 협업보다는 숙제 검사에 익숙
• 커뮤니케이션보다 숫자

 

Whole team - team balance

 

Sota?

 

연구자에게 UX를 어떻게 측정하나요

• ux를 어떻게 이해 시킬지 고민하지 말 것
• SISUQ, efficiency rate 등의 지표등을 활용, mos 같은 측정 방법을 가지고 이야기 할 것

 

 

——————————————————————————————————————————————————————————————————

[안정지향적 조직에서 애자일 적용]

 

 

야크털깍기현상 : 목표를 잘못 이해한 개인의 실수, 조직의 시스템이나 노하우 부실도 원인, 협업등으로 완화가능

lesstif.com

조금씩, 작게 변화 누적시켜서 변화 해야해

책추천 : 메이크타임, 구글 벤처스의 혁신적 시간관리법

 

협업을 위한 툴 소개,

 

진척률의 기대치와 예측치 - Gantt chart(간트)

 

CI - Hudson -> Jenkins -> jira랑 연결잘되는 bamboo로 이동

==> out of memory // Jenkins 문제 ㅋㅋㅋㅋㅋ

 

가진도구가 망치뿐이라면 모든 것이 못으로 보일 것이다.

 

Agile 개발 프로세스 : 라면 끓이는 기계와 비슷하지 않을까

 

Best practice & anti pattern

모두에게 맞는 프로세스는 있을 수 없음

Jira query lang 권장(필터)

 

Jira worklog

 

그때 맞은게 지금도 맞는가? = yoda식 도치 화법 (afraid, are you )

조직이 일을 더 잘하기 위해 하는 일도 제대로 평가 받을 필요가 있음

——————————————————————————————————————————————————————————————————

[Hans on]

 

Waterfall 

개발 프로세스가 이미 확립된 분야, 전단계에서 확정된 내용이 다음단계에서 변경되지 않거나 허용되지 않는 경우

 

Agile(반복 점진적) - 불확실성이 높을 때 적용

요구분석,설계,개발,테스트,출시 가 반복점진적으로 

 

스크럼 보드 - 백로그 및 스프린트를 관리할 수 있음,

 

waterfall을 구현하기 위해서 Structure 플러그인 사용

• 기존 프로젝트 관리방식인 wbs(ms project) 형태로 jira 데이터를 관리
• 계층 구조로 이슈를 관리할 수 있음

 

Jira free tier 생김 ㅋㅋ

 

개발팀은 워터폴, 마케팅팀은 애자일이라고 가정했을때

 

——————————————————————————————————————————————————————————————————

[OKR]

1. HR이 왜 애자일을 공부해야할까?
1. hr은 보수적인 경향이 있음
2. 창의적이고 혁신적인 구성을 위해 금융권에서도 애자일 적용하려고해
1. 근데 애자일도 느리데 ㅋㅋㅋ 그래서 디지털금융을 독립조직으로 ㅋㅋㅋ
3. 애자일 가치와 기업 문화가 충돌한다. 애자일 방법에 대한 경험이 부족하다.
2. 애자일 조직 문화의 특징
1. 권한위임(empowerment) - 빠른 변화에 민첩하게 대응할 수 없음
2. 가치 중심
3. 회고/개선
   => 철저한 계획 중심에서 적응하고 학습하는 조직으로의 변화
3. 목표와 핵심결과의 약자 / 조직 전체가 동일한 사안에 관심을 집중하도록 만들어주는 경영 도구
4. ORK
1. Plan
1. Company okr - team okr- individual okr
2. Do
1. 1 on 1 meeting
3. See
1. Okr review
4. 보통 분기의 마지막 달에 planing과 review가 진행됨
5. objectvies - what 무엇을 할 것인가, 목표, 이상, 주로 3-5개
6. key results = how 어떻게 할 것인가, 구체적인 숫자가 있어야함
7. okr 의 핵심은 뭘까(특징)
1. 우선순위 / 동기부여
   사장이 먼 시야를 보는게 맞을 수도, 실무자의 입장에서 바로바로 보이는게 맞을 수도
1. 최고의 팀은 하양식 목표 설정과 상향식 목표 설정 사이의 창조적 긴장 위에 존재한다.
1. 앞으로의 방향은 위로부터, 전체적인 시야로부터 도출되어야 하지만, 구체적으로 어떻게 이뤄나갈지는 팀이 스스로 찾아야한다.
   그 목표를 조절하기 위해서 1 ON 1 이 중요하다.
2. 도전적인 Stretch(도전적인) 
1. 일반적인게 0.7, okr의 1은 와우 싶은거
   okr은 정성적인 평가와 정량적인 평가가 조합됨, 달성률(정성적)만 가지고 평가를하면 다음에는 목표를 낮게 잡게됨
2. okr의 달성률은 평가와 연관 없지만 OKR이 진행되는 과정은 평가에 속한다.
3. 리뷰/피드백
1. 분기별로 진행
1. 성공적으로 성취한 OKRdms 무엇이며 가장 큰 성공 요인은 무엇인가?
2. 성취하지 못한 OKR은 무엇인가? 관련한 가장 큰 장애물은?
3. 이번분기에서 배운 점과, 다음 번 OKR에 반영할 것은 무엇인가요?
4. 더 나은 결과를 위해서 저희팀이 어떤 지원을 해드리면 좋을까요
4. okr은 전사적으로 공유가 되어야함, ceo의 목표를 전사적으로 공유할 수 있는가?

 

q&a

1. 중간관리자의 교육 - 일상 의사결정 과정에 계속 참여시켜서 동일한 목표를 가지게 하고 평가 보상 위원회를 구성하여 좋은 평가가 무엇인지에 대한 이야기를 많이함, 공동의사결정을 연습하는 것이 중요함
2. 도전적인 목표의 수준은 누가 판단? - 개인이!
3. 비공개(m&a)같은 경우는? - 비공개처리함, okr 공유하지 않음
4. 실제 적용해보니 직원들의 반응은? - 공정성(분배적, 절차적) - 이사쪽에서 공정하다고해도 직원은 공정하다고 생각하지 않는다고 생각함, 많이 받는 사람이 만족하지, 그래도 이런 사람이 평가 잘 받아 라고 메세지를 직원들에게 전달할 수 있다. 리더들의 만족도는 높아짐, 일반 사원은 호불호갈림

 

은혜 느낌 - 피드백이 굉장히 중요한거 같은데 팀원이 많으면 힘들지 않을까? 

——————————————————————————————————————————————————————————————————

뭔뜻이람 ㅋ

 

 code of conduct

Embrace change

How to measure product value

Docs : distributed version control systems