Blog

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

Continuous Improvement, DevOps, Innovation, Lean, Uncategorized Comments off 2546 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

DevOps Comments off 1927 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.

Doing versus Being – How Mindfulness Supports Better Lean Thinking

Lean, Lean IT, Lean Leadership, Mindfulness, Problem Solving, Process Improvement Comments off 3227 Views0

I wrote this post for the Lean Enterprise Insitute.

I was recently talking with the CEO of a large insurance company who said, “our people seem to know Lean concepts and tools, but they are not being Lean as they go about their daily work!” If this sounds familiar then read on.

After years of training, workshops, and books on Lean and continuous process improvement, most organizations applying Lean have not realized the performance breakthrough and cultural shift they had hoped for. I have visited numerous organizations who have invested years undertaking Lean activities (value stream mapping, A3 problem solving, visual management, leader standard work, Kaizen, etc.)  but have little to show for their efforts in terms of sustained value stream performance, quality, productivity, effectiveness, safety, and efficiency gains.

This is an issue we as a community need to take an honest look at. Perhaps there are some missing elements that we need to be considering. Is it possible that we’ve gone on “autopilot” and are just going through the motions without engaging our minds? Have we become robotic in our Lean thinking and doing? Have we become so comfortable with the knowledge of Lean that we have lost touch with the being of Lean?

Shifting out of autopilot

 

A state of being known as mindfulness presents a path forward. Mindfulness is defined as “a mental state achieved by focusing one’s awareness on the present moment, while calmly acknowledging and accepting one’s feelings, thoughts, and bodily sensations.” Mindfulness has gained lots of attention in the business press over the past decade. The Centers for Disease Control and Prevention (CDC) journal Preventing Chronic Disease reported: “Approximately 1 in 7 workers report engagement in some form of mindfulness-based activity, and these individuals can bring awareness of the benefit of such practices into the workplace.” 

Four Levels of Awareness 

You are probably familiar with the classic four stages of awareness:

  • Unconscious Incompetence – blissful ignorance (not knowing that you don’t know something)
  • Conscious Incompetence – painful awareness (realizing that you don’t know something)
  • Conscious Competence – intentional awareness (knowing what you know and don’t know)
  • Unconscious Competence – unaware but knowledge and experience has taken over

Initially described as “Four Stages for Learning Any New Skill”, the theory was developed by Noel Burch in the 1970s.

Isn’t it interesting that unconsciousness competence emphasized the autopilot nature of our thinking? Perhaps this works for a few people, but the rest of us would be better served relying on mindfulness and conscious competence to develop deeper levels of focus, analysis, experimentation, reflection, and learning. To that end, please consider the following model:

Four levels of awareness: Knowing, Understanding, Doing, and Being

(see image above)

A good place to start

 

Knowing is where we typically begin by training people in Lean Basics: principles, systems, and tools that make up the Lean body of knowledge. While knowing key concepts and models is certainly needed, by itself knowing does not necessarily lead to major changes in behavior. I may know eating pizza is not good for my health but that knowing does not stop me from ordering a large pizza most Friday nights!

Understanding occurs when we mentally process the new information we have learned, compare it to what we know and don’t know, and create context and perspective. We reconcile the new knowledge to give it meaning in relation to everything else we believe we understand.

But even solid understanding does not drive sustained changes in behavior. John Shook addressed this issue in his landmark Lessons from NUMMI article in 2010. In that piece, he wrote, “It’s easier to act your way into a new way of thinking than to think your way into a new way of acting.” This key insight is attributed to Millard Fuller, Founder of Habitat for Humanity. 

Activity with mixed results

Doing is where many organizations find themselves – they are diligently putting up team boards, updating metrics, holding team stand up meetings, updating A3’s, developing countermeasures, going to the gemba, and so on. There is a concerted effort to accomplish the tasks of continuous improvement. Kaizen events, team huddles, and the Lean Management System have been determined a success, but at the end of the day, not much has changed!

 

Let’s pause here: how accurate is it to suggest that “not much has changed?” If we define change in terms of sustained gains in value stream performance, quality, productivity, effectiveness, safety, and efficiency gains. Go take a walk around your company and honestly assess the level of sustained gains when viewed through this lens of awareness.

Just as understanding is needed for clarity around the “why” and “what” of Lean, doing is the action needed to close the gap between where we are and where we want to be. Someone once said, “A tool is only as useful as the user.” If a team using Lean is operating at knowing, understanding, or doing level, problems not deeply understood, changes are temporary, and solutions seldom sustained. We can often find ourselves so absorbed with the challenges of achieving our daily work goals that we lose focus and reliance on process improvement – we are doing Lean, but we are not being Lean.

To move to action, we need to move from understanding to doing. However, to sustain the change, people must progress to the next level of awareness – being.

Being is a whole new ballgame 

Being is the calm, focused state of mind where we are fully present and aware of what is here, right now. When we are in this state, the mind is nonjudgmental and accepting of the current situation. Acceptance does not mean approval; it means that we grasp the situation for what it truly is, in order to take steps to improve the situation and close the gap. With acceptance, we do so with a clarity of mind and calmness of thought that leads to a state of allowing things to be as they are while moving towards an improved target state.

Acceptance, acknowledgment, and allowing things to be as they are versus resisting, judging them, or putting up excuses for them, gives us a powerful edge for direct observation which often reveals underlying contributing factors to the current conditions.

Being delivers a key element that is missing from doing: a space for the mind to be more relaxed, more creative, and less stressed. As we become more present and focused on the moment directly here and now, the mind becomes calm, curious, and accepting.  Mindfulness positions us to approach problems dispassionately, which directly supports Lean thinking (structured experimentation, reflection-based learning, connecting with people on an authentic level).

In the next post, we’ll explore some specific mindfulness practices you can apply to boost your effectiveness at being Lean.

About the author: Mike Orzen is a member of the LEI facility and has been practicing both Lean and mindfulness for over twenty years. He can be reached at mike@mikeorzen.com.

 

 

7 Things Coaches Need to Get Over

Coaching, Lead with Respect, Uncategorized Comments off 17086 Views0

Over the years, I have noticed some common misperceptions about coaching effective problem solving skills and developing lean thinking. Here’s a few:

1) It’s not about being smart (and it’s not about you). Good coaching is not about your intelligence and ability to solve the issue the learner (e.g., person you are coaching) is attempting to address. The more we focus on our own skills and the problem to be solved, the less we focus on the learner’s thinking process and their development.

Good coaching is about centering on the other person’s pattern of thinking as they work to develop potential countermeasures. In fact, when you have no bias and don’t actively engage in solving the problem, it becomes easier to be an effective and helpful coach. The learner is the writer, producer, director and actor: make your coaching all about them.

2) Fake it until you make it is not a sound approach. To be a good coach you don’t have to an expert in the subject the learner is exploring. In cases where the topic is specialized or highly technical (for example, chemistry or IT) and you know little about the subject, be 100 percent transparent! Pretending to be someone you are not will only erode trust between you and the person you are coaching. The supply the subject matter expertise and provide the coaching.

3) It’s not about what you would do. Redirecting the conversation in an attempt to get the learner to think a certain way steals the learning experience from the other person and is disrespectful. As a coach, your role is to gently expand the learner’s problem solving skills by asking open-ended questions that do not lead the witness. Leading the witness is doing the thinking for the other person, putting ideas in their head, cross examining them, giving direct advice (as in “this is what I would do”), or otherwise taking over solving the problem. Your problem-solving expertise is irrelevant as it relates to your playing the role of problem solver. It is very relevant as it relates to your role of coach: the better you are at applying the Plan-Do-Check-Adjust(PDCA) cycle, the better you will become as a coach if you stay clear of engaging directly in solving the learner’s problem!

4) Your stories don’t always help. Telling stories that provide clues or suggestions based on your experience often influences the direction of thinking the learner is pursuing and detracts from the value you provide as a coach. The effect is similar to leading the witness but can steal even more time and focus away from the learner. Storytelling can seem like an appropriate element of coaching but often negatively impacts coaching by making the dialogue all about you (see #1 above).

5) It’s not about asking standard questions. With the popularity of Toyota Kata, many people equate the five coaching questions as everything there is to know about lean coaching. While the Kata questions can be very effective when used appropriately, they are not the end-all be-all to good coaching. Recitation of questions read from a card (or memorized) can detract for the authentic connection which needs to be fostered between coach and learner. A great coach is constantly scanning the learner’s thinking to see where they are in their understanding and application of PDCA. Don’t allow the Kata questions or any list of coaching questions distract you from the active listening and concentration required to accurately sense and respond to the learner’s current level of understanding.

6) Evaluating the learner is harmful. In coaching, judgment can limit our effectiveness. When we place labels of the learner’s thinking, we limit our view of the other person. A great coach sees the other person as having the ability to solve their current problem as well as become a better lean thinker than they are. In fact, that’s your job: to support the other’s development to be the very best they can be and sincerely desire that they exceed your skill set. We might call this practice “coaching with humility.”

7) Eat your own dog food. To effectively connect and coach another you must be authentic. To become a good coach, you need three things: a good coach to coach you, practice, and perseverance. If we don’t practice what we preach – PDCA, continuous improvement, lead with respect, reflection, go & see, life-long learning, etc. at work and in our personal life, then we are frauds. Positioning ourselves as coaches while espousing lofty ideas but failing to apply them to us personally will become obvious to those we are coaching. If we’re not leading by example, then we’re not consistently practicing and learning – we won’t be able to make a connection with the person we are trying to coach.

Let me know your thoughts on this subject. Are there other misconceptions that get in the way of effective coaching?

War of the Frameworks – Is Lean IT losing its relevance?

Lean IT Comments off 4683 Views0

I recently received an email from a colleague of mine who, after 15 years in IT, was wondering if Lean (and particularly Lean IT) is just an over-used term losing its value. Today we hear and read about Agile, DevOps, ITSM, IT4IT, Lean Startup and other frameworks all purporting to transform and revolutionize the effectiveness of IT operations. How do we make sense of it all?

In my opinion, these frameworks and the methodologies they apply to the “IT challenge” are not at all at odds with one another. On the contrary, they each bring unique insights and applications to the array of complexity within IT and support our progress towards more effective and efficient flow of information to those who need it. 

The Chassis

The principles of Lean IT, serve as the chassis to the engines of Agile, DevOps, and other IT frameworks. In 2011, I attempted to capture those principles in Lean IT – Enabling and Sustaining Your Lean Transformation. The principles included a foundation of purpose, respect for people, and relentless improvement. The next level addressed self-driven behavior where people do the right thing based on intrinsic motivation. From there we explored core ideas of Lean including voice of the customer, quality at the source, and systems thinking. Building on that, we moved into production concepts such as flow, pull and just in time. The outcome is a culture of trust, transparency, accountability and performance impacting quality, delivery time, cost, and organizational morale.

The details of the model can be downloaded here (scroll to the bottom of the page). Reflecting on the essence of what all the models are attempting to achieve, it boils down to this: 

Create Value

Flow Value to the Customer

Create a Great User Experience

Keep Getting Better  

There are many frameworks and tools to help us accomplish this, but the core principles do not change – they are universal, timeless, and self-evident once we apply them. With the advent of other frameworks, is Lean IT irrelevant? Are the core principles of an auto chassis irrelevant to a Tesla? I think not! Regardless of which frameworks your organization deploys, keeping these core principles in mind will help you maintain focus and stay the course. 

Mike Orzen is one of the early practitioners of Lean IT and contributed to the development of the “Three Ways of DevOps” found in The Phoenix Project. He has been practicing the application of Lean IT, Agile and DevOps for over 20 years. Mike is on the content board of LITA and a certified instructor.

 

How Do You Know If You’ve Created a Meaningful Challenge?

Engagement, Executive Leadership, Lead with Respect, Lean Leadership, Problem Solving Comments off 4137 Views0

Have you ever issued what you thought was an inspiring challenge for your team, only to discover they were underwhelmed and far from motivated? Many organizations that have mission statements displayed in their lobby, company values laminated on the back of employee badges, and team banners hung from rafters proclaiming lofty goals – but it may not be surprising that when their people are asked, “What do you do here and why is your work important to you?” most look puzzled and perplexed as they attempt to articulate an answer. This response is global: from the U.S. to Europe to Asia to South America – over 75 percent of people I speak with seem to lack a meaningful challenge which serves as a source of motivation, caring and commitment.

In Lead with Respect, one of the core practices is to create a meaningful challenge. How does creating a meaningful challenge demonstrate respect for people? Why is it so important that the people on your team perceive the challenge as meaningful on an individual and personal level? When people understand goals and objectives, acknowledge them as having relevance, and feel they can trust co-workers and leaders, profound levels of engagement and self-initiated involvement emerge.

The challenge must be clear 

Often challenges are vague aspirations which mean different things to different people. For example, “To delight our customers by delivering outstanding value” may sound like a worthy goal, but most people find it difficult to translate into specific behaviors which can be modeled, coached and measured. People need to understand the why of their work and identify with its importance in order to deeply care about outcomes. In other words, people need to clearly understand the why before they will genuinely care about the how and the what! (See Simon Sinek’s TED talk classic Start with Why). When the reasons why are distorted, vague or left undefined, there is little personal commitment to performance and even less motivation for improvement.

Clarity is not enough 

Clarifying the reason why the work is important is a good start but it may still lack the motivational power to engage people at a visceral, deep-seated level. How do you know if your people understand the challenge and find it meaningful enough to be inspired to take action?

One approach is to simply ask them, “Do you feel our team has a meaningful challenge?” They will most likely say, “Yes.” Be sure to follow it up by asking, “Why?” and “Can you give me a specific example of how our challenge was meaningful and motivated you?” These conversations show respect for people through honest dialogue. Focus more on listening than on speaking during these encounters. Look for examples of behavior (physical acts) that are tied to the challenge. If the challenge truly is meaningful and clearly understood, people have no difficulty describing it and drawing a recent example of how they were guided to take action because of it.

How does this fit in with go & see?

The next time you are at the gemba, watch and listen for evidence that a meaningful challenge is part of the discussion. Is the challenge understood and shared? How frequently does it come up in conversation and how is it used? Are people inspired by the challenge or discouraged, intimidated, or detached as a result of it? Can you connect people’s actions back to the challenge? How does the team know they are winning or losing (reaching their goals)? Do they care and if so, why do they care?

Take a look, reflect, and experiment

Leading with Respect is all about engaging hearts and minds and moving beyond people simply giving the minimum effort, going through the motions, or only doing what they are told to. When a meaningful challenge is present, people care at a personal level and join together as a team to find the energy, creativity and commitment needed to meet the challenge. It’s a beautiful thing to see! Take an honest assessment of your challenge and its effectiveness at creating motivational impact on behavior. Ask these questions to yourself and to your team and reflect on your current condition. If your need to improve the effectiveness of your challenge, develop a countermeasure and run an experiment to learn more deeply about the impact of a meaningful challenge on your team’s level of engagement, commitment and self-assumed accountability.

This post was also published by the Lean Enterprise Institute here.

How Lean IT can help drive growth

Uncategorized Comments off 3065 Views0

The lean process improvement principles that have driven transformational change in areas such as manufacturing, accounting and supply chain management are making big waves in yet another sector: information technology.

Today, many companies are actively seeking the benefits of “lean IT,” seeking to drive out process waste and streamline workflow, turning to lean icons such as Toyota and Honda for inspiration. At The Ohio State University Center for Operational Excellence, for example, an entire community has formed for IT leaders seeking to drive efficiency and effectiveness through lean practices.

The stakes are simple but high: When IT stops, the business stops, and when it flows, it positions the business for success. But the sector – with its complexity, cross-functional interdependencies and conflicting priorities – presents a “perfect storm” of distinctive obstacles for leaders. Moving forward with a transformation, particularly in IT, requires a clarity of purpose, an alignment of people, and a sharp focus on the processes that create value for customers.

Accomplishing all of these takes more than just a set of lean tools – it requires a shift in behavior, driven by leaders equipped to change a culture.

All transformations begin with a look at purpose. A shared purpose is essential to create and drive a common intention, alignment and commitment. Everyone in the IT organization (as well as the business) needs to be very clear on why we are in business, why we are transforming and where we are vs. where we need to be. Without a widely understood and collective purpose that people can clearly see within the context of their daily work, everyone is left on their own to identify what matters most and determine what they should do (or not do) about it.

The next component is people. While clearly a central ingredient in building a highly effective organization, people also are the source of the uncertainty, disengagement, mistrust and political gamesmanship that can plague a workplace. When we treat people with respect and create systems and processes that position them for success, we cultivate trust, engagement, teamwork and high levels of performance.

In the hands of our people are the processes that represent the work we do to fulfill the mission of our organization. When processes are undefined, unclear or not consistently followed, the effort required, the time it takes, the quality of the outcomes and the frustration of staff and customers all become highly unstable and inconsistent.

Too many organizations fail to step back and examine these elements of the bigger picture, which ultimately serves as the “True North” in the lean transformation process. Companies that have “pockets” of improvement – islands of lean in a sea of waste – often lack understanding around a shared purpose, for example.

To truly keep momentum moving, organizations need fearless leaders at the core of their process improvement teams. If they stop leading the charge, improvement work and the underlying transformation immediately begin to taper off. If they succeed, the possibilities are endless.

Why we (almost) did not write the Lean IT Field Guide

Uncategorized Comments off 2836 Views0

After writing the book Lean IT in 2011, we were amazed by the the response: a great deal of “pent up demand” and interest in applying the principles, methods, and tools of lean to IT operations. This lead to speaking engagements all over the world, webinars and papers, and a number of major opportunities to deploy lean IT in both large and medium-size companies. Like any lean experience, it was journey of trail and discovery with both success and setback, and much was learned.

As I met people in the US, Europe, Asia, and Australia, I heard a common request, “I loved the book and it has changed the way I view the function and purpose of IT and the people I work with, but… [it is always what people say after the but that is most critical!]. What followed was always some form of, “but how do we actually do it?” or “What are the steps we take to introduce and mobilize Lean IT throughout our organization?”

For several years I dismissed this request because I had been taught that people learn lean by going through the often-painful process of trying something, getting knocked down, reflecting, and trying again, until they come to understand that all of lean is a learning system based on the Plan-Do-Check-Adjust method. If we were to direct people in what to do and the sequence to do it, two problems would transpire: 1) without knowing in detail the distinctive challenges of their organization, we were not in a position of understanding to suggest a course of action, and 2) by providing such a roadmap for transformation, we would rob them of the hands-on learning experience essential to lean thinking and effective change.

Mike has had the amazing opportunity to apply lean IT at a number companies including Nike, Con-way, ANZ, Aggreko, Nationwide, and Motorists. After over twenty years of learning and struggling to be a lean thinker, it became apparent that we could share the essential elements of successful lean IT deployments in a way that would not violate either of our concerns. By keeping the roadmap at a level that would be universally applicable, there is ample opportunity for adaptation, experimentation, discovery, and learning so the reader can still experience the journey of lean IT! In fact, many of our readers have emailed to say that the book is equally effective in others areas of the business including the front office, HR, purchasing, Finance, transaction-based processing, analytical work, and even manufacturing. This is not surprising to us – these ideas are based on timeless universal principles which apply well beyond IT.

Applying our roadmap, Tom spearheaded the lean IT transformation at Nationwide with incredible success. In its seventh year, lean IT has delivered a new culture of performance, transparency, and more productive, better quality, and lower costs!

We hope that The Lean IT Field Guide inspires your journey in IT and beyond!

Accountability: Not What You Think it is…

Continuous Improvement, Engagement, Lead with Respect, Process Improvement, Transformation, Uncategorized Comments off 3643 Views0

Accountability. It’s a word often feared in society for being associated with the blame game – being singled out when things go wrong, even if the reasons are beyond your scope of control. It seems we are always hearing about the importance of creating a culture of accountability.

Unfortunately, when managers and associates hear the term, they often flinch! Expressions such as “We’re holding you accountable” are often seen as code for “You are liable and will be blamed if things do not go as planned!” This is a major problem for any organization that is serious about creating and sustaining a lean transformation.

If we consider the lessons of LEI’s Transformation Model (shown above), we see that the entire foundation rests on the basic thinking and fundamental assumptions (both overt and unseen) that drive current culture. For leaders who wish to transform from a command-and-control culture to a more participative one, a key assumption is that, when treated respectfully, people will align to a common purpose, deeply engage in both doing the work and improving the process, and assume higher levels of accountability.

The image includes employees taking on tasks without being told to do so, showing initiative to improve quality first and efficiency second, and genuinely caring about their customers, team members, organization, and community. This basic assumption that is so central to a lean transformation becomes null and void when accountability is seen as a liability that management assigns, rather than a self-assumed role that people undertake of their own volition.

When there is evidence of intentional avoidance of accountability, it suggests that people don’t trust the intentions of the organization, leadership, or even fellow teammates. They may be avoiding the risk of potential conflict that comes from taking on a task which the outcome is uncertain. This is true problem solving and it can be scary enough without the fear of being blamed if things don’t work out well. It is interesting to note the role that trust plays in all this.

Creating a lean environment is essentially creating a learning environment. In a learning environment, we move away from experts who tell others what to do and towards learners who run experiments (rapid PDCA cycles) to better understand root cause(s) and validate effective countermeasures. Accountability must be self-imposed in order for people to truly grasp the concept, take ownership, and take on appropriate levels of commitment.

But this can only be done when the fear and apprehension most people associate with words such as accountability are openly addressed. When reflecting on your own organization, here are a few questions to consider:

  1. Do we blame people when things don’t go as planned?
  2. Do people self-assume accountability or do we assign/delegate accountability?
  3. In our current culture is there fear, anxiety or hesitation around accountability?
  4. Do we ask people to be accountable before asking if they are capable?
  5. Do accountability and authority always go together? When should they?

To learn more about creating a culture of accountability and respect through effective leadership, sign up for Mike Orzen’s pre-summit workshop, Lead with Respect: Practicing Respect for People to Enable Engagement, Teamwork & Accountability, at the 2016 Lean Healthcare Transformation Summit this June. Learn more about Lead with Respect and other Summit workshops on the summit webpage.

Note: this article also appeared in the Lean Enterprise’s Lean Post in February of 2016.

The Importance of Work Systems, Sequence, & Adaptive Lean IT Systems – Part 4

Continuous Improvement, Lean IT, Problem Solving, Process Improvement, Transformation Comments off 2874 Views0

This is Part 4 of Sequences, Behaviors and Integrating Adaptive Lean IT Systems – an updated article originally published in the Lean Management Journal in October 2015.

In the previous blog entry, team huddles and a visual management system were mentioned. These are both examples of work systems designed to encourage the specific behaviors we want to cultivate. There are many work systems that comprise a lean management system including problem solving, daily huddles, leader standard work, training, recognition, visual management, strategy deployment, measurement, and monthly performance reviews, just to name a few.

It is these work systems that impact people’s behavior most significantly by emphasizing and reinforcing those actions we want to see everyday from everyone. Where many organizations get into trouble is in the sequence and timing of how and when to introduce these systems.

SEQUENCE IS CRITICAL

Over the past twenty-four years, I have tried many approaches and witnessed what works and what doesn’t. Here’s the bottom line: each organization has its own culture, history, and work environment, so one size does not fit all. There is no standard deployment sequence or collection of work systems that apply universally. That said; there are some fundamental concepts applicable to all organizations.

1) Start by establishing a clear purpose throughout the organization. This is a prerequisite for success.

2) Acknowledge that the bedrock of lean is learning and that problem solving capability is the skill to cultivate if you are serious about transformation.

3) Strive to balance the two pillars of lean: continuous improvement and respect for people. Don’t make the common mistake of falling in love with tools of continuous improvement and ignoring respect for people.

4) Create a culture of accountability by building work systems that position your people to succeed, to learn, and to grow. This is true respect for people and promotes high levels of teamwork, engagement, accountability, and ultimately performance.

5) Work systems must be designed, built, maintained, and improved by the people doing the actual work. Outside support is fine, but the frontline people must do the work.

ADAPTIVE LEAN IT SYSTEMS

Whether you are considering bringing lean IT to your organization, currently applying it to IT operations, or determined to build a lasting transformation, awareness of the lean IT diamond and the importance of behavior, work systems, and sequence will significantly increase your odds of success.

At the end of the day, Lean IT is all about effectively responding to change by continuously improving adaptive systems. In order to be effective, IT must change its behavior and functional capabilities in response to its environment and the needs of the Business. When IT reshapes systems and technology, the adaptive change is directly relevant to achieving the goals and objectives of the organization.

SUMMARY

For IT organizations to evolve and become more responsive to the changing needs of the Business while simultaneously maintaining the stability and security they are held responsible for, IT professionals need to understand and embrace the behaviors, as well as the thinking, of Lean IT.

For additional information on how to mobilize a Lean IT transformation, see The Lean IT Field Guide – A Roadmap for Your Transformation.

 

  • Page 2 of 4
  • 1
  • 2
  • 3
  • 4