1. Scrum  and  Organization English  version h"p://bit.ly/r0Lc8F

2. Ryutaro  YOSHIBA(@Ryuzee)  Agile  Coach    Certified  Scrum  Professional(CSP)    Certified  Scrum  Master(CSM)    Certified  Scrum  Product  Owner(CSPO)      http://www.ryuzee.com/    Chief  Technical  Officer  at  Startup. http://www.flickr.com/photos/adforce1/2539903964/

3. Why  Agile？

4. Business  background •  Change  in  business  environment •  Swift  decision-‐‑‒making  and  actualization   are  required. •  Companies  run  the  risk  of  being  left  behind   by  the  market  if  they  do  not  change. •  Changing  company  is  strongly  required. •  Change  in  the  purpose  of  IT  investment –  From  efficiency  to  implementing  strategy –  IT  system  is  the  source  of  competitiveness –  It  is  strongly  required  to  deliver  good  product   faster.

5. Competition  speed  get  faster

6. Expiration  time  of  business   model  is  shortened.

7. Correspondence  to  change NOT  “Sticking  long-‐‑‒term  to  an  elaborate   plan  determined  beforehand“ Instead  ”We  should  assume  that   changes  will  take  place  and  change   track  as  and  when  necessary.”

8. Software  Uncertainty •  Cone  of  Uncertainty From  10  Deadly  Sins  of  Software  Estimation  by  Steve  McConnell,  ©2002-‐‑‒2007

9. Probability  of  delivery •  The  delivery  date  forecast  of  software  is   probability  distribution.   Relative   probability In  general,  the  project  manager  sets  the  delivery  date  which   has  the  highest  probability  of  delivery. However,  the  total  possibility  to  deliver  in  time  is  very  low.  

10. Use  ratio  of  features •  64%  of  features  are  not  used. Use  ratio  of  features システムの機能の利利⽤用割合 いつも使う Usually  7% 7% O3en よく使う 13% Some;mes たまに使う 16% Rarely Never   まったく使われない None 45% ほとんど使われない 19% From  Standish  report  in  2000

11. The  seven  wastes •  Over-‐‑‒production From  TOYOTA  production  system. –  Features  which  are  not  used,  Features  which  do  not  earn  value •  Waiting –  Waiting  for  specifications,  Waiting  for  building,  Waiting  for   testing •  Transportation –  Switching  tasks •  Over-‐‑‒processing –  Reports  which  are  not  useful  to  the  team,  Duplicate  components •  Inventory –  Bulk  documents •  Motion –  Travel  time  in  distributed  development,  manual  work  because  of   lacking  tools •  Defects –  Finding  defects  at  later  process  flow  and  Reworking

12. What  is  Agile？                         Realizing  customer  value. Realizing  happiness  of  the  members   related  to  development. Raising  the  profit  of  the  company. Agile  is  a  tool  for  achieving  the   above. http://www.flickr.com/photos/dhammza/474654705/

13. Scrum  Basics http://www.flickr.com/photos/royskeane/413103429/

14. Scrum＝Framework •  Key  concept –  Self  organized –  Time-‐‑‒boxed –  Inspection  and  Adaptation •  Not  a  collection  of  technical  practices •  Not  preventing  from  using  the  other  Agile   methods  at  the  same  time •  Actually,  it  is  necessary  to  use  parts  of  XP   practices

15. プロダクトオーナー 製品に対して責任をもち機能 に優先順位を付ける スクラムマスター スクラムプロセスがうまく いくようにする。 外部からチームを守る ステークホルダー チーム  (7±2⼈人) 製品の利利⽤用者、出資者、管理理職 などの利利害関係者。鶏と称す プロダクトの開発を⾏行行う。 製品の成功に向けて最⼤大限 の努⼒力力をコミットする デイリースクラム プロダクトバックログ 製品の機能をストーリー形式で記載 プロダクトオーナーが優先順位を付け、プラ ンニングポーカーで相対⾒見見積もり。 項⽬目の追加はいつでも⾃自由だが実施有無や優 先順位はPOが決める。 毎⽇日チームが以下の３つの質問に答える ・昨⽇日やったこと ・今⽇日やること ・困っていること バーンダウンチャート Doneの定義 スプリントタスクの「推定残り時間」を 更更新してグラフにプロットする 何をもって「完了了」とするかを 定義したリスト スプリント計画会議 スプリント プロダクトバックログを再度度分析・評価し、 そのスプリントで開発するプロダクトバック ログアイテムを選択する。また選択した項⽬目 をタスクにばらす 最⼤大4週間までのタイムボックス 各スプリントの⻑⾧長さは同⼀一。この間は外部 からの変更更を受け⼊入れない タスク 時間で⾒見見 積もり 毎⽇日の繰り返し スプリントバックログ そのスプリント期間中に⾏行行う タスクのリスト スプリントレビュー スプリント中の成果である 動作するソフトウェアをデモ する ふりかえり スプリントの中での改善事項 を話合い次に繋げる 出荷可能な 製品の増分 複 数 回 ス プ リ ン ト を 繰 り 返 す

16. Product  Owner   ・Responsible  for  the  product

17. Product  Owner •  Arrange  the  list  of  features   necessary  for  the  product •  Decide  release  dates  and  contents •  Responsible  for  the  productʼ’s   business  value •  Prioritize  features   •  Re-‐‑‒evaluate  features  and  priorities     •  Accept  or  reject  teamʼ’s  work •  Discontinue  sprint

18. Product  Owner  Absence •  Typical  Anti-‐‑‒Pattern •  This  problem  surfaces  when  there  are  a  lot   of  stake-‐‑‒holders. •  Lack  of  feedback  process •  Team  can  not  understand… –  What  should  be  made –  Whether  the  features  are  correct –  Whether  the  features  have  business  value Action:   Select  Product  Owner  or Build  Product  Owner  Team

19. ScrumMaster •  Guardian  of  the  Scrum  process •  Protecting  the  team  from  external   interferences

20. ScrumMaster •  Representative  for  project   management •  Responsible  for  earning  value  from   Scrum  and  doing  Scrum  practice •  Remove  impediments •  Ensure  the  team  is  fully  functional   and  productive •  Keep  close  cooperation  with   involved  persons •  Protect  the  team  from  external   interferences

21. Team •  •  •  •  5-‐‑‒9  members Cross  functional Full  time Self  organized

22. Team •  Team  commits  that  All  the  team  members   will  make  collaborative  efforts  in  project. •  The  team  decides  who  is  in  charge  of   which  task.  Not  the  manager. •  Evaluation  is  not  based  on  how  many  tasks   have  been  completed. •  Switching  members  is  not  allowed   during  the  sprint.   •  Responsible  for  following   teamʼ’s  rules •  Responsible  for  continuous   improvement

23. Responsibility  to  follow  teamʼ’s  rules •  All  Agile  processes  require   –  Delegation  to  the  team –  Establishing  a  team  culture  and  standards •  Responsible  for  attending  daily  Scrum •  Responsible  for  doing  work  complying   with  “Definition  of  Done” •  Responsible  for  giving  help  to  other   team  members. •  Responsible  for  training  other  team   members.

24. Responsible  for  continuous   improvement

25. Retrospective Place  and  chance  to  improve  process NO  attacks  on  individuals NO  linking  individual  evaluations. All  members  should  be  able  to  speak  freely. Trace  action  items  in  previous  retrospective Are  there  same  the  problems  which  were   found  in  the  previous  retrospective? •  Trying  to  solve  all  the  problems  at  once  is   likely  to  fail. •  You  must  have  a  problem-‐‑‒solving   mindframe. •  •  •  •  •  • 

26. What  is  “Commitment”？ •  Commitment  is  … –  Doing  teamʼ’s  best  to  finish  stories  selected  by  the   team. –  Not  team  memberʼ’s  individual  responsibility  but   Teamʼ’s  responsibility   •  Estimation  is  NOT  Commitment –  But  in  many  cases,  estimation  is  considered  as   commitment.  It  is  bad  habit. •  After  several  sprints  are  complete  and  the   Teamʼ’s  velocity  is  stable,  you  can  commit  to   finish  stories  based  on  all  team  memberʼ’s   agreement.

27. Pig  and  Chicken PO  &  SM  &  Team User、Manager、 Stakeholders…

28. Operation  process  transition •  A  change  from  the  past  command  control   model  to  a  self-‐‑‒organized  model  is  required. –  Command  and  Control •  Sense  of  values  that  members  simply  have  to  obey  their   superior's  instructions –  Members  feel  that  they  are  being  forced –  Whether  the  superior's  instruction  has  been  observed   becomes  the  evaluation  point. –  Training  is  not  well  executed,  so  members  will  become  lesser   copies  of  their  superiors. –  An  excellent  person  who  is  dissatisfid  with  the  current  state   will  soon  resign. –  Self-‐‑‒organized •  Managers  have  to  take  responsibility  and  have  to  solve   impediments  which  canʼ’t  be  solved  by  the  team. •  Managers  have  to  support  and  facilitate  the  team •  Managers  must  have  firm  faith  in  the  team.

29. Team  management •  Sharing  team  Vision –  Keep  motivation  by  sharing  the  goals  of  the   team  and  purpose  of  the  team. •  Cycle  of  improvement  in  the  self-‐‑‒ organized  team –  Always  be  aware  of  things  which  can  be   improved. –  Retrospective  meetings  are  a  opportunity  to  find   things  which  can  be  improved. –  Do  not  let  the  problems  stand.  It  is  important  to   keep  monitoring  whether  the  team  is  always   trying  to  improve  and  solve  problems.

30. Changing  role  of  manager •  Traditional  conduct –  Pyramid  organization –  Command  &  Control –  Authoritarian –  No  flexibility –  Answer –  Scold –  Deny –  Micromanagement •  Required  conduct –  Network  organization –  Support –  Democratic –  Flexibility –  Lead –  Praise –  Affirm –  Delegate You have to stop micromanagement if you want the team to be selforganized. Generally team tend to follow instructions. So We will never be self-organized unless there is no instruction from outside of the team.

31. Leadership  model  (SL) •  Leadership  model  is   classified  into  four  as   shown  in  the  left  chart. –  –  –  –  From  http://www.situational.com/  S1:Specific  suggestion S2:Explanation  and  answer S3:Participatory S4:Delegative •  In  Agile  development,  S3   or  S4  is  required  and   typical  WF  leader  is  S1. •  Effective  leadership   differs  depending  on  the   maturity  of  the   subordinates  or  the   organization.  

32. Cultivation  of  human  resource •  The  team  fosters/trains  members.   •  Not  OJF  through  one-‐‑‒one-‐‑‒one  training. •  All  team  members  cooperate  to  help  improve   each  othersʼ’  skills.   •  It  is  effective  to  hold  study  sessions  within  the   team.  We  can  gain  a  good  return  on  a  small   investment. •  Rapidity  of  skill  development  depends  on  the   culture  and  environment.

33. Employee  Evaluation •  From  Individual  evaluation  to  Team   evaluation •  Transparency  of  evaluation  process –  Evaluation  standards  to  which  everyone   consents –  Do  not  use  the  transparency  in  the  Agile  process   to  punish  individuals  or  the  team. –  Obscurity  of  evaluation  is  the  root  cause  of   stagnation. –  Obscurity  of  evaluation  leads  to  over-‐‑‒burdening,     hiding  problems,  negligence,  keeping  excessive   buffers.

34. Realistic  Scrum  adoption

35. Definition  of  Done •  List  of  tasks  that  team  have  to  complete   to  achieve  a  shippable  product.   •  For  example,  Writing  code,  Unit  testing, Integration  testing,  Writing  release  note. •  Preparing  DoD  for  story,  DoD  for  sprint   and  DoD  for  release  is  highly   recommended. •  Contents  of  the  DoD  list  will  be  different   for  each  project  and  will  also  depend  on   the  teamʼ’s  maturity  level.  But  DoD  is   essential  for  Scrum  projects

36. Definition  of  Done  Example •  For  a  story •  –  All  codes  including  test  code  and   production  code  checked  in. –  All  unit  tests  passing –  All  acceptance  tests  identified,   written,  passing –  Help  file  auto  generated –  Functional  tests  passes •  For  a  sprint All  stories  satisfying  DoD Product  backup  updated Performance  Testing  complete Diagram  of  classes,  database  tables   and  architecture  updated –  All  bugs  fixed  or  postponed –  Code  coverage  over  80%. –  –  –  –  For  an  internal  release –  –  –  –  –  –  •  All  sprints  satisfying  DoD Installation  packages  created operation  guide  updated trouble-‐‑‒shooting  guide  updated Disaster  Recovery  plan  updated All  test  suites  passes For  a  production  release –  –  –  –  –  –  –  All  internal  releases  satisfying  DoD Stress  testing  implemented Performance  tuning  implemented Network  diagram  updated Security  pass  validated Threat  analysis  testing  validated Disaster  recovery  plan  tested

37. Scrum  and  XP •  Scrum  practice –  Role •  ScrumMaster •  Team •  Product  Owner –  Event •  Daily  Scrum •  Sprint  planning  meeting •  Sprint  review •  Retrospective –  Things  created •  Product  Backlog •  Sprint  Backlog •  Burndown  chart •  XP  Practice（Typical  12） –  –  –  –  –  –  –  –  –  –  –  –  Planning  game Small  release Metaphor Simple  design Automated  test Refactoring Pair  programming Joint  ownership  of  code Continuous  Integration 40  hours  work  in  a  week On  site  customers Coding  standard Some  XP  practices(red  characters)  must  be  integrated  into  Scrum  process,  so   that  the  whole  project  can  be  covered  from  a  technological  perspective.  XPʼ’s  “40   hours  work”  does  not  use  in  Scrum  because  self-‐‑‒organized  team  is  the  most   important  thing  and  if  the  team  decide  to  work  overtime,  they  can  do  that.  (But   sustainable  pace  is  also  important,  so  this  should  be  a  target  for  improvement   investigation  in  retrospective  sessions.)

38. Quality  in  Scrum 24hours Sprint 2-‐‑‒4weeks Sprint  Goal Return Cancel Return Coupon Gift  wrap Wrapping Cancel Product  Backlog Sprint Backlog Coupon Potential  shippable   Product  increments Unit  tests  and  Integration   tests  and  acceptance   test  finished  at  the  end   of  each  sprint  (or  at  the   end  of  each  release).  

39. Quality  in  Scrum At  the  end  of  a  sprint  “Tests”  are  done.  In  the  sprint   review,  we  can  confirm  that  the  implemented  feature  is   suitable  for  the  customer  or  stakeholderʼ’s  requirements. http://www.flickr.com/photos/kakutani/2761992149/

40. Quality  in  Scrum Scrum  is  only  defined  as  framework  and  Automated   testing  is  not  mentioned.  But  Automated  testing  is   essential  for  Agile  development The  cost  of  manual  for   small-‐‑‒scale  releases   testing  will  increase   with  the  growth  of  the   product... Manual  testing  decreases  the  productivity  and  earning  value.  (The  ratio  of   regression  testing  to  cost  will  increase)

41. Agile  Testing  Quadrants Business  Facing 【Manual】※1 Exploratory  Testing Scenarios Usability  Testing User  Acceptance  Testing Alpha  /  Beta Q2 【Automated】 Unit  Tests Component  Tests Q3 【Tools】 Performance  Testing Load  Testing Security  Testing Q1 Technology  Facing ※1  can  be  automated  by  ATDD Q4 Critique  Product Supporting  the  Team 【Automated  &  Manual】 Functional  Tests Story  Tests Prototype Simulations

42. Automated  Testing  (Q1) Number  of  test  cases PMD  warning It  is  necessary  to  build  an  evaluation  system,  which  is   automated  as  much  as  possible,  based  on  “Definition  of   done” Checkstyle  Warning Coverage

43. Evaluating  the  teamʼ’s  activity Line  of  code Activity  at  SCM Hours  committed

44. Documents •  It  doesn't  mean  documents  are  not  written •  The  necessary  documents  have  to  be   written  at  appropriate  times.   –  The  documents  necessary  for  observance  of  the  law   are  not  necessary  from  the  first  stage  of   development. –  It  is  necessary  to  always  maintain  the  material  for   maintenance  and  operation  from  timing  in  which  the   product  is  released  to  production  environment. –  Many  documents  can  be  automatically  created. •  Writing  documents  needs  to  be  included  in   “Definition  of  done” •  Organizations  which  have  a  principal  of   document  approval  must  be  reformed.

45. Scrum  that  fail

46. Failed  Scrum •  •  •  •  •  •  •  •  •  •  •  •  •  Opposition  of  individuals Confusion No  Discipline Subversive  Behaviour Apathy Fear Dominance Hostility Excessive  superiority Ignorance Defined  positions Being  too  comfortable Indifference

47. Failed  Scrum •  •  •  •  •  •  •  •  •  •  •  •  Micromanagement Mini-‐‑‒Waterfalls Finger-‐‑‒pointing Revoking  Team-‐‑‒Decisions ScrumMaster＝Accountable   for  the  team Heroism Command  &  Control Bad  Values Hierarchical  Thinking Securing  oneʼ’s  own  position Compliance Blame

48. Failed  Scrum •  •  •  •  •  •  •  •  •  •  •  •  •  Process  at  Sprint  N  Same  as  Sprint  1 No  Known  Sprint  Velocity No  Hands-‐‑‒on  Customer  Demo No  Code-‐‑‒Reviews Stand-‐‑‒up  meetings  monotonous Tests  Not  Run  Before  Check-‐‑‒In Misleading  Metrics No  Group-‐‑‒Reflection Missing  Self-‐‑‒Reflection Missing  Commitment Non-‐‑‒Learning Wrong  Value  Definition No  leaving  Comfort  Zone

49. Failed  Scrum •  •  •  •  •  •  •  •  •  •  •  No  Time  for  responding  to  Change Retrospective  without  Action Doing  things  that  do  not  work  again No  Refactoring Sprint  Review  without  conclusions/decision   items No  Tests 10  Ways  to  do  things  in  10  days Ineffective  ScrumMaster Cookie  Cutter  Process,  Imposed  Process Group  pressure,  Invisible  Product  Owner,  No   Empowerment No  adaption,  Change  too  frequent

50. Failed  Scrum •  •  •  •  •  •  •  •  •  •  •  •  •  Many  Loose  Ends Task  Handover Only  BA  Talks  to  Customers No  Team  Planning No  Slowing  down  for  Teammates Deciding  for  the  customer Check-‐‑‒In  Race Hard-‐‑‒coded  Communication  Path No  Shared  Responsibility Push  System Turf  Wars Separation Politics

51. Conclusions •  Agile  is  necessary  to  respond  to  the  change  in   the  speed  of  business. •  Estimates  are  uncertain  and  we  tend  to  make   useless  products. •  It  is  important  to  make  systems  based  on     business  value. •  Team  over  Individual •  We  have  the  responsibility  to  improve   processes. •  “Definition  of  done”  is  essential  for  projects.  It   is  related  to  Quality. •  Documentation  is  also  necessary. •  Many  of  the  causes  of  failed  Agile  development   are  cultural.