In this post, we look at the challenge of maintaining a DevOps mindset, especially in the face of adversity.
Speaking from a personal perspective, I can certainly say that a DevOps mindset helps me with adversity. However, when you’ve invested lots of time building your DevOps culture, it’s important to make sure you can maintain that culture in different scenarios.
During the Coronavirus pandemic teams around the world had to change how they worked and still maintain themselves as high performing teams and a DevOps mindset. In the current economic turmoil, maintaining a DevOps mindset is more important than ever.
A healthy DevOps mindset navigates various paths of continuous improvement in which disruption, discipline, and guardrails are the norm. What no one expected is the radical disruption we all experienced during and since the pandemic, and the impact it is having on our DevOps and personal mindset, our workflows, and the Kanban and agile team ceremonies.
Tuckman’s theory of group development, which outlines how teams develop into productive high performers in stages, may be familiar to you. As expected, most, if not all, agile teams that transitioned from collocated to remote setup will return to the storming stage, as shown below.
Do not be afraid of change. Returning to storming is natural, and it provides an opportunity to embrace the challenges.
Here are five ideas for a healthy DevOps mindset as we evolve our organisations’ collaboration and delivery models during (and after) the pandemic.
Let’s now look at these five areas in more detail.
Human interaction is essential in DevOps. The invention of new ways to stay in touch from a distance will most likely be a recurring theme in all the improvements that can be made remotely.
Using virtual communication to host a community of practise, discussions, demonstrations, and meetup events, you can continue to build stable relationships with your peers, colleagues, workers, and users. My team participates in monthly virtual meetups and hosting fortnightly webcasts to discuss topics of interest, such as our new continuous delivery pipelines, to replace those invaluable in-person hallway discussions. The now-virtual ceremonies enable us to connect, maintain a supportive presence, create transparency, and communicate intent, all of which are essential for demonstrating loyalty and confronting today’s trying times.
Everyone left the familiar setup of the office, where many people worked together in the same location, on short notice. Instead of teamwork and collaboration, which are essential for agile and DevOps, we are now isolating ourselves behind the Internet router. Instead of breaking down silos, we’re essentially creating a virtual maze.
Instead of becoming a hero or creating another silo, inspire and share collaboratively. This is most likely the most difficult DevOps core value to cultivate during times of adversity.
Learning does not happen by itself, so make sure to incorporate dedicated learning opportunities into your new routine. Review your processes, automation (or lack thereof), products, and documentation on a regular basis—this is an opportunity to ensure that anyone can operate without the need for a face-to-face discussion to fill in the gaps.
When you can, be positive, and when you can’t, be honest, but always smile during your virtual collaboration sessions. Others will sense your honesty, humility, and enthusiasm, and you will inspire your colleagues and stakeholders to look at new frontiers with fresh eyes and embrace a growth mindset.
Collaboration is the core value of our DevOps mindset at home, as highlighted by the first item on this list. This implies that we must listen, communicate, create transparency, and extend trust. Communicate with your manager to clarify expectations and keep in touch with your team and stakeholders via emails, chats, video conferencing, and phone calls.
During video conference calls, make sure you are present and focused. Keep your camera on, if possible, to ensure that visual cues and expressions are not lost, and most importantly, show kindness and respect. The best organisations in the world recognise that working remotely can mean home life can at times impact work life.
The success of individuals working in high performing teams and teams which have embraced that DevOps mindset is down to several different factors. One which stands out for me is the ability to innovate.
Innovation is one of the things that keep engineers happy. It is one of the things that also helps keep the business moving forward. When you are working remotely, it’s important to make sure you don’t lose the innovation angle.
Through my experience, a tight number of changes will help in the adoption of DevOps. In this post, we take a look at five changes you need to make.
Do the phrases ‘rapid innovation’, ‘time to market’, ‘customer-centricity’, and ‘acting like a start-up’ ring a bell? They’re all buzzwords that excite the CEO while terrifying those tasked with running, transforming, and safeguarding their companies.
The CEO has good reason to extol the virtues of agile. Agile methodologies have the potential to accelerate product development, create new value, and drive organisational change. As a result, most businesses have begun to implement some form of agile transformation. But the next step – getting a product to market at the same rate it was developed – is proving difficult. Most businesses are simply not culturally prepared for such drastic change.
The following five changes are things you need to focus on in your company for DevOps to be successful:
Let’s have a look at these five areas in more detail.
In every case where I’ve seen it done successfully, the most important aspect of cultural change is top-down support for DevOps; there can’t be a bottom-up approach. Close alignment between IT and business leadership is required, with the CIO, VP of Applications, and business leaders sharing a common vision and goals. For example, if you have developers bringing exciting new features to market but IT isn’t ready to capture that innovation, you won’t get the desired results.
DevOps is a set of technical practises, cultural norms, and architecture that allows for a rapid flow of work from Dev to Ops to the customer while maintaining world-class availability, reliability, and security. This is all about creating a safe work environment in which small teams can develop, test, and deploy value to customers quickly and independently, in order to increase developer productivity, foster organisational learning and high employee satisfaction, and ultimately help organisations win in the marketplace.
People are the “invisible hand” of DevOps. You cannot manage every single decision along the pipeline as an executive, so you must empower your teams – from management to mid-tier and all the way down to the practitioners in the trenches – to “think DevOps” and make the right decisions. Then you’ll create a movement with its own rhythm and self-organization. The key is to transform your DevOps heroes into DevOps champions in order to spread their best practises throughout the organisation, and you’ll soon have a team of champions.
Blame games are an especially pernicious threat to DevOps success. DevOps teams must be willing to accept failure and move on. When they can’t, troubleshooting and triage become more of a guessing game than a learning experience. Blame games, at best, divert a team’s attention away from the continuous improvement of processes, products, and services. At worst, they prevent a team from learning to collaborate because individual employees are more concerned with avoiding the crosshairs.
DevOps is fundamentally about increasing the speed with which applications are built, tested, and released. As a result, embracing a “fail fast, fail forward” mentality is a top culture change. Dev and Ops professionals must not be afraid of “breaking things in production,” because speed is critical. This culture shift necessitates the ability to detect emerging production problems quickly (fail fast) using an APM solution, as well as collect feedback on what went wrong in order to improve future release quality (fail forward).
In this post, we are taking a look at how to build a DevOps culture that helps your company on the road to DevOps transformation.
One of the biggest misconceptions is that you can hire a load of DevOps Engineers, build a team and voila, you are doing DevOps. While that team may be doing a really good job and practicing some traits of DevOps, that does not make them a DevOps team. Neither does that mean you can take what that team are doing and scale it up and say your company is practicing DevOps.
DevOps is much more than specific roles, or even specific processes, although processes do back up the ‘how’ in DevOps. It’s about culture, and people.
Autonomy across teams and collaboration are two distinct characteristics of a strong DevOps culture. As a result, efficient operations can lead to a globally successful business.
In the first post of the series, I talked about companies which are doing well at DevOps. Of course, that limited list is just a representation, and all companies you speak to, will echo the same culture and people-centric approach.
Is there a recurring theme? A communication feedback loop with all stakeholders, both internally and externally, is critical. Creating a safe environment for communication allows for process evaluation without blame, ongoing experimentation, and shared learnings. Transparency and tolerance go hand in hand with the collaboration and ownership required for a healthy DevOps methodology.
The following five tips are ones that will help you build a DevOps culture that is strong and effective.
Let’s have a look at these five tips in more detail.
In DevOps, we talk a lot about growth mindset. This is one of the aspects of a growth mindset from a team perspective, rather than individuals. In DevOps we are always learning, everything we do feeds back into the next retrospective, then onto the next iteration.
This is not about accountability – while it’s important in DevOps that everyone is accountable for their work. This is more about making sure people have a fail fast mentality, which gives them the freedom to experiment and learn without the fear of blame should something go wrong.
Having this mentality in your company stretches everyone and enables them to think outside the box.
Alignment is another cornerstone of DevOps. Ensuring that everyone is on the same page when it comes to goals is crucial. Goals should be transparent from the top down, and those goals should be split into meaningful goals for teams to execute.
Having the vision to align your team goals to the wider company goals is what creates cohesion between the executive leadership and local leadership. To be successful in DevOps, your goals at a team level must align to the company goals, you have to be aligned in your aspirations and your team goals must help the business achieve their goals.
The power of cross-team collaboration can never be stated enough. One of the most powerful ways to illustrate this is not through shared stories, slide decks and whitepapers, but actually through simulation.
The Chocolate, LEGO, and Scrum game developed by Dana Pylayeva is a great example of how to show people the power of collaboration. The simulation is based around the aim of having groups work together towards a goal. Throughout the iterations that take place, players in the game have their roles changed which dictate what that player can do and rules change to allow you to collaborate with other roles.
As the game progresses you find that as bottlenecks are identified, and removed, you become more productive through the increased collaboration. It’s a powerful message, that delivers the point of collaboration in a fun way.
In the previous post on the characteristics of a DevOps culture, we highlighted the need for autonomy and empowerment. Extending on the thinking we looked at in the previous post, ownership is also a key element for success.
Shared ownership between developers and operations teams provides strength towards the common goal. That shared ownership is what helps facilitate the cross functional working and enables the teams to communicate better. That cycle provides a base for you to build upon.
It is important in DevOps to keep an open mind. This is another aspect of a growth mindset. With an open mind you are able to learn from everything you do, both positive and negative, adapt what you are doing and make the next iteration better.
That process of taking your learnings from one iteration to the next is known as continuous feedback. It is something you can think of as a cornerstone of a strong DevOps culture. That ability to openly discuss as a team, what went well, what did not go well and what you will do differently in the future demonstrates a high level of maturity. Lots of teams struggle to shift to that open mindset.
Market research shows that cost management in the public cloud is still at the top of the list of priorities for organisations looking to either move to the public cloud, or make better use of their existing public cloud investment.
Our Cloud Management Platform includes tools to help you govern the costs of your Microsoft Azure environment by grouping Azure resources together into cost centres, environments, or workloads to show the cost of those items in a business context. This helps not only understand the cost of business resources today, but also to plan for tomorrow.
Cost efficiency and understanding the breakdown of your costs between active resources, and those which are idle or even unallocated are important as well. This shifts the focus away from just cutting costs, to making sure costs are efficiently used.
Budgets can be assigned to easily track spend and understand projections, with notifications to Microsoft Teams when budgets enter warning or breached states. Granular cost insights enable you to look at daily costs and understand fundamental questions about your cloud spend such as identifying resources responsible for increases or decreases in costs.
Let’s now look at some of these features in more detail.
So, you can represent your costs in a context the business understands, you can define your Cost Centres, Environments, and Workloads within the portal. This allows you to allocate costs across your whole tenant regardless of how many subscriptions you have.
When creating Workloads, you can also state which Environments you have configured are part of that Workload, to help understand your costs for that Workload over different Environments.
The structure defined here flows throughout the Cost Management experience as well as into other features in the portal. This means that every view is in context of your business, rather than trying to interpret data on spreadsheets and technical resource names.
Budgets are an important mechanism in the management of your cloud costs. We’ve built the ability to define budgets for any of the organisation structure you have defined.
Budgets are recommended based on historical and projected usage for your selected structure, you can also set a notification channel in Microsoft Teams to have budget notifications sent to your Teams channel, rather than come through as another email in your Inbox. You can also define a warning threshold to determine when to send warning notifications.
Notifications are based upon a combination of projected and actual usage, so when you are projected to breach your budget, you are notified before this becomes a problem. This means you have time to look at your resources, and make any adjustments to stay under your budget, or re-evaluate the budget if required.
Optimising and managing your costs is a key activity of cloud management. A key part of optimising is understanding the breakdown of the costs you are incurring and how efficient those costs are overall.
The Cost Management dashboard shows you a breakdown of costs which are utilised, idle, or unallocated. You can then interrogate the idle or unallocated costs to look for resources which can either be removed if no longer required, or scaled back to incur less cost.
All of that data goes to produce a Cost Efficiency index, the score out of 100 is designed to give you a visual indicator on how efficiently your costs are. The higher the score, the better, and the less percentage of your resources are either idle or unallocated.
Through Cost Management, you also have the ability to track usage, forecasts, budgets, and performance against budget, as well as usage increases, and decreases to identify any resources which have a significant impact on your costs.
This view also shows you when your costs, either to date or forecasted will breach your budget, providing predictability for your consumption costs.
We appreciate that looking at the consumption data may not be something you do each day, so to enable you to go back and look at usage increases and decreases historically, simply click one of the Daily Costs bars on the chart to view the biggest increases and decreases from the day before.
This gives you complete control over your cloud cost management, which means no nasty shocks in your monthly bill, and the ability to investigate and remediate impactful cost changes in your environment.
Together all these features give you the tools you need to organise, track and analyse spend while also identifying spend anomalies in real-time so that you can govern today while planning for the future.
In this post, we will look at some of the characteristics that make a successful DevOps culture. Understanding the critical elements that highlight a successful DevOps culture is important as you start your DevOps transformation journey. DevOps culture is fundamentally about two things; communication and collaboration.
That’s all well and good, but how do you start that journey to improving both communication and collaboration, and how do you identify when you are making progress?
From all the companies I have worked with and contacts I have spoken to about the success and failure of DevOps, five things stick out for me:
Let’s now take a look at these five things in more detail, to understand them better.
Start at the bottom. Change, particularly cultural change, cannot occur without top-down sponsorship. However, it does not truly take hold until it is carried out at the smallest unit possible – that unit is individual teams. Implementing DevOps at the team level, allows them to demonstrate what is possible, identify roadblocks, and overcome them while the issues are still manageable. Indeed, successful transformations are typically the result of a journey of continuous improvement rather than a “big bang” execution.
DevOps requires engineering teams to take on responsibilities that were previously held by other functions. Engineering teams that are empowered to push change through to production must embed controls in their processes to provide assurance to the organisation that testing, risk management, and escalation protocols are in place. Control must be built into the process from the start.
Automation can be extremely beneficial. However, it is not simply a matter of digitising existing, routine, time-consuming tasks. It is about rethinking how controls are implemented, so that they occur by default within the process and without the external interference that typically causes bottlenecks.
Traditionally, organisations have built trust through audit-based control frameworks that use checklists and audits of activity to improve quality, assurance, security, compliance, and risk mitigation. That is however not how DevOps works. Control functions must trust that product teams can and will be responsible stewards of organisation wide principles and requirements. Clearly, trust must be earned, but this typically occurs quickly when teams collaborate and demonstrate success through small pilots, prior to scaling initiatives. This trust can and will lead to product teams being empowered to make the right and safe changes for the organisation.
When people are measured and rewarded for the right things, cultures change. Everything from C-level performance contracts to weekly sysadmin objectives, must be aligned with strategic business outcomes and the behaviours required to achieve them.
The desire to improve—the process, the quality, the speed, and the impact of each and every individual—must pervade every corner of the organisation. That necessitates shifting mindsets from “Let’s make it perfect” to “Good enough, let’s see how it works, and continue to iterate.” To support this cultural change, flexible systems and ways of working must be put in place to identify issues and opportunities, make quick adjustments, and test again.
By Martyn Coupland, Head of DevOps at Transparity
In this first post, we are asking the simple question; what is DevOps?
“DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.” – Donovan Brown
I wanted to start with the above quote from Donovan. I love it and honestly, I can’t do a better job at explaining it. I use this quote all the time talking to colleagues, peers, and customers.
Customers expect the services we provide to always be available, dependable, and to notify them if something goes wrong. These are the same expectations that we should all have when working together to deliver the application or service that our end users will encounter. We can increase productivity and success for our users by creating an environment that values a common goal amongst our team.
Why we do “DevOps” boils down to one big word, which Donovan emphasises… Value.
DevOps provides many goals, and in fact the goals that mean the most to you, may differ from mine and the next person. That is because as pointed out, we do DevOps to provide value, and that value is different for us all.
If you extract that thought to a higher level of the goals of DevOps, then I like to think of the following five reasons.
I like these five because you can apply them to any industry. Take the automotive industry. We can take a lot from the Toyota Production System, developed by car maker Toyota, who has long been recognised as a leader in this field. The underlying principals, called the Toyota Way, teach continuous improvement, respect for people, teamwork and many other things are present in the principals of DevOps.
It stands to reason therefore that you can apply the five points above as value to the automotive industry. Taking them in the same order as above, why wouldn’t they want to:
In fact, why wouldn’t any organisation want to benefit from those?
You will commonly hear people talk about people, process, and technology as the key elements of DevOps. I always like to add another one, that is culture. Culture is so important to DevOps, and in my opinion more important than the other elements and deserves a specific part in the DevOps playbook.
Most people will put culture in the same breath as people, and there is nothing wrong with that, but as culture plays such a big role in making DevOps successful, it’s something that has to be right, before you focus on people.
Culture is all about the understanding between developers and operations, sharing responsibility for what they build. That means increasing transparency, communication, and collaboration across development, operations and the business.
We have to change the way we encourage people and deliver value to our end users. When teams start focusing on the same goals, they start working together. In order to work together, you need to adopt some processes for continuous collaboration, such as; plan, develop, release, monitor, and finally, repeat.
In DevOps, technology plays a small but vital part in ensuring processes can be automated. These processes are the fundamentals of DevOps and the automation of those processes is what sets organisations apart in their maturity.
Good question, you bet it can! Unlike some frameworks and principals, DevOps has success across various industries, including those which are usually seen as hesitant to change or rooted in their ways.
Company size is also another factor, and while enterprise organisations do benefit from DevOps, you will likely find more success stories (that are published anyway), in start-ups and small to medium size businesses.
Truth is, it’s harder for enterprises to adopt DevOps. Most enterprise organisations due to their size have been around a while, they have processes which have not changed for a long time and sometimes employees which are unwilling to change.
Unlike in the start-up or SMB world, where the success of DevOps is plain to see in many organisations, enterprise is likely to find pockets of DevOps success within them rather than wide reaching success across the organisation.
Let’s buck the trend of thinking though and look at organisations which are doing a great job when it comes to DevOps.
The point to highlight here is that these organisations represent a broad set of specialisms, not all of them are tech companies, not all of them are finance companies, but rather split across the industry spectrum. They are however, all software companies.
By Martyn Coupland, Head of DevOps at Transparity
