Agile Open '13 - Toronto

The most exciting thing about attending an Agile conference is that the planning of the conference is Agile as well! This was my first time attending an Agile Open conference where there is no agenda set for the day. The idea was pretty odd to me at the beginning, but when I saw it getting it to work; I realized the power of creating an environment where people can self-organize based on topics of their own interest.

The conference started off with a 1 hour exercise to create an agenda for the day. Our team decided to organize a session on a “New Approach for Product Development”. We wanted to share with everyone the recent experience we had in delivering a product using agile methods in a waterfall environment. When we pitched this idea to the participants, we found out that this topic resonated with other people as well. So we decided to collaborate with another participant who had a very similar experience in this field.

  

We started the session by presenting our stories to the audience and reflecting on the challenge of integrating an agile team within a waterfall organization. Our approach for delivering the product closely followed the methods discussed in the Lean Startup book by Eric Reis. The project started off by creating an MVP in two weeks and re-iterating on this MVP to incrementally build the product. We noticed that some stakeholders had concerns with regards to the quality/ compliance of the MVP to the company’s product standards. It might seem like a negative experience, but in fact that was good news for us. Using this approach we were able to help the stakeholders in clearly articulating their thoughts and ideas to describe what they want to see in the product J

Those thoughts were presented to the audience and then we all brainstormed on how to best integrate the Lean Startup methodology in a waterfall environment. After an in depth consultation about this topic, the team came up with the idea of creating a buffer zone between the delivery team and the process controllers to shelter the agile team from the “usual” waterfall process requirements. This buffer should act like a medium to deliver the minimal requirements that are essential to comply with the waterfall process without affecting the performance of the delivery team. Taking this approach will also require an iterative approach to meeting those requirements as the product will likely evolve over the course of the project.

Another idea that we explored is “How to define the size of an MVP?”. Eric Reis describes an MVP as “the fastest way to get through the Build-Measure-Learn feedback loop with the minimal amount of effort”. Well, we are discovering that in some cases this smallest effort might take several iterations before getting the first MVP out to the market. Especially when delivering an end-user product for a well-established organization that takes pride in the quality of their products. We identified two factors that should be considered when deciding the size of an MVP:

1. Complexity of the business process associated with the product. The more complex the business process the larger the MVP needs to be to be able to validate the end-to-end business value
2. The number of stakeholders within the organization. The larger the number of stakeholders, the larger the MVP will be required and the more frequent releases will be required to test the product

Although the conference seemed chaotic at the begging, I thought it was the best learning experience for our team as we had the opportunity to learn something that we can share with our clients. The organizers ended the conference with having the participants stand in a large circle and asked everyone to share what they learnt during this event. Everyone was totally surprised by the fact that all this learning was for $25 only!

Guest Blogger - Kanban Transformation from the Trenches

This post is written by a guest blogger, a client of ours has participated in one of the largest and most ambitious Kanban transformations that I've had a privilege to be a part of.

Elaine Lee (has played the role of both Business Solutions Manager as well as Enterprise Architecture Manager, whose functions have been heavily influenced by the new direction that her organization is taking as a result of taking a lean perspective. We asked for her input on how she felt the transformation was going, what was working well, and what were some of the challenges...

--------------------

  

It's been a little more than 6 months since our IT organization began introducing completely new practices on a large scale.  Early on it started with foundational training and pilot projects, then in what felt like the blink of an eye it evolved into a reality where Kanban boards surfaced on every wall we had available and lingo like "Stand-ups", "retrospectives", "MMF's", "Story Maps", and "planning poker" have become the norm for us.

In retrospect, it definitely felt very hectic at times with the number of changes we made on a daily basis to refine our new processes into something that has now become the right shape and size for our organization.  As painful as it was I think this approach has been a blessing in disguise that's helped us transform as quickly as we have and allowed us to immediately begin living our future state before the concept became stale from 'all talk and no action'.  It has forced us to immediately get used to continuous change and experience what being flexible and agile really means in practice.  The model of theories was short lived for us because we would immediately start using it whether we were ready to or not.  There were flaws with some of the things we did and how we did it, but intentionally or not it has groomed us to constantly anticipate what the next change will be.  Because of that change in attitude, I find we no longer react to change as something bad, but rather as a means to improve something we've experimented with that needs to be made better.

Our new norm is an environment where most of us aren't embarrassed to ask for help with the new. techniques we've introduced.  It's an environment where there is a much greater tolerance for change.  It's an environment where there is a willingness to try and suggest unconventional ways of accomplishing the result.  I'm optimistic that once we are all physically realigned to be collocated with the teams we work with that we will also experience the effects of great collaboration can bring.  I'm happy with what our new norm is and am excited to see how it will further evolve in the future.

Agile Depth of Adoption Model: A team-focused approach to tracking adoption of agile practices

As part of an IT transformation initiative, we needed a way to validate the success of our minimum viable change initiatives as reflected on the adoption of new skills and behaviours by the project teams. Our initial approach was through a coach-led evaluation of skills and behaviours, mapped to kanban and agile learning tracks and visualized through character sheets with gamification concepts incorporated.     

This approach turned out to be unsuccessful. The fundamental flaw was that it provided a subjective, one-sided evaluation of acquired behaviours and skills, with no participation from the individuals being evaluated. As we realized this weeks later, we pivoted and changed our approach. We did a road show to communicate exactly what tracks were targeted for certain change initiatives, what behaviours and skills were expected to be acquired, and did a turnaround on the evaluation model to make it a validated self-assessment. And yet, the self-evaluations came back with irrational results and opened up too many unnecessary points for contention in the determination of skill-level adoption. Aside from this, there was very little enthusiasm for the character sheets which we were hoping would serve as visual motivators for skills acquisition. 

Recently, we came across the Kanban depth of implementation model by Hakan Forss and have tried implementing this approach on a couple of teams to cover the Kanban piece. The simple, non-threatening, team-focused evaluation approach has proven to be suitable for the teams and the culture of the organization. Teams were receptive to tracking and visualizing their progress beside their physical Kanban boards. Using the same approach, we came up with an Agile Depth of Adoption Model which incorporates targeted practices in the areas of requirements, planning, design and architecture modeling, as well as technical practices such as pair programming, clean code, TDD, build automation and configuration management. Although a natural adoption sequence can be somewhat implied, we decided to implement it loosely where teams can choose to focus on relevant practices and adopt them in a non-linear way as agreed upon and visualized through their Change Canvas. We are hoping that this non-threatening, team-focused approach to evaluating adoption of skills related to agile practices will be more acceptable to project teams since it is more in line with our overall goal of having self-organizing, collaborative project teams that collectively make commitments and share responsibility for results and outcomes.

Using Story Mapping for Defining Business Requirements

Story mapping is a lightweight and collaborative approach to defining and structuring user requirements. Story mapping involves describing the system as a list of features that provide a sequential story of requirements in a user-centric way. It supports iterative delivery where the story is divided into Features which can be prioritized and grouped by planned Releases/Minimum Marketable Features.

Approach

To come up with a Story Map, start out by identifying user personas or the major categories of users that gain value from the system. Next, identify the business/user goals or the major objectives that the system must support. For each goal, determine the user activities or the sequential events that the user needs to do in order to get value. Finally, break the activities down into explicit system Features that have real tangible business value.

Once the overall narrative of the system is understood, the Story Map can be used to prioritize the Features. For each of the activities, vertical component can be added to define the priority of the features with respect to each other. Each set of Features for a particular user activity are reshuffled and stacked vertically according to their relative priority. The top row of the Features on the story map represent the backbone of the product, which is the Minimum Marketable Features (MMFs) that are required in order to have a functional product. Features that may be delivered later (or sometimes never) are placed lower down.

Once overall prioritization of Features necessary to support each user activity is understood, the entire Story Map can be divided by planned Releases/Minimum Marketable Features. Horizontal lanes can be used to divide different MMFs from each other. The Story Map can then be used to tell a narrative for a particular MMF. This is done by traversing the map from left to right and only looking at the Features within a particular lane.

Story Mapping enables both a top-down and bottom-up perspective of the system to emerge. It facilitates understanding of the system from the users' perspective. It also lends itself to iterative delivery in that prioritization and grouping of Features into Releases/Minimum Marketable Features is supported.

Lean Change Part 2 - The Lean Change Stack

It is my statistically unverified opinion that big bang, plan driven change programs work at odds with the way people actually change. People learn differently, and don't react the same way to suggested change.

I've been attempting to tackle this problem through the Lean Change method. Lean Change takes the methods and principles behind the Lean Startup method and applies them to the organizational change lifecycle.

While applicable to many change program, we are cutting our teeth using Lean Change on multiple agile organizational change initiatives. Agile and Lean change is really challenging, and seem to suffer from a particularly high failure rate.

The Lean Change approach allows change agents to iterate through a Prepare, Introduce, Learn cycle, accelerating learning necessary to maximizing the chances that a change program will be successful.

Introducing the Lean Change Stack

Extended from Ash Maurya's Lean Stack, the Lean Change stack provides a set of methods and tools to allow change agents to execute a organizational change program using validated learning that follows a Change Iteration Lifecycle.I'm calling this approach Validated Change.

David J. Anderson' s Kanban provide the infrastructure for the method. Kanban is used to manage the change method, as well provide learning for the success of the change in terms of actual performance. Kanban is also used to provide feedback on the change, giving additional direction for the change program.

The stack has 4 major components:

a Change Canvas, used to brainstorm a set of potential change plans, and come up with initial change model for your change program. The idea of mapping out model or plan using a canvas comes from the Business Model Generation book, by Alex Osterwalder and co.

a Change Strategy Board for laying out how you will accomplish your plan, along with a dedicated Risk Kanban. The Risk Kanban section is used track the flow of risk mitigation, represented as Risk Tickets. 

a Validated Change Board, this is a Kanban system used to track Minimum Viable Changes (MVCs) through the Change Iteration Lifecycle

a Validated Adoption Board, given to change recipients, this board is scoped to represent the data from one MVC only. The Validated Adoption Board clones details contained in the Change Canvas and a Validated Change Board, with only data for the Minimum Viable Change being introduced to a particular set of change recipients. 

In general, information flows from components going left to right. That being said my initial use of these tools indicates that data tends to go both ways and is often completed in parallel. 

A high degree of (daily) synchronization is required across these 4 Lean Change Stack components.

Change Canvas

I have already described the Change Canvas in detail in my previous post on Lean Change.

Again the purpose of the Change Canvas is to concisely describe all of the required components necessary to any successful change program.

The format supports brainstorming quickly over numerous models, and iterating to a new model as further information is uncovered while executing on the change.

Here is an example of the Change Canvas with the contents of an agile IT organizational change program.

Change Strategy Board

Once the Change Canvas has been filled out, (and even while it's being filled out) the Change Strategy Board can be used to start laying out a change plan.

Again I borrowed from Ash Maurya's Lean Stack, using the concept of analogues and anti-logs to help both change agents, stakeholders, and recipients get agreement on the direction that the organization is trying to move to as a result of the change.

Once the overall strategy is laid out, Risks risks can be listed, and flowed through the Risk Kanban section of the board.

Validated Change Board

Actual activity relating to the risk on the Change Strategy Board is represented on the Validated Change Board. Changes are represented as Minimum Viable Changes that passes through the Change Iteration Lifecycle.

The Change Iteration Lifecycle has four major stages, individual MVCs should typically only be in one stage at a time, but may move forward or backwards depending on learning involved.

MVCs are introduced to change recipients by breaking them up into individual change experiments known as Minimum Viable Improvements (MVIs).

During the Understand Reason stage, MVIs represent the work necessary to explore the reason for change, along activity required to find the most suitable guiding teams to act as first movers. Typically initial MVCs in this stage will have a non-descriptive name such as "Explore Change".

Once a potential guiding team has been found who' is passionate for responding to that particular change driver, the MVC may pass into the Definine the Change stage. 

During this stage multiple MVIs are deployed with the express purpose of brainstorming potential solutions with both stakeholders and the potential guiding team. A key milestone necessary to moving this MVC out of thisstage is securing commitments in terms of both time and effort from all change recipients being impacted by the change

Validated Adoption Board

Changes are introduced and adopted during the Validate Behavior & Verify Performance stage. Before the validate behavior states can begin, a Validated Adoption Board is introduced to the guiding team. 

The canvas portion of the Validated Adoption Board is built during the Defining the Change stage. This section somewhat equivalent to the Risks and Experiment Layer found in earlier versions of Running Lean. Only details relevant to the Minimum Viable Change being introduced are shown. 

The Validated Adoption Board also contains a dedicated Kanban used to track the flow of Minimum Viable Improvements that relate to the specific MVC.  The Validated Adoption Board makes it easier for change recipients have a clear understanding of what changes are being introduced to them, and the potential flow and future changes. 

This board is placed as close as possible to the physical location of the change recipients, and typically synchronized with the Validated Change Board on a daily basis.

During the Validate Behavior stage, learning focuses on evaluating behavior, and the impact of change on that behavior. We are still evaluating different mechanisms , but all of our current approaches are based on a voluntary, self assessment approach.

During theVerify Performance stage, learning focuses on evaluating how change impacts business objectives and organizational performance.

For agile related organizational change, we are using Kanban systems to measure the impact of lead time and throughput based on the introduction of a particular Minimum Viable Change.

Lean Change Part 1 - Combining Kotter and Running Lean

I have been spending the last six months or so enabling a large-scale IT transformation by combining Kanban with some of the principles and methods taken from the lean startup world.

The major problem with the existing method as it exists so far is that our minimum viable changes (MVC) lacked an overarching change lifecycle. We need a better approach to accelerate learning, an obvious one (in retrospect) is to make sure minimum viable changes are designed, socialized, and introduced in order of the highest risk.

Lean Change Iteration Meta-Pattern

I have supplemented the method to include a lifecycle that tries to accelerate learning in the right sequence for organizational change. My inspiration comes from two separate sources.

The 8 Steps of Change from John Kotter's - Heart of Change

The Lean Startup Stack from Ash Maurya's - Running Lean Book and Blog

This is my first attempt at taking some of the principles from Ash’s Running Lean and integrating them with Kotter's 8 Steps. The idea is to run a change program by:

1.  creating an initial change plan , capturing initial change model hypotheses

2.  identifying the riskiest parts of the proposed change, sequencing activities to mitigate resistance to change, validate correctness of the change, then mitigate the sustainability of change, and finally understanding how to optimize the change across the organization

3.  systematically testing the assumptions behind the change, iterating through an adopt, observe, and learn cycle similar to the validated learning cycle recommended by lean startup evangelists. I call this cycle Validated Change.

Stage I -Creating an Initial Change Plan

The Change Canvas facilitates planning a change program in a way that is that is fast, collaborative, and deliberately imprecise. The constraints of the size of the sections in the canvas encourages change agents to distill the plan into a form that is easy to communicate, and more important easy to change and easy to throw away.

Change agents collaborate to  develop an overarching Change Canvas filling up each section as follows:

1.  Urgency - List the top three drivers for change, identifying those most impacted by the change, as well as key decision makers

2.  Change Recipients - note those impacted by change, segmenting by role, level, and team as appropriate. Take a stab at identifying potential change champions, along with their current capability to realize change, and tactics potential champions are using now to mitigate relevant problems

3.  Vision - write down the vision that you believe will resonate with your organization, note key behaviors required to realize his vision. Create a "high concept pitch" that is easily repeatable

4.  Target State - determine a strategic enabler, descriptive metaphor, framework, and any other type of foundational component required to realize your vision. Align each element listed within your target state to one of the top three drivers listed in the urgency section

5.  Action - change tactics guiding teams will use to rollout the change, pay special attention to how your guiding teams will participate in rolling out your first minimum viable change

6.  Required Investments - list known hard constraints in terms of time, budget and people time. Write down known barriers to change.

7.  Benefits - List the expected benefits, both qualitative and qualitative

8.  Success Criteria - put down The key indicators you will use to tell you the same have successfully stuck

9.  Communication - mark down how you plan to communicate change. Note both high touch and push-based methods of communication necessary to collaborate with your guiding teams, and also taken note of other communication channels you plan to use as the change skills across the organization.

Stage II-Identifying the Riskiest Parts of Your Plan

Change agents collaborate to build an overall change canvas, and then create several refinements scoped down to represent the first Minimum Viable Change that would be introduced to the organization. Canvases are evaluated according to their ability to express a MVC that that accelerates learning and mitigates the most severe change risk.

What risks are considered the most severe will change depending on the context of the change program. That being said here are some typical change risks ordered by severity:

1.  Resistance to Change (Urgency) - target the initial change effort on members of the organization who are most able to identify with current pinpoints. The goal is to target your change efforts towards individuals who are feeling the pain stemming from current problems that the changes meant to address.

2.  Ease of Collaboration (Communication)- initial change efforts need to be focused in such a way that problems can be collaboratively solved by guiding teams. Try to choose a plan that allows your guiding team to work in a high touch session, prefer face-to-face over distributed and/or dispersed teams. This won't guarantee your executing the rate change, but it will accelerate your learning.

3.  Sustainability of Change (Investment/Benefits)- the success of the change is largely a factor of the actual commitment to leadership is willing to provide to that change. Securing bottom- Up commitment is equally critical. Choose A plan that gets the most commitment from sponsors, and secures the space necessary for the guiding team to be successful.

4.  Impact of Change (Change Recipients) - choose a segment within the organization (role, team, level, etc.) that will have the most impact on realizing the vision, in relationship to the time and effort spent by the guiding team. However, make sure to avoid falling into the trap of implementing a big bang change, still following minimalist approach

5.  Correctness of Change (Vision/Target State) - revisit your target state to make sure that the suggested change is realistic given the context of the organization, but also that it represents the minimum set of improvements required to demonstrate progress against the vision of your transformation

Key stakeholders and decision-makers are required to evaluation each MVC Canvas and select the one that  tackles the riskiest elements first and provide the maximum value.

Stage III-Systematically Testing the Assumptions behind Your Plan

Sequence Your Testing According to the Change Lifecycle

The Change Canvas was designed with Kotter's 8 Steps of Change in mind. The idea is to enhance the 8 steps with a method that de-risks the change through systematic testing. This is done by iterating through the canvas numerous times as necessary to implement a set of incremental changes (our Minimum Viable Changes, or MVCs.)

At a macro level, change agents refine the canvas over time as they learn more about what is required to make the change successful. Change agents revisit the canvas following the 8 steps iteratively,  in order to maximize learning, enabling Validated Change.

Increase Urgency

Create shared understanding for the top reasons that the change is happening. Use interviews and other observation that makes To understand how these drivers for change are perceived by those most impacted by change. Understand how the organization is currently mitigating top pain points as relating to the change, and the current capability in place to successfully execute on the change.

Build the Guiding Team

Truly understand who is impacted by the change, as well as key decision makers. Ensure that change drivers are tied to problems felt by those who will be impacted by the change. Validate shared understanding of key drivers by what people are currently doing, not just by what they're saying.

Hone in on potential change champions, looking at capability, and passion for the problem. Work with potential champions are resolving problems currently, and start building a guiding team.

Get the Vision Right

Create a vision that resonates with all levels of your organization, starting with your guiding team. Synthesize Key Behaviours based on how your guiding team behaves today. Create and share a 'high concept pitch' that is instantly repeatable by all involved.

Communicate for Buy In

Pay particularly close attention to communication channels. Poor communication is one of the top reason change fail. Start with high touch, personal, and push based methods of communication. Evolve to self serve, online, and media in order to scale. Cement a bi- directional flow of communication

Empower Action

Mark down your target state, focusing on designing the simplest, short term solution that addresses the key pain points for your guiding teams. List the change tactics your guiding teams will use to execute the change, paying special attention to your first Minimum Viable Change (MVC). Secure permission to act!

Create Short Term Wins

Roll out the first MVC with the guiding team. Pay close attention to behavior and coach as necessary to get A breathing sample of your vision. Validate that your guiding teams are receiving benefits as appropriate to the constraints (time and effort) involved.

Don't Let Up

As subsequent minimum viable changes are successfully rolled out by guiding teams, focus can switch to overall organizational adoption. The emphasis now is on optimizing Change according to hard constraints in terms of time, budget, and people's time. At first focus on your initial set of Minimum Viable Changes. Continue to test the change for benefits, both qualitative and quantifiable.

Make Change Stick

Continue to follow the validated change process, introducing successive minimum viable changes, until change is now the new reality of the organization. Pay attention to key metrics and indicators that will inform you as to when change is truly stuck in your new organization.

Advice on What Parts of the Canvas to Test First

Once you have chosen the canvas that represents a minimum viable change that will maximize learning, you are in a position to start testing inter-related sections of the canvas. Different sections of the canvas visualize different types of risks.

Change risk can be mitigated by validating portions of the canvas using a combination of customer development style interviews, observation, and measurement of implemented change.

Change agents would typically execute the change by mitigating risk across different categories. An example of the order that canvas segments cold be visited is shown below.

During my next post I will provide an overview of how I plan to further adapt the lean stack to implement individual experiments necessary to roll out an MVC.

Lean Startup for Change is Dead! Long live Lean Change! Long Live the Lean Learning Machine!

About 6 months ago I started experimenting with running IT Agile transformations using a new method dubbed by a few of us as Lean Startup 4 Change. The idea was to incrementally introduce change to an organization as a set of Minimum Viable Changes, taking advantage of validate learning, and preparing the client for pivot and pursue decisions.

As of this time I still don't feel like we have achieved validated learning, ie being able to mitigate risk and accelerate learning while building a sustainable change. 

Lean Startup 4 Change is Dead

A  part of the problem is that our lean startup 4 change method simply has to much stuff on it. (Gamification, Capability Models, etc). As of this point forward we are breaking the method into two distinct pieces that independently can be more faithful to their inspiration.

Long Live Lean Change

First of all IT Organizational Change is not a startup, so the term Lean Startup 4 Change really doesn't make sense. Maximizing validated learning by focusing on what's minimally viable does still resonate as being vital to running a succesful change program.  It seems that the underlying principles behind Lean Startup are applicable to any problem space with high uncertainty. Lots of different problems could be handled better with a pivot or pursue, hypothoesis driven mindset.

With that in mind I have rename the method to Lean Change, and defined it as:

A method that helps change agents to maximize accelerated learning necessary to plan and execute a succesful Agile / Lean organizational change. 

That definition will most likely change :)

I am continuing to build Lean Change by abstracting pieces of the leanstartup framework into an an underlying set of meta components than tailoring those meta component to make them suitable for Agile change inititiatives. 

Example of these adapted components include creation of a Lean Change Canvas, and altering the meta-iteration life cycle  into a Lean Change Meta- lifecycle. Up next is cataloging  a sequential set of change risks along with some recommended strategies to coming up with Minimum Viable Changes and Minimum Viable Improvements that mitigate those risks. 

I should stress that these techniques are a port of the methods and tools that Ash Maurya has created as part of his Running Lean book and blog posts. His works are second to none when it comes to providing easy to understand advice on how to run a startup using lean methods, and I am finding it a pleasure to map these over the change world.

I am borrowing from classic change methods such as Kotter to come up with how the lifecycle can interact with the Canvas to test hypothesis relating to validating change drivers, getting the target state right, amd validating behaviour of change recipients is actually changing.  I'm also workng with our firm's human capital practice to get their take.

Lean Change will continue to heavily use of David J. Anderson's Kanban to allow change agents to quantifiably verify performance. I don't see Lean Change working without Kanban being a core component. Not to mention that it is a measurable, viral, bottom up continuous improvement framework :)

Lean Learning Machine

The role playing game style character sheets, levels, missions, characters classes, peer based learning, etc has been abstracted away from Lean Change. The Lean Learning Machine is a customizable agile learning engine that allows change agents to create an agile learning path and use game play to promote organizational self learning.  The idea is that true agile change only happens when you no longer have to hire coaches, so we want to promote a coaching network, visualization of skill, and clarity around what to learn while respecting the fact that every change is different, and no two people wil advance the same way. 

Eating My Own Dog Food

I think the most important change is that both of these projects will be developed using lean startup methods. I'll be using Ash Mairya's Running Lean, as a process template. Here are the initial Lean Canvas below.

Lean Change Canvas

Lean Learning Machine Canvas

Up next will be problem interviews where I hope to get my target customers (I think it's Agile Change Agents...) to tell me if this either of these are even a problem worth solving.

Stay tuned...

If it Sucks it Shouldn't Sell

Most Political TV adds go so past the point of pandering, that they insult the uneducated and educated alike. 

Canadians tend to get horrible service from telecommunication companies, bad airline experiences, and unsatisfying medical care. Americans seem to face a similar reality.

Enterprise software seems to universally cause groans of dismay from the people that actually have to use it.

Consultants continue to provide their customers with target states and roadmaps that seem largely divorced from the reality of implementation. Clients continue to ask for more of the same from consultants.

So many aspects of our lives are contrained by a set of choices that are undifferentiated in their lack of ability to cause customer delight. 

Despite the heralded coming of the customer economy, a wealth of products and services are still push based. The provider decides on the thing to be built, and pushes a predetermined experience to the user. Customer feedback is completely mishandled, wether the reason is ignorance or incompetence is anyone's guess.

As consumers, we try to make different choices, but still end up with more of the same. 

Certain organizations, mostly from the tech world, seem to excel at pleasing their customers. These companies focus on the best experience for their customer, and garner political will to chase after the best customer outcome. These companies have faith that profits will come from customer delight, and know that the reverse can never be true.

What is preventing this customer experience revolution from moving faster in the corperate and public sector world?

How do we accelerate the adoption of design thinking, synergistic methods, and the mantra of the modern knowledge worker into places like Health, Banks, Government, and Insurance providers?

If it sucks it shouldn't sell, and we shouldn't buy....