Presentation on theme: "A Continuous Delivery Journey Nestor Urquiza Lessons learned from a lean transition Disclaimer: The content of this presentation express solely the author."— Presentation transcript:
A Continuous Delivery Journey Nestor Urquiza Lessons learned from a lean transition Disclaimer: The content of this presentation express solely the author personal views. It does not express the views or opinions of his current or previous employers or clients.
What is continuous delivery? ● Practice of delivering tangible results at a constant pace ● Part of a continuous improvement strategy ● Culture and tools in that order, not the reverse ● Rapid adaptation to change ( Blackberry market share collapse ) ● An Innovation machine (Collaboration, communication, critical thinking) ● A journey; there is no silver bullet
What role continuous integration plays in it? ● Human beings are extremely unproductive at repetitive tasks ● Tests are better run by computer programs (Unit, Integration, UAT) ● Code review is better done by static code analysis tools (Sonar) ● Builds are better done in a server using committed code (Jenkins) ● Message is: Automate where you can (Scripting) ● But there is more than continuous integration...
How to continuously deploy to production? ● Release and deploy get often confused with each other ● Deployment should be scripted (Devs or Devops) ● The environments should be scripted (Devops) ● The Recipe for Success: focus on quality, limit WIP, balance demand against throughput, prioritize, reduce variability ● But there is more than continuously deployment to production...
Is the goal to deliver every minute? No. ● To have predictable delivery with high quality  ● To have the capacity to rapidly respond to emergent needs ● To deliver as quickly as *needed* ● To divide initiatives in Minimal Marketable Features (MMF) and Minimal Viable Products (MVP) ● To minimize cost of delay (establishing Classes of SLA) ● Continuous Delivery is a crucial part of Continuous Improvement...
Prioritization and Estimation ● They can turn into wasteful activities (meetings and discussions) ● Business prioritizes: expected Return and acceptance criteria is mandatory. 5 min per participant meeting needed ● Business Analysts breakout in MMF/MVP and ship user stories. No meeting needed. ● Devs guestimate Investment in hours only for non Standard issues (1 2 3 5 8 13 21 34 55 89) ● BAs negotiate if some MMFs should be discarded based on estimates ● Every new feature is delivered in a more predictable way
What to measure? ● “What you measure affects what you do … If you don’t measure the right thing, you don’t do the right thing.” Joseph E. Stiglitz ● The Team must deliver Business Value. Expected ROI and realized ROI are difficult and expensive to calculate. ● My suggestion: measure the number of MMF ● Metrics for the tech team: track personal and stage WIP, cycle time, MMF throughput, effectiveness, efficiency, defect ratio. ● Now that we are measuring, are we done?
Focus on quality ● Google team suggestions: classify tests in small, medium and large ● FE is the best team to take care of UAT, which are always large tests ● Test as you code to avoid bottlenecks. Practice Test Driven Delivery ● Avoid duplication across the three different types of tests ● There is no code free of bugs, but evolving code with less bugs ● We have quality, but do we have a good foundation?
Automating the infrastructure ● Devops is crucial to achieve continuous delivery. Without scripting the infrastructure the whole stack will tremble ● Creating a new environment should be as important as having a DR or BCP plan. It should be quick. Without virtualization plus automation this would not be possible ● Value stream is as slow as the slowest of the teams. Start with the slowest and make it the fastest, then go horizontally and later vertically.
Some challenges resolved in six months ● Prioritized backlog too big (80% of total incidents). Lead time 13 days versus 1 day ● Inexistent classes of services led to due delivery date and urgent issues being late or intangible tickets being addressed first ● Multitasking caused bottlenecks. Team not completing tasks and yet taking new ones ● Costly planning versus just repleneshing available IT slots ● Unproductive daily meetings with subjective statements versus analysis of the current bottlenecks ● Technology debt increasing in isolated tickets instead of being addressed as part of the existing value stream
More challenges resolved in six months ● How to maintain 'proper' release numbering? No need to maintain that, who cares about the release number? ● We need to test in integration and staging before pushing to production? Staging is not needed in a CD system ● In six months, ratio of defects versus all issues went from 40% to 15% ● Branching cost (10% of total development time in best case scenario) eliminated ● Architecture erosion stopped as developers are forced to use feature toggling, rollback cost totally eliminated, team morale increased as proudly it shows quantitative deliverables in daily meetings and weekly release notes ● Main challenge is to convince the budget committee...
Challenges that take longer ● Variability is difficult to control. It can be 15-30 days before an MMF gets shipped ● End to End Tests (UAT) need sample data setup which is expensive ● Lead time is affected by Business queues ● Automation cost bigger in premises than in cloud providers ● Devops need ways to create and destroy new VMs on the fly from scripts, but change management, regulations and structures of IT operations still need to be on board ● Business value must account for the cost of delay up front, no exclusion ● Build a system of trust. Buy in needed
Bibliography 1. Anderson, David J. Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, Sequim, Washington, 2010 2. Urquiza, Nestor Thinking in Software http://thinkinginsoftware.blogspot.com/