Route to live

Editor's Notes

1. Contents What am I trying to achieve? What are the benefits? The Challenges… Where do I start?
2. Improving the speed of the pipeline (route) to live enables your business to deliver more incremental deliverables in the shortest possible time, therefore making reducing total product ownership by releasing more features than before
3. Software factories – allow for a high degree of variance, standardization is the enemy but its also your best friend. Stop looking to standardise your code and focus on standardising your testing around that exercise your builds Business alignment cannot be measured by continuous integration and unit testing alone
4. Your business value realisation can only occur once your code is live, if you measure one metric, make sure it’s the one that say ‘I’m alive’
5. A common problem – the dreaded double funnel Though many have drawn up double funnel models, a few days back whilst talking with Dan Brown (aka Kanban Dan) about constraints and Kanban, we modified his double funnel diagram by adding in a vice with the initial applying forces of Command & Control and as these forces are applied the blame force grows exponentially. The incoming funnel is the constraint the business places on the delivery (fixed scope, time and cost – even worse they may dictate the actual solution as apposed to presenting IT with the problem), the middle part is the teams attempting to run in an Agile fashion (iterations, test driven, etc…) and the outgoing funnel is the release train (rigid schedules, manual releases, over importance placed on documentation, etc…). What affect does this have? Ultimately it festers a blame culture (without naming companies, I have seen this in two companies I have worked for). The business places unrealistic expectations on the IT function and the limited release mechanism limits their ability to get features to market (this creating an image of a slow IT function). The business will complain that IT cannot meet its expectations and the release team will be Teflon and point the finger back at the delivery team (and often because they are doing butchered Agile they’ll say its the teams responsibility even though they place release constraints on the team; responsibility but side stepping accountability by the release team). - Pics of vice and funnels amend image
6. What are the benefits
7. Small incremental changes, easy to understand granular change impacts and measure their value Increased turn around time from cost to develop to return on investment Supports Multi-variant testing
8. Makes your job easier, it ensures you won’t break your product/s and that you can get new great functionality to live as soon as its ready
9. Its all about the money baby. If you are constantly releasing great new functionality and features to your product/s in the shortest possible time you will make the company more money and they by return (hopefully) will reward you
10. Incremental product improvements is the fastest way to gain ROI as well as enabling true MVT depending on your customers wants. Its taken a lot of incremental product improvement since Nicolas-Joseph Cugnot invited the first automobile to the Bugatti Veyron
11. Stages – CI ASAP Break for a pipeline session – use white board to draw out a pipeline, frequency of releases (what environment) and possible choke points Draw one pipeline that represents your current route to live and then draw what you believe would be the optimal route to live
12. Take a break…
13. The challenges
14. Culture, beliefs, behaviors and perception, be prepared to challenge them all Zero defects to live is achievable and for little cost Understand now and map the outcome, and what the cost of not implementing is
15. It is possible to maintain quality whilst increasing speed of delivery We maintain high quality through a managed automated pipeline that bakes automation around the builds, validate their decisions, validates the build and deploys the build to live
16. Technical resistance by those who don’t believe you can automate everything, lack of automation knowledge or value of aligning to the business
17. It is worth it – Keep trying
18. It starts in the business Its automated It finishes once its live
19. Lets get this over and done with, done should be measured once its live. A fundamental mistake is that we often deem it OK to mark something as Done whilst in a holding area (code in SC, a story in the Done column, etc…) but ask yourself, where’s the value realization of that?
20. If you are a leader… protect and empower your team to implement any automation changes
21. We don’t just want to build the right software, we want to build the right software
22. Using your value chain identify on what would gain the most from being delivered more quickly to market. You might find that ‘all of it’ will be the outcome
23. A critical game changer is when you write specification in a way that is testable; BDD is an approach to achieving this, it removes ambiguity through explicit specification that is understandable by a testing framework. Technical excellence (unit testing) is not enough to deliver business aligned value
24. Automate, automate, automate. Whatever you can… Write specifications that are testable Automate all tests Build a Continuous Delivery pipeline Remember to Including infrastructure (ServerSpec) to be expressed through testable specification
25. Now lets re-draw your pipeline
26. Hopefully you’ve had a moment like this little chap above
27. Measurement of your success? When this little fella can press a button on a mobile device that sends your product or increment live in a safe, controlled and quick fashion.
28. Now go forth and use automation to improve your route to live