Manage Learn to apply best practices and optimize your operations.

Online collaboration tools allows DevOps to delete silos

In this Q&A, Robin Gordon of CoreLogic explains how using online collaboration tools empowered her team of more than 300 developers repair broken processes.

DevOps managers encounter challenges when a fast-growing IT operation fragments into so many different departments that software delivery and performance lag. CoreLogic, a financial analytics service provider based in Irvine, Calif., faced this very problem just a year ago. Its DevOps team of 300 full-time employees and a few hundred contractors worked in small groups, each with its own set of applications. As a result, the company ran many redundant apps and DevOps processes, according to Robin Gordon, CoreLogic's new chief data officer and, until recently, the company's Solution Management Center senior VP.

"Each of CoreLogic's development teams operated within their department and didn't collaborate with other developers in the companies," said Gordon, who started at CoreLogic in June of 2013. "Each supported a particular business unit and really only had exposure to those systems."

In the following Q&A, Gordon talks about the problems caused by siloed DevOps, the steps taken to address those problems, and how her team chose online collaboration tools based in software as a service (SaaS) to foster interactivity, fix a broken ticketing system and consolidate processes.

What problems arose from departmental or decentralized application ownership at CoreLogic?

robin_gordonRobin Gordon

Robin Gordon: It was a problem for a variety of reasons. One, [the developers] didn't feel like they belonged to the larger organization. More important than that, from just a pure application development standpoint, they didn't see where there were capabilities and opportunities to improve their applications in other areas. So, whether it was a matter of reusing components in their area or leveraging technologies that other groups had utilized, they just didn't have exposure. Their world was very myopic to the area that they supported.

What first steps did you take to break down departmental silos?

Gordon: I addressed this initially by doing road shows and going out and meeting with each of the groups and trying to share a little bit more about our corporate objective, our global technology objectives. But that can be a pretty long-winded, inefficient process for me to be traveling to numerous locations across the country.

Which other online collaboration tools or technologies did you evaluate or use?

Gordon: Other options included Chatter, which was part of the Salesforce.com platform, Yammer. But it's just a platform to facilitate collaboration. You get onto Yammer, you have a conversation. The conversation is done. You move on. I've seen in my career, [introduction of] social media [that] falls by the wayside because it feels like extra work to do … and there's no objective. [Then we heard of the] POPin tool, a SaaS that allows open discussion of a topic in a casual way, not like social tools or surveys.

How did you evaluate POPin?

Robin: We launched a pilot of POPin, where I took about a hundred team members, randomly selected from different areas of my team and all different levels of my team. We just asked them a simple question: 'How do we become more effective as a complete cohesive team versus individual units?' The session lasted for three days [and let people] suggest and then build on each other's ideas. It doesn't feel like extra work. It feels like a more efficient way to do your current work.

What technology or development tool changes were suggested during this trial run?

Gordon: We had an outstanding result. I think there was over 90% participation rate. We got about an 80% engagement rate. I think we had about 75 ideas come out of this session. There were hundreds and hundreds of engagement points, where people were coming in, voting on ideas, commenting on ideas, adding new ideas.

It was a compelling exercise, in terms of really hearing from the people and getting an objective perspective on what was really bothering them and where they saw opportunities for improvement. They were engaging at a level that I don't think the team had ever engaged before; interacting as a cohesive team for the first time, instead of interacting in the silos that existed before.

What was the most common collaboration problem mentioned in this first feedback session?

Gordon: The first idea that rose to the top regarded the ticketing system that our app team has to interact with, whether they're fixing their laptop, getting a new cellphone, ordering a new server or running a patch. That tool is incredibly cumbersome, not intuitive at all. People felt like it hindered their ability to be effective in their jobs.

Were you able to use online collaboration tools to address the ticketing system issues?

Gordon: We already knew that that ticketing system was pretty bad, and we'd generated a set of high-level requirements. But we said, 'Instead of the normal approach of talking to user groups and building out requirements, what if we held a POPin session?' We did it as a sprint, over the course of an hour. [About 300 users and administrators] called into a conference line and engaged in writing requirements for an hour. Then we left the session open for 24 [more] hours.

Then, we looked back to the requirements that we had internally and the broader set of requirements developed over the POPin session. There were a lot of common themes. The POPin session helped us prioritize the things that were causing the most pain, the most egregious problems in the tool. We did not have to guess at it, as we had done in the past.

As a requirements gathering process, it was a really cool way of engaging the team and getting the right set of priorities.

What ideas for collaboration processes came up in that first session?

Gordon: It was the idea of creating a knowledge base of reusable components that team members could leverage when they were building out new systems and augmenting existing systems. They felt like they were doing a lot of repetitive work, probably recreating the real and numerous instances. That was actually the truth. They wanted some way that they could interact more holistically with other application development teams across the organization, so they could see nuggets of code that they could utilize in theirs.

The other idea was very similar, but more focused on creating a community practice, where the developers could share ideas, gain knowledge, build up their skills and become more integrated as a team.

How did your team act on those process ideas?

Gordon: Small [collaboration] groups sprouted out of this idea. We have Tech Tuesday or Tech Thursday, where small groups of people talk [via POPin] about how to solve problems in terms of new technologies, coding techniques, training on new versions of software development tools and what-not.

Generally, grass-roots teams became more acceptable to the entire organization. Instead of five people joining Tech Tuesday, we maybe have 50 people joining Tech Tuesday. They're really collaborating and learning from each other about how to be more effective and how to fine-tune their skills sets. So, that was the result of that first session.

What are your plans for increasing collaboration in the future?

Gordon: I now run CoreLogic's data organization, so I'm bringing POPin over to my new team. Also, I do have an application development team that reports in to me that supports the data supply chain.

I want to use that tool to get ideas around what's working and not working within the data supply chain, and how we can more closely connect with the corporate technology organization that I was in. The [data] team here is larger and probably more dispersed, not location-wise, but if they are working in one area, they are absolutely not aware of other areas. I definitely want to bring people together more effectively and start to map out our end-to-end processes so we can improve and be more effective within our data organization.

Next Steps

Learn more about transitioning legacy software to SaaS

Discover more about creating a strong SaaS risk strategy

Learn five ways to tell if you're ready for SaaS ERP

What role should tools play in a DevOps initiative?

This was last published in July 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

A DevOps primer: Start, improve and extend your DevOps teams

Join the conversation

5 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What experience has your company had using online collaboration tools to deal with fractured IT operations?
Cancel
One tool that we’ve used is Trello. Trello provides an online board, much like a kanban board, that can be highly customized to show any variety of information. The Trello Development board is a good example. It’s helped to break down some of the barriers between silos, and foster better communication and collaboration by increasing transparency into the work being performed.
Cancel
Thanks for the response. What were the other web-based and cloud-based tools that you considered? And what made you choose Trello over the competition?
Cancel
We are fairly siloed as well. We do collaborate a decent amount with the other teams that are co-located at the same site as we are, but there is far less communication with teams at different physical locations. 

I can understand the benefits of sharing processes and technologies, but there is also a lot to be said for being specialized in a part of the business domain. Someone needs to be extremely familiar with the domain and its history. If you force dev teams to become more generalized, you will lose some of that knowledge.
Cancel
Abuell - You make a great point. While many push towards conformity in the name of efficiency, history has proven the power of nurturing individuality.

But it seems like it's a balancing act - it's great if departments are specialized in their area, but the organization may miss out on great innovations if those specialists don't have a dependable way to interact with other specialists and see how their two groups can work together to make a better product.

Feel free to counter me, however, and please get in touch if you're ever interested in sharing stories about your own organization's approach to development and the kind of experiences you've had.
Cancel

-ADS BY GOOGLE

SearchAWS

TheServerSide.com

SearchFinancialApplications

SearchBusinessAnalytics

SearchCRM

SearchSalesforce

DevOpsAgenda

Close