DevOps Transformation in Six Simple Steps
By Michael Schmidt

DevOps is a far cry from the days of traditional software development. It is an amalgamated culture of attitudes, best practices and tools; a journey towards the Holy Grail of Continuous Delivery in which actions speak louder than words.

To understand DevOps you have to live its values. Lip service will not suffice. This requires an often wholesale organizational change for IT departments that are often stuck in their ways. A certain amount of trust must be given to those chosen to lead the revolution, but the business still needs ways to measure success. Like in any business venture, creativity is means to an end and return on investment is everything.

For this reason, I would like to propose six small steps for your team to take that will translate into six giant leaps for a sustainable DevOps transformation:

1. Urgency for DevOps transformation
An effective DevOps transformation will take time, so it is imperative to start as soon as possible. Your successful competitors have earned that reputation because their transformation has already happened. This sense of urgency must be passed on down the company.

The speed of a shift to DevOps is only measured by release velocity. Benchmarking against other companies is important to show progress and to give team members proof that their efforts are worthwhile.

2. A DevOps team vision
Team members that support change will form the backbone of your transformation. Senior IT management should be involved, but only if they have the right attitude. Those resisting chance may have to step aside, no matter how skilled or experienced.

DevOps should be aligned with the business vision of continuous delivery. The scope should be wide enough to cover all aspects of the DevOps movement, but be narrowed to focus on continuous delivery when required. A roadmap is key to document key aims and their chronological priority along the journey. This takes preference over a detailed plan, as agile principles should guide day-to-day decision-making.

3. Communication is key
DevOps revolves around collaboration, so its inception in your IT department should be very much a team effort. A democratic atmosphere is key to the blurring of development and operations, so feedback and input are essential.

The vision and roadmap should be conferred quickly once decisions are made, in order to build trust and achieve visibility. The message should be communicated on repeat to engrain the new vision in the psyche of team members. Remember, after maybe decades working as software engineers, some team members will need outside encouragement to change no matter how willing they might be.

4. Empowerment
After communication comes the transferal of power and trust. Is is important to allow DevOps team members to be autonomous when forging new collaborations and methods to reduce complexity and work efficiently.

The end product of this team-building on a micro scale is to produce an overall guiding coalition. The ability to experiment with new tools and methods is vital, so the aim of the coalition is to remove obstacles such as superfluous process steps, approvals and system access rights. Any structures that undermine the team vision should be quickly replaced. Risk taking and avant garde thinking should be encouraged.

5. Short-term wins
It's important to deliver visible results to the business to prove ROI. Pilot projects using more established team members can be used to show the increase in release velocity.

A pilot team should be chosen carefully, depending on the application. A good fit in terms of technology and architecture is more important than simply choosing your most highly skilled staff members and fitting them around the project. The impact of DevOps practices should be exhibited to the business wherever possible.

6. Establish change and increase the scale
Methodologies of experiments that worked well should be embedded into culture for long-term success. This might mean changing long-standing practices across the board, so brave decision making is needed. The credibility gained from pilot schemes can be used to prove the new system works in practice. However, each team should be allowed to practice their own flavour of the common methodology if it helps them work faster. Agility is key to increase velocity, so governance frameworks should be avoided.

After a while, these brave new methodologies will become part of business as usual. To ensure the right path is being followed, the right metrics need to be in place with close links to business KPIs. Management should

Read the original blog entry...