Technical	
  Excellence	
  Doesn't	
  Just	
  
Happen	
  –	
  Igniting	
  a	
  
Craftsmanship	
  Culture	
  	
  
By	
  All...
INTRODUCTIONS	
  
This	
  is	
  us!	
  
Allison	
  Pollard	
  
•  Agile	
  Process	
  Coach	
  and	
  
Consultant	
  
•  Firm	
  Believer	
  in	
  
Con=nuous	
  
...
Mike	
  Rieser	
  (ree-­‐sir)	
  
•  Agile	
  Coach	
  and	
  
Consultant	
  
•  Technical	
  Prac=ces	
  
Coach	
  
•  “P...
TECHNICAL	
  EXCELLENCE	
  
“In	
  an	
  agile	
  project,	
  technical	
  excellence	
  is	
  measured	
  by	
  
both	
  ...
Who’s	
  problem	
  is	
  it?	
  
How	
  many	
  programmers	
  
does	
  it	
  take	
  to	
  change	
  a	
  
light	
  bulb...
Who’s	
  problem	
  is	
  it?	
  
Who	
  should	
  be	
  
concerned	
  with	
  the	
  
long-­‐term	
  viability	
  of	
  
...
The	
  9th	
  Agile	
  Principle	
  	
  
Con$nuous	
  a)en$on	
  
to	
  technical	
  excellence	
  
and	
  good	
  design	...
Agile:	
  build	
  the	
  right	
  thing	
  and	
  build	
  it	
  right.	
  
•  Building	
  it	
  right	
  means	
  it	
  ...
GROUP	
  ACTIVITY	
  
Discuss	
  
•  In	
  small	
  groups:	
  
•  Come	
  up	
  with	
  at	
  least	
  1	
  anecdote	
  of	
  an	
  extreme	
  ...
KINDLING	
  CRAFTSMANSHIP	
  
What	
  will	
  spark	
  your	
  culture	
  change?	
  
Flaccid	
  Scrum	
  –	
  Martin	
  Fowler	
  
•  They	
  want	
  to	
  use	
  an	
  agile	
  process,	
  and	
  pick	
  Sc...
From	
  Flaccid	
  to	
  Awesome!	
  
Internal	
  Quality	
  
(Developer	
  Facing)	
  
External	
  Quality	
  
(Customer	...
Agile	
  Requires	
  Quality	
  
Waterfall	
   Agile	
  
0	
  
20	
  
40	
  
60	
  
80	
  
100	
  
120	
  
0	
   18	
   36...
Process	
  Dependencies	
  
16	
  
Waterfall	
  
Upfront Requirements	
  
Upfront Design	
  
Agile	
  
EvoluConary Design	...
Software	
  Costs	
  
!
Cost!"#$%&'( = Cost!"#"$%&'"() + Cost!"#$%&$"$'& + Cost!"#$%&'()*! (1)!
Cost!"#"$%&'"() ≪ Cost!"#$...
What	
  is	
  Technical	
  Debt?	
  
How	
  Does	
  Technical	
  Debt	
  Occur?	
  
How	
  Does	
  Technical	
  Debt	
  Occur?	
  
•  Ignorance	
  –	
  an	
  incomplete	
  understanding	
  of	
  how	
  the	...
Faster	
  is	
  Slower	
  
We’ll	
  “fix	
  it	
  later.”	
  
hUps://www.flickr.com/photos/9266144@N02/1074851879	
  
The	
  Business	
  Made	
  Me	
  Do	
  It!	
  
What	
  a	
  Tech	
  Lead	
  says	
  to	
  his	
  Product	
  Owner:	
  	
  ...
Enhances.	
  Really?	
  
Compare	
  	
  
“Con$nuous	
  a)en$on	
  to	
  technical	
  
excellence	
  and	
  good	
  design	...
WHAT	
  WE	
  TRIED	
  
And	
  now	
  for	
  something	
  completely	
  different.	
  
•  Working	
  Effec@vely	
  With	
  Legacy	
  Code	
  
•  Provides	
  real	
  examples	
  of	
  “geqng	
  out	
  of”	
  a	
...
Book	
  Club	
  
•  Engage	
  people	
  in	
  discussion	
  about	
  the	
  contents	
  of	
  the	
  book,	
  
create	
  c...
Code	
  Ninjas	
  
•  Crea=ng	
  a	
  community	
  where	
  con=nuing	
  educa=on	
  is	
  
the	
  goal…	
  This	
  is	
  ...
TDD	
  Training	
  
•  Introduces	
  the	
  prac=ce	
  of	
  Test	
  Driven	
  Development	
  
•  Refreshers	
  welcome	
 ...
Maturity	
  Model	
  for	
  TDD	
  
34
SHU	
  
(Follow)	
  
HA
(Break Free)
RI	
  
(Transcend)	
  
§  S=ll	
  learning,	
...
Code	
  Clinics	
  
•  A	
  non-­‐judgmental	
  place	
  where	
  developers	
  can	
  bring	
  their	
  
coding	
  issues...
Transferring	
  Code	
  Ownership	
  
Devs:	
  	
  
This	
  is	
  horrible!	
  They	
  ought	
  to	
  do	
  something	
  a...
“What”	
  is	
  Negotiable,	
  Not	
  “How”	
  
•  There	
  is	
  an	
  ‘N’	
  in	
  INVEST,	
  but	
  that	
  is	
  conce...
Tech	
  Lead	
  Interview	
  Process	
  
•  Recrui=ng	
  Tech	
  Leads	
  that	
  are	
  evangelists	
  and	
  mentors	
  ...
Code	
  Reviews	
  
•  Originally	
  no	
  defini=on	
  of	
  “Produc=on	
  Worthy”	
  
•  Code	
  is	
  con=nually	
  ‘ass...
Continuous	
  Isolation	
  vs	
  Integration	
  
•  Providing	
  a	
  place	
  for	
  development	
  teams	
  to	
  fast-­...
Birds	
  of	
  a	
  Feather	
  
•  Spontaneously	
  grew	
  organically	
  out	
  of	
  need	
  for	
  decisions	
  and	
 ...
Practices	
  &	
  Process	
  	
  
•  No=ce	
  the	
  upper	
  
right	
  (highly	
  rated	
  
on	
  prac=ces	
  and	
  
on	...
WRAP	
  UP!	
  
Invest	
  in	
  your	
  people	
  
	
  
CFO:	
  What	
  if	
  we	
  train	
  them,	
  and	
  they	
  leave?	
  
COO:	
  Wh...
Create	
  a	
  Safe	
  Environment	
  
“Ini=a=ve	
  is	
  punishable.”	
  
	
  –	
  Russian	
  Proverb	
  
•  If	
  you	
 ...
Fan	
  the	
  Flame!	
  
•  There	
  really	
  is	
  no	
  
subs=tute	
  for	
  a	
  
developer	
  that	
  has	
  a	
  
sp...
Perfect	
  (v.)	
  	
  
•  Con=nuous	
  Improvement	
  requires	
  con=nuous	
  learning	
  –	
  
encourage	
  a	
  learni...
Long	
  Term	
  Viability	
  Requires	
  Discipline	
  
“Just	
  put	
  it	
  anywhere”	
  only	
  works	
  for	
  a	
  sh...
THE	
  END	
  
Best	
  Measure	
  of	
  Code	
  Quality	
  
•  Hard	
  to	
  game.	
  
Scrum	
  &	
  Extreme	
  Programming	
  (XP)	
  
#59	
  
“People	
  have	
  told	
  me	
  that	
  they	
  see	
  Scrum	
  ...
Prochain SlideShare
Chargement dans…5
×

Technical Excellence Doesn't Just Happen--Igniting a Craftsmanship Culture

573 vues

Publié le

The ninth principle from the Agile Manifesto states that technical excellence enhances agility, but when the codebase is ugly and the deadlines are tight, most teams don’t choose to refactor mercilessly, adopt TDD, or evaluate automated testing tools—unless they have the proper support. In our experience working with multiple teams in a single codebase, developers can feel victim to a legacy codebase if only a few people are writing clean code or refactoring; guiding them on how to decrease technical debt while delivering their projects helps "unstuck" their other agile practices. We will talk about the challenges we’ve seen with Product Owners, Managers, and Scrum Masters interacting with teams at various stages of agile+technical excellence and how a focus on technical practices sparked a wider interest in craftsmanship. Learn how can you influence the team towards the right practices while fostering their sense of ownership. Getting serious about technical excellence requires support from technical and non-technical roles, and we’ll share how we partnered as coaches to help an organization through a technical turnaround with some tips for others who need to do the same.

Publié dans : Technologie
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
573
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
9
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Technical Excellence Doesn't Just Happen--Igniting a Craftsmanship Culture

  1. 1. Technical  Excellence  Doesn't  Just   Happen  –  Igniting  a   Craftsmanship  Culture     By  Allison  Pollard  and  Mike  Rieser  
  2. 2. INTRODUCTIONS   This  is  us!  
  3. 3. Allison  Pollard   •  Agile  Process  Coach  and   Consultant   •  Firm  Believer  in   Con=nuous   Improvement   •  DFW  Scrum  User  Group   leader  and  Dallas  Agile   Leadership  Network   board  member   •  Glasses  wearer  
  4. 4. Mike  Rieser  (ree-­‐sir)   •  Agile  Coach  and   Consultant   •  Technical  Prac=ces   Coach   •  “Programmer  shirt”   wearer  
  5. 5. TECHNICAL  EXCELLENCE   “In  an  agile  project,  technical  excellence  is  measured  by   both  capacity  to  deliver  customer  value  today  and  create  an   adaptable  product  for  tomorrow.”     –  Jim  Highsmith  
  6. 6. Who’s  problem  is  it?   How  many  programmers   does  it  take  to  change  a   light  bulb?   6   hUps://www.flickr.com/photos/belobaba/6058142799/  
  7. 7. Who’s  problem  is  it?   Who  should  be   concerned  with  the   long-­‐term  viability  of   the  codebase?   7   hUps://www.flickr.com/photos/f-­‐oxymoron/5005673112/  
  8. 8. The  9th  Agile  Principle     Con$nuous  a)en$on   to  technical  excellence   and  good  design   enhances  agility.     hUps://www.flickr.com/photos/ikoka/16843413711/  
  9. 9. Agile:  build  the  right  thing  and  build  it  right.   •  Building  it  right  means  it   has  a  simple  design,  and   is  maintainable  and   flexible.   •  Successful  socware   needs  to  be  able  to   evolve  to  meet   expanding  needs.  Photo  by  Yann,  hUps://en.wikipedia.org/wiki/File:Taj_Mahal_(Edited).jpeg  
  10. 10. GROUP  ACTIVITY  
  11. 11. Discuss   •  In  small  groups:   •  Come  up  with  at  least  1  anecdote  of  an  extreme  in  technical   excellence.  Either  “too  much”  or  “not  enough”  that  you  can  share   in  30-­‐60  seconds.   •  We’ll  try  to  hear  from  1  or  2  of  the  groups  acerward.        
  12. 12. KINDLING  CRAFTSMANSHIP   What  will  spark  your  culture  change?  
  13. 13. Flaccid  Scrum  –  Martin  Fowler   •  They  want  to  use  an  agile  process,  and  pick  Scrum   •  They  adopt  Scrum  prac=ces,  and  maybe  even  the  principles   •  Acer  a  while  progress  is  slow  because  the  code  base  is  a  mess   Five  Years  of  Flaccid  Scrum   My  advice  s$ll  stands  -­‐  ensure  you  take  technical  prac$ces   seriously  when  introducing  Scrum  (or  indeed  any  agile   approach).  –  Mar=n  Fowler:  29  Jan  2014  
  14. 14. From  Flaccid  to  Awesome!   Internal  Quality   (Developer  Facing)   External  Quality   (Customer  Facing)   Advice   High   High   You’re  awesome!   High   Low   Get  Customer-­‐focused!   Low   High   It  won’t  Last.  Refactor  now!   Low   Low   Refactor  versus  Rewrite?!  
  15. 15. Agile  Requires  Quality   Waterfall   Agile   0   20   40   60   80   100   120   0   18   36   54   Quality  over  Time   0   20   40   60   80   100   120   0   4   8   12   16   20   24   28   32   36   40   44   48   52   56   60   Quality  over  Time  
  16. 16. Process  Dependencies   16   Waterfall   Upfront Requirements   Upfront Design   Agile   EvoluConary Design   Refactoring   Automated Developer Tests   Test  First   Test  ADer  
  17. 17. Software  Costs   ! Cost!"#$%&'( = Cost!"#"$%&'"() + Cost!"#$%&$"$'& + Cost!"#$%&'()*! (1)! Cost!"#"$%&'"() ≪ Cost!"#$%&$"$'&! (2)! Cost!"#$%&$"$'& = Cost!"#$%&'("# + Cost!"#$%& + Cost!"#$! (3)! ! !
  18. 18. What  is  Technical  Debt?  
  19. 19. How  Does  Technical  Debt  Occur?  
  20. 20. How  Does  Technical  Debt  Occur?   •  Ignorance  –  an  incomplete  understanding  of  how  the  system  works   •  Complex  Requirements  –  producing  overly  complicated   implementa=ons,  unreduced  complexity   •  Over  Engineering  –  developers  building  more  sophis=cated  code   than  is  necessary  (Specula=ve  Development).  [Gold  Pla=ng]   •  Undone  Work  –  deciding  “wri=ng  automated  tests  slows  us  down”   •  Good  code  /  wrong  place   •  CuJng  Corners  –  “quick  and  dirty”    
  21. 21. Faster  is  Slower   We’ll  “fix  it  later.”   hUps://www.flickr.com/photos/9266144@N02/1074851879  
  22. 22. The  Business  Made  Me  Do  It!   What  a  Tech  Lead  says  to  his  Product  Owner:     “To  do  it  right  will  take  2  Itera$ons.  If  we  do  it  this  other  way,  we  can   do  it  in  2  days,  but  the  developers  will  be  forever  burdened  with  fragile   code  and  it  will  impact  our  delivery  on  every  project  in  the  future.”     What  the  Product  Owner  hears:   “You  can  have  it  in  2  days!”     Moral:   Be  sure  you  can  live  with  the  op$ons  you  present.  
  23. 23. Enhances.  Really?   Compare     “Con$nuous  a)en$on  to  technical   excellence  and  good  design  enhances   agility.”    –  9th  Principle,  Agile  Manifesto   with   “Speed  is  a  long-­‐term  side-­‐effect  of   producing  code  with  the  highest   possible  internal  quality.”   –  Agile  Tes$ng  by  Lisa  Crispin,  Janet   Gregory   perhaps   Con$nuous  a)en$on  to  technical   excellence  and  good  design  sustains   agility.     hUps://www.flickr.com/photos/mr_t_in_dc/2322412546/  
  24. 24. WHAT  WE  TRIED   And  now  for  something  completely  different.  
  25. 25. •  Working  Effec@vely  With  Legacy  Code   •  Provides  real  examples  of  “geqng  out  of”  a  legacy  codebase,   organized  by  “reason  it  can’t  be  done”…   •  Legacy  Code  is  code  wriUen  without  tests.  Establishes  a  common   language  across  the  technical  team  for  the  daily  problems  they’ll   face     Outcome   •  Some  read  it  (especially  those  in  the  book  club)   •  Some  did  not   •  Was  nice  to  be  able  to  say,  “go  read  Chapter   15”  in  the  book   Free  Book  
  26. 26. Book  Club   •  Engage  people  in  discussion  about  the  contents  of  the  book,   create  community  ‘buzz’  about  the  concepts  in  the  book.   •  No  real  disagreements  have  been  encountered!     Outcome   •  Book  club  started  very  successfully,  we  finished  Legacy  Code   and  Clean  Code   •  Observa=on:  Millennials  do  not  read  books   •  Third  Book  –  folks  lost  interest.  Will  do  a  reboot  
  27. 27. Code  Ninjas   •  Crea=ng  a  community  where  con=nuing  educa=on  is   the  goal…  This  is  not  intended  to  be  a  one-­‐man   show…  any  and  all  are  welcome  to  bring  interes=ng   topics.   •  Low  ceremony!     •  PowerPoint  okay,  Code  preferred.   Outcome   •  Seen  as  an  “output”  device,  a  way  to  get  a  message   out.   •  Not  good  as  an  “input”  device  for  determining   direc=on.   Photo  by  ReRaise,  hUps:// commons.wikimedia.org/wiki/ File:Ninjaaa.jpg  
  28. 28. TDD  Training   •  Introduces  the  prac=ce  of  Test  Driven  Development   •  Refreshers  welcome     •  ‘Ignites  the  spark’  around  Test  Driven  Development  and  why   we  need  it   Outcomes   •  Shoot  for  “Test-­‐Infected,”  coach  the  rest   •  18,000  Unit  Tests  with  100%  pass  rate  every  build   •  Tasks  for  “Unit  Tests”  have  disappeared   Red   Green  Refactor  
  29. 29. Maturity  Model  for  TDD   34 SHU   (Follow)   HA (Break Free) RI   (Transcend)   §  S=ll  learning,  follows  but  may   not  know  why.   §  New  code  comes  with  new   tests.   §  Changed  code  comes  with   tests  around  the  changes.   §  Internalized  prac=ce,  but  s=ll   needs  a  coach.   §  Understands  pros  and  cons.   §  All  code  is  wriOen  test-­‐first.   §  Able  to  go  beyond  what  has   been  taught     §  Creates  a  unit  tesCng   framework  because  they   needed  one  and  it  didn’t  exist.  
  30. 30. Code  Clinics   •  A  non-­‐judgmental  place  where  developers  can  bring  their   coding  issues  to  look  for  feedback  or  work  collabora=vely  on   solu=ons,  watch  and  help  others,  get  mentoring  if  needed,   iden=fy  how  to  apply  concepts  from  the  book  or  get  some   code  under  test.   Outcome   •  Some=mes  repurposed  into  “Code  Review”   •  A  few  dedicated  “Lurkers”   •  As  delivery  pressure  increases,  aUendance  decreases   •  Found  “classroom  exercises”  this  way   hUps://www.flickr.com/photos/lloyds-­‐ screenies/2696378369/  
  31. 31. Transferring  Code  Ownership   Devs:     This  is  horrible!  They  ought  to  do  something  about  this!   Coach:   Management  wants  you  to  have  a  nice  code  base  to  work  in,  but  they   aren’t  in  the  code  every  day.   This  is  where  you  work  every  day.     If  you  want  a  nice  place  to  work,  you’re  going  to  have  to  clean  it  up.   “You”  are  “they.”   Outcome   “Don’t  touch  that!”  replaced  with   “Why  didn’t  you  clean  that  up?”  
  32. 32. “What”  is  Negotiable,  Not  “How”   •  There  is  an  ‘N’  in  INVEST,  but  that  is  concerned  with  scope   •  Do  not  let  the  Product  Owner  and  the  Developers  get  into  a   nego=a=on  around  whether  certain  prac=ces  will  or  will  not   be  followed   hUps://www.flickr.com/photos/bellatrix6/168479364/in/photostream/   Outcome   •  Have  a  clear  Organiza=onal  Defini=on  of   Done   which  specifies  standards   •  Business  not  happy,  but  …   •  Avoid  technical-­‐only  projects    
  33. 33. Tech  Lead  Interview  Process   •  Recrui=ng  Tech  Leads  that  are  evangelists  and  mentors  for  the   concepts  we  care  about  (TDD,  Quality,  Refactoring,  OO  Design)   •  Interview  includes:  a  coding  problem,  a  code  review  problem,  a  non-­‐ technical-­‐solu=on  problem   •  Allowed  no  excep=ons  for  folks  hired  into  a  Tech  Lead  role   Outcome   •  “New  DNA”  rejec=ng  “Old  DNA”   •  “Supervisor”  Tech  Leads  did  not  do  well   •  Hit  most  on:  Senior  Devs  looking  for  their  next  level   hUp://disney.wikia.com/wiki/ File:Star_wars_movies_darth_maul_obi-­‐ wan_wars_hd-­‐wallpaper-­‐481469.jpg  
  34. 34. Code  Reviews   •  Originally  no  defini=on  of  “Produc=on  Worthy”   •  Code  is  con=nually  ‘assessed’  (every  itera=on)  and   feedback  given  to  ensure  we  con=nue  to  steer  away   from  the  addi=on  of  debt  to  the  codebase   •  The  more  frequent  the  code  reviews,  the  more  likely   we  are  to  avoid  pixalls  at  the  end  of  a  project   Outcome   •  Reviews  with  different  teams  were  at  different  levels   •  Smell:  sign-­‐off  became  “required”   •  Now  community  owned   hUps://www.flickr.com/photos/ericvaughn/ 9728829199   hUps://www.flickr.com/photos/dmcdevit/ 1143743631   hUps://www.flickr.com/photos/ 26116471@N03/6788264645  
  35. 35. Continuous  Isolation  vs  Integration   •  Providing  a  place  for  development  teams  to  fast-­‐track   characteriza=on  tests,  safe  code  refactors  /  improvements  to  all   teams  early,  outside  of  a  release  cycle   •  Refactoring  code  in  this  stream  gives  fellow  teams  the  benefits  of   refactored  code  and  debt  reduc=on  without  wai=ng  for  a  given   project  to  ‘go  live’   Outcome   •  Before  this  code  cleanup  had  a  reverse     incen=ve  due  to  custodianship   •  Every  team  has  used  it  at  least  once   •  A  few  stars  are  huge  contributors   hUps://www.flickr.com/photos/luizfilipe/2722089483/  
  36. 36. Birds  of  a  Feather   •  Spontaneously  grew  organically  out  of  need  for  decisions  and   conven=ons   •  Technology  related:  “How  do  we  use  SpringMVC?”   •  Not  formally  created   hUps://www.flickr.com/photos/tambako/8011612529   Outcome   •  Email  distribu=on  lists  were  created   for  each  interest   •  Encourage  and  nurture  this  type  of   self-­‐organizing  solu=on  process    
  37. 37. Practices  &  Process     •  No=ce  the  upper   right  (highly  rated   on  prac=ces  and   on  process).   •  Focus  on  process   and  prac=ces  and   you’ll  get  delivery!   •  Where  would   focusing  only  on   delivery  get  you?   Process   Technical  Excellence  
  38. 38. WRAP  UP!  
  39. 39. Invest  in  your  people     CFO:  What  if  we  train  them,  and  they  leave?   COO:  What  if  we  don’t,  and  they  stay?   Copyright:  David  Franklin/ShuUerstock  
  40. 40. Create  a  Safe  Environment   “Ini=a=ve  is  punishable.”    –  Russian  Proverb   •  If  you  want  teams  to  take   ini=a=ve,  you  must  allow   for  failure.   •  Mistakes  are  an  indicator   of  trying  something  new.   •  Teams  require  autonomy   to  achieve  excellence.  
  41. 41. Fan  the  Flame!   •  There  really  is  no   subs=tute  for  a   developer  that  has  a   spark  to  make  it   right.   •  When  you  see  the   spark,  encourage  the   flame!  Photo  by  Billy  Hathorn,  hUps://commons.wikimedia.org/wiki/ File:Kindling_for_star=ng_a_campfire_IMG_2454.JPG  
  42. 42. Perfect  (v.)     •  Con=nuous  Improvement  requires  con=nuous  learning  –   encourage  a  learning  environment.   •  Problems  are  one  of  the  first  signs  that  something  needs   changed.   •  Get  to  the  root  cause,  and  fix  it.  The  symptoms  will  go   away.   hUps://pixabay.com/en/learn-­‐note-­‐sign-­‐ directory-­‐64058/  
  43. 43. Long  Term  Viability  Requires  Discipline   “Just  put  it  anywhere”  only  works  for  a  short  =me!   Image  from  Raiders  of  the  Lost  Ark  
  44. 44. THE  END  
  45. 45. Best  Measure  of  Code  Quality   •  Hard  to  game.  
  46. 46. Scrum  &  Extreme  Programming  (XP)   #59   “People  have  told  me  that  they  see  Scrum  as  the   management  approach  to  agile  development  and  XP  as  the   engineering  prac$ces  that  make  it  effec$ve,  both  bonded   together  by  complimentary  prac$ces  and  goals.”     –  Ken  Schwaber    

×