Six Tips to make Story Mapping more effective

Story Mapping is a practice that helps you experience a customer or user journey. You would first capture the end-to-end customer experience by asking what would a user do? This includes establish a backbone, steps, and options.  

The story mapping process promotes the team to think through elements of what the customer finds as valuable from a process perspective. It moves away thinking of functionality first and instead advocates thinking about the customer experience first.  Then you would use an incremental approach of building, inspecting, and adapting for the next increment. What might be some tips to help you more effective work through a story mapping session? 

Tip #1 – Craft your Persona (aka, customer)

Draft the persona that will be taking the customer or user journey.  Place the persona at the top or head of the story map. This provides empathy for the user and inspiration for those that are attempting to craft the journey through the eyes of the user (via the story mapping practice).  Learn more about personas at Personas - Getting to really know your Customer.  

Tip #2 – Everyone stands up around the story map

As simple as it sounds, have everyone working on the story map session stand-up and around the story map as they are creating it. This keeps everyone engaged on crafting the story map.  

Tip #3 – Everyone writes options

When it comes time to imagine options for each step along the customer journey, provide everyone with a post-it pack and marker.  Ensure everyone knows that they should put up the option ideas as they think of them.  This gets lots of options up quickly. This also reduces any single threaded thinking where only one person is doing the writing.  

Tip #4 – Promote lots of chatter during Affinity of options

After a number of options are written by a number of people, it is time to determine if there are affinities.  This is a good opportunity to promote conversation for understanding the customer journey together as each option is discussed.

Tip #5 – Ask owners of options if they are similar

If two options are similar, ask the owner of each to determine if they form an affinity.  Often times when there are similar options on post-its, those that didn’t write them speak up to discuss if they are indeed related. Instead, those that wrote them should determine the affinity (or not) as they would know better.  

Tip #6 – Use verb/noun

Use short verb/noun phrases to capture the backbones, steps, and activities (e.g. capture my address, view my order status, receive invoice). This helps with understanding the expected action for each step of the user journey. 

You can learn details of executing a story mapping session at Story Telling with Story Mapping.

Dangers of Certainty in Realizing Customer Value

Don Quixote was certain he saw Giants instead of windmills. In this epic story, he believed he knew the answers and saw what he wanted to see.  Unfortunately in many organizations, there is this same phenomenon, a need to act as if we are certain.  In fact, the higher up you go in an organization, the compulsion of acting with certainty becomes greater and greater.  Statements like “That’s why we pay you the big bucks” are used to imply that the higher in an organization, the more you are expected to just “know”. 

Some think they must act with “pretend certainty” for the benefit of their career.  Others have convinced themselves of “arrogant certainty” where they believe they know the answer or solution but don’t (or can’t) provide any solid basis for this certainty. Unfortunately this arrogance can be interpreted as confidence that can be dangerous to the success of a company.  Nassim Nicolas Taleb refers to “epistemic arrogance” that highlights the difference between what someone actually knows and how much he thinks he knows. The excess implies arrogance. 

What has allowed certainty within companies to thrive is that there is a distance between the upfront certainty and the time it takes to get to the final outcome.  There lacks accountability between certainty at the beginning and the actual results at the end.  Often times the difference is explained away by the incompetence of others who didn’t build or implement the solution correctly.

Of course, the truth is somewhere in between. The concept of certainty is actually dangerous to an enterprise since it removes the opportunity of acknowledging the options and allowing the enterprise to apply a discovery mindset approach toward real customer value via customer feedback loops and more.

We also want to avoid the inverse that is remaining in uncertainty due to analysis paralysis.  A way to avoid this is to apply work in an incremental framework with customer feedback loops to enable more effective and timely decision-making. Customer feedback will provide us with the evidence for making better decisions. Applying an incremental mindset will enable us to make smaller bets that are easier to make and allow us to adapt sooner. 

A healthier and more realistic approach is to have leaders who understand that uncertainty is actually a smart starting position and then apply processes that support gaining certainty. It is, therefore, incumbent upon us to have an approach that admits to limited information and uncertainty, and then applies a discovery process toward customer value. In the end, the beaten and battered Don Quixote forswears all the chivalric false certainty he followed so fervently.  Is it time for management to give up the certainty mindset they think they have and instead replace it with a discovery mindset as a better path to customer success? 

There is no Success or Fail, only Learn

I have been in discussions both in-person and on twitter with colleagues on whether we should use the word “fail” or “learn”.  This was in context to projects (aka, releases, increments).  Did they failed or did we instead learn.  I also realized that the term “fail” is somewhat subjective (e.g., did the whole project fail or just parts of it?).  The overwhelming agreement was that “what did we learn” was a better way to discuss the findings or results. This lends itself to a shift in mindset, to a continuous learning environment that recognizes that there is value even in the negative feedback.   We can learn from that feedback and adapt for better results in the future. 

Then it occurred to me, the term “success” was also a bit subjective.  I recall reading a Standish Group Study where those projects that were “deemed” successful, 45% of the features were never used.  Another 19% was rarely used.  This meant that projects deemed successful built 64% never or rarely used features.  That seems to be a very loose definition of what “success” looks like.  In addition, how many projects are deemed successful because it met the scheduled deliver date yet few customers upgraded to it or bought it?  Is there a benefit to use the term “learn” in place of success?

While it may sound feel like the terms success or fail are the way to traditionally judge a project, release, product, or service, we lose sight of the most important result of the work, the feedback and what we learned from that feedback.   This learning helps us adapt to achieve better results.  If you are working in an Agile context where there are short increments of work, there is the benefit of continuous learning where you can continuously adapt for better business results.

I would suggest in the modern lexicon of work, when a project, release, or increment of work is done, it is much more important to ask what was learned instead of classifying it as a success or failure.  This strengthens the mindset within the organization that there is a value in feedback and the most important thing is what did we learn.  It also emphasizes a discovery mindset where what we think a customer wants is really a hypothesis that must be explored.  It is in the learning that can help us lead to better business results in the future.  So next time people talk about a project as a success or failure, instead turn the discussion around and ask “What did we learn”?  

How Value Stream Mapping can help your Agile Journey

Would you be surprised to learn that many people who participate in getting an idea to market are not very aware of all of the steps it takes to get it to the customer?  People know their sliver of work well but when asked if they know where in the full process their slice lives, it can be a bit challenging to pin it down.  One solution is to apply Value Stream Mapping (VSM) to gain that end-to-end view. 

Value Stream Mapping is a lean method for mapping an end-to-end flow of a product or service from the idea to the delivery to the customer.  It represents all of the activities required to transform a customer request into a product or service.  More importantly it is a way to optimize your flow through understanding what the state is today and then incrementally improving it over time to reduce waste and achieve faster delivery.  It is a means to help you optimize the value being delivered to the customer by creating a value stream that indicates what is value and what is waste.

Having applied Value Stream Mapping a number of times, the first benefit is it makes people aware that they are part of a much larger value stream than they thought.  People start to realize that there are more upstream and downstream steps and interdependencies than they thought.  It can be quite an eye-opener for some. 

The next benefit is that it highlights the end-to-end flow of work, not just the development work.  Some folks like to highlight only the development work and fail to realize that there are activities occurring prior to and after development.  An example is that if you are applying a yearly planning process, an idea or customer request may sit in the planning pipeline for upwards of half-a-year.  This is a very slow way to get an idea to market.  An end-to-end view ensures we visualize the full picture starting with an idea or request and then understand the amount of time it can take to get it to market. 

Another benefit is that now we visualize the end-to-end view of the work, we can identify the value-added and non-value added steps as well as the waste (e.g., wait) states.  It becomes much easier to become aware of the value and non-valued steps and waste when the big picture is in front of us. 

And most importantly it provides us an opportunity to incrementally improve.  Now that we are aware of the end-to-end value stream and we know what steps are value and where is there waste, it is time to experiment with incrementally improving the process.  The primary goal of the incremental improvement is to increase the process cycle efficiency and reduce the lead-time from the idea or customer request to delivery. 

Process cycle efficiency is a number that represents the efficiency of your lead-time (concept to cash).  It is a summation of all value-added time divided by that same value-added time + all of the wait/waste time.  A process efficiency example is while the value-add steps takes 115 minutes and the full processing time takes 2275 minutes, then you divide 115 by 2275 or 5%.  The goal is to look for those incremental areas of improvement.  

How does this help in an Agile environment?  If a goal in Agile is to get an increment of value to market quicker, then by identifying waste in your end-to-end value stream, and removing it, can reduce the time to get that value to market.  Value Stream Mapping is yet another tool in your Agile toolkit.  Consider learning more about Value Stream Mapping and experimenting with it for incremental improvement.

Agile and the Cloud – Match made in Heaven!

Agile and the Cloud are both pervasive these days.  Agile is a software development method based on an iterative and incremental approaches. Applying an Agile method and mindset can, on the one side, can incrementally build Software as a Services (SaaS) based products and, on the other side, utilize IaaS (Infrastructure as a Service) and PaaS (Platform as a Service) to build the SaaS products and services.

As most software professionals are aware, the action of delivering the increment into the traditional on-premise software product environment is often laborious and time consuming. SaaS conveniently provides shared software products as services, and associated data via the Internet, a model that can be scaled and configured to a company’s or product team’s needs. SaaS changes the software paradigm by providing the software as a service “in the cloud” to people and companies that need that product or service. Companies no longer need local administrators to handle the rigorous and time-consuming effort of establishing on-premise product infrastructure and the installing the software.

When building products for the cloud, a production-ready environment is made available to teams almost instantly. While most products require an on-premise installation, building cloud products reduces the need for the often rigorous and time-consuming effort of installing the new releases of the software product infrastructure prior to the installation. Because Agile utilizes an iterative and incremental approach, SaaS products can be incrementally upgraded when the Sprint Review (aka, demonstration) indicates that the product is ready. The effort on the SaaS provider side is reduced also, because a few installations by experts are much easier to develop and manage than the many installations by customers (and documentation, ramp-up, and problem resolution that are included).

On the Agile side, the challenge is to build an infrastructure that supports Agile and does not impede the progress of the Agile team that must continue to deliver value. A simultaneous goal is to avoid investment in infrastructure that may not be needed in later phases of the project. One suggestion is to utilize the infrastructure envisioning approach, which applies an incremental approach to the continuous establishment of an effective infrastructure. This is where Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) can be useful to Agile teams. The cloud IaaS and PaaS approaches enable consumers to only use and pay for what they need. This is a distinct advantage for incremental development processes like Agile. This "use-what-infrastructure-you-need" approach minimizes technology debt and allows the team to adjust and scale its needs just-in-time.

As Agile methods continuously build SaaS product increments (i.e. functionality), the cloud delivers them as increasing business value to the customer with little effort from the customer. In addition, the cloud (by way of IaaS and PaaS) provides Agile projects with tools and infrastructure just-in time, so that the team always has the tools and infrastructure they need but never wastefully invests in unused equipment. Consequently, they are able to provide continuous value to the customer in the cloud. This mutually beneficial relationship is a “match made in heaven” for project teams utilizing Agile to build software in the cloud and using cloud infrastructure to support Agile projects. 

Have you benefited with the Agile and Cloud relationship?  If so, in what ways?