It's been over a year since we published our first #DevOpsFriday5 and to celebrate we're publishing collections of our favourite answers to each of the questions - and have launched a whole new set for the twelve months ahead. This week we're tackling Question Three:
How Do You Recommend an Organisation New to DevOps Start?
Much like with question two, this question received numerous responses which although varying in some ways all managed to come under the sub-titles below. Unlike with question 2 we were hoping to get a similar response as although DevOps may not have a Manifesto like Agile there are only so many ways in which companies can start a DevOps transformation.
Baseline current state (measure key metrics)
"For me, to achieve those goals in the first place, the whole organisation has to buy into exactly where the pain/waste is and then put in place processes (and yes tooling) to overcome those issues. Before they can do that though, they need to measure key metrics on the journey from business idea to customer feedback – get a baseline, understand as an organisation where the pain points are and what the low hanging fruit is (actually all the fruit, some of the high stuff might be worth tackling early in some cases) - that should I think be the focus." Rob Vanstone
"First they should sit down and evaluate what it is they want to achieve, then how they're going to measure that success, and then start working on what it is that's in the way and how applying DevOps to those obstacles might eliminate them. That might mean automation. In fact, it probably will include automation. But automating tasks that will have an impact requires that you first understand where the bottlenecks and obstacles are, which means defining and measuring first." Lori Mac Vittie
"By undertaking a DevOps Maturity Assessment to understand the current organisation, processes and tools, and then identifying the gaps and requirements in order to move towards a Continuous Delivery process. Implementation is best done in a "biggest bang for the buck approach" removing bottlenecks in an iterative, phased way, achieving success stories at each stage. This creates positive feedback, fostering willingness for people to change and adopt the new processes." Dave Upton
"I’d suggest taking an approach as if you were setting up a new project. As an example here’s some of the phases and questions you’ll need to consider:
- Understand the current challenges your organisation faces
- Gather as many metrics as possible
- How can DevOps help?
- Look into the marketplace for assistance – can we do this ourselves or do we need external support?
- Engage IT and Business stakeholders – ensure this is a collaborative activity and you have the right level of involvement from IT and the Business
- Build a business case for investment – use the metrics captured in your Analysis
- Choose pilot project(s)
- What assistance does the team need? Does the team have the right skills?
- Measure pre and post implementation results
- Feedback to IT and Business Stakeholders
- Communicate results to wider IT and Business community" Paul Hancock
"Start with an honest assessment of where the organisation is now, include all teams involved in the SDLC including customers. Agree on a definition of DevOps and define a target operating model shared across the organisation. This might be agreeing to get to level 4 of a DevOps Maturity model and laying out a path to get there. The assessment will identify quick wins and strategic desires. The quick wins will almost certainly look like a tooling or platform solution however the cultural/people aspects of DevOps (leadership, management style, trust, collaboration, sharing) are the most important things to address. Get the people aspect right and the tooling will follow naturally. Most SMEs and enterprises that are new to DevOps will have to go through a transformation to address these. Transformation is really hard but vital. To paraphrase Adrian Cockcroft: “If adopting DevOps doesn’t involves a transformation, you’re probably not doing it right”
As well as tooling in the continuous delivery pipeline, other quick wins at work can always be found by simple collaboration such as inviting Infrastructure and Ops to standups, ensuring dev and ops are involved in incident triage, ensuring developers are involved during go live, rotate devs into support roles, get some shared training on how to avoid the blame culture. On a more personal level that is within everyone’s control, go to meetups and conferences and read some books (Phoenix Project, The Goal, Understanding Human Error, Lean Enterprise to name a few)." Richard Wadsworth
"Make sure you have executive buy-in, then start by realising this is a journey with cross functional teams and continuous improvement being key to success. If your organisation operates using a waterfall methodology then:
- Start by enabling the developers and testers to collaborate and together become responsible for implementing working software. (Agile/lean development)
- Next I recommend that the business stakeholders (the people who define the requirements) are brought into the team so they can gain the benefits of prioritised requirements. If you can do step 2 with step 1 you will REALLY speed up your DevOps adoption :-)
- Finally, teams I have worked with quickly realise that the bottleneck in the workflow is release into production. Therefore, bringing operations into the whole cross functional team, together with supporting tools, will allow the collaboration and continuous delivery that is truly DevOps.
Once you can say that the flow from requirements to implementation to production is 'on demand based on business prioritisation', then you are truly a DevOps organization.
Of course none of this can really be achieved without tools. An end to end collaborative lifecycle management (CLM) solution to facilitate collaboration from requirements to deployment, test automation tooling to enable speedy implementation, test virtualization to reduce burden on the environment and last, but by no means least, release and deployment tools to ensure full stack environment management for continuous delivery.
Also you can check out the DevOps Adoption Framework for a more detailed roadmap." Kay Johnson
"By baselining their current state - culture and interactions and toolchain. If you don’t baseline your current state, you can’t report on and reward success, recognise and address failure and you can’t write a business case. Metrics are essential and even cultural metrics (an organisation’s attitude to failure, blame, ideas, motivations) are quantifiable (if nigh on impossible to associate with a hard dollar value so difficult to incorporate into a business case). Other metrics we consider essential to anyone starting out on a DevOps project are: volume and frequency of releases, elapsed time to release, volume and frequency of defects, time to fix a defect, volume and frequency of outages, MTTR and resource costs and business impact of all of these components." Helen Beal
"First thing is do a maturity assessment. By doing this you know exactly where you belong. This will make sure you do not start behaving as if you are level 5 when in actual fact your ways of working are level 2. At the end of the maturity assessment, you will have a clear plan of action.
Please, please, please make sure this is led by your internal team with inputs from consultants. You want someone who knows the details rather than some external people who will look at things from high level perspective and create action plan without your involvement." Pinak Vedalankar
"By baselining where they currently are - picking the key measurements that are important to the individual organisation such as # of monthly releases, user experience, # defects, revenue goals etc. It's only once you have a good understanding of where you are today, that you can plan how to get to where you want to be, and measure success along the way." Tom Levey
"Identify the key influencers in your organisation – the people everyone respects and listens to – and buy them a copy of The Phoenix Project. And once they’ve had a chance to read it then take them all out for a nice steak dinner to outline your vision for a DevOps transformation. I call this my “steak-holder management” theory of DevOps transformation. Then identify a product in your organisation that’s big enough to be important to senior management but not your #1 flagship “cash cow” product that people won’t want to risk. Build a product team (note, not a “DevOps Team”) that will apply DevOps principles to that product – cross-functional, rapid iterations, metrics-focussed, automation-driven. Show the benefits of DevOps principles, win the “hearts and minds” of the business/product owners on how awesome this alternative model for the creation of business value and then roll it out to the rest of your product portfolio." Stephen Thair
Introduce DevOps into a new project / Start small
"I would recommend organisations start with a new project, often retrofitting DevOps to older projects can be painful and not always beneficial. Start fresh, get help and continually improve. Don't be afraid to throw things away if they don't work and always iterate." Sam Marland
"More seriously: pick a new project that is run primarily by people who are eager (or at least willing) to try new stuff, get buy-in from the stakeholders to run it DevOps-style, and have a go!" Ingo Weber
"Start with a POC in the form of a smaller scale project. Ensure that the Developer, QA and Operations analysts meet at a kickoff meeting to personalize everyone involved. Ensure that the team consists of at least one member who is familiar with the DevOps culture. Ensure that the project uses an Automated Deployment pipeline, Regression Test Automation scripts etc. to eliminate any possible opportunity for failure." Nitin Gonsalves
"Depends on the organisation. For larger more established teams I think you start with small bite size projects that if done successfully can be momentum builders to justify a larger shift within the organization. In smaller start up environments DevOps is almost a natural fit with today’s business environment. Many start ups do DevOps naturally rather than “adopting” it." Alan Shimel
"Start small and simple, measure and show the benefits in terms that the business and senior leadership teams understand and appreciate." Matt Wills
"For me there are several keys:
- Observe the current delivery process and identify bottlenecks
- Start small (find a pilot project / product)
- Get the buy-in
- Learn every day
The first point is important as it's tempting to rename a team, buy some tools set them loose without thinking about what you should actually be doing or how you can improve business agility. Sitting back can be hard to do but observing / measuring the current process can alert you to issues you may not have realised existed (or the extent of their effect).
Pick a project where it's possible to deliver fairly rapid business benefit while keeping your business exposure low-risk. This will go a long way to helping with the buy-in. Everyone from C-level down needs to be involved in the process of developing and releasing a product so it's essential that everyone is on-board for the journey.
With a wide range of stakeholders it's difficult to balance everyone's opinions, although regular checkpoints to observe and learn as much as you can about the implementation of new processes and culture change are essential. This is heavily tied into the Build-Measure-Learn (Ries) and Plan-Do-Study-Act (Deming) feedback loop theories." John Harris
"I would say maybe start small on a project and build a team of just DevOps individuals who have worked in a successful DevOps environment (if that luxury is an option!). If DevOps is to deliver on its promise of increased productivity and a more efficient organisation then the structure and culture in a large company needs to change. For a start up, I would say 'do' DevOps from the word go but I am a DevOps Enthusiast (it really does work!)." Rhys Davies
"Implementing DevOps ways of working into an organisation should be seen as any other business change insofar as it has the potential to revolutionise the way the organisation functions and the culture within it. That isn't to say it should be seen as a monolithic all or nothing business change project. Far from it. I would recommend agreeing on a realistic view of where the organisation is and a vision of where it wants to be then start small and work towards it, inspecting and adapting along the way. It should be noted that seemingly small and relatively insignificant changes - such as having the development and operations team sitting together or using IRC - can sometimes make the biggest impact. I would also recommend attending events such as DevOpsdays or local DevOps meet ups as a way to learn from others and share ideas." Paul Swartout
Gain (key) stakeholder buy-in
"I don’t think there’s one single starting point, but for us when we started the journey, we were hearing messages such as business stakeholders telling IT we were too slow, or needing us to be more nimble. Other possible indicators might be linked to high defect rates, or laborious change control processes, or repeated failed releases. As for how to start the journey, senior management buy-in is key. By far the most difficult element to make progress in is Culture, and this can often only effectively be changed with a top down approach. Once senior buy-in is obtained, having the boss tell the organisation "this is important to me" is hugely powerful. Then looking at the process in question, looking for waste and inefficiency, and targeting what mix of people/process/culture and technology will address that waste. Then key is to measure before and after stats to demonstrate value, and iterate from there." Gareth Wharton
"That's a question I've had to ask myself recently and my conclusion is: get as many people involved as possible. Try to identify all the issues that need a solution and brainstorm around it, all together. Do not direct the discussion too much, try to act as a neutral person: point/nudge people in the right direction by asking them questions; they must come to their own solution, which might be better than yours. It takes time but it gets people to think your way and usually even broadens your way of thinking. The rest is business as usual: read, read, read, go to conference, try to participate in forums and so on..." Bertrand Besnard
Locate pain points /bottlenecks
"Start with an honest assessment. If you can't be honest due to internal politics agree to go with an outside consultant. Assess the true bottlenecks and constraints that limit the ability of IT to release software into production in a manner that is both reliable and responsive. Working backwards from the goal will reveal issues that travel all the way upstream to the point of development. Then develop a plan that aims to mitigate these bottlenecks and constraints." JP Morgenthal
"I believe the best way to start the DevOps journey is to:
- Understand / measure overall flow and identify bottlenecks
- Pick 1 / 2 practice areas to attack. There are 12 key practice areas, I recommend starting with the low hanging fruit
- Pick an application to pilot
- And once you have a deeper understanding optimize and expand
A few words of advice - don’t just stick to the 20%. I know that feels safe, but if you want to make real change focus on the processes in between and around the activities as well (i.e the 80%). That is where the real inefficiencies are hiding." Mustafa Kapadia
"Start by engaging members of Dev and Ops to do an analysis of the existing flow of work within and between the teams. This will identify obvious bottlenecks and waste. They can then discuss human and technical options for eliminating one bottleneck or one area of waste at a time." Jayne Groll
"Assuming you know what DevOps is, if not that's the first order of business.
Observe your org. Identify your value chains and your stakeholders internal and external.
Identify bottlenecks in your value chains.
Focus on and remove impediments.
Rinse, repeat. (ie "the first way")" Sarah Baker
"First understand what you want to get out of it. Be very clear what your own definition of DevOps is and make sure you start small.
DevOps at a business level is about reducing the time it takes to take a value-realising idea or concept through to production – and keeping it fresh and relevant. To do this requires analysis across the value chain – looking to see where bottlenecks lie and reducing those bottlenecks. An Agile approach is perfect for organisations new to DevOps as it allows for regular, focused bursts of activity, with regular feedback loops to the wider business." Craig Pearson
DevOps Teams/ Champions
"Start by forming a strong multi-discipline leadership team which must include budget level sponsors and technical leadership teams. The sponsors need to have budget level authority because doing DevOps right requires investment to start and ongoing investment to operate and improve it. The technical leadership team needs to have architects that have an expert level understanding of DevOps practices and experience with successful DevOps implementations that include continuous integration, testing, delivery and process monitoring practices and tools. If there are any areas that have gaps bring in outside expertise to fill the gaps." Marc Hornbeek
"Set shared goals and objectives for DEV and OPS. Build small focus teams with experts from different domains (or departments) that share common objectives. Enable (cross departmental) collaboration, knowledge sharing and collective responsibility. Hire people that already have the right mindset." Olaf Kilian
- "Find someone that really understands what DevOps is, what challenges it aspires to overcome and that has led a DevOps change program
- Don’t just look at tools but the whole holistic IT delivery function
- If you do get any tooling in later then look at the before and after metrics (i.e. have we made things better) and then evangelise that as much as possible" Jonathan Fletcher
"There are many approaches: do nothing, slipstream, silo, and rip off the bandaid. The later three are all good options. For the enterprise the most realistic is slipstream, unless you have the opportunity to build a completely separate business unit that can be DevOps bottom up. It is a long tail effort, and the best way to do it is to not talk about DevOps and start with analytics that will help everyone make better decisions. The Analytics will lead to a test and fail, improve, culture and ultimately lead to DevOps frame of mind." Chris Riley
If you want to take a look back at the first 2 question please click the links below:
Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5, click the button below.