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.

The Portal Builder Story: From Hell to Lean, from Zero to Cloud - part 2


Published on

Common pitfalls to avoid when developing software with Scrum

  • Login to see the comments

  • Be the first to like this

The Portal Builder Story: From Hell to Lean, from Zero to Cloud - part 2

  1. 1. From hell to lean, from zero to Scrum. Part IIPitfalls to avoid proyecto:Christian RodriguezCertified Scrum Mastercrodriguez@softeng.esTwitter: @guezianBarcelona, 3 de Octubre de 2012
  2. 2. Introduction Objective How scrum helped us? How we need to improve?proyecto:Impediments Internal Quality Personal and Individual Issues Detecting ImpedimentsStory Points, estimation, value The problem Wrong Estimation More work found
  3. 3. IntroductionAbout me 8 years in the software industry 3 Years Scrum Master This talk is for people who know scrum, and are applying it or starting to apply it I hope my experience helps you improve your process. Context! Product Team of 6 people Scrum Master / Architect
  4. 4. IntroductionObjective: Avoid pitfalls Internal Quality Problems Rushing Impediment: Velocity Pressure
  5. 5. proyecto:Introduction How scrum Helped us? How we need to improve?
  6. 6. IntroductionHow scrum helped us
  7. 7. IntroductionHow scrum helped us Steady-forward development rhythm Almost no critical bugs found in production Few interruptions Reasonable achievable release plan Potentially shippable product at the end of each sprint Feedback on working software during sprint and sprint demo Stable and robust releases
  8. 8. IntroductionHow we (always) need to improve We still need to improve Release cycle: 3 Sprint + Stabilization (1-2 weeks) Potentially shippable products (but not shippable) Require a Release / Stabilization Phase Need to use % of the sprint solving (non-critical) known Bugs The overall velocity could be better
  9. 9. IntroductionHow we (always) need to improve
  10. 10. proyecto: Impediment: Internal Quality
  11. 11. ImpedimentsInternal Quality During late 2008 we started using Scrum We adopted Scrum and the “Scrum miracle happen” In a number of sprints:  order  progress  (reasonably) working software But, as codebase grew…
  12. 12. ImpedimentsInternal Quality
  13. 13. ImpedimentsInternal Quality Very slow progress Constant Bugs IN production, sometimes very critical, causing Panic Mode and work in sprint abandoned No release plan possible Unable to measure progress, velocity Application ultra slow performance Application crashing Team demotivation User (and management) frustration
  14. 14. ImpedimentsInternal Quality But why??? We where using scrum!!!
  15. 15. ImpedimentsInternal Quality I entered the company as a Junior programmer in late 2007 Our codebase, was a mess, a REAL mess. Immense up-front architecture So strange, unintelligible Only architecture, no features The core was doomed, and so the rest of the system Portal Builder DIED
  16. 16. ImpedimentsInternal QualityLack of internal quality is the worst impediment of them allLack of internal quality can cause Death, the destroyer ofworlds
  17. 17. ImpedimentsInternal Quality In January 2010 I was named Scrum Master In August 2010 Portal Builder V2 started…
  18. 18. ImpedimentsInternal Quality Portal Builder V2, now, has  More features  Integrated with Azure  Incomparable better performance  Incomparable better stability Flexible design No big up-front architecture. Microsoft NLayerApp Everything can be improved at a reasonable cost
  19. 19. ImpedimentsInternal QualityWarning! I’m not saying stop and throw all your codeWe were in an extreme situation, “Scrum wasn’t enough”Luckily you will be before the point of no returnThe price of quality is eternal vigilanceYou must be alert to symptoms of bad internal quality:  Bugs  Recurrent Bugs  Slow progress
  20. 20. ImpedimentsInternal Quality You are not doing Scrum if you only do Scrum
  21. 21. ImpedimentsInternal Quality Scrum is incomplete ON PURPOSE The team is left to determine  Engineering practices  Or technical practices  Or development practices  Or VOODOO
  22. 22. ImpedimentsInternal QualityTDD Buy books  Convince by example Training  Red-Green-Refactor Pair Programming  Design at the Refactor phase! Code ReviewsATDD (BDD) (both of them)Webcasts DDDGroup discussions Hire!Coding Dojos Technical Stories
  23. 23. ImpedimentsInternal QualityNot all of a large system will bewell designed
  24. 24. ImpedimentsInternal Quality“Not all of a large system will bewell designed” – Eric Evans
  25. 25. ImpedimentsInternal QualityModifications Improvement High value Feature Changes FeatureAdjustments Feature Feature Feature
  26. 26. proyecto: Impediment: Individual or personal issues
  27. 27. ImpedimentsIndividual or personal issues “Over-relaxing” “Releasing the gas pedal” Acting as individuals not as team Self-organization does not mean do whatever you want In a “I don’t care” attitude:  “I don’t care if the sprint is good or bad I just come here do my work and don’t care about anything”  “I don’t care if someone else on the team already solved that problem I don’t want to ask I’ just rewrite this code again my way and that’s it”  “I don’t want to do test, it makes me think too much”
  28. 28. ImpedimentsIndividual or personal issues Talk to the team to solve these issues Talk to individual to solve these issues If it cannot be solved  You must raise the issue with management  Maybe with human resources…  Hard decisions or recommendations must be made
  29. 29. proyecto: Impediment: Detecting Impediments
  30. 30. ImpedimentsDetecting Impediments Impediments kill productivity One of the most important things to do is to “detect” impediments. Examples  Slow compile time  Slow CI Build (and automated) test time  No build visibility  The team does not see all this as an impediment
  31. 31. proyecto: Points, estimation, value The problem
  32. 32. Points, estimation, valueThe problem At the end of a sprint “We are going slow”: The Scrum Master must be the “referee” Why are we “slow”?:  Impediments  Wrong estimations. Why?  Was there a mess under the hood?  Internal Quality  Need to improve your estimation  More work found
  33. 33. proyecto: Points, estimation, value Improve your estimation
  34. 34. Points, estimation, valueImprove your estimation There are “normal” reasons why an estimation failed
  35. 35. Points, estimation, valueImprove your estimation You can improve your estimations Perhaps during the planning meeting:  Not enough question asked  Backlog Items not split correctly  Backlog items not enough divided into tasks  Everyone wants to kill themselves!!! The Team must LEARN from these mistakes Product Owner pressure
  36. 36. Points, estimation, valueImprove your estimation“There’s no sense in being precisewhen you don’t know what you’retalking about”-John von Neumann
  37. 37. Points, estimation, valueImprove your estimation Official Scrum guide 2011 changed the term “the team commits what will be developed” to “the team forecasts what will be developed” That’s logic How can you commit over an estimation !?!?!? Force to commit will cause defects Scrum Master must defend the team Or negotiate with the Product Owner.
  38. 38. proyecto: Points, estimation, value More work found
  39. 39. Points, estimation, valueMore work foundConsider this situation: After finishing the most valuable stories, the team discovers that they require more work, or discovers valuable improvements:  Perhaps the story is open  Or the product owner does not exactly know what he wants This extra work is much more valuable than the rest of sprint items, its better aligned with the Sprint objective! This “much more valuable” is agreed between the product owner and the development team
  40. 40. Points, estimation, valueMore work found“Responding to change over following a plan”“Scope may be clarified and re-negotiatedbetween the product owner and the Development Team”Fast feedback, collaboration, great Job!Adapt the sprint!But make it count on the velocity!
  41. 41. Points, estimation, valueMore work found Re-estimation! (danger!) Remember, story points are a tool to:  Estimate size, to compare with other stories  Estimate size and complexity, not amount of time!  Do not re-estimate only because it took longer
  42. 42. Points, estimation, valueMore work found
  43. 43. proyecto: Thank you Christian Rodriguez Certified Scrum Master Twitter: @guezian Barcelona: Pau Claris, 162-164 2ª Planta Madrid: Avda. Doctor Arce, 14