Category Archives: DevOps

The Third Way of DevOps: Stacking the Cards in Your Favor

No Comments 41 Views0

This post was written for DevOps.com

In the first bit to this  post, “The Third Way of DevOps – From Knowing to Being,” we shared our thoughts on effectively applying knowledge to put the Three Ways of DevOps into practice. This blog explores a complementary dimension: How to build confidence when faced with a seemingly impossible task.

This is the all-too-familiar setting. You’ve seen an opportunity to improve things and genuinely want to do something about it. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers, who are oblivious of or indifferent or hostile to your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. In short, you don’t take action on what you have learned and know.

Self-efficacy

Expressed in the somewhat abstract language of the theories of Planned Behavior and Reasoned Action, there’s a gap between behavioral intention and actual behavior. A plausible explanation for the gap is low self-efficacy, defined as the conviction that one can successfully execute the behavior required to produce desired outcomes. It’s the belief we have in our own abilities, specifically our ability to meet the challenges ahead of us and complete a task successfully. This is a crucial precondition because investigations have shown that peoples’ behavior is strongly influenced by their confidence in their ability to execute that behavior.

If-Then-Else

So why doubt your ability to change? Well, when a change seems large, the gut reaction is to feel the need to come up with a project plan. Because a plan creates the confidence that when the steps are taken, the desired results will be achieved. Without a plan, we’d be irresponsible risk-takers. That’s how we’ve been taught to think. And rightly so—at least, in a predictable environment, where you can determine which steps will have which effects. If you work with IT, you are likely to think in terms of If-Then-Else. This is how we would like to believe IT always works. Predictably.

If-Then-Maybe

However—and this might be the biggest “however” you’ve come across for a while—things are not always predictable. Not unpredictable in the sense that it should have worked but something just went wrong because we didn’t do enough homework; unpredictable as in simply unknowable. Unpredictable as in possibly seeing a pattern of behavior in hindsight, but never having been able to predict it, let alone control it. Unpredictable as in “complex adaptive systems,” as they are referred to in the world of complexity thinking. It’s no longer If-Then-Else; the name of the game is If-Then-Maybe.

Complexity Thinking 

Complex adaptive systems are all around us but if you’ve been used to thinking that things are—or could or should be—predictable, you tend not to see them for what they are: one of kinds of systems that exist in nature. The Cynefin sense-making framework describes systems in terms of five domains: obvious, complicated, complex, chaotic and disorder. Obvious and complicated are both predictable domains, where something in the complicated domain needs a bit of work to discover the predictability than when it is obvious. Complex and chaotic are unpredictable domains, the main difference being that something chaotic is dangerously unpredictable and therefore needs direct action. There is a fifth domain: disorder. You are in this domain when you don’t know which of the other four domains best describes the current situation. A word of warning: People’s cognitive bias will often lead them to think that they are in their usual domain, in which they feel most comfortable.

Step by Step 

The way to introduce changes in complex systems successfully is to take it step by step. Because you can’t predict the results of a step, you have to closely monitor what effects—both desired and less so—each step creates. Then, based on your assessment of the new situation, you determine which next step to take. Rather than moving in a straight line toward a “to be” end state, you move each step to the “adjacent possible.” You make good use of the disposition of the system; in other words, where the energy is tending to flow.

No Big Answers, Just Little Questions

So, it’s not a case of looking for the big answer. It’s about a series of small questions. The Toyota Kata approach recommends asking ourselves (and others) these questions:

  • What are we trying to achieve?
  • Where are we now?
  • What obstacle is now in our way?
  • What’s our next step, and what do we expect?
  • When can we see what we’ve learned from taking that step?

A key concept is that we should work towards the next “target condition.” This is an interim goal on the way to whatever we want to achieve. It just describes where you want to be next, not how to get there. It labels the future set of circumstances that lie just beyond our current level of understanding. It will typically have to be achieved between a relatively short period between a week and a few months; otherwise, it will be ineffective. How we will get there will emerge though the process of experimentation.

Stack the Cards in Your Favor 

So the next time you feel inspired to make a (little) difference, don’t be discouraged by the prospect of having to think everything through in detail. This is often even contra-productive. The liberating realization that you can take things step by step, is good for your self-efficacy, increasing the chances of actually achieving results.

This article was co-authored by Mark Smalley.

The Third Way of DevOps: From Knowing to Being

No Comments 37 Views0

This post was written for DevOps.com

Why is the Third Way of DevOps so difficult to master?

We all know the feeling. You’ve seen an opportunity to improve things and genuinely want to do something about is. But you soon feel the clarity and anticipation draining out of you. First there’s the pressure of the day job. Then there’s the inertia of your co-workers who are oblivious of, or indifferent or hostile to, your ideas. And finally, as if these concerns weren’t enough, you’re faced with the difficulty of unlearning old habits and developing new ones. You wonder why you bother. In a way, it’s a bit like a lottery: You buy a ticket fully knowing that the odds are stacked against you, but it’s the worth it for the uplifting short and illusory dream that it might just happen.

This is, of course, all about the Third Way of DevOps—creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure, and the understanding that repetition and practice are the prerequisites of mastery. It all sounds great in theory, but why is it so difficult to put into practice?

Information Abundance  

It’s not due to lack of knowledge and skills. We have more information available to us and more easily accessible than ever in the history of our planet. We can thank technology for that. But has it really made us more effective at what we do? If I know something and don’t apply it, how is that so different than not knowing it at all? If I know how to read but choose not to, how is that so different that not knowing how to read? If I don’t use what I know, how long will I retain it and how will I integrate it with the other things I know? Most importantly, can and will I apply what I have learned to make things better?

Lifelong Learning 

We have been learning and studying all our lives in an attempt to make things better: our ability to understand IT, frameworks, methodologies, capabilities, practices, work processes and, of course, tools. Consider how many thousands of hours you invested in school, self-study, read out of curiosity, listen to podcasts and do work-related training and certification. Most of my friends proudly describe themselves as “lifelong learners” and one claims the day they stop learning shall be the day they die!

Training in Skills

We’ve also invested considerable time and effort into improving ourselves so that we may work more effectively with others: communication skills, teamwork, shared rituals, structured problem-solving, leadership and coaching all fit into this category. Who (in IT) has not been a part of some Service Management, Lean, Agile, Scrum, Kanban or DevOps training? After all of our training, you’d think we’d be further along than where we find ourselves.

Knowing and Understanding 

Knowing and understanding are not the same thing—I can know the Four P’s of IT Service Management (People, Process, Products and Partners), yet not view it as a lifecycle model and understand that to obtain the benefits of this knowledge, my team must determine the roles of people and objective of work of processes and then implement tools to automate the processes enabling people’s roles and tasks.

Understanding and Doing

Nor are understanding and doing the same thing—I can know that structured problem solving is based on the scientific method and can be broken down into four stages (Plan, Do, Check, Adjust). I may also understand that structured problem-solving is preferable to the reactive educated guesswork my team engages in whenever it encounters a problem. But if we do not change our behavior when it comes to problem-solving, our understanding will not manifest as action.

Doing and Being 

Neither are doing and being the same thing—I can be doing something and still not have internalized it so that it becomes who I am. I can know the core principles DevOps (engage in systems thinking, amplify feedback loops, foster a culture of experimentation and learning). I may understand that all three principles must be applied to foster a sustaining DevOps environment. I may be even be holding initial planning sessions with my team during which we map out the DevOps value stream, identify bottlenecks, create feedback loops and introduce changes to create a create a culture of experimentation and learning.

Moment of Truth 

But what happens when we meet with our next P1 incident? Does the knowing, new understanding and behaviors get tossed aside while we fix the problem, or do we hold fast to the new way of doing things as we grapple to not only remediate the incident but to view it within the context of DevOps?

So, What’s a Person To Do?

The velocity and degree to which we can move from knowing to being determines how effectively we can apply what we know. Here are a few things you can do to smooth the transition from knowing to being and help put the Three Ways of DevOps into practice:

  1. See and feel the potential impact from moving beyond knowing to being
  2. Use the uplift to get motivated
  3. Take action by changing something within you and your team’s circle of control
  4. Reflect on the fact that you have realized potential (this is very powerful when you share it with your team)
  5. Check and adjust based on the outcomes of step #3
  6. Allow the feedback from the previous step to motivate you to carry on!

Curiosity and Humility

This approach requires a certain attitude. One of curiosity and humility. You need to be inquisitive so you keep striving to understand. And you also need to be unassuming and you see yourself as having plenty of room to learn and grow; being deeply (almost obsessively) interested in what’s going on and how things could be improved; trying to be aware of and to set aside any preconceived ideas—adopting a beginner’s mind.

To Be Continued …

In our next post, we’ll explore specific steps you can take to leverage The Third Way of DevOps and make tangible progress based on what you know and don’t know, understand and don’t understand, and do and don’t do.

This article was co-authored by Mark Smalley.