Blog

The Amazing Power of a Game – What I learned from the facilitating The Pheonix Project Simulation

No Comments 110 Views0

I recently had the opportunity to become certified to lead a simulation based on the best-selling IT book The Phoenix Project. When I went through the training, it was apparent that the developers of the simulation had created something very special. The Phoenix Project simulation is not a product as much as it is an experience. The realistic scenarios, challenges and pain points embedded in the game created a creative tension in a safe environment and allowed everyone (including me) to discover new insights into applying DevOps to improve flow throughout the value stream: from the business request through IT and to customers!

DevOps and Agile practices are built on the back of Lean principles that go back decades to before the Toyota Production System. As someone who attempted to apply Lean to IT long before DevOps came into existence, I have always said that DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. I was fortunate to meet with Gene Kim many times while he was writing The Phoenix Project. We always talked about lean thinking, lean systems and lean tools. Those discussion eventually morphed into The Three Ways – the core principles of DevOps!

Alignment with the business changes the feel of work

The simulation put people in a position where It was easy to see and feel the impact of not being aligned with business and not being coordinated with all the elements of it (AppDev, Engineering, IT Ops, Change Management, etc.). In each round the team was able to reflect and learn from the experience and experiment with new ways of working. What we all experienced was profound: the DevOps principles, systems and tools are effective only when the team directly experiences the frustration of a broken work system and works together to see, understand and act.

What was amazing to see was how quickly people took on the personas of the functional tole they had been assigned. The woman who took on the role of Retail Operations (you may remember Sarah in the Phoenix Project) became rather aggressive as she demanded results. The CISO (John in the book) constantly nagged people about SOX-404 issues. And of course, the CEO was a royal pain on everyone! Although we all knew this was a simulation game, everyone reported the stress and tension they felt as we embarked on round one with no real plan of how we were going to transformto a DevOps team.

You can’t improve what you can’t see

 What became instantly apparent among the chaos of trying to get the work done was that the team had no visibility of all the work nor priorities. True to life, there was more work that our people could handle so we needed a way to see the work, compare it to our capacity to do the work, identify trade offs and then work with the Business and other stakeholders to set priorities. Once the team was able to accomplish this (through some trial and error) we all could feel the alignment of purpose, see the smile on peoples’ faces as we created value and feel what collaboration between silos is really like.

 This discovery was just the tip of the iceberg. As a coach and facilitator, I was able to ask the team questions that positioned them to reflect on what had just happened and see within themselves additional changes that needed to take place to improve the quality, speed and volume of our deployments. Some of the other topics which were experienced and later expanded on include:

  • A recipe for coordination among silos
  • Making time for improvement, learning and technical debt
  • DevOps without Value Stream Mapping can be hazardous to your health

I’ll share some thoughts on these topics soon.

At the end of the day, DevOps is about creating an environment where it is safe to observe, experiment and learn based on outcomes. The Phoenix Project Simulation creates an environment to give everyone that experience. From there, they return to work and begin their journey.

 

 

 

Change Fatigue, Psychological Safety and the Leadership Void: Why Most CI Initiatives Don’t Last

No Comments 107 Views0

Continuous improvement has been around for decades, and yet there are few examples of organiza- tions that have successfully created a lasting culture of problem solving, learning, and improvement. Many books, blogs, and workshops are available on these topics, and there is no shortage of resources on the tools and techniques of Lean process improvement. We understand the mechanics of improvement, but stumble when it comes to connecting with people so they engage and participate.

What are the factors that hold people back from investing themselves in a culture of continuous im- provement? For many years, I have served as a coach, trainer, and consultant to numerous organizations across many industries and have consistently encoun- tered three key barriers to creating a new normal, which includes daily problem solving, employee initia- tive, and higher levels of participation.

In a CI culture, improving the way we work is more important than doing the work! Most people spend their day doing their work and view improvement as an optional “when I have time” activity.

Change Fatigue

Over the years, multiple programs have been rolled out (e.g. Lean, Six Sigma, Operational Excel- lence, Agile, TPS, Total Quality, etc.) with prom- ises of making work less chaotic, creating work- life balance, and making things better. While these initiatives are well-intentioned, over time people be- come exhausted with the new “flavor of the month” and no longer get excited about the envisioned benefits of process improvement.

Psychological Safety

People need to feel comfortable sharing their thoughts, expressing when things are not working, discussing problems, asking for help, making suggestions, and even disagreeing with the way work is done. It is not easy speaking up when one feels it is risky to disagree with their boss, question current policy, or simply ask why something is done a certain way. The freedom to ask “What if ?” is not something most of us are com- fortable doing when we are not certain where the con- versation will lead.

Here’s the key: it is precisely this level of safety we all require before we will step out and speak up. The engagement and participation that is so crucial to a CI cul- ture will only develop in an environment of psychological safety and nowhere else. Improvement requires learning, learning requires experimenting, and experiments seek to better understand cause and effect. The process starts by asking questions. But no one will ask questions or speak up if they feel it is unsafe.

Leadership Void

Leaders, managers, and supervisors set the tone of the workplace and must model the behaviors necessary for a CI culture to grow. Yet all too often, they unintentionally do the very opposite. Leading with Respect is a collection of specific leader behaviors that create an authentic con- nection with people to develop a background of mutual trust. Trust is the basis of all relationships. It is the glue that makes a team a team.

Building a great organization requires effective leader- ship. A key element that is often misunderstood is what it means to lead with respect. This involves awareness of a leader’s focus and intention and how well the leader con- nects with people to create an environment of mutual trust and sustained high levels of performance. This is accom- plished through the application of seven core practices. We’ll explore why leading with respect is essential in a suc- cessful transformation, what respect looks like in practice, the seven core practices, and how they impact people to drive lasting change for the better.

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

No Comments 157 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 104 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

No Comments 860 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

1 Comment 1603 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?

2 Comments 2048 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?

No Comments 1914 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

No Comments 1427 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

No Comments 1413 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!

  • Page 1 of 3
  • 1
  • 2
  • 3