‘Software is eating the world’ said Marc Andreessen, a confidant of global corporate giants.
‘Say no more!’ said the leaders of businesses across industries.
In no time, every software company started adopting various development methodologies to build better software (with bigger appetite maybe) and release faster. DevOps is one of the well-known adoptions and claimed to be a revolutionary one at it. While everyone is trying to take notes and simulate the efforts of first-generation digital adventurers, not everyone is ending up nearly as successful as them. Where is it going wrong? A lot of market and entrepreneurial experts say it’s the direction of transformation and we can’t agree more. So, let’s look at the control centric as well as self-managed structures and transformation models to try and assess their effectiveness over DevOps adoption.
Business owners have realized the on-going shift from hardware-based to a software-based economy. The digital era is forcing them to transform everything from culture to business operational models. To lead a living and breathing agile enterprise, delivering quality software and motivated workforce is very important.
We helped an organization that was trying to get their teams to adopt DevOps. A detailed Discovery process, with confidential feedback from the teams on the ground, revealed that while the leadership had provided necessary investment, they were trying to push a specific Cloud-based DevOps platform. But the engineering teams felt that the tech stack currently in use would not align well with this platform.
We conducted a workshop with leadership and walked them through our tailored Transformation model. The “how” was then left to the CTO, Architects and project teams to decide, since the leadership was mainly concerned about business agility than the technology.
Chances to go off course:
Leaders and/or Product owners often jump-start the transformation plan without listing the requirements that map out the immediate business requirements, customer priorities and how they all relate. That may send out the signals to rest of the organization that the initiative isn’t another management fad. Displaying the fear of failure and imposing methodologies, systems and tools on engineering teams would discard their ownership towards the initiative.
Many best-selling business transformation books and articles are promoting an emerging new paradigm of self-managed, egalitarian organizations. But, does it work for DevOps transformation? The concept of a teal organization is interesting, but it isn’t practiced widely for a reason. Broad-based local performance improvement certainly brings a fresh perspective of solving problems, but it has a potential threat with inconsistent implementation and varied performance objectives.
Chances to go off course:
Though the local transformation opens doors for innovation, too many voices can slack off the progress. Little to no centralized control shall lead to a state where opportunities for improvement are overlooked, and the new skills and behaviours aren’t built. As a process (or a business) grows from a start-up to a scale-up state; as the resources, needs and complexities grow; it’s important to have a delegate authority and hierarchal structure. Committing to full transparency is a challenge in self-managed teams.
Our vote goes to ‘Cross-functional Core Process’
For a sustainable change, everyone must buy-in the ‘Why’ and be involved while coming up with a ‘How’. Being the new buzzword of IT industry, the adoption of DevOps comes with many conjectures and assumptions. While the top and bottom camps try to win the steering end of transformation journey, the rest of the organization in middle gets pressurized and the core objective is compromised often.
In Cross-functional transformation, core process gets redesigned to link activities, functions, and information in new ways to achieve Transformational goals. What’s ideal is leadership announcing the intent, setting direction and establishing constraints, while the teams are empowered to operate within those constraints. There is no question of either, it must be both.
To achieve the promised land of Agility, if you chose the path of DevOps, make sure your adoption plan follows these principles of transformation drafted based on our experience.
- The objective is ‘Performance’. Faster cycles, faster failures, faster feedback, everything is to (should be) better the performance consistently. The leaders need motivate the employees, take informed decisions, quantify the potential benefits, and maintain transparency with their core teams.
- Strategy and Structure is NOT out of fashion. As we said earlier, self-managed teams might get temporary freedom but there is no promise of continuous improvement there. Transformation efforts are done better with viable economic and organizational structures.
- People matter! We, at Qentelli firmly believe that people can make or break any company during transformation. It is important to hand-pick the right skills and building high-performing teams is necessary.
- Automate the configurations, the change and the deployment process.
- Focus is essential. Nothing can be fixed with ‘Fix everything at once’ attitude. Whether it’s the structural conflicts from top-down or procedural complications from bottom-up, the respective personal must prioritize the issues based on their possible consequences.
- Process is nearly useless without values. Building performance-oriented workforce can’t be built with rigid hierarchies focussing on procedures instead of results. The leaders must clearly communicate the value they’d like to embrace and how are they linked to performance to the employees.
Business scaling consultant and Executive coach Lex Sisney says, ‘behind every high-performing, bottom-up, self-managed, seemingly egalitarian company, there is a well-run top-bottom hierarchal organization’. DevOps adoption is not a cure-all but it sure can enable continuous delivery, continuous feedback, bring in a cultural shift at workplace and most importantly improve customer experience and positively effect the delivered value. Talk to our DevOps experts to know what’s the safest way to transform the way you produce software before its too late.