Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Refactoring the Organization Design (LESS2010)


Published on

These are the presentation slides from a presentation I gave at the Lean Enterprise Software and Systems Conference 2010 (LESS 2010, The presentation is based around the paper I submitted that is published in the proceedings.

From the paper abstract:
Every organization has a design. As an organization grows, that design evolves. A decision to embrace agile and lean methods can expose weaknesses in the design. The concept of refactoring as applied to software design helps to improve the overall structure of the product or system. Principles of refactoring can also be applied to organization design. As with software design, the design of our organization can benefit from deliberate improvement efforts, but those efforts must have a purpose, and must serve the broad community of stakeholders that affect, or are affected by, the organization. Refactoring to agile and lean organizations demands that we have a shared vision of what the refactoring needs to achieve, and that we optimize the organization around the people doing the work.

Published in: Business

Refactoring the Organization Design (LESS2010)

  1. 1. Refactoring  the  Organiza=on   Design   ©  Ken  Power  2010  
  2. 2. Mo=va=on  3.0  and  the  Type  I  Toolkit   Carrots  and  s=cks  work,  but  only  in  a   surprisingly  narrow  band  of   circumstances.  For  enduring   mo=va=on  and  high  performance,   autonomy,  mastery,  and  purpose  are   much  beLer.   Get  back  to  first  principles:  deligh2ng   customers,  challenging  employees,  and   making  a  contribu2on.     ©  Ken  Power  2010  
  3. 3. Refactoring   •  Mar=n  Fowler  “Refactoring:  Improving  the  Design   of  Exis7ng  Code”  (1999)   –  “Behavior-­‐preserving  transforma=on  that  improves   the  design  of  exis=ng  code”   •  Joshua  Kerievsky  “Refactoring  to  Pa;erns”(2004)   –  Suggests  that  using  paLerns  to  improve  an  exis=ng   design  is  beLer  than  using  paLerns  early  in  a  new   design   •  Whether  code  is  years  old  or  minutes  old   –  “We  improve  designs  with  paLerns  by  applying   sequences  of  low-­‐level  design  transforma=ons,   known  as  refactorings.”   ©  Ken  Power  2010  
  4. 4. Tease  Apart  Hierarchies   •  You  have  an  inheritance   hierarchy  that  is  doing   two  jobs  at  once   •  Create  two  hierarchies   and  use  delega7on  to   invoke  one  from  the   other   ©  Ken  Power  2010  
  5. 5. Remove  Middle  Man   •  A  class  is  doing  too  much  simple  delega=on   •  Get  the  Client  to  call  the  delegate  directly   ©  Ken  Power  2010  
  6. 6. Collapse  Hierarchy   •  A  superclass  and  a  subclass  are  not  very   different   •  Merge  them  together   ©  Ken  Power  2010  
  7. 7. Transi=on  Journey   scale   Agile   Company   Working  Group   Role   Pilot  Program   Defini=ons   Performance,  Reviews   Agile   Release   Lean   Group   Transi=on  Team   PorFolio   Train   Thinking   Management   Systems   Pilot  Program   Systems   Of   Communi=es   Kanban   Systems   Systems   For  Systems   Forums   Agile   Value  Stream   Office   Mapping   Business   Agile   Lean   Agile   Transi=on  Team   Thinking   PMO   Unit   PorFolio   Kanban   Management   For  Reusable   Con=nuous   Kanban   Components  Improvement   More  Programs   Pilots   Majority  of   Program   Pilot  Program   Projects  and  Programs   Kanban   Select   More  Projects   Pilots   Kanban   Agile   Project   Pilot  Projects   More  Projects   For  Support   Feature   Individual   Teams   Individuals   Evangelists   2008   2009   2010   2011+   =me   ©  Ken  Power  2010  
  8. 8. Challenges   •  Gaps  in  training  –  not  a  subs=tute  for  experience   •  Integra=ng  people  and  groups  outside  the   development/QA  teams   •  Integra=ng  User  Experience  groups   •  The  role  of  managers   •  Understanding  and  managing  dependencies   across  complex  systems   •  Customer  engagement  for  mass-­‐market  products   and  systems   •  Rewards,  incen=ves,  performance  management   ©  Ken  Power  2010  
  9. 9. Core  Framework  vs.  Toolbox   Toolbox   Sets  of  prac=ces   Core   Common   Framework   Baseline   ©  Ken  Power  2010  
  10. 10. Refactoring  Toolshed   ©  Ken  Power  2010  
  11. 11. ©  Ken  Power  2010  
  12. 12. How  many  people  …   •  …  are  in  a  single  Scrum  Team?   •  …  does  it  take  to  build  and  deliver  a  product?   •  …  does  it  take  to  ship  a  product?   •  …  does  it  take  to  ship  a  system?   ©  Ken  Power  2010  
  13. 13. Typical  Sta   ©  Ken  Power  2010  
  14. 14. Any  group  or  individual  who  can  affect  or  is  affected  by  the  achievement   of  the  organiza=on’s  objec=ves   STAKEHOLDERS   ©  Ken  Power  2010  
  15. 15. What  is  a  ‘resource’?   ©  Ken  Power  2010  
  16. 16. Freeman’s  Basic     2-­‐=er  model   The  Firm   Government   Primary   Stakeholders   Compe=tors   Media   Communi=es   Customers   Secondary   Stakeholders   Financiers   Employees   Suppliers   Special   Interest   Customer     Groups   Advocate   Groups   ©  Ken  Power  2010  
  17. 17. Example:  Product  Architecture   Product  Architecture   Client  Development   Teams:  ‘Late  integrators’   Primary  Stakeholders   3rd  Party     Developers   Customers   Client  Development   Media   Teams:  ‘Early  Integrators’   Architecture   Teams   Secondary  Stakeholders   User     Experience   Teams   Other     Product   Business   Management   Units   API  QA   Client   Teams   Applica=on     Tech   QA   API  Development   Support   Teams   Team   Team   Special   Interest   Test  Automa=on     Groups   Team   System  Test   Team   ©  Ken  Power  2010  
  18. 18. Stakeholder  groups   ©  Ken  Power  2010  
  19. 19. Stakeholders  in  a  So@ware  Product  Development  effort   • Responsible  for  managing  the   Program     projects  that  are  part  of  the   Sorware  Development  Engineer   User  Experience   program.   Core   • Repor=ng  progress,   QA  Engineer   Universi=es,  Colleges   interfacing  with  the  wider   Team   organiza=on,  and  generally   Test  Automa=on   Research  Ins=tutes   keeping  the  project  on  track.     Feature  Test   Technical  Writer   • People  who  have  a  stake  in   System  Test   Development  Manager   Product   guiding  the  end  deliverable,   Owner   either  through  providing   Performance  Test   QA  Manager   Team   input  or  reviewing/approving   the  output.   Alpha  Test   Product  Manager   Early  Field  Trials   Program  Manager   Marke=ng   System  Architect   • Anyone  that  has  a  stake  in   Enterprise  Architect   Release  Manager   Product   building  the  product.   Delivery   • Generally  responsible  for   Security  analyst   Account  Manager   Team   comple=ng  tasks  that  belong   to  User  Stories.   HR,  Recruiter   Technical  Support   • People  who  have  a  stake  in   Customers   Regulatory  Bodies   evalua=ng,  buying,  or  using   the  product  that  we  build  and   Lawyer   Accountant   in  determining  how  it  fits   with  the  strategic  direc=on  of   Director   Sales   Product   their  own  organiza=on.     Consumers   • Responsibili=es  include   Vice  President,  Senior  VP   Solu=on  Architect   evalua=ng  the  product,   purchasing  the  product,  using   Compe=tors,  Partners   Lab  Administrator   it,  providing  feedback,  and   providing  input  to  the   President   Scrum  Master  /  Agile  Coach   product  direc=on.   CxO   Sorware  Architect   • Anyone  who  has  a  stake  in   Porqolio   the  product  and  how  it  fits   Open  Source  community   Standards  Bodies   Council   with  the  strategic  direc=on  of   our  organiza=on.   3rd  Party  Developers   Media   ©  Ken  Power  2010  
  20. 20. STAKEHOLDER  MAPPING   ©  Ken  Power  2010  
  21. 21. ©  Ken  Power  2010  
  22. 22. Scrum   Master   Product   Cross-­‐Func=onal   Owner   Delivery   Team   Scrum   Team   Product  Owner  Team   System   User     Porqolio   Experience   Extended  Delivery  Team   Council   Team   Other     Business   Units   Product   Development   Beta   TME   Manager   Manager   GB   Channel   UE   Ramp   Program   Product   Lead   Alpha   Manager   Early   Sales   Access   Architect   Support   QA   Program   Manager   Engineers   Tech   Customer   Support   Engagement   Team   Product   Team   Marke=ng   ©  Ken  Power  2010  
  23. 23. ©  Ken  Power  2010  
  24. 24. Stakeholder  Management  Principles   1.  Stakeholder  interests  need  to  go   6.  We  need  intensive  communica=on   together  over  =me.   and  dialogue  with  stakeholders  –   2.  We  need  a  philosophy  of   not  just  those  who  are  friendly.   volunteerism  –  to  engage   7.  Stakeholders  consist  of  real  people   stakeholders  and  manage   with  names  and  faces  and  children.   rela=onships  ourselves  rather  than   They  are  complex.   leave  it  to  government.   8.  We  need  to  generalize  the   3.  We  need  to  find  solu=ons  to  issues   marke=ng  approach.   that  sa=sfy  mul=ple  stakeholders   9.  We  engage  with  both  primary  and   simultaneously.   secondary  stakeholders.   4.  Everything  that  we  do  serves   10.  We  constantly  monitor  and   stakeholders.  We  never  trade  off   redesign  processes  to  make  them   the  interests  of  one  versus  the   beLer  serve  our  stakeholders.   other  con=nuously  over  =me.   5.  We  act  with  purpose  that  fulfills  our   commitment  to  stakeholders.  We   act  with  aspira=on  towards  fulfilling   our  dreams  and  theirs.   ©  Ken  Power  2010  
  25. 25. The  role  of  manager   •  “Whatever  the  magnitude  of  their  stake,  each  stakeholder  is  a  part   of  the  nexus  of  implicit  and  explicit  contracts  that  cons7tutes  the   firm.  However,  as  a  group,  managers  are  unique  in  this  respect   because  of  their  posi7on  at  the  centre  of  the  nexus  of  contracts.   Managers  are  the  only  groups  of   stakeholders  who  enter  into  a   contractual  rela7onship  with  all   other  stakeholders.  Managers  are  also  the  only   direct  control  over  the   group  of  stakeholders  with   decision-­‐making  apparatus  of  the  firm.”   –  (Hill  &  Jones,  1992:  134)   ©  Ken  Power  2010  
  26. 26. Crea=ng  the  right  environment   Product  Organiza=on   • Build  organiza=on   • Org  strategy   Directors   • Remove  barriers  at  org,  cross-­‐ Product   product  level   Product   Owner  Team   Product   Owner   Product   (CUCIMOC)   Owner  Team   • Build  teams   Product   2nd  Line   • Product  strategy   Product   aster   Scrum  M Owner   (CUCIMOC)   Managers   • Remove  barriers  at  product,   Owner  Team   cross-­‐team  level   Owner   Product   Scrum  Master   Delivery   Scrum  Team   Master   Product   Delivery   • Develop  people   1st  Line   • Release  strategy   Team   Delivery   Managers   • Remove  barriers  at  release,   Team   team  level   ©  Ken  Power  2010  
  27. 27. Stakeholder  Engagement  Rhythm   Full  Product  Release   Release Rhythm Project Product   Rhythm Increment   Itera=on   ©  Ken  Power  2010  
  28. 28. Metaphors   •  “Each  metaphor  gives  us  some  insight,  and   taken  together  they  show  what  a  complex   concept  learning  really  is.  No  one  metaphor  is   “correct”,  but  each  represents  a  different   understanding.”   Mul2ple  Metaphors  for  Learning  by  Gary  Woodill     In  “Learning  and  organiza,ons:  towards  cross-­‐metaphor   conversa,ons”   ©  Ken  Power  2010  
  29. 29. ©  Ken  Power  2010  
  30. 30. Jazz  Improvisa=on   •  Provoca=ve  competence:  Deliberate  efforts  to   interrupt  habit  paKerns     •  Embracing  errors  as  a  source  of  learning     •  Shared  orienta=on  toward  minimal  structures  that   allow  maximum  flexibility     •  Distributed  task:  con2nual  nego2a2on  and  dialogue   toward  dynamic  synchroniza=on     •  Reliance  on  retrospec2ve  sense-­‐making     •  "Hanging  out":  Membership  in  a  community  of   prac2ce     •  Taking  turns  soloing  and  suppor=ng   “Crea,vity  and  Improvisa,on  in  Jazz  and  Organiza,ons:  Implica,ons  for   Organiza,onal  Learning”  -­‐  Frank  J.  BarreL   "Organiza2on  Science"  /  Vol  9,  No.5.  September-­‐October  1998   ©  Ken  Power  2010  
  31. 31. Arqul  Making  –  Ch.  1:  What’s  really  different  about  knowledge  work   AS  BUSINESS  BECOMES  MORE   DEPENDENT  ON  KNOWLEDGE  TO   CREATE  VALUE,  WORK  BECOMES  MORE   LIKE  ART.   ©  Ken  Power  2010  
  32. 32. An  industrial  making  process   Concept  genera=on   Product  planning   Product  engineering   Process  engineering   Produc=on  process   Product   ©  Ken  Power  2010  
  33. 33. An  ArFul  Making  Process   Generate  Product   Talk  with   Repeat   customer   about  product   Expose   customer  to   product   ©  Ken  Power  2010  
  34. 34. Release   Collabora=on   Ensemble   Play   4  QUALITIES  OF  ARTFUL  MAKING   ©  Ken  Power  2010  
  35. 35. A  method  of  control  that  accepts  wide  varia=on  within  known   parameters.  Release  contrasts  with  Restraint,  the  usual  method  of   industrial  control.   RELEASE   ©  Ken  Power  2010  
  36. 36. The  quality  exhibited  by  conversa=on,  in  language  and  behavior,  during  which   each  party,  released  from  vanity,  inhibi=on,  and  preconcep=ons,  treats  the   contribu=ons  of  other  par=es  as  material  to  make  with,  not  as  posi=ons  to   argue  with,  so  that  new  and  unpredictable  ideas  emerge.   COLLABORATION   ©  Ken  Power  2010  
  37. 37. The  quality  exhibited  by  the  work  of  a  group  dedicated  to  a  collabora=on   in  which  individual  members  relinquish  sovereignty  over  their  work  and   thus  create  something  none  could  have  made  alone:  a  whole  greater   than  the  sum  of  its  parts.   ENSEMBLE   ©  Ken  Power  2010  
  38. 38. The  quality  exhibited  by  a  produc=on  while  it  is  playing  for  an  audience;   or  the  quality  exhibited  by  interac=on  among  members  of  a  business   group,  and  ul=mately  between  the  group  and  the  customer.   PLAY   ©  Ken  Power  2010  
  39. 39. So@ware  Development   Play  Making   Itera=ve  Cycle   Product  build  and  test;  try   Rehearsal   different  op=ons   Distributed,  independent,   Individual  developers  at  work   Individual  actors  preparing   simultaneous  inven=on   on  design  or  source  code   between  runs   Unifying  ac=on   A  product  build   A  rehearsal  run   A  director  who  facilitates   The  Scrum  Master  or  project   The  director   coherent  chaos   manager   Forum  for  conversa=on   Mee=ngs,  technology-­‐based   The  rehearsal  room   collabora=ve  forums,  Daily   Standup,  Itera=on  Review,   Pair  Programming,     Retrospec=ves,  …   Way  of  sezng  structure   Code  holds  structure   Actors  enact  structure   External  characteris7cs  of  ArFul  Making  in  Agile  SoYware   Development  and  Play  Making  (slightly  modified)   ©  Ken  Power  2010  
  40. 40. Organiza=on  PaLerns   •  The  organiza=on  paLerns  iden=fied   by  Coplien  and  Harrison  address   specific  stakeholders,  and  the   rela=onships  between  stakeholders     •  Provide  guidance  on  building   effec=ve  stakeholder  rela=onships   within  sorware  development   organiza=ons   •  Consider  an  organiza=on  as  a  social   system  with  structures   •  Iden=fy  paLerns  that  have  helped   sorware  companies  to  achieve   improved  efficiencies  in  organiza=on   and  performance.     •  Four  paLern  languages   –  project  management   –  growth  of  the  product  and  process   –  organiza=on  style  and  role  rela=onships   –  people  and  code     ©  Ken  Power  2010  
  41. 41. Summary   •  Agile  and  Lean  lead  to  organiza=onal  change   •  Organiza=on  design  can  benefit  from  principles  of  refactoring   •  Our  organiza=ons  have  stakeholders   –  Take  a  broad  view  of  stakeholders   –  The  principles  of  stakeholder  management  help  us  to  iden=fy,  understand  and  engage  with   the  many  diverse  range  of  stakeholders.     •  When  refactoring  an  organiza=on’s  design  to  support  agile  and  lean  development,   we  aim  to  op=mize  the  structures  of  the  organiza=on  around  the  people  who  are   doing  the  work   •  To  be  meaningful,  refactoring  must  have  a  purpose.     –  Metaphors  provide  a  useful  tool  to  communicate  that  purpose.     –  Jazz  improvisa=on  and  Arqul  Making  are  two  useful  enabling  metaphors  for  understanding  the   rich  and  complex  interac=ons  between  the  many  and  varied  stakeholders  in  a  product   development  organiza=on.     •  Organiza=on  PaLerns  provide  a  rich  body  of  knowledge  that  compliments  agile   and  lean,  and  that  provides  proven  paLerns  for  engaging  stakeholders  and  guiding   changes  in  the  design  of  our  organiza=on.   ©  Ken  Power  2010  
  42. 42. ©  Ken  Power  2010