Enabling Enterprise Agility
Culture exists in the garden of your mind.
Here is a fun and short video about that.
This is an awesome video from an awesome person who made a huge change in the world.
This man was quite a culture hacker. Enjoy it !
Elapsed Time: 3 minutes 11 seconds.
I teach #Agile teams that when gathering requirements, it’s best to intentionally leverage the “back of mind” of all the participants. This is what I call a cognitive leverage point in team learning. To make use of this, you must restructure your meetings, to leverage the unconscious….the back of the mind.
…it works like this:
We have all participated in long, soul-sucking meetings without breaks, where we are on a kind of death march to complete the meeting. These meetings are highly demotivating…. and also completely ignore (and therefore do not leverage) the extremely powerful “back of mind” feature of human cognition.
The trick is to STOP having long meetings. Especially when working on sense-making!!
Instead, for any kind of important group sense-making task, like requirements-gathering, schedule several short 1-hour-or-less meetings, 1 per day. The first meeting is short, and highly focused, some work gets done….and then it ends.
However, we ALL KNOW that tomorrow we are doing this meeting again. This is where it gets interesting. The game is just beginning…
Cognitive Recycling
Everyone in the group keeps ‘cycling’ and working in the problem when in the elevator, when commuting home, when winding down at home, AND when sleeping. They “work” on the problem, “back-of-mind”, for 24 hours…even when sleeping. (Participants report dreaming about the work in between meetings.)
They anticipate and expect the next meeting the next day, and because of this, they tend to integrate learning, from the “back-of-mind”, even when sleeping. They iterate and re-iterate…cycle and recycle…using the unconscious “back of mind”.
The next day, the deeply integrative learning goes to the front-of-mind, where it is accessed and used to advance the task at hand with the group during the meeting. This occurs at every meeting.
Cognitive Recycling and Permaculture
Cognitive Recycling is a way to get people “thinking” 24X7, even while doing other tasks. It leverages your “backchannel” or back-of-mind, by setting up a clear purpose for a meeting, and some anticipation…via a predictable and scheduled rhythm, or cadence.
As a practice it honors several of the 12 permaculture design principles:
My clients report the following:
Simple Steps for Cognitive Recycling:
To leverage the effects of cognitive recycling, follow these steps:
1. Replace a planned meeting of N hours with N meetings of 1 hour each, on successive days. For example for a 5-hour meeting plan five or 1-hour meetings … on successive days.
2. Schedule the meetings for the same time each day. This is effective, because it establishes the regular period or cadence, which is essential.
Team and organizational learning is NOT random— I teach that we must intend it. Group learning is not automatic. What is nearly automatic is low levels of learning when people gather in groups. Group learning is no accident.
Learning leverage is what you get when you leverage the unconscious processes of the brain. When a group of people actively do this together, leveraging “back-of-mind”, the volume of excellent-quality results can be quite astonishing.
Cognitive Recycling. Give it a try. It’s a technique of Organizational Permaculture.
(NOTE: This and other strong techniques for group learning are described in detail in my book, THE CULTURE GAME.)
Please investigate and consider joining the Organizational Permaculture Facebook group. In this group on Facebook we are mixing people from the agricultural permaculture movement with folks from organizational development, agile coaching, culture hacking and others tribes who are interested in this concept.
DAN LE FEBVRE on: GATHERING AGILE REQUIREMENTS (PART 2)
Slides from this PART 1 of this event are available online as a PDF.
Anyone can attend this meeting, regardless of experience. You need not have attened Part 1 to get the most from this meeting
NOTE: This event is being held at Sungard in Boston. To accommodate security, registration will be closed at 11:30 PM on Tue 6/26. Walk-ins will not be allowed to attend. Please be sure to register in advance for this event and bring a photo ID.
The gathering of requirements is an essential task for every Agile team. Yes, the Scrum framework makes it clear that only the Product Owner owns this task and is responsible for it. The reality is that the gathering and and grooming of requirements is a complex task that must be executed in groups to be done well.
The gathering of requirements and the preparation needed to make these requirements READY for Sprint Planning is a very common ‘pain point’ for Agile teams just starting out. Experienced teams also face real difficulty when the organization is not ready to execute on the deep level of collaboration needed to get the job done.
Attend this session to get your head around gathering and grooming your Product Backlog. We’ll show you 4 specific sense-making tools that can help your team gather requirements at he rate of one per minute. We’ll show you how to groom those same requirements at about one minute per. Since the average Product Backlog has over 200 requirements coded as user stories, you have some work to do. We show you how.
WHAT YOU WILL LEARN
MEETING SCHEDULE
0330PM Agile Scrum Introduction
0400PM Break with light food, beverage
0420PM MAIN EVENT: GATHERING AGILE REQUIREMENTS with Dan LeFebvre
0520PM DONE
0530PM DONE DONE
ABOUT THE PRESENTER
Dan LeFebvre
Dan LeFebvre is the founder of DCL Agility, LLC, a provider of agile and Scrum coaching, training, and transition services. He is a Certified Scrum Coach with over twenty years in software product development as a developer, manager, director, and coach. He has been applying agile practices to successfully deliver products since 2003.
Dan helps software engineering organizations improve quality and productivity. After successfully delivering software products in diverse industries, he has developed a strong passion for helping organizations create great products and teams.
Dan spent two years as the internal agile coach for Kronos, Boston-based Software Company, where he coordinated and implemented Scrum in the 700 person engineering organization across all sites including Massachusetts, Atlanta, Chicago, Oregon, Montreal, British Columbia, Belgium and India. This resulted in increased visibility into the development process and a reduction in defects by 60% in 18 months.
Dan holds a Master’s degree in Computer Science from Boston University. He is a Certified Scrum Master, Certified Scrum Professional, and the first Certified Scrum Coach in New England. He has contributed articles to Scrum Alliance and Boston SPIN. He has presented at Scrum Gatherings, agile conferences, and agile user groups around the country.
NOTE: This is a AGILE BOSTON/DOWNTOWN event. The venue is:
SUNGARD
100 HIGH STREET, 19th Floor
BOSTON MA 02110
Please enter the building through the 100 High Street entrance. You must check in with security at the front lobby with a photo ID and get a temporary pass. After getting your temporary pass, take the elevator to the 19th floor. The conference room can be seen after exiting the elevator.
The notion that “all organizational cultures are of equal merit” is seriously flawed. If the goal is continuous improvement; that is, Kaizen culture, some cultures are better than others. Business history is littered with stories of organizations that learned slow, did not rapidly adapt to change, and went away.
At the level of civilization, it is clear that the most adaptive cultures get to live, while less adaptive cultures get to be dominated and/or die. Early Rome is a good example. In the business world, highly adaptive organizations take advantage of various forms of change and convert it to cash and market position by responding to change faster than less-aware competitors. Apple is a good example here. Google. Facebook. Zappos. The list goes on. When the learning inside these cultures slow down, they can expect trouble…
Let’s call the goal “identifying and exploiting opportunities”. Cultures that are optimized on learning are more adaptive and therefore superior to those that do not. This is the Lean Startup mindset. Where learning is concerned, all cultures are definitely not equal. Some learn faster than others.
So: let’s stop pretending that all cultures are OK, and good, and everything is beautiful and nothing hurts. Because, that is simply NOT TRUE.
Agile is a culture hack in the direction of more rapid learning, in service to more rapidly responding to change. Agile methods (which INCLUDE Kanban!) are the A-B-C steps that build a small Learning Organization we call a Team. Cultures that resist these A-B-C steps are learning slower than those that more rapidly embrace Agile principles. As a result they are slower to respond to change. Organizations with premium, protected, “moated” businesses like insurance can pretend they do not have to learn fast. That might work for awhile, while the pace of technological change is slow. No more. The pace of change is SPEEDING UP and mandating more adaptation. That requires more sensing and responding to change. Therefore, this whole idea that all cultures are OK is seriously flawed. Trying telling it to Google. Try telling it to FaceBook. In the 1990’s tell it to Microsoft. Each of them won big via an adaptive, sensing, responding LEARNING culture.
Let’s stop pretending any business culture is “OK”, even if it is a slow learner. This is a concept that encourages a dangerous disregard for adaptation. Adaptation and learning are tightly correlated. Organizational cultures that are optimized on learning are superior in almost every way to those that are not. When the technology disruption hits your business, you are either ready, or not. This is a major theme of my book, THE CULTURE GAME.
Cultures that learn are superior. Those that learn fast are truly great. Those that learn fastest are magnificent, and eventually have more influence than any other culture in a given context.
(NOTE: I am asking for help. I am looking for books that make the connection between Agile and the Senge’s Learning Organization concept. (Do you know of any??) My book published in 2012. If you know of any book published before 2012 that asserts that Agile methods actually manifest a small Learning Organization, please send me the link so I can honor these people. Thank you !
Related Links:
The Culture Game book (link)
There is absolutely nothing automatic where group learning is concerned.
As a group, we either intend it, or we don’t. Look no further than the current (low) learning levels of typical groups: teams and organizations; and local, state and federal government. Look no further than how nations act and behave with respect to learning.
If learning in groups was automatic, we would already:
AND SO ON. See? Very little of these achievements are actually within reach. Getting all of this kind of stuff done requires people who agree. People who are aligned. No one person can pull any of this off alone.
No, group learning or what I call Tribal Learning, is a highly intentional and uncomfortable act. If it was easy, we’d be colonizing Mars by now. Cancer would be cured. See? You have to intend it.
In a business setting, Tribal Learning requires that we do at least some of the following:
These are the exact patterns and topics that The CultureGame book addresses. Most of these group-level behaviors are very uncomfortable.
That is because learning is uncomfortable.
That is because learning is change, and change is uncomfortable.
To learn as a group, everyone has to want to do it. Or, they have to at least tolerate the new patterns of behavior (see above) that encourage group learning.
Is it really this simple? Yes, it is really this simple.
Tribal Learning: If nobody wants to, it ain’t gonna happen.
Leaders have a role to play in helping people to ‘want to’. I plan to explain that one soon.
The following is printed with permission from Keith Ray. It originally appeared here. The post is preserved here in unadulterated form. In this post he makes certain assertions that start to link Agile practices with the ability to manifest a Learning Organization. This is a great read.
Quotes:
Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit.
and this one…
“….If everybody isn’t learning, then learning becomes a subversive activity.”
What is striking about this post is the obvious development of many of what are called Tribal Learning Patterns in the Culture Game book….blogpost follows…..
============================================
2003.Apr.24 Thu
What is Industrial Extreme Programming?
At the BayXP meeting last night, Joshua Kerievsky, Russ Rufer, Somik Raha, and Tracy Bialik of Industrial Logic gave a presentation on their version of XP that they have developed over the last several years. They named it “Industrial Extreme Programming” (IXP). What follows here are taken from my notes. Any errors are my own.
IXP is what Industrial Logic has been doing the past few years as they work with their clients in training and coaching XP projects. Joshua said he was concerned with recent “blendings” of XP and other methods (DSDM, FDD, Scrum, Crystal) because some of those blendings were throwing away XP’s planning practices (one of the most valuable aspects of XP). Many of these blendings were for the most part untried and unproven, as well, though the unblended methods have records of success.
IXP doesn’t remove any of the core practices of XP (except Metaphor, and few teams have really felt like they successfully used XP’s Metaphor practice). IXP builds on XP, adapting it for survival in larger companies, highly political companies, and large teams.
Kent Beck defined four values of Extreme Programming, values he felt were essential… other values were good, but he wanted to emphasis four in particular. XP’s values are Communication, Courage, Feedback, and Simplicity. Agile Modeling adopted those four and added Humility.
Joshua and his team have chosen five values, which they not only want to emphasize, but insist that the absence of these values in the project or company will cause failure and unhappiness. The IXP values are: Communication, Simplicity, Learning, Quality, and Enjoyment.
The value of Enjoyment is sometimes deemed controversial. Joshua considered Fun, and probably felt Enjoyment sounded better. People who enjoy their work are more likely to want to learn I’ve always said that XP requires a Learning Organization). People who enjoy their work and enjoy working together are more likely to have the teamwork that XP requires.
Quality is “we know it when we see it.” Quality products, quality code, a quality process, quality people.
These are the original XP practices that IXP includes (more or less), sometimes with modified names and meanings: [names in brackets are the original XP names, or the names I prefer over Kent’s names.]
The name changes are for clarity and to expand things beyond just coding — people can pair on other things besides code, collective ownership can extend beyond code. The new practices are:
Readiness Assessment answers the question “Are they able to transition to IXP?” See http://www.industriallogic.com/xp/assessment.html. Viability Assessment answers the question “Is the project idea viable? Profitable? Feasible? Does the project have the necessary resources?” Project Community expands on Kent Beck’s “Whole Team” concept. “People who are affected by the project and who effect it.” (Hope I got that quote right.) This includes QA staff, middle and upper level managers, tech support staff, programmers, DBAs, customers, end-users, and probably marketing and sales. (Reference to David Schmaltz / True North Consulting’s Project Community Forum.) Project Chartering provides the Vision and Mission, as well as the definition of who is in the Project Community. A light-weight exercise that seems to be necessary for clarifying the project’s goals. Test-Driven Management requires objective measures be defined for the success of the project. External results like “support 100 users by December 2003.” The Whole Team cooperates to achieve this goal. Also defines return on investment. Sustainable Pace. They considered renaming this to “Slack” (see the book by Tom DeMarco). An example of the value of slack is that it can provide the time for someone to write the tool needed to increase development speed — too much focus on getting stories implemented quickly can be sub-optimal. Storytelling. I think Joshua separated this out from Planning Game in order to emphasize that story-telling is a natural way to get requirements (sometimes after a bit of coaxing). IXP stories are not necessarily “user-centered” stories, since they may address concerns of administrators, maintainers, etc. “A story is an excuse to have a conversation.” Conversation is required to understand some stories — a story that can’t be understood can’t be implemented. Five words for a story title was also mentioned. Storytesting. One word, to parallel Storytelling. This is defining the acceptance tests, but not writing them. IXP coaches help their clients in both Storytelling and Storytesting. Ideally, you do want “executable documentation” and they talked up Fit by Ward Cunningham – a framework that allows anyone using any editor capable of creating HTML tables to be able to specify acceptance tests. (Programmer help is still required to plug an application into Fit’s acceptance test framework.) Planning Game. Joshua says that it is very weird that some of the hybrid methods are throwing away the planning game. This practice is so useful that many of Industrial Logic’s clients, who did not adopt all of XP, did adopt the Planning Game. Still, the concept of “velocity” (work done per iteration) seems to elude some clients Frequent Releases – frequent end-user releases — same as XP’s practice. Enables rapid return on investment. Releasing to end-users provides opportunity for feedback, to find issues in deployment, issues raised by real live users. “Without learning, feedback does no good”. Small Teams — for large projects, set up networks of small teams, with their own code-bases and coding rooms. A 30-person project might consist of teams as large as ten people and as small as three. Sometimes there might be a testing team and/or refactoring team that join the each of other teams at various times and then move on. Industrial Logic practices Pair Coaching, which does not require that both coaches be together at all times. Pair Coaching does enable coaching larger projects than a single coach could cope with. Sitting Together — Joshua says that the term “Open Workspace” turns some people off, but it is the same concept. He has seen a 40-person XP team in one very large room, but that’s unusual. He has also seen one or more people give up the office they worked hard to get, because pairing in the same room as other people let them focus better and learn more. Sitting together / pair-programming can be done via internet collaboration, so it isn’t limited to open workspaces. The gave an example of a team split in two time-zones, who decided to synchronize their hours to allow more “virtual pairing”. Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit. Examples… Study groups who are not just allowed, but encouraged to get together for three hours a week, during office hours, because they know this helps them advance in their careers. XP Coaches who assign practice drills to the programmers or QA testers. “Lunch Break” learning groups show that management doesn’t care enough about their employees learning. An XP coach in Italy spends an hour a day teaching his junior programmers — whose skills are rapidly advancing. I think an member of the audience said “If everybody isn’t learning, then learning becomes a subversive activity.” Joshua also said that “resume-driven-design” tends to happen because programmers are starving to learn, but not given opportunities to do so. Iterative Usability. The UI must be usable and tested regularly. Management-Tests should be tied into Iterative Usability. Redesign the UI as soon as feedback shows its flaws. Paper-based GUI design was also mentioned. Time was running out, so the remaining practices were discussed quickly… Evolutionary Design. Drives all design. Their tutorial has ten practices for this. (http://www.sdmagazine.com/documents/s=7928/sdmsdw3d/sdmsdw3d.html.) Coding Standard. Have one. Pairing. As per XP, but not just programmers. Collective Ownership. As per XP, supported by tests, pairing, etc. Retrospectives are a critical practice. Some clients are reluctant to get 40 people together for 2 or 3 days for a full project retrospect, but they should do it for the unexpected learnings that come from it. Also do mini-retrospectives each iteration. Refactoring. Early and often as per XP. Don’t let “refactoring debt” accumulate. Domain Driven Design. Even though never officially a part of XP, it has been done by every good XP programmer that Joshua knows. The Model objects are kept separate from the rest of the code (GUI, etc.) The acceptance tests normally operate on the model objects, skipping the GUI. See the book on this subject at http://domainlanguage.com/. See also Erik Evan’s “Ubiquitous Language”. Story-Test-Driven-Development. First write a failing acceptance tests. Then use the TDD cycle (failing programmer test, code to make programmer test pass, refactor) until the acceptance test passes. This is “top-down” TDD, and it best avoids writing unnecessary code. Continuous Integration. As per XP. See http://www.industrialxp.org/ for more information. Check out these papers, too: http://industriallogic.com/papers/index.html |
I am actively looking for people who have been linking Agile to the Learning Organization concept before 2012. Specifically, I am looking for folks who have written anything in books, papers and blog posts predating 2012, that explain how Agile practices are actually the A-B-C steps to building a small Learning Organization that we currently call a Team.
Here are some of the links I have received so far. These links show how pioneering thinkers have been VERY CLOSE to the idea that Agile practices actually are the A-B-Cs that get a group to start engaging in patterns of behavior (the Tribal Learning Patterns) that literally manifest the Learning Organization in small groups.
These are the pioneering thought leaders, the true trailblazers:
Chris Matts: 2003, web page:
http://abc.truemesh.com/archives/000107.html
“…Agile is Learning…All Agile principles and practices are based upon feedback and learning. ”
Chris Matts: InfoQ interview: 2010
http://www.infoq.com/news/2010/05/learning-machine
“…I want the the Agile community to know that the community is in fact a learning machine….. and it is broken. If something is not done to fix it, it will only last another couple of years before it fragments and something else will rise to replace it.” (NOTE: Please examine www.TheCultureGame.com and www.CultureConference.org)
“…I recently wrote a blog post where I state the Agile Manifesto is actually a call to arms to create a software learning community. This is not a recent view of Agile although it is a recent reflection on the manifesto.”
Keith Ray, circa 2003, via his blog:
http://homepage.mac.com/keithray/blog/2003/04/24/
“…Continuous Learning. I’ve always said that XP requires a Learning Organization, and this practice make it explicit.”
NOTE: If the above link is broken, USE THIS ONE: http://newtechusa.net/agile/keith-ray-thought-pioneer/
Keith Ray: A link from Keith Ray circa 2003…
….that covers QUITE A FEW of the Tribal Learning patterns that Agile practices encourage…..no direct mention linking Agile practices to the manifestation of the Learning Org…
http://tech.groups.yahoo.com/group/extremeprogramming/message/82917
There’s a company that provides facilitators and arranges events for
other companies to help them think about their problems. They get a lot of people together in one room (they have places in various cities for
this purpose), and do various exercises not unlike some described in
Norm Kerth’s book on Retrospectives, and among other things do a log of
writing on sheets of paper on the walls.
Senge wrote a description of “the Learning Organization” in his 1990 book, THE FIFTH DISCIPLINE. That book and subsequent books by him and others made it obvious:
Manifesting a Learning Organization is far more difficult than describing one. (The Culture Game book, page 23)
In my book The Culture Game, I explain the following:
1. The software development environment is a complex and harsh place to actually SHIP anything, unless and until you get the “team” thing figured out;
2. The harshness of this situation, leading to colossal failures in software development, costing tens of millions in some cases, led to the Agile Manifesto and the Agile movement;
3. Agile practices, under the “cover story” and mandate of streamlining software engineering, have actually cracked the code on how to build a true Learning Organization, a small-sized unit we call a Team. The Agile movement has blessed the world with this work. We now know how to build a organization that learns….we know how to build a Genius Organization !
4. Agile practices actually build small Learning Organizations. We call them Teams. If we distill and extract the lessons learned from Agile software development, we can build Learning Organizations at scale. This is the entire premise of The Culture Game book.
Now I am looking for others who have asserted this idea before 2012 in a book. I want to identify and interact with and HONOR these authors!
So…..
I am now asking you for help:
If you know of any book published before 2012 that asserts that Agile practices are in fact A-B-C steps for building a genuine and authentic Learning Organization, please send me the Amazon link.
Send it to: dan [at] newtechusa <dot> net
I am very interested in honoring any book authors that have made this connection.
I believe we are on the verge of extending Agile ideas and genuine organizational learning from teams to tribes and eventually, to entire enterprises.
Thank you for your help !
If you work with people, conflict is inevitable. Even the most dynamic, productive teams experience conflict; disagreements arise, ideas collide, and passions about principles can be tested. This could possibly describe your relationship with a customer or two. A key question is: does conflict on your team or with a customer lead to resentment, rivalry or hostility? Whether you answer yes or no, what is the outcome you want and how can you achieve that?
Agile teams value responding to change over following a plan; collaborating with customers to meet their needs; and prioritizing individuals and interactions over processes and tools. A core component for being in alignment with these values is developing individual and team skills for handling conflict so it serves the desired outcome.
In this interactive program, you’ll explore key skills for navigating differences and conflicts at work. You’ll also learn a simple four-step protocol to follow for achieving outcomes that work for all parties involved. You are encouraged to bring a real life situation to the experience for practice.
About The Presenter:
Pat Arcady owns Arcady Mediation, a consulting practice committed to resolving difficult workplace conflicts that cost companies time, money, and diminished commitment by their employee teams. Consistent with the Agile Manifesto where we value individuals and interactions over processes and tools, Pat’s work teaches busy IT professionals how to interact with colleagues and customers in ways that best serve achieving the successful outcomes and ROI work teams seek.
As a former manager at Verizon, seasoned college administrator, and a trainer in the Non-Violent Communication (NVC) system of conflict resolution, Pat is an expert in creating environments that foster high levels of productivity, collaboration and positive morale. As a speaker and trainer, she especially enjoys delivering interactive workshops designed to balance the challenge of new learning and personal growth with the support needed for taking risk.
Pat has a doctorate in Higher Education Administration, a certificate of completion of the yearlong NVC Mediation training program, and has completed the 33 hour Dispute Resolution training at the Community Dispute Resolution Center in Cambridge, MA. Pat resides in Somerville, MA.
Meeting Agenda:
6:30 pm Agile and Scrum introduction
7:00 pm Food, beverages, and socializing
7:20 pm Main Event: Pat Arcady on Interpersonal Conflict Inside Agile Teams
8:20 pm Done
8:30 pm Done Done
Meeting Location:
Waltham, MA
I’m proofing a book for a friend and the book is amazing. It’s on culture. I told you before about the Agile Culture Conference and how Agile is a Culture Hack. In the book, there is a story about really bad service. It’s this story about trying to get a deposit made at a bank by using an ATM that does not work. When I read this frustrating tale of woe, it hit me: no sense of control. No sense of progress.
Now I am telling you straight about why bad service makes you unhappy: it is because bad service associates with a low sense of control and low sense of progress. When your feelings of ‘no control’ and ‘no progress’ hit a certain level, you completely disengage! It’s like hitting the [OFF] button on a human being when control=0 and progress=0. This is a critical lesson for Agile teams. Agile teams do well when sponsors and Product Owners are feeling a strong sense of control and progress.
Anyone who has examined the DELIVERING HAPPINESS book from Tony Hsieh of Zappos knows about his 4-part Happiness Framework found in the Appendix. I’ve already explained it to you in the post on Gaming Happiness At Work.
This table sums up why bad service makes you unhappy:
| Type of Service | Sense of Control | Sense of Progress |
| BAD SERVICE… | Little or None | Little or None |
| GOOD SERVICE… | A comfortable and expected sense of control | Comfortable and expected feelings of progress |
| WOW SERVICE ! | A surprising sense of being honored | A surprising sense of leaping forward (leveling up) very quickly |
Remember, we expect a certain level of service. Expecting something comes from experience. When you expect something, it matches your model of reality. When you are surprised, it doesn’t.
Ok, why do you care? How does expecting something, and sense of control and sense of progress play out in business? Simple:
GOOD SERVICE is the expectation! No one gets a gold star for merely good service. Good service delivers the expected sense of control and progress.
WOW service makes you feel good by OVER-DELIVERING on a sense of control and a sense of progress.
BAD SERVICE is irritating precisely because it delivers a sense of control and progress that is far less than expected.
MORAL OF STORY: Under-promising is a good idea. Do it. It allows you to over-deliver and that makes people happy.
MORAL #2: If others in your market space are always over-delivering, the definition for ‘good service’ goes up. If you do not notice this, you have been checkmated. Your customers automatically disengage and do not tell you why. They just LEAVE.
MORAL #3: If you make over-delivering (WOW) your standard, you change the game for your competitors. They have to constantly “level-up” to compete, and they are always chasing your (re)definition of what is expected!
Summary:
Great service makes customers happy by delivering a strong sense of control and sense of progress. That makes customers feel good. When they feel good about your product or service, they feel good about you.