Lets learn tech skills with storytelling

Reading time ~ 5 min.

What’s Inside ?

• DevOps with a story - Part 2

• Interesting “thing” of the week

I would first like to thank all of you for the overwhelming response to the first post of this series. This indicates people want to learn and like it when the means is interactive.

Lets get into second part today.

Recap

If you haven’t read the first part, here is the Link to part 1.

Here is the Summary

• Bruce joins Hard Pixels.

• Hard pixels comprises of 2 sub teams - Hard Coders, Dead Breakers.

• Hard pixels work on the software Elixir, which is used by the town of Gotham

• Bruce is given the task to understand Elixir

• Bruce finds problems in the setup, he decides to bring them to notice but is not accepted by either of the teams.

• Instead, Harry, the manager then explains the unwritten rules of running Hard pixel to Bruce.

• Bruce is perplexed, he decides he has to change things with his new Idea.

Story commences

Bruce comes to office, it is business as usual. Hard coders are busy writing and pushing code, dead breakers are busy building the Elixir.

After the meeting with Harry and others, Bruce is given one more week, This time to understand the hard coders way of working specifically.

Bruce knows it is hard to push his Idea, so he focusses on processes.

He has a plan. it is to highlight each listed problem and provide a solution for each.

This helps teams understand the problem with context.

He begins his plan.

One of the most popular way to understanding Devops is using the CAMS model. Bruce applies this.

CAMS Stands for

1. Culture

2. Automation

3. Measurement

4. Sharing

Lets see how each solution contributes to CAMS.

Problem 1: Conflicting roles and responsibilities

In Devops world, team members work together on end to end software development and there is no conflict.

Currently, When Hard coders focus on speed and Dead breakers focus on stability, both are going in opposite direction. This leads to conflict in day to day decisions.

Hard coders want more changes to reach Gotham (Speed) but Dead breakers want less changes to maintain stability of Elixir (Stability)

This cannot work.

Instead, there should be a single team responsible for the overall software system - End to End, Right from development till the delivery to Dev - Gotham Engineer.

When single team plans the entire end to end software work , they work better. Developers(Hard Coders) understand the pain to keep the system stable and Operations(Dead Breakers) understand the importance of time to market and customer expectations.

This is the culture aspect of CAMS Model.

Problem 2: Little/no communication between sub teams

In Devops world, sharing information within (and outside teams) is sacrosanct.

There is an huge information wall between dead breakers and hard coders. Hardly both team know what happens on the other side.

There are numerous problems with this. Team members not having a common understanding of the software product being the significant one.

When each team has a different understanding of the same system, the results aren’t effective.

The solution is to freely share all the information between each team member - the ones relevant to the Elixir.

Working on same set of software practices, following the same set of processes, makes things much streamlined.

This is the Sharing aspect of CAMS Model