Wednesday, June 26, 2019

New CX Journey Inc. Website Launching!

Image courtesy of Pixabay
CX Journey Inc.'s site is growing up!

I'm so excited to have a new site going live this week! I'm sharing this note as a blog post as it will be my last post on what is currently

A couple of things to note:
  • This site will will revert to my previous Blogger URL,
  • The new site will take over the URL.
  • I'm moving the site over to WordPress, but this Blogger site will remain live for some transition period.
  • Most of the content will remain here during that transition period.
  • If you've subscribed to receive my blogs in your inbox, your subscription is safe. We've moved your subscription over to the new site, as well.
  • Of course, if you haven't yet subscribed, please do so on the new site.
If you have any questions, experience issues with the new site, or aren't seeing new blog posts in your inbox next week, please let me know.

Thank you!

It is not necessary to change. Survival is not mandatory. -W. Edwards Deming

Tuesday, June 25, 2019

Agile Working in Practice: More Tips to Help Analytics Teams Transition

Image courtesy of Pixabay
Today I'm pleased to share another guest post by Paul Laughlin. This post originally appeared on Paul's site on March 9, 2019.

This is the second in two-part series from Paul about agile working. Find the first post in the series here.

In my first post on how to achieve agile working in practice, I focused on four principles that were needed - principles of attitude and culture in order to have the right mindset and approach to working this way.

Continuing with this series has been driven by the feedback I have heard from a variety of data and analytics leaders. Those working in business today are telling me that this challenge is still very much a work in progress. Senior leaders want a more agile business, but it’s not a quick fix to achieve.

To help, in this post I focus on two more aspects. Firstly, common practices, that I’ve observed in analytics teams implementing this approach. Then four drivers of success that I and other writers have observed. Those behaviours and attitudes that differentiate those who achieve successful Agile Working.

Agile working in practice: common practices
At the start of my first post on agile working, I referenced the five most popular agile methodologies. But, whether you are implementing Scrum, Kanban, or one of the others, certain practices appear to be needed by most methods.

So, whatever nomenclature you prefer, watch out to ensure you are implementing:

(1) A visible "backlog" of prioritised work
Every member of the team can see new work and any significant changes needed. One key here is having real clarity as to commercial priorities and drivers, so that requests for work can be compared and prioritised.

(2) Tickets for the units of work needed
Work is broken down both to suit time periods for sprints and to divide the different skills needed. One key here is the ability to diagnose early on the work units needed from different data, analytics, and other skills – worth planning out common work units in advance (based on experience). Plus, the use of tools like competency frameworks to raise awareness of skills really help with allocation.

(3) Public boards to track progress
Internal customers, sponsors, and the wider team have a common view of priorities and progress. Such transparency is key to the culture needed for this collaboration. One key is to consistently use this to support stakeholder management and sponsor conversations. Driving expectation of them using the board too.

(4) Planning short sprints together, with bidding for units of work
A regular rhythm, e.g., two weeks, is established as the duration for delivery and cycle for new priorities. One key here is the cultural attitudes I praised as needed in my first post; another is to focus more on collaborating in order to achieve delivery rather than more rigid planning.

(5) Stand-up meetings for the whole team to share progress and challenges
Regular opportunity, e.g., daily, to spot issues early and collaborate to fix. Once again, the attitudes and culture I shared previously are crucial to this working well. Managers also need to ensure that they encourage openness about issues or mistakes. Good news: reporting is the very antithesis of agile working.

(6) Post-sprint reviews to learn from what worked and what did not
Time is taken post-delivery to identify any lessons to be learnt for future sprints. One key here is to focus on systemic issues. Depersonalise criticism and work on improving how everyone works together to improve the system for future work. Any under-performance by individuals should be handled separately. Use one-to-one chats with managers, where possible giving close-to-the-moment feedback.

I have documented such a simple list to help reveal that a significant amount of agile working is not "rocket science." You may well have more success by simplifying to ensure everyone gets it, rather than an over-complex purist approach.

Agile working in practice: drivers of success
Through a combination of reading other blogs on this topic and reflecting on what I have seen in practice, I have four drivers to propose.

Driver 1: achieving personal "flow"
Despite all the focus on collaboration and flexible team working, Agile working also relies on high-performing individuals. At its best, team members know their strengths and have honed ways of working very productively.

Entering a state of "flow" - that state where you no longer notice time passing and are not easily distracted - is important for leaders and analysts. You are absorbed in the task and make surprisingly fast progress. I may well blog more on this important topic, but for now I recommend those interested to read Mihaly Csikszentmihalyi’s book, Flow.

Driver 2: a culture of Collaboration
"We are all in this together." Rather than being political spin, it should be the ethos of working this way. Successful delivery relies upon a flexibility and mutual support that is often not present in larger teams working within more rigid projects.

Team members should be encouraged to stay aware (keep eyes and ears open) of both their own progress and how the wider team is doing. Joint success often relies upon a willingness of every team member to both ask for and offer help. Once you are winning with your work unit, look up and see where you could help with other top priorities.

Driver 3: learning continually
Agile working has close affinity with the principles of continuous improvement from Systems Thinking. A commitment to spotting and closing gaps in knowledge and skills, plus a thirst for personal growth are key attitudes from effective team members.

A visible organisational commitment to Personal Development Plans can really help. In too many businesses, large and small, these can be token efforts – too easily reduced to documenting a book that was read or a training course attended. Embedding a culture of L&D takes time, but supporting individuals with time and money to prioritise their development pays huge dividends in improving team effectiveness - what Stephen Covey called taking time to "sharpen the saw."

Driver 4: reliability and clarity
Every team member in an agile working team needs to both understand what is asked of them and keep their promises. The lifeblood of working this way is effective communication, and it requires a higher level of personal responsibility, not less.

The old adage of "my word is my bond" is the attitude to encourage here, and leaders should challenge individuals if commitments are not delivered. Accountability is needed to avoid drift and any degree of hiding behind collaborative processes. In addition, I recommend investing time in developing leaner and more-effective communication. I recommend reading Brief by Joe McCormack.

Agile working in practice: what is helping your team?
I hope those thoughts and recommended resources are useful. It would be great to hear your thoughts.

If you are new to working this way or have it working well, please do share your experience in comments box below. What tips do you have for others who want to make the transition to agile working in practice (not just using the buzzword)?

Paul Laughlin, Chief Blogger at, has over 20 years experience of leading teams to generate profit from analysing  data. Over the last 12 years he’s created, lead and improved customer insight teams across Lloyds, TSB, Halifax and Scottish Widows. He’s delivered incremental profit of over £10m pa and improved customers’ experiences.

Thursday, June 20, 2019

Agile Working for Analytics Teams Needs a Cu​lture Change

Image courtesy of Pixabay
Today I'm pleased to share a guest post by Paul Laughlin. This post originally appeared on Paul's site on February 21, 2019.

The term Agile working is being used within more and more businesses. Although loosely defined, it generally refers to a more flexible and pacey way of working. In this series, I share what this means for data, analytics & insight teams who need to work this way.

Those businesses who have invested in formal training will likely be following one of the five most-popular methodologies. Although sounding very professional, in reality the application of Agile to non-IT teams is still in its infancy.

The top-five Agile development methodologies are generally agreed to be:
  1. Scrum
  2. Kanban
  3. Extreme Programming (XP)
  4. Lean Development
  5. Crystal
For more details on the technical pros and cons of each method, a useful overview has been published by Xpandit.

Agile working methodologies were originally developed for use when delivering IT projects. They were a response to slow, bureaucratic projects that all too often failed to deliver using the traditional "waterfall" methodology. With 8 out of 10 IT projects failing to deliver, one can see the need for change.

Agile working in practice
As with most innovations, they have a mixed track record. Agile software development has certainly delivered some significant improvements. The pace of delivery and visibility to business users have improved as a result. However, some large complex projects still benefit from greater consideration and planning when following traditional PRINCE-type methods.

My interest in this topic is the impact Agile working is having on customer insight, analytics, and data science teams. I’m finding many of my clients are working hard to adapt their way of working to these new methods.

Part of their challenge is that adaptation of these IT development methods to business processes is still a "work in progress." Despite the confidence and eloquence of a growing number of Agile Coaches and Scrum Masters, best practice for business teams is still not proven.

Data and Analytics leaders can feel under pressure to learn a whole raft of new terms and practices. To name only a few these include:
  • Visible backlog of prioritised work
  • Tickets for units of work needed
  • Public boards to track progress
  • Sprint meetings with bidding to deliver units of work
  • Standup meetings to discuss progress
  • Post-Sprint reviews to learn from what worked & what didn’t
Beyond those shifting sands, the other problem I have recognized is that succeeding with Agile working requires a culture change, not just process change. Those teams who succeed have mastered how to collaborate better. In this two-part series, I will share some themes I have seen amongst those teams who achieve this.

Agile working in hearts and minds
The first theme I noticed is a culture that embeds four principles. Each is a new way of working compared to the traditional behaviour seen by data or analytics teams seeking to "cover their bums" when working with business. Together they represent a winning over of hearts and minds to the benefits of a more-collaborative way of working as a business.

Principle 1: Individuals and Interactions
The first principle is a valuing of individuals and interactions over processes and tools. Rather than hiding behind formal steps or documents, Agile working means human interaction. That is the person who is delivering a particular unit of work talking directly to the internal customer who needs it. Together this encourages personal accountability and early transparency.

Such conversations are aligned with the dialogue encouraged in our post on Socratic Questioning. Talking early and often can avoid misconceptions or wasted work. Compared to many traditional projects, it can be a revelation just knowing who to talk to. However, analysts may need to be encouraged to be this visible and supported if things go wrong before you will see sustained progress.

Principle 2: Working (but imperfect) output
The second principle is to prioritise delivering working (but imperfect) output sooner rather than later. This is counter to the traditional approach of using QA check and documentation to ensure output is "up to scratch" before others can see it.

I’ve posted previously on the numerous benefits when analysts embrace imperfection. This is one of those examples. As long as both the business user and the analyst recognise that the output is expected to be imperfect, it helps to see it sooner. Early feedback can help address misunderstandings and bring to life priorities. It can be surprising how much more effective this is than relying on documentation to clarify requirements.

One word of warning: this is not a panacea. Quality and diligence still matter. I have seen cases of analysts delivering slap-dash work under the guise of this principle. If this happens, leaders need to recognise their responsibility to give "in-the-moment feedback."

Principle 3: Collaborate with your customers
Here I mean both real (end) customers as well as internal stakeholders. Principle 3 is all about collaborating to co-create what is needed. All too often in the past, project leaders have resorted to formal contracts to protect them from unreasonable or ever-changing customer expectations.

This principle turns that conflict on its head. What if both your customers and your insight team felt equally invested in your project? I’ve shared a series on how to run an insight generation workshop. It can be a powerful exercise to invite your customers into your business to innovate with you.

Principle 4: Respond to change when (not if) it happens
The last principle relates to the reality that things change. As William Buist wrote when responding to the challenge of GDPR, external change is a reality for businesses. One they should expect.

In a similar vein, it would be hilarious (if it were not so tragic) how surprised project managers are when things change. Name me the last project you worked on when nothing changed from the original plan? You see my point.

In response to that reality, this principle encourages breaking away from a rigid plan. Expecting change and having an agreed (more flexible) way of embracing change. Utilising the more-regular communication with stakeholders, about smaller units of work, to empower better responses. The ethos should be to agree on changes quickly, so as to be able to see the impact and minimise cost or time wasted.

This isn’t a panacea either, and this time business users can exploit this flexibility if left unchallenged. That is one reason why Agile working also requires strong leadership and empowerment of all team members. Any business that still expects analysts to be "order takers" from leaders wanting evidence is not ready for Agile working.

Are you Agile working this way?
I hope those thoughts help any data, analytics, or insight leader who is transitioning to Agile working. Have you seen these principles apply in your business? Do you have any other insights into how to get the best out of Agile working? Please share your thoughts in the comments below.

Next in this series, I will turn to drivers of success. Beyond those culture principles, what drivers distinguish teams who succeed with Agile working from others?

Paul Laughlin, Chief Blogger at, has over 20 years experience of leading teams to generate profit from analysing  data. Over the last 12 years he’s created, lead and improved customer insight teams across Lloyds, TSB, Halifax and Scottish Widows. He’s delivered incremental profit of over £10m pa and improved customers’ experiences.

Monday, June 17, 2019

Is Your Own Management Stalling Your Customer Experience Transformation?

Image courtesy of Pixabay
I originally wrote today's post for Forbes. It appeared on the Forbes site on November 14, 2018. I've made some slight modifications since then, as it turned into a two-part series. This is the second in that series; the first part can be found here.

In this follow-up to my recent article titled “Has Your Customer Experience Transformation Stalled?” I continue to outline why customer experience transformation efforts stall or slow. In the previous article, I focused on those reasons attributed to company leadership; in this article, I'll outline reasons associated with employees and operations. (Ultimately, it’s all on leadership.)

1. Expecting Miracles from Someone with No Customer Experience Background
Some employees have been “volun-told” into customer experience positions because an executive heard that customer experience is important to the business. These employees haven’t previously held customer experience roles but were told they needed to take on such a role and head up the company’s customer experience transformation – without being properly educated on what that means or how they’ll go about developing and rolling out a CX vision and strategy.

These well-meaning employees put forth their best efforts to educate themselves and then begin to roll out a strategy that is flawed at best.

2. There’s a New Hire Fail
Employees are critical to customer experience transformation success. First and foremost, you have to hire the right people (both management and individual contributors), i.e., those who fit your values and culture, a culture that should already be described as customer-centric. Beyond that, once you've got those folks on board, it's incumbent on you to teach and train them about the customer-centric culture they've joined. Share with them where you are in the journey, how their roles impact the customer and the customer experience, and what their involvement will be as the transformation continues. Don't let new employees be the reason your efforts stall.

3. You’re Not Activating Your Base
On that note, get employees involved in the transformation. Changing the company's DNA is not a journey for one person to undertake; this is an organization-wide effort. There needs to be leadership from the top, but a grassroots groundswell is also required for the transformation effort not to stall.

As such, a governance structure is critical to the foundation of any customer experience transformation. It outlines who will ensure that there is alignment and accountability across the organization, and it defines roles and responsibilities key to the transformation, including a core program team, an executive sponsor, an executive/steering committee, cross-functional champions, and a culture committee. What that spells is a lot of opportunities for employees to take part in this journey!

4. Trying to Imitate not Innovate
Your culture and your customer experience are your own unique fingerprints. You cannot attempt to copy another company's culture to serve your needs and your customers' needs. This just doesn't work. If you started down that path and things have stalled, now you know why. Develop your own unique culture and your own unique customer experience.

5. Change Fatigue Has Set In
Author Dawn-Marie Turner describes change fatigue as a general sense of apathy or passive resignation toward organizational change and notes that “change fatigue means that you have neither the energy to defend the current state nor the energy to move through a change process.” According to Ken Perlman of Kotter International, “Change efforts are all too often unfocused, uninspired and unsuccessful. As our research shows, 70 percent of transformation efforts fail.”

Why does change fatigue happen? There are a variety of reasons, but it often starts with a non-stop flow of change initiatives, many of which are "flavors of the month" or reactionary, with no thought given to long-term strategy, execution, goals, and outcomes. Each initiative requires employees to do more work - work they believe is superfluous - on top of their already overwhelming workloads. Oftentimes, the initiatives don't have clearly-defined objectives, outcomes or owners. And if these exist, their importance and purpose are not clearly communicated to employees. Finally, employees never see tangible, relatable outcomes or actual changes as a result of these initiatives, further perpetuating the “flavor of the month” label.

6. Employees Are an Afterthought

I have said this many times: quite simply, without employees you have no customer experience. The adage, "Happy employees means happy customers," could not be truer. But far too many companies aren’t putting employees - and the culture in which those employees work - at the top of the priority list. Employees have to come first. If you are not doing what it takes to improve the employee experience, customer experience transformation efforts will stall - or fail.

7. Technology is Not the Answer
Know that technology is only a facilitator of a great customer experience. It can help you get the right data to the right people at the right time. It can help you deliver the experience. But it is not the customer experience silver bullet. It is not the answer to fixing the customer experience. Don't use it as a crutch. You still have to understand customer needs and jobs to be done - and figure out how technology can facilitate that within the grand scheme of things. But don't slap the latest and greatest tech on a problem and assume it's fixed.

8. You’re No Longer Understanding Customers
And, finally, customer understanding, which I've defined as listening/asking (e.g., surveys or online reviews), characterizing (i.e., personas), and empathizing (i.e., journey mapping), never stops. It is the cornerstone of customer-centricity.

Customers change. Their needs and expectations evolve. The business changes. New products are introduced. New competitors enter the marketplace. Don't rest on your laurels. You've got to continue to learn about customer needs and expectations. Don't rely on what you learned a few years ago; it's no longer relevant today.


There are likely more reasons your customer experience transformation is stalling or even failing. Take a good hard look at what you're doing and where your efforts are today. Do any of these reasons resonate with you? If so, revisit and refocus. Up your game and get back on track. Your customers are depending on you.

Once you stop stalling and start working, it takes a whole lot less time to do things! -Crystal Paine

Wednesday, June 12, 2019

The Secret Sauce to Achieve Outcomes with Journey Mapping

In today's post, I reveal the secret sauce for journey mapping success. Are you ready?

There's a lot of bad press out there about journey mapping. And there's a lot of bad journey mapping (or what people think is journey mapping).

A few months ago, I shared my six-step journey mapping process. Remember, journey mapping isn't just a tool, it's also a process. Know the tool, and create it correctly. Embrace the process because the process is what's going to ensure you achieve your desired outcomes.

I would call journey mapping the most critical and pivotal component in any customer experience transformation. An in-depth understanding of the experience today - what's going well and what isn't - is the only way to really drive change going forward. (You can't transform something you don't understand, right?) This is why journey maps and the journey mapping process are often called the backbone of customer experience management.

So, back to the six steps of the process. The first two steps, Plan and Empathize, are all about getting the map done and getting it done right. The third step, Identify, revolves around bringing data into the maps, identifying and prioritizing moments of truth, conducting root cause analysis, and creating a plan to make improvements to the current experience.

The fourth step, Introspect, is a critical one and ties in neatly with the third step, especially with regard to root cause analysis. This is where the secret sauce comes in: it's time to look inward and create a service blueprint, which outlines the people, policies, tools, and systems that support and facilitate the customer experience, and a process map, which outlines the workflows that do the same, to correspond with the customer journey you’ve mapped. (You can include the processes in the service blueprint, as well, which is what I've done in the image below.) By linking the service blueprint to the customer's journey, you've got that end-to-end picture of the journey plus the surface to core view, giving you the complete picture of what's working and what's not.

Here's an example of what that service blueprint will look like.

If you've been mapping and making tactical improvements as a result of your map findings without service blueprinting to really understand what's happening behind the scenes, the resultant improvements are likely cosmetic or short-term. You cannot fix what's happening on the outside (for the customer) without identifying and then fixing what's happening on the inside to facilitate what the customer is experiencing.

Service blueprints help us understand how we are delivering the experience to customers today. They are necessary to reveal, uncover, and then redesign the root cause of a painful customer experience. I guarantee you that most companies did/do not think about the customer as they develop or implement the tools, systems, policies, and processes that result in an experience for the customer. The blueprints can and will certainly showcase where silos occur and the impact of those silos. But with that information, when the blueprints are done right, you will align stakeholders on the common goal: to design and deliver a better experience, from the inside out - while thinking outside in! Once you've completed the blueprint, you will have identified improvement opportunities, cost savings, process inefficiencies, and skill gaps for your people.

Last week, I was invited to be part of a fireside chat with Vinod Muthukrishnan, CEO of CloudCherry. During that chat, we discussed my journey mapping process, starting with the third step and barely finishing with the fifth step! We spent a chunk of time talking about service blueprinting and answering audience questions about journey mapping, in general. It was a great conversation, and there will be future chats to talk about service blueprinting and more. Be sure to check out this fireside chat and future chats in which Vinod will explore more details about the mapping process.

Everybody that's successful lays a blueprint out. -Kevin Hart