Changing Culture: Tips, tricks & transforming

Editor's Notes

• #2: The greatest challenge to successfully transforming to DevOps is not the implementation of tools, but the changes to culture, which can at minimum be disruptive to your business, at worst, alienate and drive away your best people.
• #3: Culture involves to primary attributes: 1. Attitudes and behaviour which describe the ways in which we act and perform actions 2. A particular social group, in our case, the employees of the enterprise Or as we term them, the process and the people
• #4: We are at a unique time during this digital revolution. Our customers and our workforce could not be more diverse, from the “Baby Boomers” who come from a time where they were told there would never be more than 5 computers in the world, through Generation X who experienced the first commercial use of IT, Gen Y and Millenials who have experienced a PC in every home, to the future developing now and for tomorrow that have not known life with out the internet or a computer that they can carry with them everywhere.
• #5: At the same time we are asking this varied scope of generations to accelerate the outcomes of our businesses. We want to run better, faster, cheaper and safer
• #6: And this demand is happening right now. The demands from customers are only getting stronger for better “service” from business. In turn, business is looking for better “service” from IT to support that increasing demand. The next few years may be crucial in determining the future strength of many organisations
• #7: This Gartner report from 2015 highlights the key challenges that Enterprises face today with DevOps adoption. It is not about the tools and the data, it is about the people and the process – otherwise known as “Culture”
• #8: One of the greatest challenges to cultural change is the conflict that can exist when supporting 2 ways of working. Add this to the mix of multiple generations, increasing demands and short timescales, and it is inevitable that there is concern for all parties.
• #9: For any of you that have been through a process transformation in the past, whether it was CMMI, ITIL, Prince2, Scrum or DevOps, I am sure at least of these phrases spoken by those impacted by the change will seem familiar
• #10: So what is the key to the successful transformation of an enterprise to a DevOps culture. Well let me firstly say that the first thing that needs to transform is yourself and your own way of thinking. Always keep an open mind, and with that, let us look at some practical hints and tips
• #11: Tip 1: Start with Why. Simon Sinek wrote a book called the Golden Circle which he summarised nicely in a Ted Talk available on YouTube.com. It is about 18 minutes long and I strongly recommend it. I will try me best to reprise that summary here. Everyone knows What there company does. What’s are easy to identify Some companies and people know how they do what. This is sometimes called their USP. Many think of this as the differentiating factor. However, those that do best understand that there is one thing missing Very few people can explain Why they do What they do. Not about money, that’s a result. This is about the purpose, cause or belief. In DevOps terms, why does your company need DevOps and why should anyone else in your company care that you do it?
• #12: Here is an example Start with Why. Compare a traditional historic view to the reason why I get out of bed in the morning and get excited about what I do.
• #13: From that same earlier mentioned Gartner report, here are some example “Why”s. These are just the Top 5 for others, but you must explore your own reason Why and use that as your vision.
• #14: Tip 2: To be Agile, you must think Agile I have been involved in a substantial number of transformations, including Agile and SAFe, but there was 1 thing I always found to be true. There are 2 truths in any transformation – The constraints, those things that are fixed, and the estimates, those things that can change and flex over time. As a new culture is proposed, there is often little understanding of what that end state culture will be, and in order to sell the view of it, a picture must be provided. So very early on, the requirements for our new culture are defined. We are then asked how long that will take and how much it will cost, and so we estimate those. The result is naturally and plan driven transformation…which is waterfall and predictive….and we know the issues with that. Instead, we need to think Agile. Fix the timeframe for your transformation and the amount you want to spend from the start. Then deliver the features that are important to you company, i.e. your Why’s from Tip 1. Your result is a value driven transformation where you ensure you deliver as soon as possible the things that provide the greatest value to you.
• #15: Think of it in these terms and consider the additional benefits. In delivering in a waterfall style you will have a single big bang delivery. I am going to be generous here. The value you see there is the amount realised by the programme on delivery as a comparison to the programme cost, that is, your ROI. Now if we consider an agile delivery, we are delivering value sooner. Perhaps not initially an amount to cover the costs of our programme, but an early delivery allows us to experiment with our changes to culture, and where things are not working or can be improved, so we are able to quickly adapt and deliver further increases in value. The result is a cumulative growth in the delivery of our business value – continuous improvement.
• #16: Tip 3: What are you delivering? Consider your entire enterprises culture is made up of many smaller units, all compromised of the people, processes, tools and data. This is the sum of your IT business that supports your business broken down into smaller manageable chunks, and we’ll call it a cultural backlog. This should breakdown into several epics drawn from your values elicited from Tips 1 and 2. In our example here we have a first epic for cloud based deployment and the number that you see there is an assigned value. The unit of the value is irrelevant, as long as it is consistent across the backlog and is of meaning to your business in value terms. So it could be $’s, mandays, story points or even bananas! We also have a second high value epic for change management automations. Each of these epics breakdown into User Stories. The first three from Epic 1, where 2, Containerisation and Continuous Deployment, account for nearly a third of the value of that epic. The third story, Cloud Capacity Procurement, is a process we require in order to ensure the rest of our stories are effective. The other two are important to us to ensure we retain control of our estate management and security. Those 5 stories together create a feature for Automated Cloud Delivery Management with an associated cumulative value that we can demonstrate back to the business. Naturally, the best way to control these changes to the culture is through the use of a Kanban.
• #17: Here are just a few examples of the kind of epics you may find useful for a DevOps Transformation. Note that these are broken down into Services, which means that these are not just technical deployments, they consider also the people and the processes, i.e. the culture. In using tips 1 & 2 you can determine which of these epics is most important to you, prioritise and therefore only implement what you need to implement. In this very statement it shows why there can never be and answer to the question, “What is DevOps?”, because the What is unique to every organisation based upon their business and their values.
• #18: And speaking of values, here is an example of some that you may want to consider. To determine if value is being delivered, you must measure and in this Gartner Metrics Pyramid are exampls of the kind of measures you will want to employ to prove that you are delivering business value.
• #19: Tip 4: Think big, start small. By implementing the first 3 tips, this will enable you to focus your efforts in a meaningful and constructive manner that consistently delivers value over time
• #20: IT4IT is an Open Group Standard that upholds that way of working. Since 2011, an original consortium which included HPE has been developing this standard which is owned by the Open Group who I am sure you are aware of. Links to the standards are there on the slide. Developed over the last few years, there are 2 principle considerations The Operating Model describes the structure of IT management and demonstrates the Value Chains. Value Chains which are important as described previously to any DevOps transformation. The Reference Architecture provides the underpinning foundations on which any IT business must run, irrespective of any other framework such as ITIL, CMMI, TOGAF, SAFe etc. In fact the RA underpins and strengthens these things
• #21: Using IT4IT as the basis for you Journey to Value in a DevOps transformation ensures that you consider all aspects of your IT business, including those you may have thought to not be significant otherwise. The journey starts with an advisory service where you will validate your priorities. Starting with Why – Tip 1 It then continues with a transformation service, which determines your values and how you will deliver them – Tip 2 Finally you will move into a programme of iterative deliveries that realise value by delivering what your DevOps is – Tip 3
• #22: A key aspect ensures IT4IT drives the best of possible DevOps solutions is that it provides a lens onto your organization to ensure that no aspect is omitted. It drives from the Why, showing How, to deliver What is required for your organization and allowing you to prioritise that demand to fulfil business value at the soonest possible opportunity.
• #23: Tip 5: Using a third party. There are key advantages which must be considered for using a third party, but there are also areas to be aware of. First the advantages. If you use your own internal resource, they will come from your existing culture and be influenced by that. Using a 3rd party ensures that they are culturally agnostic. They can bring experience and solutions from previous engagements which would not be available to you internally. How many DevOps transformations do you do within your organisation? A third party can act as an arbitrator between parts of the organisation that may have differing agendas, helping to provide focus on a common goal. They can ensure that your own people are able to continue with the job they are supposed to be doing, which is delivering to your business and not just to your IT, ensuring value continues to be delivered and grow. They should have already prepared education which can be customised to your needs to meet your journey to value goals. And finally, they should be able to follow and open standard for delivery value such as IT4IT But there are also things to be considered. Ensure that you work as partners and not with one side dominating the other. The third party are the DevOps experts, but you are the experts on your business and its values, so ensure you own the requirements and ensure that the third party is not operating inside a black box. Ensure they are providing visibility, that you are not being locked in and that there is a complete handover to you for control of your IT business to support your business. Ensure they deliver value that meets your needs and expectations in an iterative way and ensure that they are technology agnostic and not driven by an agenda. You DevOps culture needs to be underpinned with a best of breed automated toolchain
• #24: As a further example, this is how HPE ensures that those advantages are there for you to use, whilst alleviating any concerns that may exist.
• #25: What you need to do is to Lead the Change, Know the Way, Educate and train, inspire with values, be all-inclusive and understand what gets your people out of bed in the morning
• #26: So in summary, Start with Why you want DevOps Then think How you will deliver DevOps The deliver what your DevOps is to you Think big, start small And consider the advantages of a third party.
• #27: For more information, please do not hesitate to contact HPE and ask about our DevOps services capabilities using IT4IT. Thank you.