DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Databases
  4. Keep CALMS and DevOps: S Is for Sharing

Keep CALMS and DevOps: S Is for Sharing

You might be surprised at how incorporating the simple act of sharing can elevate your DevOps implementation.

David Mckenna user avatar by
David Mckenna
·
Mar. 13, 19 · Opinion
Like (5)
Save
Tweet
Share
8.02K Views

Join the DZone community and get the full member experience.

Join For Free

One day, my son came home from kindergarten and was waxing lyrically about: “Sharing is caring.” A simple phrase taught to a child to help them to understand that sharing provides a benefit. I realize that there is a pattern developing here with my use of children’s sayings to convey a point about DevOps, but perhaps that is because these sayings are basic truths. “Measure twice, cut once”, “Sharing is Caring”: the messages are so basic, yet we often don’t follow the wisdom of these simple truths.

Source: The Peanuts Movie

So, if to share is to care, then the opposite must hold true, namely, not sharing means not caring! This might seem harsh, but if we ever find our inner monologue saying, “That’s not my problem” or, “Let them figure it out,” then we are harming ourselves in the long run, because it’s harmful to the success of our company. We can show that we care about our organization by simply sharing. We need to share more and more. Here are some examples of where we could show we care more by sharing:

  • If you ever leave the building (“Get Out of the Building”) to visit a customer, prospect, analyst, conference, then you have an obligation to share your findings with everyone.
  • If you investigate a new technology, then share your findings.
  • If you answer a support query, don’t just provide the answer, go further and explain how you came to your conclusion – “give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime”.
  • If we win or lose an account, then we should be able to share findings with the organization, so that continuous improvement actions could take place to improve either people, product, or process.

We should share experiences, successful or not, to enable others to learn. Keep in mind, sharing works both ways; we must take an active interest in learning, we must seek to learn. If we ignore what is being shared, then we are just as guilty of not sharing.

We should be cognizant of our culture and know that most of our sharing will naturally be at our local watercooler. We need to come up with more global watering holes, so that we can share. We must adopt a common practice of sharing knowledge globally to build a stronger more competitive organization.

It boils down to learning and improvement: turning local knowledge and discoveries (what a single person knows) into global knowledge and discoveries (what your entire team or organization knows). We must continuously improve and learn.

Every team needs a convenient way to organize and discuss their work. Suitable team collaboration software is a big help when you need to create a knowledge base, share files, plan projects, collaborate on tasks, store and distribute documentation. Your organization could have a lot of disparate collaboration tools which may be impeding the flow or access to information within the organization. Regardless of the state of your collaboration tools everyone should know where to go and for what i.e.

  • Office 365: use this for writing and collaborating on documents and presentations
  • Confluence: good as system of record (i.e., final design/architecture, epic details)
  • Slack\MS Teams: good for chat and video. Greater adoption and usage required to get to “ChatOps” level.
  • JIRA: issue tracking/backlog management. System of record for all work being carried out by a team; critical to the delivery

As we’ve previously identified, to err is human and stuff happens. When something goes wrong, getting to the "what" without worrying about the "who" is critical for understanding failures and improving. We need to trust our team members in that nobody knowingly would make a deliberate mistake. If they did intentionally make a mistake, then that would be sabotage and their next conversation needs to be with HR. We must accept that failure happens, systems are complex and humans make mistakes. Enter the blameless post mortem, this subject is worthy of a blog entry on its own, or read this excellent post from Etsy.

"The cost of failure is education." – Devin Carraway

The individuals involved in a post mortem must feel that they can give this detailed account without fear of punishment or retribution. No finger pointing! Writing a post mortem is not a punishment – it is a learning opportunity for the entire company.

We should adopt the retrospective prime directive:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. At the end of a project everyone knows so much more. Naturally, we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass,” writes Norm Kerth in Project Retrospectives: A Handbook for Team Review.


Database DevOps System of record

Published at DZone with permission of David Mckenna, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Deploying Java Serverless Functions as AWS Lambda
  • Better Performance and Security by Monitoring Logs, Metrics, and More
  • Bye Bye, Regular Dev [Comic]
  • Real-Time Stream Processing With Hazelcast and StreamNative

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: