LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
The Portal Builder Story: From Hell to Lean, from Zero to Cloud - part 2
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
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
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
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
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
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…
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
ImpedimentsInternal Quality But why??? We where using scrum!!!
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
ImpedimentsInternal QualityLack of internal quality is the worst impediment of them allLack of internal quality can cause Death, the destroyer ofworlds
ImpedimentsInternal Quality In January 2010 I was named Scrum Master In August 2010 Portal Builder V2 started…
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
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
ImpedimentsInternal Quality You are not doing Scrum if you only do Scrum
ImpedimentsInternal Quality Scrum is incomplete ON PURPOSE The team is left to determine Engineering practices Or technical practices Or development practices Or VOODOO
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
ImpedimentsInternal QualityNot all of a large system will bewell designed
ImpedimentsInternal Quality“Not all of a large system will bewell designed” – Eric Evans
ImpedimentsInternal QualityModifications Improvement High value Feature Changes FeatureAdjustments Feature Feature Feature
proyecto: Impediment: Individual or personal issues
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”
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
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
proyecto: Points, estimation, value The problem
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
proyecto: Points, estimation, value Improve your estimation
Points, estimation, valueImprove your estimation There are “normal” reasons why an estimation failed
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
Points, estimation, valueImprove your estimation“There’s no sense in being precisewhen you don’t know what you’retalking about”-John von Neumann
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.
proyecto: Points, estimation, value More work found
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
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!
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