Good Software Delivery on Andrew Khoury

How to implement Good Software Delivery in 30 seconds

Thu, 11 Nov 2021 19:22:11 +0000

Good Software Delivery (GSD) is the term we use for the set of practices that help deliver, well, good software. There’s a focus on short feedback loops, a consistent developer experience, with more time spent delivering and less time spent on chores like workstation setup and debug.

For context, I’ve previously written the following blogs that explain a lot of the “why” you’d want to implement the app I’m about to demo:

Assumptions

Before we dive in I want to share my assumptions and expectations. This blog/demo is aimed at developers, who are also familiar with pipelines, local development environments, and tools like docker.

While you can clone the repo and run the commands quickly (even with zero knowledge or experience in the underlying Golang app), it will take you longer than 30 seconds to read this blog, and even longer to look through the repo’s README.md and code in the repo to see what’s happening when you type each command. I’ve tried to add as much detail and context for those that’d like to deep dive, both in this blog and in the repo itself.

The purpose isn’t to copy and paste what you see here into production, but I do hope I’m able to demonstrate some ways of setting up your repo and local development environment in a way that could save you and your team time for your next product!

What we’ll do in this demo

In this post, I wanted to share a hands-on implementation of some of these concepts that you can try for yourself. We’ll be using a hello-world app written in Golang, and by the end of the demo I’m hoping:

You’ll see how wrapping our pipeline in 3 Musketeers can greatly reduce the amount of toil spent getting a new project started (thus the 30 seconds claim for this simple app)
You’ll see that you can adapt the concepts in this demo to just about any app (Java, .Net etc) — More complex apps may take longer to compile, but no extra effort should be required in terms of desktop setup (toil)
You’ll be able to extend the logic for other pipeline tasks like testing or security

If this demo takes you longer than 30 seconds to run this demo, I suspect:

We need to get you a better Internet connection (most of the 30 seconds for me is spent downloading the initial Golang image on an empty docker cache)
We need to help you with the base requirements that this blog assumes you already have (make,dockerand docker-compose)

In any case, reach out on LinkedIn if you have suggestions to improve this demo, or set up a virtual meeting with me if you’d like a 1:1 workshop/chat!

The demo (build and run a Go app in 30 seconds)

At a minimum, you’ll need _make_, _docker_ and _docker-compose_ on your workstation. See requirements for more info or continue on if you’ve already got these.

Not sure about running this demo on your computer? Never fear! You can use this online environment from the safety of your browser: GSD HelloWorld katacoda (repo will already be cloned in this environment, with required software ready to go)

You can see all of my Katacoda courses at https://www.katacoda.com/drewkhoury/.

Clone the repo: Start by cloning the GSD HelloWorld repo:

git clone git@github.com:contino/gsd-hello-world.git && cd gsd-hello-world

2. Build the app: Once you have the codebase, build the app using:

make build

This step will create a build artifact (in our case, a docker image) by doing the following:

downloads the appropriate docker image onto your workstation
copies the source for our app into the image
builds the application in the image
configures the port/cmd to be used at runtime

3. Run the app: Now that you have your build artifact handy, you can run the application locally with:

make run

This step will run/deploy the artifact on your workstation by doing the following:

uses docker to create a container based on the image from the build step
exposes port 8080 locally
the docker image runs the cmd ./main which starts the application for us

That’s it, you’re running the GSD HelloWorld application written in Golang and containerized so that it can quickly be deployed in Docker.

Bonus: You can run make test to execute the test suite (note this may legitimately fail if it doesn’t meet the testing threshold), andmake down to clean up once you’re done.

The beauty of this model is in its simplicity. We’re using make as the interface and we’re running all the tasks in containers to ensure consistency. It’s easy enough to peak under the hood to see what either of those tools is doing, and this runs just as easily on your workstation as it does on your CI tool of choice.

Digging into the code

To keep this section brief I’m going to assume some prior knowledge around development, docker, and make.

What if I want to make my own changes or do something similar in my own repo?

For the curious: Checkout the Makefile, docker-compose.yml and Dockerfile in the repo. These drive our pipeline and app build etc, and while they abstract the complexity away from day-to-day usage, they’re intended to be developer-friendly in terms of understanding exactly what each step is doing.

Building the app: For example make build is what builds our application, and in the Makefile you’ll see it does the following:

docker build -t ${FULL_TAG} .

Replacing the app: If you wanted to replace our Golang application with your own Java application, you’d drop in your own Dockerfile , replace the /src, and leave everything else as-is. The beauty is that any developer using the repo still runs make build and they don’t need to worry about Go vs Java dependencies (or in theory even know that you completely rewrote the application) — it just works™.

Note: This repo is a testing ground for GSD practices — simple but powerful ways to supercharge your development.

If you’d like to see what else you can do, have a look at the rest of the https://github.com/contino/gsd-hello-world — we have plenty for you to explore.

build, test and run actions are driven by a simple Makefile — with underlying execution via docker containers
Build badge in README.md
Repo Visualization in README.md
Sonar quality, reliability, and security badges in README.md
Golang security in-pipeline
Local tests via make test
Artifact storage via Github Packages
Github Actions
Deployment to k8s in GCP

Further reading:

May your software be good, and your delivery be continuous — drew

Info

Also posted on medium as How to implement Good Software Delivery in 30 seconds.

3 Musketeers for an epic Developer Experience

Sat, 28 Aug 2021 14:18:09 +0000

We all want to reduce toil and improve the developer experience (when starting new applications or joining the team). Developers have had to invest significant time in creating production-ready pipelines when building new products and configuring their workstations when joining teams. Their workstations may not run all the same tests as their pipeline and thus they’re left with #slowfeedback and an inconsistent experience.

The larger the organization (ie Enterprise with 10’s-100’s of teams and applications) the worse the problem gets.

GSD is built on the principle of reusability through a pattern called 3 Musketeers (test, build, and deploy your apps from anywhere, the same way). It gives consistency, control, and confidence to development teams.

Docker is a key part of this pattern, but the use of docker, docker-compose and make together really unlock the powers of consistency, control and confidence in your application build, test and deploy steps. The 3musketeers Docs have some great examples of these patterns.

Here's what the most simple usage looks like:

While the pattern itself is simple, the power (and benefit) comes from the widespread usage across your organization. Here’s what usage might look like:

Agree on a standard interface for all pipeline actions (much like API’s have an agreed interface, all pipelines in the org use the same interface, ie `make build`, `make test`, `make deploy`)
Keep the interface simple (avoid custom pipeline logic, one simple Makefile calls Compose, the container handles all the logic)
Create docker containers for each pipeline step, make them stateless, reuse them where it makes sense

Wins: Modern pipelines already support running steps in docker containers. This pattern extends portability across almost any pipeline tool or development workstation and runs the same way in every single environment. Pipeline steps can be tested independently and reused. This pattern makes it easy to go one step further and generate pipelines on-demand based on boilerplate starter templates. Oh yeah, and #fastfeedback (we’re talking pre-commit).

Info

Also posted on medium as 3 Musketeers for an epic Developer Experience.

Good Software Delivery — Trust and Verify

Tue, 24 Aug 2021 13:23:48 +0000

I’ve decided this week is Good Software Delivery week! #goodsoftwaredelivery

The concept of GSD is something I’ve implemented for clients in one form or another over the years, and you might have done something similar without knowing it.

I remember one particular collaboration with a small but amazing team. We helped implement a particular flavor of GSD and unlocked value for the business.

In this diagram, we’re showing that the “path to production” can be codified. By making the process transparent and available to developers, we can show them “what good looks like” on day one.

The last thing you want as a developer is to find yet another requirement before you can push to production, so using the “Trust and Verify” model helps development move fast. This pattern also removes any manual surprises when trying to deploy to production, thus getting software in the hands of your users quicker!

The “Trust and Verify” Pipeline Pattern is part of a wider effort of Transformation through Good Software Delivery.

Info

Also posted on medium as Good Software Delivery — Trust and Verify.

How Cloud Transformation at Scale can enable Good Software Delivery

Wed, 04 Aug 2021 22:50:33 +0000

Why should you transform?

Each person, team and organization is going to be on their own journey to cloud, writing good software and attempting to delight customers, or increase profitability. Finding your why can take some time and deep thinking (and deserves a whole blog to itself).

For now here are some common why’s for transformation and good software delivery that might also apply to you:

To enable product (development) teams to ship software with less dependencies on other teams/humans
To speed up delivery
Allow the business to scale products quickly
To build new products quickly
To support the business in getting fast feedback through frequent delivery
To achieve consistency in infrastructure and software deployment, so we can reduce the risk of issues due to manual changes
To reduce the manual but repeatable steps close to production (security and compliance checks) that often slow down or delay releases

A picture

If a picture tells a thousands words, then I present to you Cloud Transformation at Scale:

Cloud Landing Zone

In purple we have the “Cloud Landing Zone” which is the starting point for key cross-cutting concerns that span the entire organization:

Automated Account-Provisioning for shared Cloud Accounts
Account Guardrails
Security & Logging Accounts (SIEM & IAM)
Networking Foundations
Shared-Services Account

This is the foundation of most modernization efforts that depend on the Cloud. Automation of Accounts & Infrastructure unlocks the ability to “move fast” in a way that traditional on-prem data center or operation teams aren’t able to match.

Most organization on their cloud journey are building or buying some variation of this or started off with some manual steps and a few scripts, and are maturing their operations to look at lot like this as they scale.

Services for Developers

In red we have the next set of shared services focused on supporting product (and thus development) teams. This includes:

Automated Infrastructure-Provisioning for Shared Services (think shared k8s clusters)
Common Shared Services (build agents, artifact storage etc)
Self-Service Cloud Accounts for Product teams (self-service being the key)

It’s important that developers can manage their own accounts via a self-service mechanism (if you’re an organization with more than 10 developers). This means automated pipelines for infrastructure and account provisioning that have a well thought out developer-experience that make it easy for them to manage their own accounts, securely (ie with Account Guardrails built into the pipelines and Cloud Accounts), and sans human intervention.

Product Teams — Trust and Verify

In blue we have application and app-related infrastructure pipeline(s). Each commit should result in a single artifact built and tested then promoted into production if it passes the automated tests.

Developers should have access to reference pipelines that show exactly how to pass all the organizational, security and compliance requirements (which should all be automated within the pipeline). It should be easy to start a new project that can quickly pass through the pipeline into production.

Developers should have the freedom (and trust) to do whatever they need to do before they reach production. They should have access to every automated security and compliance check that will be run in production so they can quickly assess how ready they are for production on the very first commit.

The organization should automatically verify every production deployment with the same rules they supplied the developers on day-one, commit-one. No surprises, no extra work to do on production-day.

This seems like a simple concept, and the name I give it is “Good Software Delivery” because it’s simply how we all should be delivering the software we want to ship.

So how does one transform? In practice it’s a journey that individuals, teams and organizations need to be prepared to go down. And that’s a completely different rabbit hole I welcome you to explore: https://faun.pub/one-devops-please-part-1-df7a2787fde8

Appendix

We could go deeper into each area, but here’s a quick teaser that goes into more detail, in particular for the blue Product Team’s Pipeline(s):

Info

Also posted on medium as How Cloud Transformation at Scale can enable Good Software Delivery.

From DevOps to Good Software Delivery

Tue, 21 Jul 2020 19:18:39 +0000

Andrew Khoury & Ralph Bou Mechrek: Principal DevOps Engineers @ Contino.

Putting the Good in Good Software Delivery

With so much progress in "Agile, DevOps and Automation" writing Good Software in 2020 should be easy - so why are so many companies still struggling? Somewhere along the line we got lost, and never really appreciated the power of understanding business value, value streams and continuous improvement to unlock the true potential of development teams.

Info

Event on Meetup as From DevOps to Good Software Delivery.

Why Business Value eats DevOps for breakfast

Sat, 11 Jan 2020 22:18:26 +0000

It’s 2020 and my new years resolution is to keep a list of words that deserve to be on the naughty list:

DevOps
Agile
Requirements

It’s not that these words are inherently bad — but my industry has twisted, abused and polluted them leaving behind a trail of over-engineered solutions and misguided teams.

For an in-depth look at “how to do the DevOps” see my post One DevOps Please which talks about how to do transformation and discusses the unicorns that are “DevOps teams”.

First, a little warm up…

I’d like to interrupt this blog to do a warm up exercise. Sorry-not-sorry for anyone I’m about to offend.

Repeat after me:

I am not a DevOps Engineer

Let’s try another one:

I don’t belong to a DevOps team, because I only work with things that are real

One more:

Doing standups every day at 9am doesn’t make me agile

You say these every day along with burpees, planking or whatever your daily routine is. I promise you they’re good for your health.

Why — should I care?

You might have heard the following:

We’ve always done it this way

If “why” is the super hero of this story, then this phrase is the villain.

Like many youngsters I spent most of my childhood asking “why”. Ironically I’m sure my parents asked themselves “why” they had to have one more kid as I pestered them with endless questions about science, the universe, or whatever else was on my mind.

My questions didn’t stop at childhood. I’ve always had an obsessively curious mind and a determination to understand everything inside-out. I did it with helpdesk support, then when I stepped into development, and again when I learnt about cloud and automation.

Helpdesk me:

Why do clients always call with the same MSSQL replication errors

Developer me:

Why does my code work differently in production

“DevOps” me:

Why doesn’t this DevOps thing solve my client’s problems

An important part of what I do today is about helping foster the same kind of curiosity in others, and helping hone in the skills to make the best use of that curiousity.

Examples of times you should ask — Why

Hint: If you’re not sure — always ask why.

You’ve been invited to a meeting, with no description or context, and no idea what the outcome is.

You’re creating a presentation as a team but you haven’t agreed on the audience, the intention or the outcome.

You’ve been told to create a kubernetes cluster.

You’ve been told stand-ups happen at 9am (and they happen to go for 45 minutes, nobody seems to have an understand of what to do for the rest of the day even after the meeting).

You’ve been asked to join a new project, team or a recruiter has told you they think you’re “perfect for Job X”.

Your company has decided they’re moving to the Cloud.

Why we ask why

Okay so that heading was very meta. The intention isn’t to challenge or be confrontational. It’s not a power play or a fun party trick.

Asking why is about having a shared understanding.

In each of the previous scenarios and indeed in many interactions there’s always an underlying intention. Sometimes it’s just about communicating with each other to gain that shared understanding.

Warning: Here be dragons. Sometimes (e.g when people aren’t sure why) asking them can lead to defensiveness and well, make them angry. Other’s don’t like being interrupted or challenged. Some people have values and principals that favor hierarchy over creativity and innovation. Asking why isn’t always a happy path to making friends.

What does all this have to do with Business Value?

Business Value should be well known and clearly articulated in every team of your organization. Everyone should know the why (and how what they’re doing ties back to a very specific business value). Your business should have a way to measure the business value (so you know when you’re done). Everyone should be contributing to the business value metrics, and collaborating to get it done together.

Assuming you’ve done the hard work of figuring out what your business is trying to do (you understand the business value and have some metrics to measure against) the next part can be fun and rewarding!

Why haven’t you talked about DevOps yet?

Let’s assume (like many companies today) you “develop software as part of an effort to provide products & features, to give you a competitive advantage”.

Where I think “DevOps” has failed us is the misconception that it’s “half dev” and “half ops” and that problem lies in the very core of DevOps — It’s name! But in reality without software there’s nothing for “Ops” to do.

Customer leads to Business Value leads to Software. How we build, test, deploy and operate our software is important but we can’t call it DevTestSecQADeployOps so let’s just call it Good Software Delivery Practices.

Good Software Delivery Practices

You’ll likely want to incorporate automation and optimizations that allow you to “produce working (aka releasable) software every sprint” and reduce manual steps in favor of automated ones where rework is likely to occur.

You’ll want to “drive value through the system” and this usually translates into working on new products and features that benefit your customer (hopefully identified by your product team’s close relationship with it’s customers).

Your product/development team might also decide to operate in some flavor of “you build it, you run it” team which encourages them to build good quality software with resilience and alerting that’s actually helpful.

If I know I’m going to be woken up at 3am when things go wrong it’s going to fundamentally affect my choices when designing and operating my software (hint: for the better).

Ultimately when you combine “Business Value” with “Good Software Delivery Practices” every choice you make has clarity. You know “why” you’re doing something and you can trace it back to a specific metric that has a positive impact on your business (and by that I mean improving the lives of your customers in some way).

So when you go to that next meeting, or pickup your next Jira ticket from the “todo” column ask yourself:

Do I know why am I doing this?

Info

Also posted on medium as Business Value eats DevOps for breakfast.

One DevOps Please — Part 2

Sat, 23 Nov 2019 20:09:40 +0000

“One DevOps Please” — Part 1 recap:

DevOps is part of a learning journey for people
We can categorize how people learn in 4 Stages
The hardest part of the learning process can be a willingness to learn
Companies don’t transform just because we teach a handful of people in isolation (BottomUp)

Organizational Transformation — The path to “DevOps”

DevOps is an overloaded term these days. A DevOps journey might touch on agile, lean, learning, metrics, business value, pipelines, CI/CD, shifting left, 12 factor apps, Cloud, serverless and kubernetes. It can be exhausting! Why is DevOps so vague and buzzwordy? Because DevOps covers the people, process and technology aspects of modern software development. Let’s expand on our original definition from Part 1:

“DevOps is a culture shift or a movement that encourages great communication and collaboration to foster building better-quality software more quickly with more reliability.” — Mike Kavis

But what does transformation look like for an entire company? While teaching somebody how to master automated pipelines could take a few weeks or months, it could take years to see changes that span the entire company. This is because companies are made up of people — each with their own contribution to it’s culture.

Let’s go on the same learning journey we did for people but through the lens of the entire company this time around. We’re going to leverage tried and trusted models from https://web.devopstopologies.com/ to take you on this journey because they’re such a good representation of what we see in the real world.

Stage One — Everything is okay

We start off much the same way we did with the people side of things. The company is operating in Silos like “Dev” and “Ops” and thinking:

“Everything is fine the way it is”

Stage Two — Automate all the things

“Let’s do something and call it DevOps.”

In the next stage the organization recognizes they need to change so they “try to do DevOps”. This is where we typically see a few anti-patterns form as people try to find the sweet spot for their new team structures and ways of working — this is also more common than you might think. We often spend a lot of time with clients at this stage and it’s by far where the hardest work gets done.

So let’s explore the swinging pendulum of DevOps Anti-Patterns and appreciate how easy it is to get things wrong — even with the best of intentions.

Anti-pattern 1 — The DevOps Silo: This happens when you create a “DevOps” or “Platform” team that’s separate from your development teams or cross-functional teams. You’ll write some great automation scripts but transformation doesn’t happen here.

Anti-pattern 2 — NoOps: While this doesn’t seem like a terrible idea at face value, downplaying the importance of operations within software development can lead to poor choices that wake you up at 3am.

Anti-pattern 3 — AllOps: Isolating developers is not going to lead to better software delivery, and most definitely won’t lead to transformation in your organization (unless you really need to spend 80% of your time building that wondering k8s cluster).

So at this point you’ve tried a few different changes and had varying success. Hopefully you’ve seen some improvements along the way and you’re ready to take your organization to the next stage.

Stage Three — Transformation

Why don’t we try the “You build it, you run it” model. Now we’re talking!

Operations: Responsible for providing and operating the platform

Developers: Responsible for operating their applications, which are built on top of the enterprise guard rails.

This is where we usually start to see“shifting left” in terms of QA and Security — and that’s a win for everybody.

Here are some key indicators that your organization is maturing in it’s DevOps transformation journey:

Improved collaboration across departments
Value stream mapping exercises are performed to drive process improvement
A learning organization takes shape
Blameless post mortems
Gamedays
Lean principles are embraced — Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build integrity in, Optimize the whole

Stage Four — The pursuit of Continuous Improvement

Hopefully by now you’ve realized there’s no perfect Venn diagram to determine the success of your organization. There are however some key indicators you can look at for.

Building on the success from true DevOps transformation in Stage Three you should now be capable of deploying multiple times a day with increased certainty and minimal risk. This means more automated tests and better quality code. Removing bottlenecks should second nature and everything should start shifting left.

What we should see now are these new ways of thinking spreading throughout the entire organization, no longer a “DevOps” thing for the I.T department — continuous improvement is happening in all parts of the business. Instead of teams building up towers of influence to protect their corner of the organization people are working together toward a common goal.

The recipe for successful transformation

So far we’ve focused on “how we learn” and touched on “DevOps” but we haven’t really gone into practical advice for how to transform a company. Offering up a personalized plan in a blog post would be foolish but I can definitly set you off on the right path. If you’re a leader trying to kick-start your own company transformation there are some lessons others have learned that will save you years of banging your head against the wall.

Top-Down is half the recipe — Your company needs to hear the right things from the leadership group, and people/teams/departments also need to be held accountable if they’re not supporting the target-state laid out in the vision by leadership group (actions always speak louder than words).
You guessed it Bottom-Up is the second half — Teams on the ground need to be bought-in on the vision and willing to execute. We’re talking about completely changing people’s working lives and the way they think. Start with teams most willing to change, prove what works in small but significant teams and products, and use them as a lighthouse for the rest of the teams.
Find change-agents/champions — These are people within your organization that are not only willing to change, they’re ready to shout it from the rooftops and inspire those around them.
Don’t just hire contractors — find genuine transformation partners and learn absolutely everything you can from them.

Homework for transformation leaders: Take a deep-dive into how Microsoft, GE and Amazon went on their own transformation journeys (and explore what went well, and what they could have improved).

Transformation Partners needs it’s own section…

I can come in and build you a shiny new k8s cluster, maybe I could take 4 of the brightest developers I know and churn out our own applications faster than most of your existing teams, or embed in your teams and give you a report showing how we increased development by 320%. But if everything goes back to how it was after I leave — you’ve made 0% progress towards transformation (also please stop building k8s clusters because it’s cool — focus on if each of your teams can succinctly explain who their customer is, how they obtain feedback in the shortest loop possible and what business value they’re delivering in each two-week period).

So what does a transformation partner look like (and am I about to sell you my services?). The only two things I need to tell you about the company I work for is “we charge reassuringly high rates” and we “fall in love with our customer”.

If you can hire the right people to inspire, lead and transform your organization please do that. I assure you I’ll still find a way to put food on the table.
If you want a power-boost, a consultancy that’s focused on transformation filled with people who’ve done it before should definitely be on your list — Pair them up with your change agents and the willing development teams in your organization, and watch your growth sky rocket (but be prepared to do to work).

Hiring a consultancy for transformation and asking them to do all the work is like hiring a personal trainer, making them do all of your situps, then wondering why they look great but you still haven’t ‘transformed” — Andrew Khoury

Not keen on a consultancy and feel like you’re company only needs a small nudge in the right direction? Sounds like you want to head-hunt a few key people (when you do that make sure they’re empowered to make the changes you want them to make) and have some key mentors by your side to bounce ideas off and keep you honest.

Summary

Many organizations try to replicate the success of others “doing DevOps” by hiring DevOps consultants or building DevOps teams but they often miss the mark in doing so — the journey is more important than the destination. Let’s recap what we learnt on this journey together:

How people learn: We explored how people learn and why it’s important to take the time to bring them along the journey. Trust and empathy are key here.

Learning from your trusted partners: We touched on how valuable it is to have a trusted partner in your corner, with a focus on drawing from their experience and maximizing how much you learn from them. This allows for new ways of thinking to take hold in your organization which ignites the transformation process.

Organizational transformation: We broke down transformation into four key stages:

Everything is fine the way it is
Automation — but not much direction (this is the hardest stage and where we learn what doesn’t work)
Actual transformation (this is where the hard work pays off — We see Improved collaboration, Value stream mapping, a learning organization, Blameless post mortems, Gamedays, Lean principles)
The pursuit of Continuous Improvement (this is where we refine what’s already working)

Approach transformation with a plan — That means Top-Down & Bottom-Up, identifying and empower your change-agents, holding people accountable for transformation and positive behaviors. Don’t forget to find those willing development teams who are ready to transform into cross-functional product teams with with a healthy obsession for their customers & continuous learning and improvement.

Info

Also posted on medium as One DevOps Please — Part 2.

One DevOps Please — Part 1

Wed, 16 Oct 2019 05:57:48 +0000

One DevOps Please — An Enterprise Journey to a DevOpsy-Cloud

“I’ll have one DevOps please.”

Over the last few years large organizations have been coming to consultants like myself to ask for help “Installing DevOps” into their organization. Some of them just want kubernetes clusters, while others are talking about true transformation.

In this two-part blog I want to take you on a DevOps transformation journey. I’m going to share with you my recipe for success and give you all the secrets to unlocking true business value through people and organizational change with a culture of learning at their core.

Because everyone’s definition of “DevOps” can be slightly different, I’m going to set the scene with a simple definition:

“DevOps is really about eliminating (most) Technical, Process and Cultural barriers to between Idea and Execution — using Software.” — Kishore Jalleda

My DevOps Journey

Before we get stuck into how people and companies transform the way they work, let me start by sharing the journey I took to get here and how it’s shaped my ways of thinking.

I started my career by learning. I strived for technical excellence and perfection through delivery. I poured my heart and soul into my craft which started out as web development but quickly grew into cloud and automation.

One thing I realized was that I loved teaching people new things. What took longer to learn was how impactful learning and transformation could be to both teams and companies.

Nowadays my value comes from enabling my teams and coaching my clients. Our team’s success depends on my ability to foster the right skills, remove the noise/blockers and leveraging my previous experience to set us up for success.

How People Learn

I mentioned earlier that some organizations want to “Install the DevOps”. Astute readers will know that DevOps isn’t a piece of software and so hiring consultants to “Do the DevOps for you” won’t give you long term results. The aim for your organization should be to empower your people by giving them opportunities to learn and grow (hint: that’s where the transformation happens).

So how does learning happen? Can you just send your employees on DevOps training and have them come back 1 week later ready to tackle the world’s problems? Unfortunately it’s not that easy, and here’s why. Learning typically follows the following 4 stages:

Step 1: I don’t need to learn . I’m fine just the way I am.
Step 2: I need to learn — can you help me?
Step 3: I know a little about now. I can start to contribute with some help and guidance, thanks!
Step 4: I know now. I can contribute on my own, and I can teach others too now

This model is known as The Four Stages of Competence and it’s a critical part of any “DevOps/Transformation” journey. If you don’t understand how to take people from step one to step two all your efforts will fall on deaf ears. There’s also something called the Dunning Kruger effect — a cognitive bias in which people mistakenly assess their cognitive ability as greater than it is. Psychology can really work against us!

Now we know that unlocking the very best from your employees involves taking them on a learning journey, and unlocking the mind (steps 1–2).

The exciting part of the journey (Steps 2–4) involves knowledge transfer, which I’ll touch on briefly. Something I’m really proud of about Contino is how we help people on their personal journey through the dual-delivery model. This might sound fancy, but it’s just leveraging practical experience to pair-program with people. We also tend to spend plenty of time at the whiteboard teaching, but most importantly we establish trust and show empathy by working along side our clients and having shared goals.

Getting from Step 1 to Step 2

One of the hardest parts of transformation is getting past the very first step — so it deserves it’s own section.

Getting people to recognize that they need to learn something is the first hurdle. Getting them to be vulnerable in the workplace and admit that they need help is often the second one.

Getting individuals to open up and trust you can take time. My job as a consultant is to deliver, but also to fall in love with my customer. I’m not talking about butterflies in my stomach, I’m talking about caring about my team’s success and how happy they are each day. I’m lucky enough to love what I do and have the opportunity to work with teams I genuinely care about.

But sometimes there are other factors at play and empathy alone isn’t enough. It helps to have a trusted partner along with your for the ride, and the key is to get the most value out of them by leveraging their skills and experience to maximize your learning. Let’s have a look at common pitfalls that may hamper learning with your consulting partner:

Hiring a consultancy and having them do all the work (no learning)
Hiring a consultancy and telling them what to do (staff augmentation)
Your team is “too busy” or you aren’t able to grow/hire within your team (you can’t learn if you’re not present)

Person vs Organizational Transformation

So can we transform a company one person or team at a time?

Well, sort of. It’s often easy to find inspired people in an organization who can be your champions. Investing your own time in someone can be very rewarding and the results can be seen relatively quickly within your teams or sphere of influence. The other benefit is that investing in people (or your team) doesn’t usually require CEO sign-off.

While helping people learn new skills and ways of thinking is a great starting point you won’t be able to achieve large scale transformation without a well thought-out (and properly executed) strategy for your organization. You’ll also need buy-in from your leadership.

So how do we achieve organizational transformation, what does it look like and what are the pitfalls? Find out in One DevOps Please — Part 2 where we’ll deep dive into what it looks like to transformation a company (ie Installing DevOps company-wide).

Info

Also posted on medium as One DevOps Please — Part 1.