DevOps

Smart devices, the IoT and analytics can give your enterprise many insights into customer needs. And your technology organisation will need a new approach to respond to these insights–be Agile to be ready.

We were part of such an organizational transformation in Europe. Being ready, for this retail industry leader, meant removing the walls between development and operations. Up to that point, they were operating under the waterfall methodology. Every stage of the software development lifecycle (SDLC) had defined entry and exit gates. This made their release cycles longer, and often changing business-needs forced changes in requirements. And rework created even longer release cycles. We realized very quickly that their current organization was unable to respond effectively to the market needs.

So, we set about transitioning their technology organization to a new methodology which could handle expanding sets of new requirements–DevOps. With DevOps, our founders had to help the client team get self-organized, go to market early, gather feedback, act on it and iterate to develop a potentially shippable product..

More than just the tools to be implemented, DevOps calls for a mindset shift. It was like preparing long-distance runners to instead run sprints. And jump over hurdles at the same time. For this transition to succeed, we also had to build a closer relationship between technology and the business units. And even more closer relationships between the development and operations groups within technology.

We did this at informal gatherings in the enterprise, where we met business owners and users to gauge the end-customer landscape from casual discussions. Our clients came to love these coffee chats! They found it was the perfect forum for everyone to understand the pains and complaints in their areas. It was also a forum for the founders to earn the trust of the stakeholders who would lead the change. We talked about how agile methodologies bridge the gap between different teams and roles. We talked about how it naturally promotes collaboration within the technology organisation and teams. And we talked about how it reduces unwanted surprises for business.

At another informal networking weekend, we conducted a fun workshop for all stakeholders, where we introduced the mechanics of DevOps to them. The sessions were vital in cultivating a shared mindset – a mindset that made it easier for everyone to accept, and promote, change.

We began the solutioning process only after the founders had created enthusiasm within the team members. DevOps bridged the gap between development, QA and operations activities. The solution we implemented was to automate the build-and-release process (using TFS, now called Azure DevOps Server) to save time. Reduced manual intervention between handoffs also meant fewer human errors.

In the end, we helped the technology organization get into the customers’ and business’ shoes. In a period of three months, they saw how critical it was to get their technology products out to production – delays meant lost opportunities. And the solution we helped craft and implement captured these opportunities.

Our takeaway: Tools and processes are only half the solution for DevOps. The other half of the solution is building consensus between business, technology development and operations. Spend more time explaining why DevOps is needed before getting into the what and how.