Anyone who works in IT for financial
services understands the pressure to keep up with a competitive market,
where customers expect all their services to be online and where regulations
shift rapidly. It’s this pressure to continually deliver improved services at a
fast rate that moved Freedom Mortgage, a top U.S. mortgage provider, towards
adopting DevOps.
As the point person for driving the organization’s
DevOps initiative, Ting Cosper, Director, Enterprise IT Change Management
and DevOps, understood that adopting DevOps was not a luxury—their ability to
respond quickly depended on it. But change does not come easy, and it was up to
Ting to lay the groundwork for the transition. Ting talked about his
experiences a few weeks ago at the XebiaLabs DevOps Leadership Summit. Below
are 3 tips he shared for transitioning to DevOps.
1. Start with People and Processes
Ting’s team manages change management. Any changes to tools,
systems and processes go through them. Their job is to make sure things are as
solid as possible before sending software to production.
Inconsistency across groups in managing revisions and
storing them to secure repositories was a key problem for them. On top of that,
the team was using manual processes to deploy changes, which took a toll on
their small staff because someone had to be on call nights and weekends to make
them. It might have been tempting to immediately look for tools to address
these problems. However, tools were not the main issue. Rather, it was the lack
of standardization that was creating conflicts and burning people out.
So, if you’re considering doing DevOps
and plan to dive into tools as your first order of business, Ting’s advice is
to stop. Tools are important, but you can’t buy a tool that will “do DevOps.”
Instead, Ting’s top priority was improving how people interact with each other
and with technology to drive performance. He wanted to standardize their
processes and reduce manual work that was hurting their efficiency and the
quality of life for their employees. In addition, he needed to show management
how the organization was losing money by continuing to follow the status quo.
2. Reflect and Document
Before he could convince anyone else to accept change, some
reflection was necessary. Ting suggests that, before jumping into a DevOps
initiative, think about what your organization is doing right and wrong.
Maybe your developers are good but you fall short when it’s time to deliver, or
maybe QA needs extra resources. Taking a hard look in this way helps you
understand your processes: what you’re doing, where the waste is, and where you
can improve. For Freedom Mortgage, their delivery team was very efficient with
execution but fell short on documentation, which is crucial for communicating
your intentions.
An important part of documentation is calculating the cost
of your processes. After gathering metrics on their change system, Ting and his
team were able show that, while there was a drastic drop in failed changes over
the course of several months, the financial and human costs of doing so were
too large. Their staff was consistently working weekends, and overtime costs
were upwards of $200K in one year alone—excluding follow up on Monday to put
out fires and have development do fixes. Show people, especially management,
the ROI of hard and soft saves that will result from your plan and you’ll get
their attention.
3. Find the Right Tools
Once you’ve figured out where to improve your processes,
it’s time to look at DevOps tools. Ting’s team wanted to start by getting a
better handle on their deployments, so they researched leading DevOps solutions
companies. While product quality was a high priority, they also wanted a vendor
who would share practical knowledge about getting their initiative going and
scaling it in a controlled way.
They chose XebiaLabs because they preferred the interface
and modeling feature of XL Deploy and believed that XebiaLabs would be their
partner throughout the transition. Bringing in XL Deploy and XL Release is
giving them a better handle on how to do their deployments and release
software. XebiaLabs products also enabled them to show the larger community
that there’s a better way to manage the pipeline and get software into production.
The Results So Far
Ting and his team began putting their new processes in place
in January. Although it’s still early, they’ve already implemented controls
that enable consistency across teams. And people are starting to see the
benefits: there’s less conflict between groups, individuals don’t feel blocked
from getting their work done, there are fewer budgeting issues, and it’s much
easier to train new people or to cover if someone is sick or on vacation. It’s
also simpler to expand or contract a team as needed for a project.
Do’s and Don’ts
Based on Ting’s experience, he offers some do’s and don’ts
for successfully
transitioning to DevOps:
Do…
- · prepare to be successful. Focus on the end-result and how the investment will pay off in the long run. Spread that message to all your stakeholders.
- · your homework and document everything. You are going to have to explain yourself every step of the way.
- · communicate and celebrate each milestone. If you make it a big deal, so will everyone else. Celebrate even small achievements, and highlight why they matter.
- · financial analysis. He or she who gathers the information decides how to tell the story. People will find ways to make it financially difficult to move forward, so make sure you have the data to justify your plan.
Don’t…
- · be discouraged by setbacks. Not everything is going to go smoothly. Setbacks will happen, but don’t let them deter you.
- · expect overnight results. Change comes with some frustration and pain, so be patient but consistent. Set an agenda and stay the course.
- · bite off more than you can chew. Don’t overpromise. Set realistic expectations right from the start and live up to them.
Finally, believe that what you’re doing will deliver value
for the organization. Document your journey, practice patience, and press
forward with confidence.
Source: blog.xebialabs
No comments:
Post a Comment