DevOps Dojo – Customers & Trust
In DevOps Dojo first blog, we explained what trust really is—competency and character. In our conversations with customers, there are two surprising facts that top the list of trust. The 1st one is that we act with the customers’ best interests in mind, and we can think on behalf of customers’ long-term goals. If you think deeper, this requires you to have a level of competency above the things that everyone already knows to envision the future for your customers. For example, if customers already know A and B and you tell them A and B, then they don’t really need you. You need to guide them to see beyond A, B, C, D, etc. The 2nd one is how quickly can we reply to their phone calls, text messages, or emails. This requires you to be accountable, proactive, and responsive, which are directly linked to your professional character. Note: Pricing doesn’t make the top 3!
Let’s look at another surprising fact that most people often underestimate. There is a perception that trust is built through large or dramatic events. On the contrary, trust is built through small, incremental, continuous, and consistent interactions. There are those who are competent and full of integrity in large events but who fail to check in from time to time and update you with small but critical information that you need to make decisions in a timely fashion. Surely you would hesitate to trust this person because you would wonder if they genuinely cared about your causes.
Why are the small and frequent interactions so critical in building trust? According to Jon Levy—the behavioral scientist best known for his work in influence, human connection and decision making—the key to building a trusting relationship is to find something that will motivate you and your customers to invest effort in together and, ideally, is consistent with what you enjoy and value. When you do, you will notice how quickly relationships form, all because of a problem, group effort, vulnerability loops, and a moral molecule.
Now with this foundational understanding of human trust that is based on integrity, competency, and frequent interactions, let’s first deep dive into various customer scenarios to understand their complicated and complex needs in their DevOps Transformations, then discuss how we define our guiding principles to address those needs, and finally present our holistic approach to serving our customers through building bridges so that we can meet them where they are and where they want to go.
Customer Scenarios
The importance of laying the proper groundwork before attempting to solve a problem is emphasized in a popular statement that is usually attributed to Albert Einstein, “If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.”
So, do we really understand the problems of adopting a DevOps Culture? The following is not an exhaustive list of customer scenarios but is rather the most common scenarios we have encountered. Let’s look deeper across each scenario to understand the real problems of adopting a DevOps culture.
Scenario 1 – Customers know what they want but push towards evaluating their partners and services providers to better understand if they can walk the talk.
Many software companies’ professional services, or System Integrators (SI), sell DevOps services while only a handful of players in the market can showcase “dog-fooding” from a practitioner perspective, or in other words, how DevOps is leveraged internally to build their own software. Customers try to understand what your best DevOps practices are accumulated over a long period of time, how you make decisions, and what your decision-making process is. For customers, this seems to be an easy ask. For service providers in DevOps, this is a million-dollar question because it is very difficult to accommodate, even though they sell DevOps services. Why? Well first, as provider, you must have a culture of transparency and vulnerability to show your struggle in your own journey of DevOps. Second, it is a major investment for any software company or SI to successfully transform their internal organization into an organization built on DevOps principles, the continuous investment in becoming an elite DevOps organization can span years or even a decade—it is a paradigm shift!
What exactly do customers want to see from their service providers? For example, 1. How do you organize your product delivery using Agile and DevOps? 2. What do you measure and how do you measure for continuous improvement?
3. How do you handle constant changes in the DevOps landscape? 4. Can you offer concrete examples of you handling complicated vs. complex problems in DevOps? 5. How can you improve and measure DevOps culture and mindset? 6. What principles and philosophy guide your decision-making process? 7. How do you attract DevOps talents and build DevOps skills? 8. How do you handle quality and security in a continuous and consistent way? 9. How do you scale your organizations, your processes, your architecture, your governance, and your knowledge in DevOps? 10. Some customers even want to visit your product team(s) to see how exactly you work in a DevOps way on daily basis.
Scenario 2 – Customers need help to advise and educate their senior leaders on moving to a product-centric organization in their DevOps Transformation journey so business and IT can be aligned to create the business values more quickly and efficiently.
We have seen that most of the conversations about DevOps are at the IT level. In a considerable number of cases, it is either at the Ops, QA, or AppDev Org level. Most of the service providers don’t get a chance to talk to CIOs and businesspeople.
According to recent research by Gartner, many organizations continue to pursue defensive central IT strategies and their business-IT relationships still result in partly adversarial experiences. Vendors and central IT mostly “project deliver” applications as self-contained suites designed and packaged for independent operation. Although some product-style delivery is beginning to be used, the full impact of this new approach has yet to be absorbed into the organization’s culture and practices.
Without fully moving to a product-centric model, Business-IT alignment has been struggling. The perception of business leaders is that their IT organizations are slow and expensive. Businesses also don’t see business value from DevOps initiatives. Business stakeholders are choosing a business-led IT approach because they can fund it and consider themselves best qualified and resourced to do so but don’t consider the full life cycle of software delivery. IT organizations are being asked to deploy business-led solutions to production, but do not feel empowered to be partners. Most IT organizations are neither funded nor resourced appropriately to be an effective partner to business-led IT. As the misalignment goes, it is at a tipping point now.
Business leaders, executive management, and even IT personnel will be uncomfortable or even combative about moving from a project to a product-based approach. Concerns include funding models, a perceived lack of control, and losing the project management “iron triangle” of scope, timeline, and cost.
So, the large enterprises are looking for product-centric services providers with practical experience to guide them in transitioning from the project-centric model to product-centric model. Although a bottom-up approach could be a good trigger for the DevOps transformation, a holistic and successful transformation will require executive sponsorship, and both business and IT senior leaders should be aligned to make this possible. Additionally, IT must be quite well versed in understanding each LoB’s business process to technology enablement.
Thus, many customers turn to software product companies because those software product companies have built products for years or even decades. They have the most practical experience in building digital products that include product management, product strategy, product discovery, product delivery, product adoption, and change management approaches.
Scenario 3 – Customers had several attempts in DevOps transformation over past few years but failed to achieve any sizeable outcome.
Across various regions at the WW level, we have met customers who told us that they have made several attempts at adopting DevOps over the past 3–5 years. In the end, some organizations even went backwards, and some organizations became even more siloed. Some hired services providers to conduct assessments to measure their maturity level, but many seemed to dislike the output or argued about the interpretation of the maturity level provided by services providers.
Some believed that technology would bring the organization forward, but it often didn’t. Some made great automation in a small team, but business never sees any business value from their initiatives, so their work couldn’t be scaled at the organizational level. Some invested in many tools from different vendors, but instead of focusing on creating business value, the IT team spent a great deal of time fixing the integration issues of the pipeline caused by the various tools that needed to be upgraded constantly.
Frequently, the Ops side of the pain/solution, which is part of DevOps, is often not taken into consideration by customers as it initiates from the Dev side. To bridge the gap between Dev and Ops, which is a huge challenge and requires higher level sponsorship, someone who is overseeing both the Dev and Ops sides should be driving the sponsorship.
Some companies had a strong grassroots movement in DevOps, but due to lack of executive sponsorship, the initiative and community struggled or failed. Some had executive sponsorship and even a strong grassroots push, but no transformative leaders drove the initiatives, so it never took off. In many cases, middle management was simply not motivated to make the changes. In some other situations, the organization was undergoing so many changes at once that it reached its change saturation point. In fact, according to PROSCI more than 45% of organizations are either past or at the limit of their organizational saturation point.
We have also seen that some organizations hate the word “DevOps” because it was being used in so many ways and caused a lot of debate, so the word “DevOps” is banned internally and externally. As a result, they created new and fancy names to replace “DevOps” and tried to solve the DevOps problems by changing the name. As you can imagine, it has never been possible to solve a problem by just changing the name.
In some organizations, we have also seen that DevOps is a mandate, so everything is prescriptive from the top down. This includes massive OKRs on output not on value, massive documentation to record all DevOps practices, and hope that everyone can follow the book to execute and create great value. This model is a waterfall at scale, not only killing innovation due to control overhead but also making it hard to show any ROI. Furthermore, by not testing the hypothesis and failing sooner and smaller, the model creates large organizational failures in DevOps transformations. This leads to company losing customers and market value given the high stakes tied to the opportunity.
Scenario 4 – Customers are still at the very beginning of the DevOps journey. They don’t know what to do and where to start.
For some government organizations, due to the risk and compliance requirements, almost all development projects are waterfall-based. Moving to Agile and DevOps seems to be quite challenging. Before the pandemic, digital transformation was optional for some customers, but now it is about survival for them. Those customers cannot grasp Agile and DevOps, let alone understand what a product-centric model really is. DevOps is not a standard, it is a cultural shift and set of guiding principles, so making it real is difficult for many customers.
In some cases, companies have too narrowly defined DevOps, which leads directly to incorrect organizational placement and DevOps anti-patterns. For example, many organizations think DevOps is about development-focused practices, so their DevOps investment is from their VP of Apps and their operation and reliability are afterthoughts. We also ran into a few companies that thought DevOps was Operational App Support, so their DevOps funding and personnel were placed into app support teams. Some organizations thought DevOps is a separate team, so they created a new organization called “DevOps Team” which focuses on pipeline and platform.
Scenario 5 – Customers had some small success in CI/CD automation in their IT or digital department, but it either created a YOU vs. US siloed environment or failed to scale DevOps to the larger organization.
We also see companies where they created “startup” organizations in their digital front-end (bi-modal approach). With the focus and the funding, they hired top talents from outside and moved them to big cities. In six months to a year, they were able to deliver every day with great pride. However, this creates a YOU vs. US culture—the unicorn vs. old school—where most of the core systems that digital front-end needs to integrate with are still managed by the “old school” back-end organizations. So, the unicorn’s short-term success couldn’t lead to larger organizational success and agility. The scenario in this example is not uncommon in our customer environments. Most of their subsidiaries are cloud-born. Their key corporate mothership has grandfathered in a whole stack of heavily customized, home-brewed solutions from the spin-off.
We also have seen in many large organizations where local or functional organizations have their own processes and tools that when their CIO wants to see the global view, it is almost impossible to aggregate the status in real-time or near real-time. By the time the CIO has the information, it is already outdated without much value. Since the CIO has no real visibility of how the field is doing and what they are struggling with, CIOs can’t take actionable steps to help the organization. The field is looking for help but the information isn’t making to the top. More interestingly, since each functional organization has its own tools, when the tools are upgraded, they must redo the integration every time to make their ETL process work to generate reports. People spend more time working on tools integrations than working on high value-added work.
We have also seen that there may be one successful business system, but CIO cannot replicate the same DevOps success laterally into other business systems. Scaling DevOps at the organizational or company level is extremely difficult. It requires strategy and execution power to scale at the organizational level, process level, architecture level, governance level, and institutionalized knowledge level. According to McKinsey, “Given the complexity of large program implementations, it is crucial to have people who have already done them, or something comparable. There is just no substitute for that kind of experience and ‘pattern recognition.’ Without it, failure is far more likely. As might be expected, these people are hard to find, especially since these sorts of large programs happen infrequently for most organizations.”
Scenario 6 – With a shortage of DevOps talents in the market, customers want to reskill their workforce to increase their developer’s productivity and velocity, customers are looking for providers to teach them how to fish.
DevOps has evolved from initial Agile process, configure management, version control, CI/CD, and testing to much more sophisticated and broader practices. Some examples of this are continuous security, SRE, KPI measurement, product-centric model, development in the cloud, full-stack feature team, frequent safe-deployment, telemetry, and data-driven decision, InnerSource, accessibility, user experience, human-centric design, etc. The skills required in DevOps are beyond technical skills, and people even find it hard to keep up with these technical skills let alone having to learn nontechnical skills while continuously improving on both.
Before the pandemic, CEOs rated skills gaps as a top business challenge. Enterprises couldn’t hire all the talent they needed for digital transformation, such as agile ways of working, digital product management, and artificial intelligence (AI). The COVID-19 crisis won’t change this because few workers with these skills are being laid off. Most of these customers would not be able to find DevOps talents because there are just not enough available in the market.
Therefore, the only option is to reskill and upskill their current employees. To fill these gaps, current employees must acquire new skills. Before the pandemic, executive leaders couldn’t spare workers’ time for training. Now, some workers have been temporarily laid off, and others have less work to do. Thus, many workers now have time for training that they would never usually have. Executive leaders could take advantage of this unique window to reskill employees to meet strategic business needs. If the enterprise ignores this opportunity, it will face the same talent shortage during the recovery that frustrated its digital transformation before.
For some industries such as retail, we have seen significant acceleration of digital transformation. Their challenge is that while the need for DevOps Transformation is so pressing due to digital disruption during the COVID-19 pandemic and digital natives eating away market shares, keeping the lights on for outdated IT landscapes supporting their still very profitable “nondigital” business is even more demanding. How on earth would these companies be able to attract new talent that will stay once they notice the actual truth let alone find time for existing employees to learn these new skills?
Finally, learning requires focus, but unlearning and relearning require much more. it requires choosing courage over comfort. This is especially important for team learning since DevOps is a team sport, so how can a team learn and unlearn together to make progress?
Scenario 7 – Customers are looking for continuous product-centric services providers to supply a multidisciplinary team that builds, deploys, and supports software using Agile and DevOps approaches.
According to Gartner, by 2024, 80% of the IT organizations will undergo radical restructuring and changes to their missions as they embrace product-centric operating models. This increased depth of adoption of the product-centric model goes hand-in-hand with the adoption of agile development methodologies and DevOps to increase the cadence of delivery.
During this transition from a project-centric model to product-centric model, companies are faced with a transition from functional outsourcing service providers to product-centric service providers (as described in this blog Optimizing Outsourcing with Cloudsourcing). For example, instead of contracting business consultants, implementation partners, infrastructure-managed services providers, and application managed services providers separately, customers would move to a multidisciplinary (product) team model.
A “multidisciplinary” team could include business analysts, architects, user experience/customer experience (UX/CX) designers, Scrum Masters, developers, testers, infosec engineers, DevOps specialists, infrastructure experts, and site reliability engineers.
A product-centric services team takes requirements from the backlog created by the customer’s product owner. The team then develops software, as well as automates the test suite, deploys to production, and resolves Level 2/Level 3 support requests for incident resolution, defect correction, and software enhancement.
This also creates challenges for services providers in terms of contract. Each option below has its pros and cons depending on the trust level between customers and services providers, the complexity of the product, and the ambiguity of the business requirements and market dynamics.
- Option 1: Time & Materials: The customers bear the risk; the service provider bears none.
- Option 2: Managed Capacity: A predictable monthly cost for the customer but a high-level control over the team.
- Option 3: Unit Based: Customers like it but it is hard to find a unit measure that works for both sides.
- Option 4: Business Outcome: Customers are interested in it, but it is very difficult to implement.
- Option 5: Fixed Price Per Sprint: This is an effective and hybrid model for holding both accountable, but trust is the key for this model and trust takes time.
Scenario 8 – Customers are moving their critical workload into the cloud, so they look for a strategy to integrate DevOps before, during, and after cloud migration.
We have seen customers spending millions to create a cloud platform that enables internal teams to access the public cloud securely. After spending a sizable amount on funding, resources, and effort, customers are still not able to move their critical workload onto a public cloud. Why? Cloud platforms are generally Ops or IT driven. These customers forget to involve every business line (especially business lines supporting their full profitable “non-digital” business) to help them move a critical workload to the new platform during inception. In these cases, the creation of the new cloud platform is simply an Ops exercise without business involvement. Business obviously won’t appreciate the value and can’t articulate the business justification.
It is very important to have InfoSec’s involvement in working with business and IT to ensure cloud vendors’ adherence to their security controls, without which they struggle to onboard, migrate, or justify. Cloud security has become the biggest driver in the online consumer digital payment sector.
We have also seen customers who moved workloads to the cloud but were afraid to make any changes and enhancements because it was so painful to deploy changes and new releases to production in the cloud. Thus, when customers treated cloud adoption and DevOps as two separate and unrelated initiatives, it ended up costing them more, taking a longer lead time for changes, and creating more waste in human capital. Therefore, customers are looking for a better strategy to use DevOps in cloud migration or application modernization in cloud.
We also have seen customers who are obliged to move critical workloads to the public cloud within a short timeframe because of corporate cloud-first policies or government regulations. They depend solely on their system integrator partners. The partner brings in their own approach and toolset to deliver and operate the workload, which causes customers to lose control, struggle with the high barrier to exit for their business backbone and depend on the partner’s technical expertise to maintain the new/modern way of doing things (IaC, governance as code, etc.).
Scenario 9 – Customers have a mixed waterfall/iteration development model and an agile development model in their products development and try to find better ways to enhance their development capabilities through leveraging DevOps approaches in a complex development environment.
In some industries, customers have a very complex development environment and product release cadence. Some customers have bimodal IT system development: Backend systems are in the stable model that requests traditional waterfall or iteration development, while some front-end mobile applications or business portals/websites are in the agile model that requests the use of DevOps based development. Both the stable model and the agile model exist in the same development organization.
In other cases, some customers focus on providing smart devices combined with chipsets/hardware drivers/OS’s/applications. The development organizations have different development and release cadences during their products’ life cycles.
These customers are looking for a DevOps platform with the best practices in applying the processes to support these various development models and requests. At the same time, they are very interested in an immersive training program that showcases the team topology to achieve productivity in real-world scenarios. They want the training program to build their DevOps capabilities and deliver the services and products to their end-users cheaper, quicker, better, and more securely.
Scenario 10 – Customers who want to “do” Agile/DevOps without investing too much time and effort or simply to “buy”/ “install” DevOps.
In some situations, the organization understands the benefits of a DevOps transformation but is simply not willing to spend the necessary internal energy and resources to develop this capability. In this situation, the organization will rely on external providers to come and enforce the DevOps transformation internally with a “predefined” process that worked for other customers.
Although it might sound reasonable to try to save time and energy by leveraging past successes, every organization is unique, so every DevOps transformation should be different. The external provider’s value resides in DevOps transformation journey acceleration rather than bringing a prepackaged end-to-end DevOps transformation. One simply can’t buy DevOps.
It is simply impossible to avoid spending the necessary time to understand the organization’s context and adapt the guiding principles to match the organization’s context. This requires a lot of brainstorming and collaboration with internal people who know the context better than any provider might. It also requires an Agile approach to the transformation itself, where it is possible to try solutions (process, tools, organizational change, collaboration, etc.), measure the results, and reiterate as needed to find the best approach for the specific organization’s situation.
A DevOps transformation approach should be Agile!
Summary: So far, we listed ten scenarios we have encountered frequently; we welcome your feedback on those ten scenarios, as well as any additional scenarios that were not covered in this list.
Dojo Guideline Principles
Like any services providers, we are facing the same challenges in serving customers given how enormously complex and complicated the problems in DevOps are. However, despite how different each customer’s situation and problems can be, DevOps problems can be addressed if we follow the fundamental principles in DevOps. Mastery of the principles themselves and their applications improves our ability to reason, explain, design, communicate, act, predict, and explore.
Let’s look at the guiding principles we have placed for DevOps Dojo. Guiding principles are a set of moral values that establishes a framework for expected behavior and decision-making. The term “guiding” refers to the fact that these values are established to lead the organization in any situation it might face. They are essential in the decision-making processes since no decision should contradict any of these principles.
At the beginning of Dojo ideation phase, we debated at length about our guiding principles. These principles guided us through all those years in making decisions, including our most difficult and controversial decisions. Our guiding principles have served us well in both good and challenging times.
- Understand DevOps transformation is people transformation
- Understand DevOps’s success requires leadership sponsorship
- Understand DevOps needs transformative leaders to drive it
- Understand complicated vs. complex problems in DevOps
- Understand trust comes from competency and character
- Understand economies of flow vs. scale in DevOps
- Understand walking the talk in DevOps is GOLD
- Understand the definition of DevOps in MECE
MECE: The MECE (mutually exclusive and collectively exhaustive) principle—pronounced by many as “ME-see”—is a grouping principle for separating a set of items into subsets that are mutually exclusive (ME) and collectively exhaustive (CE).
Dojo Holistic Approach
When customers come to us with various problems and challenges with various needs and constraints, we offer holistic and modular solutions so that we not only can inspire customers to reach the art of the possible in their DevOps journey but also meet them where they are at throughout their DevOps journey. The end-to-end and modular solutions enable us to empower any customers to do more and better.
#1: Envisioning Workshop
This workshop is designed to understand customers’ vision, ambition, mission, as well as the current challenges and ongoing initiatives in their DevOps Transformation. We use model thinking to help customers decide on their DevOps transformational path. Those models are formal structures represented in data, mathematics, and diagrams that help customers understand their industry and organizational landscape.
We showcase how our product and services teams do DevOps in our daily lives. We have “ask anything” sessions to share how we make our decisions, explain what philosophies lie behind these decisions, show the mistakes we made, look back on what we would/could do differently, share surprising innovations and hypotheses we have made, reveal what the outcome was, etc. We strive to understand what it takes to enable our customers to reach to the art of the possible.
#2: Executive Workshop
This workshop is a combination of training, interactive discussion, discovery, and problem solving with customer executives. The workshop is designed to address some of the most important topics such as business/IT alignment, product-centric model, Culture and Management of Change, Objectives and Key Results (OKR), Talents and Reskilling, and DevOps strategy at the company or organizational levels.
This is a DevOps and product-centric model-focused workshop with senior executives from both business and IT. It is a multidisciplinary approach for envisioning the DevOps transformation strategy. The goal is to establish a common understanding, consensus, and alignment, as well as to gain stakeholder commitment.
Please note that this executive workshop is NOT a DevOps solutions review or technical discussion, NOT a DevOps demonstration or hands-on session, NOT a DevOps maturity model assessment, NOT a DevOps tools selection presale session, and NOT a sales or commercial discussion for DevOps.
#3: DevOps Lensed Sprint 0
First, the maturity level of our assessment can often be very subjective based on a limited number of questions and our interpretation. Second, telling customers that they are immature in DevOps is neither helpful nor productive. We need to figure out a more effective way to assess that can build trust quickly with customers and can lead to actionable next steps together. The solution is to focus on capabilities, not a maturity model, so we developed DevOps Lensed Sprint 0 (LS0).
DevOps LS0 supercharges regular Sprint 0 by using a structured and persona-based requirements collection framework harvested from years of Microsoft transformation experience and reviewed by subject matter experts to drive comprehensive DevOps transformation requirement gathering and backlog creation. We meet customers where they are at by understanding what is possible for customers given their immediate, short-term, and long-term needs, as well as what the best options and strategies are for customers to consider achieving them.
DevOps LS0 provides insight into customers’ actual DevOps situation with more than a hundred actionable backlog items, prioritized into DevOps transformation strategy and roadmap.
We also started to offer Industry-lensed DevOps Sprint 0. This includes industry trends and drivers for your industry, digital trends and technologies in your industry, customers’ strategic priorities and competitor analysis, customers’ OKRs and challenges in DevOps transformation, mapping objectives and scenarios for LS0 practices, and finally, creating and prioritizing backlogs and generating actionable reports.
#4: DevOps Master Class
Through Microsoft’s 10+ years DevOps journey, we can provide real-life experience to show why we embarked on this transformation, what potential benefits it has already seen, and how we can scale DevOps. DevOps Dojo can demonstrate a clear vision, help to gain consensus, develop new skills, offer incentives, allocate cloud resources on-demand, and provide action plans so our customers can mature their software delivery capability and innovate at the speed of business.
The Dojo master class is an immersive learning place for a team, not for an individual. The class has 3 phases designed to deepen a team’s learning for each capability: 1) The best industry practices and science behind the concepts; 2) Challenge resolution, discussion, and debate; 3) Hand-on labs with either Azure DevOps or GitHub end-to-end solution.
DevOps Dojo Master Class provides consensus across, fosters appreciation, and builds trust among the participants. For more information, please visit our DevOps Dojo – Experiential Learning blog.
#5: DevOps Implementation
Once we have leadership buy-in, transformative leaders in charge, DevOps assessment outputs, and skilled DevOps teams, the implementation can much more effectively lead to outcome. We can build a strategy with customers on how to mature their DevOps capability and offer Lean Product Management leadership with feature teams, InnerSource platform consulting, delivery MVP together with customers, and many more services based on tested and practical IPs.
#6: Continuous Improvement with Support
Customers who have a support contract can get help from us for continuous improvement. All the practices built inside of Dojo can be consumed in smaller pieces. For example, support customers can ask for a value-stream mapping workshop to understand what is wasted in their value stream, they can ask for a SRE workshop to look at specific SRE practices, or they can focus on accessibility in their client-facing digital platform to ensure inclusiveness and compliance.
In Summary
Dojo is the foundation and connective tissue of our end-to-end DevOps approach. Dojo is built based on the aligned autonomy principle, and while we have guiding principles that we must live by, there is a great deal of autonomy in our IPs, readiness, solutions, and deliveries that empower Dojo practitioners and customers to achieve more.
To end our blog, we would like to repeat our mission:
- Solve the hardest problems in DevOps
- Accelerate DevOps culture
- Make DevOps real
Final Thoughts
In this blog, we discussed various challenges our customers are facing and how we can help them to innovate at the speed of business. However, it is impossible to succeed in DevOps when culture and mindset are not addressed. As Gene Kim said, “DevOps is a journey full of challenges, and rarely are those challenges simply due to the wrong technology or the wrong processes. In fact, the biggest and most difficult obstacles tend to be cultural. And if you get the culture wrong, even if you get everything else right, you’re headed for frustration, extra cost, and likely failure.”
What do we mean by culture? We will leave you with food for thought before our next blog on culture. In the next blog, we will discuss one of the most important pillars of DevOps Dojo: Culture and Mindset.
Special Dedications
This blog was written and reviewed by the following authors in Dojo Community.
- April Edwards – April.Edwards@microsoft.com
- Paul Fijnvandraa – Paul.Fijnvandraat@microsoft.com
- Roopa Krishnaiah-Felten – Roopa.Felten@microsoft.com
- Abdeslam Menacere – Abdeslam.Menacere@microsoft.com
- Harry Chen – harrchen@microsoft.com
- Ronghua Chen – ronchen@microsoft.com
- Kitty Chiu – Kitty.Chiu@microsoft.com
- Gautam Patel – gautampatel@microsoft.com
- Daniel Jasnik – Daniel.Jasnik@microsoft.com
- Andrew Wolff – Andrew.Wolff@microsoft.com
- Kan Tang – kan.tang@microsoft.com
Light
Dark
0 comments