Step 1 to get started with DevOps: Decide what you want to achieve
I meet and regularly work with clients who are looking for the promised value of adopting DevOps to improve their IT shop’s software delivery. Their first questions are always about how to get started practically. Our consulting team has a clear four-step process that we introduce in all workshops, and in this and my next few blog posts I will outline those steps and show how you can use them to get moving with DevOps.
Think through business-level drivers for improvement. IBM’s approach to DevOps defines a broader view of a continuous delivery lifecycle that extends beyond the idea of development and operations working collaboratively. This approach expects the inclusion of other stakeholders such as lines of business, suppliers involved in software delivery and consumers themselves. Consider the ways that different groups such as business planning, development, test, release engineers or monitoring teams can affect your plans.
Most clients I visit have an IT plan or strategy they use to guide their investments and priorities. You should use your strategy to think through business-level drivers and the outcomes you want to achieve. “Enable market experimentation” and “deliver more continuously” are only good examples if you can show clear alignment to your business priorities. Then the key is to keep these drivers in mind as you follow my recommended four-step process, which I will cover in this series. Then use them to guide your goals and help you set priorities.
Image credit: IBM Software Technical White Paper "Dev
However, when investing in change, you must consider how the change will make improvements across the organization and stakeholders. It is always a good idea to think in terms of measurable goals. Once metrics for objective success are defined, break the measures into incremental milestones and use them to measure interim wins.
Recent goals from IT departments I’ve worked with include “improve test environment availability and consistency,” “reduce time from development to production” and “improve quality of distributed applications promoted from the testing environments.”
Decide how you will measure the change. If you take the goal to “improve quality of distributed applications promoted from the testing environments,” consider a measure for the root cause of defects. For most clients these can range across misunderstanding the business need, incomplete requirements, changes to architectural agreements, design errors, coding errors and incomplete test coverage. You probably measure these today, so you can use the benchmarks and measures to monitor the impact of a change. This is the hardest part of step 1, as it may drive you to rethink the goals until you can truly measure the improvement.