By Amit Gupta, Associate Vice President – Delivery, Ness Digital Engineering
December 4 2016: Culture transformation is at the heart of a DevOps evolution for any organization. When merging software development and IT operations teams to improve software quality and accelerate release cycles, the way people within the organization think, work and collaborate is vital for successful adoption and execution of DevOps.
However, cultural transformation is also the slowest and the most difficult to achieve, and it requires specific focus.
At the onset, end customers must be figuratively placed at the centre of any company’s DevOps approach. The most important message is that the company is transforming to become more agile so it can address customers’ needs faster and better, and not because the industry today is adopting DevOps or because certain tools and methodologies look interesting to explore.
Here are seven focus areas that can help drive a DevOps mindset into the cultural fabric of an organization.
Management Sponsorship and Drive
This may sound anti-Agile relative to Agile development’s complementary tenets to DevOps regarding team empowerment and breaking hierarchies and bureaucracy. But, you do need a personified, strong conviction that sets the stage and serves as the change catalyst along the journey. This conviction could manifest in the following behaviours and expectations:
- The sponsor(s) should have a clear vision on how a DevOps evolution will benefit the organization, its customers and its employees
- This vision should then be clearly articulated to all stakeholders
- The sponsor(s) should be able to demonstrate their personal involvement and motivation to make DevOps adoption successful
- DevOps adoption and realization of its benefits should be a goal that becomes part of performance measurement for the sponsors and other stakeholders alike.
- Most certainly, DevOps adoption should not be treated as a side initiative that does not or should not disrupt “Business As Usual;” in reality, quite the contrary should be expected.
Inclusiveness and a sense of a ‘common goal’
Product Management, Development and Operations should have a sense of a common mission and goal for the product or release or sprint they are working on. The definition of this common goal should be the value delivered to the customer and not the value of code, test results or deployment steps individually. Inclusion of Operations roles within a Scrum team working closely together benefits this cause in many ways:
Brings in a common view on what a product, release or sprint is intended to deliver
Creates an opportunity to bring forward and address operations needs during the development cycle; for example, consider inclusion of key operations factors into the ‘Definition of Done’
Creates a better understanding of mutual expectations and empathy for delivering outcomes that meet customer expectations.
Common view on progress
The teams’ collective progress – what has been achieved and what more needs to be done by when - is another a powerful mechanism to bind Development and Operations teams together towards a common goal. In the best case scenario, in which processes become so mature that an output of a sprint is deployable to production, it is imperative to be able to view progress in real time.
Common Tools Environment
A well-integrated, engineering tools platform provides a common workbench for all team members (who are quite likely also geographically distributed), as well a common instance of truth for everyone. It’s a powerful mechanism to eliminate ambiguity on ‘real status’ based on hearsay.
One of my managers used to say that there is nothing except your salary and performance rating that is confidential in a team. Evolution of open seating perhaps has its roots somewhere in this philosophy. It is a topic that draws vehement differences in opinion, especially in certain geographies and cultures. However, it certainly provides for open, frequent and ‘boundary-less’ interactions among the team.
Retrospectives fostering Continuous Learning
Unfortunately, holding a retrospective session to discuss lessons learned after a development cycle is usually either a misused or under-utilized tool for many teams. If used effectively, however, it could easily bring forward tactical, operational, personnel and strategic issues. Assuming the retrospective is indeed conducted in the right spirit, the sponsor and the management should take time and effort to clearly understand each of the points. Just like a product backlog, there should be a plan built to add and address the list of ideas shared and ensure that subsequent retrospectives reflect the issues that have been addressed.
At all levels, the stakeholders should be bold to bring the problem forward, rather than just brushing them aside so as not to impact Business As Usual. Retrospectives could lead to disruption which indeed enriches the overall DevOps adoption journey.
Identify Non-Agile mind sets, make changes if necessary
All of us have worked with people in our teams who are less willing to change. Fundamentally, there is nothing wrong with a difference in perspective and thought – all are welcome as a part of continuous learning and improving culture. The problem starts when a parallel organization starts to operate which becomes counter-productive for the organization at large. It is only fair to have constant, formal and informal discussions and mentoring sessions with people who express concern about change; but, if futile for a long period, don’t feel shy about moving team members to something different that better aligns with their ideology.
The Ubiquitous Question: How to Start?
Have a Charter: Develop a charter that is bold and clearly answers why and when the organization wants to adopt DevOps and articulates what the transformed state may look like. The charter should address benefits for the customer, the organization and its employees.
Form an Evangelist DevOps Team: While the perfect end-goal should be a well-formed, integrated Development and Operations team, it is practical to initially have a small evangelist team of ‘DevOps Engineers’ that bridge between the two teams today. It should be known upfront that the evangelist team will have a short lifespan.
Invest in Training: t the risk of stating the obvious, the topic of cultural transformation is so wide and varied that there is nothing better than continuously learning from different, practical experiences.
Identify a Pilot Identify a pilot project that already has a strong process and engineering orientation, led by a team with the capability and willingness to change. Learnings, successes and benefits from a pilot will encourage stakeholders and other teams to learn and adopt DevOps.
Amit Gupta, leads onsite Delivery and Account Management for Ness-DACH
Ness Digital Engineering designs and builds digital platforms and software that help organizations engage customers, differentiate their brands, and drive revenue growth.
DevOps (a clipped compound of development and operations) is a set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.