Core Ideas
Hello and welcome to Small Batches. I’m your host Adam Hawkins. In each episode, I share a small batch of software delivery education aiming to help you find flow, feedback, and learning in your daily work. Topics include DevOps, lean, continuous delivery, and conversations with industry leaders. Now, let’s begin today’s episode.
My self-study began with a question: “Where does DevOps come from?” I read anything relevant, pulling each thread, to try to find the origin. That terminated with Deming, which I covered in the previous episode.
But, how do we get from Deming’s System of Profound Knowledge to what we think of today as “DevOps” or “Software Delivery”? Well, we need nine ideas.
Four come from The High-Velocity Edge and the other five come from The Fifth Discipline. While there is overlap between them, I think they’re distinct enough to create a conceptual foundation for deriving DevOps.
The first idea is mental models. Mental models are deeply ingrained assumptions, generalizations, or even pictures or images that influence how we understand the world and how act.
The aim is make the mental models explicit, then align everyone with them. Here’s an example.
My mental model for this episode is that we can model an abstract idea like “DevOps” as a bunch of interconnected ideas. This will create a deeper understanding of each idea and related practices.
If that wasn’t explicit, then it is now. I hope that reinforces what I’m doing with this episode.
The second idea is system and design and operation. The premise is simple: design systems that surface problems, then stop on them.
This idea yields related ideas like jidoka, which the ability to automatically stop when problems are detected, and pull-based work systems like kanban. Both promote the flow of work and surface problems to participants.
A helpful way to model this is with the saying: “don’t let defects leave your station”. This implies that there’s a way to detect defects, thus the ability to surface problems, and to halt when detected.
Project this concept onto software development to create practices like continuous delivery, trunk-based-development, and continuous verification driven by SLOs. Each is vital to DevOps.
The third idea is problem-solving. Again, the premise is simple: swarm and solve problems as close to the source as possible.
Over time, this creates higher-quality systems with fewer problems. There’s no magic here, just a commitment to the scientific process and disciplined problem-solving.
Project this concept onto software development and you’ll find 24x7 automated monitoring, andon coords, mob programming, hypothesis-driven product development, automated testing, and bunch of other practices.
The second idea creates the flow. The third idea creates the feedback for continuous learning and improvement.
However, improvement requires intrinsic motivation. This is the fourth idea: personal mastery.
Individuals have their own dreams and desires. Those that seek personal mastery will strive for excellence. That drive will push them to keep learning and improving. The individual cannot be forced. Their actions must be voluntary.
I think you already understand this. You’re listening to this podcast because you want to learn, you want to improve. You’ll put in the extra work and seek to collaborate with other like minded people.
Project this concept into DevOps which replaces silos with cross functional collaboration. Developers must want to learn and improve their operations expertise. The same goes the other way. Operation engineers must want to learn and improve their capabilities in software development.
Personal mastery works well for individuals but doesn’t scale well to teams. For that we need the fifth idea: shared vision.
Shared vision is the bigger and brighter future that pulls people in. It provides everyone a target to aim for. It’s a way to focus each individual’s intrinsic motivation and desire for success.
DevOps does this by providing a clear vision of success for people to aim for. This is why The DevOps Handbook is important. It’s a rallying cry for transforming organization.
The vision is three parts: Create fast flow to production, collect feedback at all stages of the value stream, and continually improve those activities. It includes a set of ideas and practices that everyone can orientate around.
So far I’ve introduced five of the nine ideas. I’m going to bundle three related ideas into one. The three are: “Team Learning”, “Knowledge Sharing”, and “Developing Others”. Let’s call these three “Mutual Development”.
The premise here is that voluntary collaboration as a way of mutual development of everyone involved.
Consider the simple act of writing docs. Writing docs for others is a way to share knowledge and practice your own skills as author.
Consider pair programming. It’s a way to develop the skills of each person in pair, transfer knowledge about the system, and pick up the amazing workflow bits from other people.
Consider the student-teacher relationship. The student shows the teacher how to teach, and the teacher shows the student how to learn.
There’s always mutual development if you seek it out.
The other side of mutual development is developing these specific ideas in others, so they’re better equipped to develop others.
The ninth and final idea is systems thinking. The premise is simple: think holistically about interconnections between everything; aim for the benefit of the system, not individual components.
Here’s an example. Consider the overly helpful senior engineer who’s always quick to patch other engineer’s PRs. This may seem beneficial because PRs are patched and the senior engineer derives satisfaction from a job well done. This is component-level thinking. Systems thinking tells a different story.
In this case, the system of engineers is consistently producing PRs that must be patched. The senior engineer is papering over the defect in the system that removes a learning opportunity from other developers. Moreover, it removes an opportunity to change the system to produce PRs without defects.
DevOps advises us to see the entire value stream and optimize for flow across the value stream to the customer; not for individual departments or teams.
This is systems thinking. Systems thinking ties all the other ideas together.
Here’s a recap of the nine ideas:
1. Mental Models
2. System Design & Operation
3. Problem Solving
4. Personal Mastery
5. Shared Vision
6. Team Learning
7. Knowledge Sharing
8. Developing Others
9. Systems Thinking
Alright, that’s all for this episode. Go to SmallBatches.fm/85 for related software delivery education and links to support the show.
Anyways, I hope to have you back again for the next episode. Until then, happy shipping!
Creators and Guests
