Unlocking the Potential of DevOps
Many organizations are now embracing DevOps, following their previous adoption of Agile methodologies. However, they often fail to achieve the expected benefits due to the sometimes frayed relationship between Developers and Operations teams. Developers may view Operations as obstructionists who constantly impede progress, causing delays. Consequently, the term “DevOps” has become a buzzword that is tossed around without a clear understanding of its true essence. Meanwhile, Operations teams perceive DevOps as yet another attempt to enforce poorly managed changes and assign blame to them when things go awry.
In response to this challenge, senior-level executives craft a clear and well-defined mandate: “Do something with DevOps!” This directive filters down to the IT architects, who envision a need for new DevOps tools. It cascades further into the depths of application development, where it often gets misinterpreted as “NoOps.” The mere mention of the term “ITIL” gets someone expelled from the room, while the word “Culture” elicits the response, “Give them a DevOps certificate!” The business, enticed by statistics like “2000 deployments a day,” becomes eager for DevOps implementation by the following week. This entire process is part of an end-to-end strategic plan, but unfortunately, the desired business value often ends up as nothing more than a fairytale, akin to a prince on a white horse transforming into an unsightly frog with warts. Pardon my mixed metaphors, but they seem appropriate given the mythical nature of these so-called DevOps unicorns.
From DevOps to DevOooops
To measure the value derived from DevOps, organizations often focus on internally-oriented metrics tied to development and operations, such as time to market, failure rate of new releases, lead time between fixes, and mean time to recovery. Sadly, these metrics say little about the actual realization of business value. Discussions around “enterprise value realized” are met with confusion and indifference. It seems that the obsession with DevOps has led us to turn white horses into frogs more frequently and at a faster pace, all while keeping the frog alive until the end of the process.
In fact, a study conducted by F5 Networks in January 2017 revealed that only one in five IT executives and industry professionals surveyed believed that DevOps had a strategic impact on their organization, despite its widespread adoption. This lack of impact is hardly surprising given the reliance on the aforementioned metrics.
Dispelling the DevOps Fairytale
So, where does this leave us with DevOps? Lewis Carroll once wrote, “If you don’t know where you’re going, any road will get you there.” This quote perfectly encapsulates the current state of DevOps. We find ourselves in a situation where there is no magic recipe book or implementation guide for DevOps. It is a journey that we must embark upon by making it up as we go along.
To prevent this fairytale from turning into a nightmare, let’s play a game! What does a game have to do with DevOps, you ask? Well, it can serve as a fun and interactive way to learn and explore the essence of DevOps.
Fun and Learning: The DevOps Game
In a recent internal simulation exercise, we played the Phoenix Project DevOps business simulation with a group of organizational consultants tasked with advising their respective organizations on DevOps. These consultants were already involved in technology initiatives and had heard rumors about DevOps. Naturally, they felt the need to understand what DevOps was all about before advising their organizations. This exercise may seem unusual, but it’s not the first time consultants have found themselves in such a position.
To their disappointment, I informed them that there is no fixed standard for DevOps, unlike ITIL. In DevOps, you have to embrace the “make it up as you go along” mindset.
Embracing DevOps Principles
During the game, we aimed to discover and define key DevOps principles that would guide our high-level discussions. Whenever the group identified an important principle, it was added to the discussion board.
These were the principles we captured:
- BusDevOps: This holistic approach ensures that the organization commits to its role in achieving business value by involving product managers.
- Focus on Value Creation: It’s not just about delivering new features quickly; it’s about reducing value leakage and addressing technical debt.
- Integrated Testing and Test-Driven Development: Testing should be involved from the beginning, not just at the end. We need to understand and adopt this end-to-end concept before deploying a suite of automated tools.
- Consultant/Coach Role: Every new DevOps team needs a mentor to help them self-organize, reflect on their work, capture iterative improvements, and establish effective communication and collaboration practices. Self-organizing teams cannot be created by simply pressing a button.
- Time for Reflection and Improvement: DevOps is not an overnight transformation. It requires trial and error, experimentation, learning, and continuous improvement. “Improving your work is just as important as doing your work.”
- Culture of Knowledge Sharing: Encourage openness, admitting when you don’t know something, investing in new skills, and fostering cross-functional teams. Let’s break free from the “hero” culture.
- T-Shaped Skills: Empower every team member to run stand-ups and reflection sessions. This responsibility doesn’t have to rest solely with managers. A manager who only gives instructions can hinder open feedback, exploration, and experimentation.
- Meaningful Metrics: Business value realization is a crucial metric that also validates the maturity of the business case, rather than succumbing to immediate demands without proper evaluation.
- The Right to Say Stop: Everyone should feel empowered to halt the flow if something isn’t working, communication is unclear, or assistance is required. The team should unite to address the issue and, if necessary, add an improvement item to the visual continuous improvement board.
- No Blame: Failure is an opportunity for learning, as long as we learn from it and take steps to prevent its recurrence. Blaming others stifles an open and learning-oriented culture.
- Effective Communication: Communicate without assumptions, actively listen, and allow everyone to have their say. Confirmation is key.
- Clear Priorities and “Why”: Make priorities and the underlying rationale visible during stand-ups to expedite decision-making and foster a shared sense of purpose.
- Work Until Business Value is Realized: Completion should be tied to the realization of business value, not just code deployment.
- Ownership and Management: Teams should take responsibility for their work and ensure it remains manageable. The same team that fixes failures after go-live should also share knowledge to strengthen incident management capabilities.
- Visualization of Improvements: Visual management should not only focus on work but also highlight potential improvements in how tasks are performed.
- Single-Piece Flow: Avoid multitasking excessively, as it leads to errors and frustration.
- Inclusion of Service Management: Incorporate practices like problem management to foster feedback and build quality upfront, preventing unplanned work. Define and approve standard changes to streamline the flow of change management.
This game was more than just a form of entertainment; it proved to be an invaluable exercise for exploring and discussing the true meaning of DevOps. We recommend repeating this exercise with key decision-makers to foster a shared understanding and commitment. Additionally, it can be a valuable tool for DevOps teams, bringing together individuals from Development, Operations, and the Business to explore and learn what DevOps truly means. It creates a safe environment for effective communication, collaboration, and the development of new behaviors.
In conclusion, let’s embrace the path of DevOps and move away from fairytales towards successful collaboration. With a clear vision and the right approach, we can transform our organizations and achieve remarkable results.
Conclusion: So above is the DevOps: The Path to Successful Collaboration article. Hopefully with this article you can help you in life, always follow and read our good articles on the website: Megusta.info
