Step 4 to get started with DevOps: Plan and Execute!
In step 3, the most recent of my posts on the topic of getting started with DevOps (step 1, step 2 and step 3) I discussed how you would prioritize your practice improvements through a simple process using user priorities, pain points and complexity. Then I discussed creating a backlog of these prioritized improvements and explained how to group them into an improvement release measurable that could help produce specific outcomes and support an incremental roll out of changes. With those steps in mind, we now move to the final step, creating a plan, executing on it and achieving a quick win!
JazzHub, self-organized activities and hosted run times such as Soft
Phase your improvements with prescribed value!
Using the set of prioritized improvements from step 3 that are now in your improvement backlog, you can define the improvements to be introduced in each release (or change) across your organization. Be sure to also define the measured value to users, programs and the organization. The value will help you to grow support socially as your team leads the organization through the adoption.
A template for phased improvements
When starting to define the right phasing model, you should consider the maturity model assessment you performed in step 2. This model reflects your current state and goals. A phased improvement should be planned so that can measure your achievements on the model. The following phases can be a great starting point for your initiative plan. Note that you can start with any applicable phase. Maturity levels refer to the maturity model levels in my paper on adopting IBM’s approach to DevOps:
Phase 1: Mature to level 2 in your objective practices. Identify measures that will reflect your business outcomes at the appropriate maturity level. Work to standardize your practices in a particular adoption path and introduce necessary supporting technology. Leverage a core group of technical users to identify “best practices” in the area of improvement that can be used to achieve the desired outcomes.
Phase 2: Mature to level 3 in your objective practices. Implement measures across the segment of practices. Automate the practices you standardized or improved in phase 1. Drive and measure cross-functional collaboration to support feedback. Use technology for measuring with metrics that reflect your outcome goals.
Phase 3: Mature to level 4 in your objective practices. Evolve automation from manual initiation to monitored, event-driven services. Provide a continuous self-service capability to users and teams to reduce time for work or rework. Improve reporting to leverage trends for the continuous improvement of practices.
Any of the paths introduced in my paper about adop
What is a pilot?
To reduce risk, validate your usage model or confirm your solution with users, it’s always a great practice to “pilot” part or all of the solution prior to introducing it to all teams and users. A pilot involves using all or a portion of your new solution in a real activity, project, team or application to monitor and measure specific aspects of the solution. The purpose of your pilot might include:
The first pilot in your phase is one of the most critical. It is your opportunity to gain an early win and communicate the value of your team’s efforts. We like to refer to it as the “quick win pilot” to ensure our clients emphasize the first step. When you are affecting change involving multiple roles, practices and technologies across an organization of 1,000 to 3,000 users, the first pilot should start within the first 4 to 12 weeks. This is a rule of thumb. However, for more scoped changes you could just as easily get your first “win” in two weeks.
See your IBM account team—or contact me directly—for more information on your options.
Are you introducing change? Moving to a new DevOps practice? I would like to hear your thoughts, so post here or follow me on Twitter @PaulBahrs. Also, look for my next blog post here on The