Change Management exists because of resistance to change. We’ve found that we can remove the need for formal change management and allow change to occur naturally – virally, even – through the use of introspection, invitation, and socialization.
The notion that resistance to change is unavoidable is a myth, as is the notion that organizational change has to be managed via a large, formal, expensive process or framework. In fact, it’s a myth that organizational change has to be hard. The secret to busting these myths lies in the answer to the question: “Whose transformation is it?” Change is a lot easier when each person in the organization answers with “My transformation!” We will teach you the secrets to using “my transformation” to accelerate change in even the largest, most challenging organizations.
Pulling from 20 years of combined organizational change experience, we will share how to change your organization by leveraging your core culture. You’ll learn practical techniques to help people change by reminding them who they really are. You will learn how to use lean change management and open space agility to accelerate your change and ensure success. You will learn how everyone can be invited to change. And, hopefully, you’ll learn what not to do from our mistakes.
We have both experienced the growing pains that come from becoming Agile and helping others with the same. We’ve had similar experiences and learned similar journeys, though our journeys have been surprisingly different. One of us took fifteen years, the other took five, and both took longer than necessary.
In late 2013, we were tasked with leading Walmart Information Systems Division’s Agile Transformation as its first two Enterprise Agile Coaches. Walmart ISD employs thousands of technologists, both at our home office campus in Northwest Arkansas as well as in-country offices that support our global enterprise. At the time, less than 10% of our work was executed using an Agile approach. In less than two years, that number flipped to less than 10% of our work being executed using non-Agile approaches
Most change initiatives either fall short of their intended goals or fail outright. Failed change initiatives can cost tens, if not hundreds, of millions of dollars. Those that “succeed” still often fail to achieve lasting, effective changes. We’ve experienced failed change initiatives, but we’ve also experienced success. We’ve found that the use of invitation – allowing change to be pulled rather than pushing it on people – makes all the difference.
Our latest change effort was limited in time and budget and we needed a better approach to change management. We needed a fast, easy way for two (who would become four) change agents to transform thousands to new ways of thinking and working.
There are a lot of models and research that illustrate that people do not like to change. For example, the Virginia Satir change model shows that people often resist and deny change. Our research told us we needed a way to work past the resistance.
Still, we wondered if it were possible to tap into viral changes, the social change phenomena where there is little effort to get change started and people fuel change on their own. What if change could happen like it does in fashion or music? What if change was something people liked? What if change agents aren’t needed?
Lest you think we were both born naturally gifted Agile Coaches, let us share with you some stories of change management past. The difference between success and failure is simple, but it took us 20 years of experience to find the secret. We’ll relate our respective stories from beginning to end, then illustrate the simple ingredients to viral change: introspection, invitation, and socialization.
3.2.1 Mandatory Failure
“In governing, don’t try to control. In work, do what you enjoy. In family life, be completely present” –Lao Tsu
Todd’s journey began as a consultant almost 20 years ago. He started his change initiative while working at one of the big consulting firms that sell change in packages of services with templates, frameworks, and lots of consultants.
His first client was an auto manufacturer where the CIO demanded that the company move to an entirely new methodology. She was an imposing figure as she pounded her fists on the podium and said, “You will be on board with this process or you will not be on board at this company!” She then pointed to Todd and said, “And here is the guy who is going to transform you.” Todd had a sickening feeling in his stomach as the hostile glares from 400 managers were directed at him.
Through sheer force of will, the company began to move to the new process in an effort to appease their leader. The direction was top-down, command-and-control. The CIO had inadvertently just demanded everyone in the company jump off a cliff. Todd successfully helped them do just that. His initial engagement with the company lasted a year. The expected improvements did not come, despite his best efforts.
Roughly four years after leaving, Todd revisited the company and they were still failing. The people were still trying to make the CIO’s way work, and therein was the problem: the change did not belong to the people. They did not take ownership of it. They weren’t doing this because they wanted to; they were doing it because they didn’t want to lose their jobs.
Mike entered his first job out of college as they were just getting into the swing of Waterfall. Their Project Management career path had just been established and their Software Development Life Cycle (SDLC) was fresh off the presses. As a junior software engineer, he struggled with the constant churn and politicking that came as by-products to the new Waterfall methodology. He didn’t know that there was another way – a better way- to do things. After all, he was fresh out of college and had been warned that the “real world” would be different than academia.
In an attempt to make things run more smoothly, his company became a matrixed organization; unfortunately, this had the side effect of finger-pointing and stifled collaboration. Mike did his best to make his projects as successful as they could be, but all of them left a bad taste in his mouth. He knew they could do better, but struggled to improve with subsequent projects. He noticed a few small things. For example, smaller projects worked better, as did those where you worked with people with whom you’d previously worked. Still, every project seemed too big and no two projects’ teams were identical.
Mike worked for about three years in this methodology before he decided he was sick of it and was going to try something called “Agile”.
3.2.2 Giant Baby Steps
“The journey of a thousand miles starts from beneath your feet” –Lao Tsu
Todd left the auto manufacturer for a time and consulted with an insurance company. He was to assist with their Agile transformation. They took a much more human-centered approach and did a fantastic job of getting buy-in. Yet their process seemed to take much longer to emerge and mature than anticipated. They were willing to experiment, but experiments were drawn out and took too long to learn from.
While Todd appreciated their patience with people, he often found himself wondering how to speed up the rate of change. His engagement ended before the company arrived at their originally intended destination. It took over eight years to achieve the desired level of company-wide maturity.
Mike became the tech lead for a new project that he decided would be Agile. Unfortunately, he had no idea what that meant. He started reading up more on what Agile meant as the project entered the Initiation and Requirements phases. He began doing design work and planning out construction Sprints while trying to wrap his head around the concept of Story Points.
Then Mike managed to get Agile training for his team, shortly after the Construction phase of the project started. They started to see the error of their ways and began to retrofit practices to help them run the rest of the project in a more Agile way. They had already planned on multiple releases, so the requirements that had been gathered and designed were only a portion of the full scope of the project. The team experimented a lot over the course of a year and learned a lot about how not to do Agile.
The project ended up losing funding after the first release, about a year after it started. Despite the many stumbles and fumbles of the team, the project highlighted the success of Agile in Mike’s area – they had a project’s budget (and therefore time) cut in less than half and were able to deliver more than just documentation.
3.2.3 Benevolent Despotism
“When you are content to be simply yourself and don’t compare or compete, everybody will respect you.” –Lao Tsu
Todd moved on to another Insurance company with plenty of experience under his belt. He knew what was best for them. All he had to do was show them the way; they would surely see the wisdom and follow. The company liked what they heard and they saw that Todd clearly knew what he was talking about. Unfortunately, Todd put the focus on him and the practices he brought instead of getting the teams to own their transformation.
To be fair, his practices were impressive. Todd was able to share with them many great ways of doing, and they liked what they saw. In fact, Todd became the best practitioner they had. Of course, he wasn’t brought in to become their star practitioner; he was brought in to develop star practitioners.
By the time he left, about two years later, many were still struggling with the change instead of feeling empowered to continuously improve themselves.
Mike was loaned to another area to help with a struggling project. It was in a different domain, and for a different country with a different language and culture. On top of all that, almost all of the developers were contractors. He could see the flaws in how they did things and couldn’t wait to show them the error of their ways.
He got involved mostly through emails and conference calls, though he was sent on a 3-week visit at the end of his engagement. While there, Mike evangelized XP practices and Scrum techniques that he knew would help get the project out of the proverbial ditch. He had been using these practices during his engagement to that point, and he showed them the results in person.
At the end of his half-year involvement, the developers had not changed at all. They were more concerned about fighting fires than fixing the root problem, and Mike’s approach did not help them “see the light”. Perhaps the only change Mike brought about was the resentment with which the development team viewed him.
“The ancient Masters didn’t try to educate the people, but kindly taught them to not-know.” –Lao Tsu
Todd went back to the auto manufacturer of his youth, this time through a different consulting company, and realized how much damage he had helped implement more than five years ago. The company was struggling with a growing over-architected process and had moved further and further from their roots. In other words, they were still trying to out-live jumping off a cliff.
He helped them to see how much better their roots were than what they had become. He worked with them to simplify their processes. They unlearned what they had learned over the past five years so that they could start to learn the right things. Over the course of 3 years, they leaned down their processes and began running much more happily and efficiently. Simplicity was a process they could really own.
Mike came back to his home area, no longer on loan, and became his domain’s first full-time Scrum Master (a.k.a. not a Tech Lead / Scrum Master). He worked with a Scrum team that had just split from one team into two. They looked to him for answers that he tried not to give them. They would argue and try to defer to his judgment. What he found was that the root cause was usually the team’s culture and the mindset that resulted from it.
He helped them agree on problems and experiment with solutions. He used his knowledge of common practices to help guide them, but tried to let them “have it his way”. They almost always went in the direction that he wanted, but he helped them arrive there as if it were their decision all along. They understood both what they were doing and why.
By unlearning command-and-control and learning to experiment, they were able to fail fast consistently. After eight or nine months, Mike transitioned the teams, which had now become three, to new Scrum Masters.
3.2.5 Humble Competence
“If you want to govern the people, you must place yourself below them. If you want to lead the people, you must learn how to follow them.” –Lao Tsu
Todd left the consultant world and joined the where Mike was working. He became part of the organization within the company responsible for defining and enforcing its SDLC. He worked hard to increase the knowledge and adoption of Agile, despite finding little traction for it. He did his best to lead Agile by example, showing others on his team what “Being Agile” looked like. They added Agile to the SDLC and several teams began to implement it, with varying levels of success. He continued to act as change agent for three years before becoming a full-time Agile Coach.
Mike’s domain decided to go “all Agile”. All new work was to be done using Agile, and all in-flight work was to be transitioned to Agile. They went from three teams to seven, and he led them from an Agile perspective for nine months (during which time they grew to eleven teams). He did his best to learn from his past, letting the teams own their transformations and experiment to find improvements. He developed strong Scrum Masters who understood what it meant to be a Servant Leader. He was able to leave the domain in the hands of a capable successor because he brought her along instead of asking her to just do as told.
3.2.6 Masterless Mastery
“If you don’t trust the people, you make them untrustworthy.” –Lao Tsu
Todd and Mike met when Mike founded the Agile User Group at Walmart’s Information Systems Division (ISD). They eventually began to work together as company-wide Agile Coaches, helping teams and individuals learn Agility so that they didn’t need help anymore. They presented at user group meetings and local Project Management Institute (PMI) chapter meetings. They provided ad-hoc training for teams, including some who had no full-time Agile Coach and weren’t developing software.
Their goal is not to help teams learn how to do Agile. Best practices for doing Agile are always changing and are defined by those who truly are Agile. Todd and Mike protect people from executive mandates and help them unlearn what they have learned. They show them the benefit of short iterations, small chunks, and continuous improvement. They provide an environment conducive to learning so that people can teach themselves competence. And, as necessary, they provide teams helpful tools and practices as examples of “how” to the “why” of Agile.
Todd and Mike have learned that there are different types of workers. Each type of worker has a different way to respond when their management tells them to jump off a cliff. First, there is the person who jumps. This is a bad employee. This employee costs time and causes damage to themselves and their management. Second, there is the person who refuses to jump. Subversively or in open mutiny, they will refuse to damage themselves and the company. However, they also won’t accomplish anything. This employee, while good, is not very useful. The third type of employee shows management that they are asking the team to jump off a cliff. They help management understand the cliff and build a bridge across it so that the needs of the company are met without damage. This is the best employee. This is the employee you get when you don’t try to control people.
The third type of employee is the type that Todd and Mike now try to emerge out of the people they work with. These are the people who will own and drive organizational transformation so that you can take a little time to relax on the beach.
The first technique to getting people to change is to realize they do not need to change who they think they are. In their minds they are the right person and they have what they need to solve the problems. In reality, they are not who they think they are. Their behaviors don’t reflect their values. The things that people need to change are what they think they are already doing.
Most companies have a great mission, great values, and a great written culture. They just don’t realize that their behavior doesn’t always represent the best of their culture. They fail to see the gap in the actions they believe in and what they do. They don’t realize the impact of the dissonance between their written culture and their practiced culture.
People will start matching their behaviors to their values when they see the gap. We believe this is more about people reaching their full potential than it is about changing them. This can be accomplished by holding up a mirror. If people have autonomy and they can clearly see the consequences of their actions, they will change what they do.
From the beginning, we tell stories from Walmart’s past. Sam Walton’s “Made in America” is chock full of stories that teach Agile principles and exemplify the Agile mindset. Walmart has a rich history of telling stories, and our culture was founded on ideals that resonate with Agile in a deep, practical way. By using our past as the foundation for our transformation, we leverage a shared history that is meaningful and accessible to everyone in the company.
One of the exercises we use to help “hold up a mirror” to our cultural disconnect is to write each of our three core values – Strive for Excellence, Customer Service, and Respect for the Individual – on separate cards and put them up on a wall as three points in a triangle. We then have groups align the 12 Agile Principles to one or more of our core beliefs, with the option to not align with any. Though the distribution is rarely the same, every single group is able to align every single principle to at least one of our core beliefs. As we then discuss each of these principles, we ask if they are being practiced in our daily work or not. This allows participants to think of our culture in a new light and challenge our way of working in a safe context.
To get people started with specific Agile practices, we share stories from early adopters. The logic and rationale behind why people begin experimenting with Agile in the first place are commonplace and very real. It’s similar to the reaction Gene Kim says he gets whenever he first meets someone that has read “The Phoenix Project”: “You were clearly writing about my company!” “Who did you interview to find out about how bad things had gotten here?” We don’t speak in hypotheticals; we share real stories that illustrate our pain points and how Agile is helping us overcome them.
Finally, we pull from “The Phoenix Project”, “Joy, Inc.”, and countless other sources to paint a picture of what life could be like for us some day in the future. We share how others have been where we were, worked hard, and become a beacon of hope, a target of aspiration. We paint pictures of a better life and explain how we can’t get from point A to point Z without taking our first steps. All of these storytelling approaches are designed to make the journey to Agile personal, which makes the invitation based change much more powerful.
Why do we embrace some changes and resist others? Think back to a change in your life that you anticipated. Think of childhood Christmases or your first smartphone. Think of the latest new gadget you got. These things change what you do, may even change who you are. Recently, Todd’s daughter received an iPad Pro for her birthday. She welcomed it and it has changed her. She talks about becoming a graphic artist and spends hours drawing on it. This device has changed how she spends time and whom she wants to be when she grows up. Do you think she went through denial and resistance? Did she kick and scream in the store? Did she resist changing how she spent her day?
We anticipate these changes. We enjoy them. Yet we are taught that change is difficult, that it must be managed. We learn to help people “find the cheese”. We bring in consultants and follow change methodologies. Changing people is a billion dollar business. Over 70% of change initiatives fail. We hear that change is hard. We are told that change initiatives fail because people resist change.
People may resist change, but not their changes.
To illustrate this point, think about your watch or bracelet – something you wear comfortably. Now, take it off and switch wrists. How does it feel? What if we told you that you must wear everything opposite of how you do now? That is not an extreme change. How do you feel? How many changes like this will you tolerate? A key difference between the changes we resist and those we embrace is who decides the change will happen. It’s not the nature of the change but how you perceive the change that matters.
So the second secret is that people have to opt-in to change. We can’t guarantee success with this, but we can guarantee failure with a method or any approach that starts with the premise that people can’t choose change.
Todd was fortunate enough to be brought back into the organization where they mandated 400 people change, this time under his own company. He was fortunate that his friends did not blame him. The first change initiative didn’t fail because it was the wrong change, it failed because it was approached in the wrong way.
Over the next three years, the people transformed. Massive changes were made. For example, each project used to start with three-day meetings. By the time he left, people had reduced this to hours. They did this on their own. They did this without big changes. They did it little by little. They changed behaviors and mindsets, and these changes lasted. There was no resistance. The only difference was who drove the change. This approach was founded by people who directed their own changes.
Leadership communicates the overall Agile direction. They provide guiderails, but not mandates. Their leadership is based on invitation. They focus on engagement and help people connect their internal motivations with the needs of the company. They define why the company needs them to change and why people want to change. Invitation based leadership starts by authorizing change.
It starts with meeting people where they are, with respecting them and believing they can make the right choices. We use an Open Space Technology to introduce the problem to people and let them decide what they need to change, how they need to change, and, even who needs to change. We call back to our “Walmart Cheer”, in which associates are asked, “Whose Walmart is it?” to which they respond, “My Walmart!” If it’s their Walmart, then it’s also their transformation. Leadership must repeat this message – the transformation belongs to each person in the organization – until the people understand that there is a problem and that they own the solution.
Coaches are not as necessary as we might hope. This is a harsh lesson; but people can change themselves better than someone else can change them.
When people change themselves, you can get away with as few as one change agent in a thousand. Effectively, you can get a free transformation effort for thousands of associates. We found a way to not only manage the change for those working in the United States; the Agile Coaches have traveled to Mexico, Costa Rica, the United Kingdom, and India to help with the Agile transformation efforts in those offices. As the work of transformation continues to grow, Agile Coaches will likely travel to other development centers around the world in the coming years. How does that work? With the help of Agile Champions.
Success has come from connecting people to who they are and helping them unlock their potential, person by person. We learned this from different sources. We tried our hand at the art of Nemawashi, the Japanese art form for continuous alignment and change. The fundamentals of the process are meeting individually and forming a common vision. The vision is adjusted as conversations are had, person by person, until everyone sees the same vision of how to change to achieve the best possible solutions. Everyone is co-author of the vision that emerges.
Our most recent transformation has, by far, been our most successful one. Three years ago, Todd was asked by our leadership how we were going to transform everyone. At that point, he looked our sponsor in the eye, and with a straight face said, “Five minutes with Mike.” This was a simple way to say that we were going to use Nemawashi. Our sponsor looked at Mike and then at Todd. He was silent for a minute and then he smiled. He could see that we knew that the secret is that change occurs between individuals. It is contagious. It can spread virally from person to person.
We call the virus carriers ‘champions’. Mike was our first champion. There is no question that our success would not have been possible without our Agile Champions. Not only do they relieve some of the pressure on the Agile Coaches, they embrace self-organization and grow in their capacity as leaders and change agents. They show others what it means to be a Servant Leader and help those outside their traditional circles of influence. They are empowered and it shows. As they grow they evolve into greater transformation agents. We call these people Coaches.
We started our “Agile Champion Network” with the premise that people do not need change management. They are capable of changing themselves. Open Agile Adoption is a critical component to changing quickly and cheaply. A key component to this is to help people explore the problems and find their own solutions.
We held an Open Space to kick things off, with the stated objective “[…] to crowd-source the collective intelligence and skill of our associates to determine how they can change themselves.” The first thing to do is to set a theme around the challenge or the opportunity. For example, start with this agenda:
“The Agile Coaches have an immense responsibility for such a small team, which is why the Agile Champions are so important. The leadership and initiative of our Agile Champions takes some of the load off our backlog, allowing more people to get the assistance they need. If you are interested in taking a more active role in the adoption of both ‘Being’ and ‘Doing Agile’, please plan to attend the Agile Champion Open Space.”
One of the first opportunities to pursue is to help change agents (Agile Champions) define their own answers to the following questions:
“What are the responsibilities of an Agile Champion?
“How do we identify existing and emerging Agile Champions?
“How can we better leverage our Agile Champions?
“As we’ve been preparing for this event, one of the frequently raised questions is ‘What’s the difference between an Agile Coach and an Agile Champion?’
“I’ll start by covering what they have in common. Both have a solid understanding of the Agile mindset, or what it means to ‘Be Agile’. Both are change agents who seek to increase value delivery and reduce waste. Both assist others seeking help with their personal or team Agile adoption.
“Now let’s look at the differences.
“An Agile Champion is only expected to have a deep understanding of at least one facet of ‘Doing Agile’. Agile Coaches have a broad understanding of Agile practices, with depth of knowledge and experience in many facets.
“An Agile Champion assists others part-time; he or she is an active practitioner on an Agile team or project. Agile Coaches have experience as a practitioner (and we have organized ourselves as an Agile team), but our full-time job is to assist others.
Out of the Open Space, you’ll get a definition of an Agile Champion and what traits or skills they should possess. Each group will come up with unique outcomes; but here’s some basic outcomes you can expect:
- Knowledgeable about one or more specific aspects of Being or Doing Agile and have a willingness to share that knowledge
- Credibility in the organization
- Excellent interpersonal and communication skills
- Ability to demonstrate the Walmart Culture
- Passionate, positive and enthusiastic attitude
- Commitment to continuous learning and improvement
Agile Champions opt-in to the network, where those seeking assistance can find them and reach out. Champions register with their name, the skills with which they can help others, their location, the number of hours per week they are typically available, and a few other pieces of information. Those seeking help can search by skill and further sort or filter by any of the other attributes before selecting someone to reach out to. If things play out well, you could have hundreds of Agile Champions across half a dozen locations worldwide, all willing and able to help their peers through this journey.
Do not make the central Agile Coaches long-tenured positions. The Agile Coach role should be viewed more as a sabbatical for those who have passion for Agile and have already garnered a reputation for assisting those around them with their transition to Agile. Let people play these roles over a year and a half before leaving to take another position within the company. This helps ensure the working knowledge and skills of the Agile Coaches are relevant to the changing demands that come with an ever-shifting technological landscape. It also seeds the organization with network of deeply connected change agents. This can form the foundation for continuous change.
In addition to the self-service network, the Agile Coaches can keep a pool of core champions at all times to whom they frequently pass off requests for help that they know the champions can handle. This helps the coaches stay focused on the work that they alone have the skills or bandwidth for. Core champions also pair with the coaches frequently to help build up their skills and reputation. It is from this core champion pool that Agile Coaches can be chosen. Make sure future Agile Coaches are chosen by the existing Agile Coaches and not management. Let the team choose successors when one is ready to leave to take on new responsibilities.
We know this is an unorthodox approach to such a massive undertaking, but this works better than anything else we’ve tried and it’s much more efficient.
In one case we saw the amount of work being done using Agile approaches has increased from around 10% to a projected 80%+ by the end of the current fiscal year. Our associates have gone from discussing whether Scrum is a good idea to how we can achieve Continuous Delivery. Our internal Agile Community has grown from 514 members to almost 1500, with dozens still joining every month.
There is no question that our success would not have been possible without our Agile Champions. Not only do they relieve some of the pressure on the Agile Coaches, they have embraced self-organization and grown in their capacity as leaders and change agents. They are showing others what it means to be a Servant Leader and help those outside their traditional circles of influence. They are empowered and it shows.
We continue to grow champions, turn them into coaches, and move coaches into key places in the organization. We keep a small central authority (the Agile Coaches) working with a large, decentralized network of part-time “volunteers” (the Agile Champion). We pull in mentors from the outside to help grow our coaches who help grow the champions. It’s a simple model. We highly recommend it.
That is it; those are the three key lessons we can give you from our 20 years of transforming corporations. The secrets to efficiently using ‘my transformation’ to accelerate change can be summarized as:
The culture stated on the walls is good. The culture practiced often isn’t. Sometimes, all people need to do is to be who they know they should be.
Open Space Agility is foundational. It provides a framework for people to change themselves. Don’t tell people to go agile. Invite them to become better. Get a sponsor, a very powerful sponsor. Don’t have the sponsor do anything. Just get a sponsor.
You can call them champions or let them name themselves. Regardless of what they are called, they will be your friends. These are the people who are open to improving. Invite them to help y’all change.
A very special thanks to others who have taken their turn being a Walmart Technology Agile Coach, namely Barry Nicholson, Amanda Tygart, Joshua Rowell, Steve Thomsen, Jenny Swan, and Selena Hriz.
We also want to thank all of our Agile Champions who have helped make our Agile Transformation the viral sensation it is.
Thank you to our wonderful servant leaders, Clare Matthews and Spencer Offenbacker, for your invaluable insights and WIP-saving guiderails.
Thank you to our sponsor, Randy Salley, our CIO, Karenann Terrell, and the entire Walmart Technology family, without whom we would have no story to share.
Thanks to Daniel Mezick for his early advice, invitation based leadership, and continued mentoring.
Thank you to our coaching mentor, Pat Reed, for sharing your wisdom and drawing out the best in us.
Finally, thanks to our “shepherd”, Tim for your patience and your attention to detail – we couldn’t have done it without you!
Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns, Ph.D. and Linda Rising, Ph.D.
Mezick, Daniel J. The Culture Game: Tools for the Agile Manager. FreeStanding Press, 2012
Mezick, Daniel J., et al., et al. The OpenSpace Agility Handbook, 2 edition. s.l. : Freestanding Press, 2015.
Brown, Tim. Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation. s.l. : HarperCollins, 2011.
Bingham, Tony and Conner, Marcia. The New Social Learning: A Guide to Transforming Organizations Through Social Media. s.l. : Audible Studios, 2010.
Little, Jason. (2008) Lean Change Management: Innovative practices for managing organizational change.
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford
Sheridan, Richard. Joy, Inc.: How We Built a Workplace People Love. s.l. : Gildan Media, LLC, 2014.
Walmart Principles – http://corporate.walmart.com/our-story/working-at-walmart Our beliefs are the foundation of our culture: service to our customers, respect for the individual, striving for excellence and acting with integrity.