devopsy.kinsta.cloud

Tag: tranformation

  • Can Culture Detract from Success with DevOps?

    Can Culture Detract from Success with DevOps?

    Collaborative culture is considered to be an essential best practice for enterprises. DevOps culture correlates strongly with enterprises that achieve the highest level of business performance. However, is it possible that an organization can get overly fixated on organizational culture improvements? Can culture actually detract from achieving success with an enterprise DevOps transformation?

    An article by Curtis Franklin Jr.,”8 ways to fail at DevOps,” indicated that there are “plenty of places in the DevOps process where an organization can run aground on rocky shoals of woe.” My blog, “7 Pillars of DevOps,” identified seven essential best practices areas that make up successful DevOps. One of the seven pillars is collaborative culture. These pillars are not silos, but rather foundations that need to be kept in balance.

    I bet most of us have experienced situations in which cultural improvement missteps hindered an enterprise DevOps transformation.

    Culture Missteps

    I’ve listed some examples l below which I have personally seen. Have you experienced these? I would love to hear examples of your experiences and solutions you have observed, too.

    1. Unrealistic expectations from leadership: Business expectations from leadership get too far ahead of the DevOps implementation reality—then teams reporting to leadership end up feeling unappreciated and experience frustration, resulting in organizational friction.
    2. Ops-side transformations fall behind Dev-side transformations: The Dev team accelerates ahead of the Ops team and implements “its part” of a DevOps transformation before the Ops team has a chance to implement complementary changes. The Dev-side is disappointed that Ops has not kept up with the complementary Ops-side planned changes. Dev changes cannot be put into effect, which deepens the mistrust between Dev and Ops.
    3. Dev-side transformations fall behind Ops-side transformations: This is the reverse of the second example, with similar effects.
    4. QA tester roles are confusing: When new continuous test strategies are implemented, the lines of test responsibilities between Dev, QA and Ops team members became blurred. Communication between cross-functional team members become confused, resulting in misunderstandings, dissatisfaction and organizational friction, which obstructs progress.
    5. Infrastructure and tools teams are siloed: Dev, QA and Ops teams maintain separate, siloed tools and infrastructure staff and do not cooperate to support end-to-end infrastructure and tools improvements. The transformation needed for a smooth DevOps pipeline stalls.
    6. Rewards and measures are not consistent with DevOps goals: The organization makes changes toward a cooperative culture but fails to change the way people are rewarded and measured. Conflict results between the teams.

    Solutions

    Below are solutions that were applied to the situations listed above. Do you agree with these solutions, or have others to suggest?

    1. Leaders were coached to be more aware that DevOps transformation is a journey of continuous improvement. Leaders then understood that there is really no “end state” to DevOps—there are specific business improvements that can be expected along the way. Each DevOps improvement initiative was refocused on realistic specific use cases and goals. With improved clarity, leaders were more realistic in their expectations for each improvement. This drove alignment between leaders and their teams, improved satisfaction and productivity.
    2. Project goals and team meetings were realigned and organized. Dev and Ops sides could monitor end-to-end progress together. When situations occurred in which one team got ahead of the other, the end-to-end progress visibility helped overall group communication. Empathy across the Dev, Ops and QA teams improved. With improved communication, team members celebrated the success of each other’s improvements. Teams shared a common end-to-end goal.
    3. Same as 2.
    4. QA testing responsibilities changed significantly during the DevOps transformation. Separate independent test team member responsibilities changed toward QA testers being more integrated with Dev teams. New skills requirements for the QA engineers emphasized test automation more than in the past. Training for the cross-functional team helped mitigate concerns related to the new QA responsibilities. QA testers were uplifted with new skills and became more valuable and respected by their peers. Cross-functional productivity improved.
    5. The tools and infrastructure teams from the separate Dev, QA and Ops teams were combined into a common tools and infrastructure team. Project goals were realigned. The improved clarity around knowing they are working toward tools and infrastructures for a common end-to-end pipeline accelerated implementation of DevOps.
    6. Rewards and measures that had been in place for separate Dev, QA and Ops roles were changed to rewards and measures that encouraged end-to-end cross-functional team activities. This improved overall morale and job satisfaction and reduced organizational friction that was previously impacting progress.

    Summary

    From the above real-life examples, it is clear to me that culture and organizational practices must evolve in concert with progress on other DevOps pillars. And as the pace of change increases with each transformation, the cross-functional teams must be even more cohesive. Continuous acceleration of interactions between team members drives the need for tighter relationships, more end-to-end responsibilities, improved customer awareness, continuous skills training and end-goal focused leadership.

    The is no need to create the “perfect culture” before starting a DevOps transformation journey. It can be counterproductive for sections of the culture to get too far ahead of itself, as indicated in the examples above. Perhaps it is best to evolve the culture carefully. Changes most important for each transformation project should be the focus. Continuously communicate goals and progress, and evolve the culture together with evolution of other pillars. What do you think? Do you agree is it possible that an organization can get overly fixated on overall organizational culture improvements?

    While DevOps implemented with all seven pillars provides a strong foundation for long-term enterprise business improvements, it is important to understand DevOps is not an island. Enterprises implementing DevOps should be aware that DevOps interoperates with other IT systems and practices. Enterprises are well-advised to choose tool-agnostic IT partners that can provide solutions that best suit the needs of each unique enterprise and can integrate and evolve DevOps together with all of their IT systems.

  • Are You Ready for Your DevOps Transformation?

    Are You Ready for Your DevOps Transformation?

    You’re done with missed release deadlines, long release cycles and risky releases. If your objectives are continuous application delivery to achieve fast feedback loops and reduced waste, DevOps practices provide the means to reach them.

    DevOps is all about agile transformation, which reaches beyond agile development into production to achieve continuous delivery. DevOps practices provide help for the necessary next step after agile development to leverage the full potential of agile and avoid massive post-delivery changes through the development teams, but before they are ready to go into production.

    The challenge is to navigate that DevOps transformation—and make it happen faster and at less risk. The speed and direction of that transformation depends on individual circumstances—for example, the type of technology you have deployed, the shape of your organization structure and processes, and what your overriding business and IT requirements are.

    Beginning the Transformation Journey

    Only once you have assessed your organization’s current DevOps maturity and orientation can you begin to scale your DevOps implementation—and move faster on the transformative journey toward continuous delivery. In other words, to know where you’re going, you need to know where you are now.

    transformationBy measuring your status across each of these dimensions on a scale of Level 0 and Level 4 (see diagram), you can benchmark where you are today and derive recommendations and measures for future improvements.

    Culture and Strategy: DevOps requires a strong vision and strategy and its success will depend on the awareness, knowledge, skills and motivation of your employees. This pillar addresses the effectiveness and alignment of your awareness-building and enablement programs as well as your incentivation system with regard to agility in all involved units, dev and ops. It also includes a snapshot of the sentiment and motivation of people to make such a change reality.

    Automation: This pillar addresses the maturity of your organization in terms of IT automation as an important prerequisite for continuous delivery. Both the application architecture and the DevOps automation tool chain are assessed. Relevant automation capabilities in application configuration, provisioning, deployment, test, infrastructure and application monitoring are included in the assessment. The maturity is assessed across the tree layers infrastructure, platform and application, and by technology stack—for example, your SAP platform, .NET or Java stacks—and then combined into a single level.

    Structure and Processes: The current organizational structure and methodologies and processes in use within all involved units are assessed with regard to their effectiveness for continuous delivery. This focuses on their agile fit and maturity. Governance and how agile teams and processes are embedded into the broader organization are part of the assessment scope as well.

    Collaboration and Sharing: Collaboration and sharing between development, operations, infrastructure and middleware teams are crucial to accelerate the delivery process and make it leaner. The assessment looks at particular sharing vs. redundancy of tools (e.g., tools used for deployment), information (e.g., the status of a package in the delivery pipeline), processes (e.g., an ITIL release process and a development release process) and functions (e.g., a release engineer in development and a deployment expert in production).

    Now you have the facts at your fingertips. The DevOps Maturity Assessment Service presents all of this as documented findings, to include a series of recommendations on how you can scale and mature your DevOps activity.

  • What is DevOps and Why Should CIOs Care?

    What is DevOps and Why Should CIOs Care?

    Like the buzz-phrase: “cloud” or “big data”, DevOps is the new flavour of the month within the IT industry.   You’ve probably heard of it by now – but many CIOs and heads of IT have not got to grips with what it is and are therefore reluctant to let developers take ownership and run their own operations.

    A recent survey found that 23 per cent of respondents were not familiar with the term DevOps, and another 17 per cent thought it was all hype. DevOps is a method for improving the performance of the entire IT group.  It is aimed at creating a better set of joined up IT outcomes for the business.  As a methodology, DevOps allows all IT functions and activities, from cradle to grave, to be integrated into a seamless whole.  It is an IT engineering philosophy and discipline that sees each part of the IT activity and value chain as being important to the delivery of IT products and services.

    So why is it important?  Well, DevOps is about culture, organisation, people, processes and tools. It helps directly address the historic silos that have existed between ‘development’ and ‘operations’.   It also deals with the unhelpful and counter-productive behaviours that exist within different parts of the IT organisation that interfere with the smooth running of IT and impedes the delivery of high quality and cost-efficient products and services to the business.

    DevOps provides a model for a more efficient and effective IT group; one that delivers more business value for less IT cost.  By changing the way that different parts of the overall IT group operate together as a unified whole, DevOps improves the eventual outcomes for the business by making the ‘business of IT’ more efficient and more effective: “Better IT means better business”.  Well-implemented DevOps initiatives will deliver rewards in terms of IT efficiency and quality improvements.

    Whilst it can be a difficult sell to the business, the commercial benefits of a DevOps methodology applied to the ‘business of IT’ can bring significant improvements in productivity, consistency, flexibility and stability and must be championed by the CIO in order to get business buy in.

    As promising as the DevOps movement is, especially for global organisations, some clear lessons have already emerged. Understanding these in advance could be the difference between success and failure for your DevOps initiative, and ultimately, your entire IT strategy.  The alignment and collaboration of development and operations is key to a successful DevOps programme.  Both groups must strive to achieve business agility through enabling change whilst preserving the stability of the existing IT infrastructure.

    To achieve this the CIO must foster an environment where there is no longer two groups with opposing interests but one team that is pulling in the same direction and a culture where the individuals are cogniscent of each other’s responsibilities.

    Get this right, and it will undoubtedly lead to better business.

     

    About the Author

    RedPixie shoot via Simon Glazer of Elate comsPaul Greer is Chief Software Architect at RedPixie. Paul works alongside the product and services teams to ensure products are high quality and enterprise ready. Paul also maintains a close relationship with RedPixie’s client base to ensure software services are delivered to a professional standard and exceed expectations. Prior to co-founding RedPixie, Paul spent 14 years in the financial services sector, holding technical leadership roles in business application development, innovation and architecture. 

    @paul_greer