Make Continuous Delivery work for middle management
- 1. MakeContinuous Delivery work for middle management – it is not black magic! Matteo Emili twitter.com/MattVSTS || mattvsts.blogspot.com
- 2. Who am I? Visual Studio and DevelopmentTechnologies MVP Visual Studio ALM Professional Scrum Master I Community enthusiast! I work at One Identity (part of Quest Software) as an ALM and DevOps advisor
- 3. The problem The journey to Continuous Delivery is fraught with hurdles Technical Methodological Historical There is often friction between the CD champions (teams or C- suite) and the middle layer.
- 4. CDChampions A Continuous Delivery Champion is someone who pushes and evangelises Continuous Delivery across an organisation CDCs are usually from a development team or from the C-suite They are enthusiasts who want to bring much needed value to the company with the adoption of a successful set of best practices They often stumble with a middle management which is not aligned
- 5. Why? A Champion often has either a top-down or a bottom-up approach, depending on the background Middle management is often insulated from this because they are responsible to directors and above for their teams’ results The disconnection makes it drift away from the priorities of the Champion Barriers are erected, causing friction and misunderstandings
- 7. Challenges experienced adopting and scalingAgile From 11th Annual State of Agile Report - https://explore.versionone.com/state-of-agile
- 8. Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations” The Mythical Man-Month – Fred Brooks, 1975
- 9. There is one additional challenge… Continuous Delivery relies heavily on DevOps DevOps doesn’t have a definition! It isn’t a process, it isn’t a methodology, it isn’t a technology There is no DevOps Enterprise Edition installer… DevOps is a collection of best practices where the whole organisation is involved in bringing value to the customer Also, there are many methodologies that can be used in a Continuous Delivery environment, leading to further confusion
- 10. TheThree Ways The Phoenix Project is a fictional story of an organisation like many others… One of the takeaways is about TheThreeWays Principles you can use in any production context, not just IT Most of DevOps and Continuous Delivery’s practices are derived from these three principles
- 11. Flow First Way
- 14. How to make it work #0 Break the barriers down and change things slowly Barriers are the main issue in a CD transformation, preventing the implementation of the FirstWay If barriers are still in place there is no way of creating a feedback loop across the whole company (SecondWay) Without a feedback loop teams are insulated, and there is a high risk of delivering little value to the customer (with lots of technical debt) or no value at all! Not much of a ThirdWay here… Changes should be brought forward in a small and iterative way No big-bang breaking changes, less resistance Automation helps reducing waste and removing bad habits inherited from years of traditional development
- 15. How to make it work #1 The Minimum Viable Product Start small where you can have disruptions or failures Start by delivering something – a small set of working features Build incrementally on top Why?You can quickly test if your ideas are correct, and estimate the added value for both the customer and the company Short timebox, a few features, go!
- 16. Also tools! Tools contribute to the segregation Everything should be open to anyone (with the appropriate security) Closing the ALM stack to business roles (e.g.: POs, support, etc.) is not a smart move – and it is also a barrier Information sharing should be encouraged, in areas like Acceptance Criteria for example
- 17. A common ground for anybody From 11th Annual State of Agile Report - https://explore.versionone.com/state-of-agile
- 18. Data is unbiased With a unified platform you are generating a unique and unbiased data source for the company The more you expand this platform across the organisation, the better you can use it for approaching the Continuous Delivery problem Involving higher ranks means you will get an expanded view on how a certain story fits into an overall strategy There is no such thing as “a developer/business/operations tool” – most modern ALM/DevOps platforms are meant to be used by different roles with different tools
- 19. Set your scope Middle Management is squashed in the middle of the approach the CDC decides to use and their visibility is somewhat reduced Their scope is set above the single teams but below the vision and the strategy used by the C-suite What usually matters to them is how many features are delivered, maybe correlated with the relevant Epics
- 20. Start small Backlogs are not just for PBIs
- 21. How to make it work #2 Flexible scoping The tool you use should be able to drill down from Epics to PBI, but retaining a rollup view With specific exceptions, PBIs are not really interesting for Middle Management Backlog is relative – what matters is what is in progress and what is done Focus on the value you are bringing on, drilldowns on technical matters always come second
- 22. How? Start small, with filters – make the backlog a ubiquitous presence, tailored to what you want to show Take advantage of items relationships (parent-children) Use a tool you can access with Excel Pair your tool with something that gives you a high level overview of the release train across multiple iterations
- 23. Catch the train Delivery Plans inVisual StudioTeam Services
- 24. Make Product Owners meet the customer Product Owners should know the customer demands for real, not from an analysis point of view The strategy should be focused on customer feedback and priorities should be dictated by what customers really want POs and above must be in agreement Added value is going to be perceived both ways
- 25. So, how to make things reasonable? “You can’t change what you can’t measure” In the Build-Measure-Learn loop the Measure stage is the most important one By measuring you gather evidence of something to change or improve without relying on biased opinions Only Metrics will tell if you are going in the right direction, so it is critical to ‘get them right’ Extend your product to include what really matters Reduce maintenance costs Proactively understand potential problems
- 26. How to make it work #3 Insights for the win Instrument your application and gather insights on how users behave Telemetry is a must have these days, providing your teams much needed information about usage patterns and performance Real world example: your exceptional market changing feature you spent millions on might be buried beneath seven different user interactions Nobody uses it and the company just wasted resources The Product Owner drifts away in its own bubble
- 27. Close the feedback loop Application Insights in your applications
- 28. Recap People first, process then, tools follow Remove bottlenecks Facilitate communication Start small, build on top of your wins Show evidence and gather actionable and objective data
- 29. Recap Share it all Every role in the company should have access to what you work with Try to estabilish a ubiquitous language across the toolset Non-technical management should have a clear idea of the direction of the product Stakeholders are part of the process, they are not separate
- 30. Recap Close the loop with feedbacks Feedbacks and insights, coupled with internal data make sure you are getting in the right direction Quickly validate your ideas against real world usage You are building for the customer, the customer is sharing its priority Everybody take advantage of it, from developers to Product Owners
- 31. Thanks! Slides available at http://docs.com/matteo-emili