Wednesday, 2 January 2019

10 sureshot practices to supercharge your DevOps effectiveness

Share
Whether you're about to implement DevOps or for ways to optimise it within your team, you must remember that DevOps is all about discipline and is definitely no magic bullet to doing it right from the outset or to fixing your perceived issues in one fell swoop. But you're in luck, because successful DevOps practitioners leave clues and patterns that you can start implementing today to supercharge the value from your DevOps program.

You can start implementing these 10 DevOps best-practices with your team from today:

1. There is a pattern to DevOps success

Like most patterns, you will either fall in line or you will try and take shortcuts. Taking shortcuts diminishes you and your teams ability to truly understand, harness and exploit the DevOps' potential to supercharge your business results.

If you still want to take shortcuts, keep scrolling. Otherwise:

  1. Build solid foundations: identify the processes, people and products that you will use to establish your DevOps practice. Then, agree on how they will communicate and share information and learnings to transform your culture to one that aligns to DevOps principles.
  2. Rationalise your tech stack: reign in your teams' propensity to collect the latest and greatest tools and ask them to decide on those components of their technology stack that are absolutely critical to delivering measurable business outcomes. This is your chance to minimise your tech footprint by refactoring applications to work on common environments and reducing the number of moving parts.
  3. Standardise & share learnings: as individual teams begin to understand how to minimise their tech footprints most effectively, you'll find that they will have built a knowledge base of what works and what doesn't. This is a great time to share these learnings across team and functional boundaries.
  4. Evangelise more key stakeholders: simply by doing the above your teams should be able to commit more to production environments than ever before. This supercharged pace of advancement will some of your testing and security teams feel like they're losing control and drowning, because of which they will create roadblocks. Bring such people into the DevOps fold, share learnings and build trust. This is where you start eliminating every superfluous manual intervention in your delivery process.
  5. Remove infrastructure bottlenecks: you do this by ensuring that your infrastructure configuration and management doesn't become a bottleneck to developer productivity. This is achieved by starting to promote a self-service culture, first by automating infrastructure delivery.
  6. Full automation & self-service: you should now be seeing material benefits in terms of productivity and noticeable improvement in trust, both intra-team and inter-team. Your teams should have self-service system that allow them to continually grow productivity levels and automation that removes bottlenecks.
You can simply rinse and repeat this template across teams, across divisions and across any functional borders. Follow this pattern and you'll find that your likelihood of achieving the DevOps promised land is boosted because everyone now has a recipe for success.

A word of caution: be very deliberate when turning manual tasks into automated workflows and build feedback loops to ensure that anything of significance is caught before its absence starts to damage on multiple fronts. Not only is this sound business practice, but also a great way to increase knowledge sharing and collaboration between, otherwise highly protective, stakeholders.

2. Cross-team sharing is key to scaling DevOps effectiveness

Do you have sharing, caring team members?
We discovered that the foundational practices — the practices with the most significant impact across the entire DevOps evolutionary journey — are dependent on sharing, one of the key pillars of DevOps.
State Of DevOps Report 2018
Communication is the key to solving most business challenges. The same goes for IT challenges. So it will not surprise you to learn that sharing and communication is a "key pillar" of DevOps.

If your teams communicate well internally and externally, then adapting your communication to facilitate cross-team and cross-functional sharing while implementing DevOps will be an easier exercise. You can start with the usual channels for knowledge transfer - ops manuals, mastermind sessions, lunch presentations, etc. The trick is to continue what is working and change that which needs improvement.

If you know your teams' communication is your Achilles heel, then you could either decide that DevOps is not for you. Or you could your DevOps implementation as a catalyst for fixing this area of your business or department.

You must buy into the idea that DevOps is just another buzzword, unless you apply it to change the fundamental components of your team and those changes deliver measurable business benefits. Without your complete buy-in, your teams will unable to exploit the non-technical aspects of DevOps to deliver anything other than utter frustration and confusion.

3. Start closest to reality & work backwards

In this instance, "reality" means two things:

  1. Look to start your DevOps journey on a project or with a team where your pain is most visible; and
  2. Also, implement DevOps principles as close to your production environment as possible.
By doing this you are building DevOps muscles based on reality, not assumption-riddled scenarios that create too much room for doubts and will require modification when you want to use them on production environment. Experience tells us that this is the fastest way to spread the DevOps culture throughout your teams.

You will know that there is no magic spells to fix culture. But you can start by improving collaboration (and results) from the areas that need this improvement the most. These internal case studies will be key to convincing the remainder of your teams to grow and flex their own DevOps muscles.

4. Change your mindset about security

You have to believe it before you see it.
Unknown
Changing your mindset is not an easy task, yet it is the key to success. Think about this: you're on this DevOps journey because at some point in the recent past you decided and / or agreed that DevOps could really transform the way your team and your business operates. And here you are.

You now need this same empowering belief to change your mindset about the importance and place of security within your DevOps practice. You need to believe that its is not only important, but also commercially beneficial to transform the cybersecurity of your applications from an afterthought to a competitive advantage.

Achieving this is not easy, because it first requires you to facilitate constant and consistent communication between your ops and security teams. You need to progress mindsets where security is about resolving immediate pain to one where it is a key strategic focus.

Move away from the school of thought that pigeon-holes application security as a tick-box audit exercise and towards one where cybersecurity actively contributes to maximising your bottom line.

5. Automate functional testing

DevOps without automated software testing is like racing a Ferrari with the handbrake engaged. After interacting with many new DevOps teams, my sense is that many of them are hamstrung by the imagination and risk appetites of their senior leaders, in a classic case of you don't know what you don't know.

If you don't like my Ferrari analogy, here's a more seasoned that will hopefully help you understand why your mindset around test automation needs to change if you really want to supercharge your DevOps environment:
A ship in the harbour is safe, but that is not what ships are built for.
John A. Shedd
You've gone down the DevOps fork in the road because you wanted speed and effectiveness. You wanted a competitive edge. Right?

By sticking to your old software quality habits you are only minimising your ability to achieve all these lofty goals. In short, you're attracting DevOps failure.

The good news for you is that there are lots of automated software testing tools and testing methodologies that work hand in glove with DevOps teams' needs and desires. It's up to you to select the right testing tool for your organisation and eschew the rabbit-in-headlights approach of simply gravitating to the big brands that are top-of-mind.

Get our Ultimate Guide To Test Automation for a comparison of the most popular, modern software testing tools and test automation engines.

6. Talk to the people at the coalface

Senior leadership in large and small organisations often fails to comprehend the nature and scale of the challenges and frustrations faced by those at the coalface. Like many other methodologies, think Agile, Kanban, Scrum, etc, decision-makers are often believe and promote a prettier picture that is reality.

This disconnect between IT decision makers and their minions is a chilling illustration of the disconnect between senior leadership and their people at the coalface:

While this is human nature and hard to change, mistaking fallacies for the truth will lead to systemic issues that will blow up in your face at the most inopportune times. It also leads to undeniable stress and misery for your team, which I'm guessing you REALLY want to avoid:

The question before you is quite simple: do you just want a good story to promote or do you want DevOps to drive real growth and profits in your business. The best way to do the latter is to talk to the people implementing your grand plans to identify and resolve the real issues behind the bottlenecks and inconsistencies that lead to frustrations, resentment and inefficiencies.

7. Make it continuous...

...both in terms of deployments, testing and security. You MUST have highly (although not "fully") automated pipelines where real people are not required to sit in front a screen to make something happen.

Without this level of automation you will not achieve the benefits that you visualised when you set out on your DevOps journey. Without this level of automation you are introducing room for failure that will be filled, not because your people are inept, but because as humans we revert to the comfortable and the unknown - even if it produces sub-standard results.

Be wary of recognising perceptions as reality, because what you perceive as a decision-maker is likely to be very different to what is reality:

For this to become reality your teams need to adopt continuous delivery pipelines that run your delivery processes where APIs act as puppet strings. This means that your infrastructure needs to be configured for automated deployments; that your software testing tools must be able to be controlled by APIs; and that your security testing tools must have two-way operation and communication through APIs.

This functionality set in software delivery tools is not a pipe-dream. It's available now. Your job is to find the combination of processes, products and people which allows you to achieve your results.

You've probably already worked out that the first step to achieving this requires the standardisation of your technology stack. This means that you have to force a culture where tools are used because they deliver a real and measurable benefit, not just because they are the lastest fad that someone found on ProductHunt.

8. Make alerting and monitoring automated & configurable

I know what you're thinking: "here's that A word again!" If you haven't got the picture yet, sit down and make a list of all the manual reporting and monitoring tasks that your teams are still performing. Then work out the low-hanging fruit in terms of what can be automated now and what must be automated later.

But the "configurable" part of this best-practice is just as important. Without the flexibility to customise monitoring and alerting activities your teams will engage in 2 flights of fancy that will definitely having you pulling your hair out:

  1. Create new monitoring and alerting capabilities that overlap and require lots of maintenance; and
  2. Revert to manual, which will break the system entirely!
Doing this will help you transition your team from building and relying on someone else to monitor and manage what they've built (in case you haven't already heard, a central team to run DevOps "ops" is bad form!). Amazon's tech innovation czar (and CTO) put it best as early as 2006, when he said:
“You build it, you run it.
Werner Vogels, Amazon CTO
As your DevOps practice grows you will find manual alerting and monitoring tasks are often the bottlenecks that create the most frustrations and inefficiencies. Alerting and monitoring activities follow a linear growth trajectory alongside your building efforts and at some point they will become a burden on your team's time and your money.

If you like making data-driven decisions, then this fact should make this best-practice a no-brainer for you to implement:

9. Make data-driven decisions

You'll agree that this is one of the most abused buzz-phrases in the tech industry today. But, if this is not second nature to you then you need to take immediate steps to inculcate this into your personal and your team's decision-making process.

Unlike most other concepts you will read about this year, this is not a fad. Your organisation's performance could be explained by whether you make decisions based on data or pure instincts whims and fancies:

Transitioning to a data-driven decision making culture obviously requires accurate, consistent and timely data. Therefore, it becomes imperative that you and your team has access to relevant dashboards for every element of your DevOps practice. This should be a major consideration when you rationalise your technology stack.

Learn from the experts about how to transitioning to an evidence-based decision making culture.

10. Think, do, analyse, repeat

The way to get started is to quit talking and begin doing.
Walt Disney
Follow Mr Disney's advice and avoid the trap of safe and comfortable waterfall thinking. DevOps empowers you to embrace the fail fast motto. Why is this important? Because failure is the step before success.

This mindset is important if you are going to successfully implement the pattern of success I gave you above. The biggest mistake that I see even experienced professionals making during their transition to DevOps is the propensity to over-engineer their every decision and process.
Don’t worry about failure; you only have to be right once.
Drew Houston
Instead run smaller proof-of-value experiments and ingrain this culture of succeeding by failing fast into your team. This is the secret that helps successful leaders scale their outcomes.

Talk to one of our consultants if you need help supercharging your DevOps practice or book a Mastermind session to get your automated software testing and cybersecurity testing purring.

Or call us on +61 3 7001 1430 or +44 20 3411 4974 if you're in the UK, or email solutions[at]audacix.com

0 comments :

Post a Comment