Agile w/o CX? Epic Fail.

There are a number of success stories, and horror stories, with #Agile implementations, many including significant investment, people mobilization, and work effort to launch. And there are a number of reasons for Agile efforts thriving or failing in an organization; but the one I see a lot more these days, and that will sink your Agile transformation efforts 100% of the time, is the lack of #customerexperience (#CX) inclusion -- it results in an epic fail.

First, why is this phenomena happening? For starters, CX and Agile are typically led by two different individuals (and rightly so); depending on how big your organization is, these fine people may never have a chance to connect, so they may be working in different directions. Additionally, while Agile uses the CX Toolkit, there may be competition between these two leaders (as unfortunate as this is, yes, there are egos out there). Yet another reason is that the business loves the speed and efficiencies created by Agile, yet view CX as something taking too much time to execute on; so, by design, you have two competing disciplines with different goals/outcomes in the minds of different leaders. This last point here is the one I see and hear most often; how do I take the time to use my CX Toolkit when I have to deliver something in a two-week sprint?

Before we go there, let's be clear on something that I believe in: Agile can be, and is, an incredibly powerful way of working that can have significant, positive impact on your customers and your organizational culture. But Agile, to be sure, is a way to improve the customer experience, not just deliver something cheaper and faster. When incorporating the CX Toolkit, and training Agile teams on effectively using these tools throughout their maturity, teams are able to deliver more efficiently and more effectively. I would even go so far as to argue that all you need are four specific CX tools embedded in your Agile teams to be effective. Let's explore these further.

Personas:

Personas are a distillation of your customers or potential customers. They are the heroes of your story. They aren’t real people, but combinations of real people whose desires, likes, dislikes, pain points, and personalities help inform your decision making. They are based on quantitative and qualitative research to help you build them; that's right, you can't sit around a conference room table with colleagues and simply create them based on your experiences or what you think your customers want. Personas will include things like a short bio of the person to make them more real, what their goals are, and likes/dislikes to name a few.

How do Agile teams use personas? First and foremost, they help put a "face" to their user stories and help answer the question: who is my customer? Moreover, what are their behaviors and purchasing patterns, the user's goals and objectives, and what demographic and psychographic information influences their decisions.

Being able to come together as a team and discuss the above as part of your regular sprints, or more strategic forums, creates a shared understanding and alignment around who is actually using the solution you are delivering; teams that do this are more likely to succeed because their solutions meet user need(s).

Journey Maps:

If you're already not aware, Journey Maps are an outside-in, step-by-step representation of how a user or customer interacts with a process, channel, product, service, etc. The map provides detail into what happens at each stage of an interaction, what touch points they're interacting with, what obstacles customers may encounter, customer sentiment at each interaction, and it's completed in the context of the persona going through the journey.

I used to work for a leader that I loved because she would always start with, "let's get all of the facts on a page." Journey Mapping lets you do that, get everyone on the team on the same page, and develop a shared understanding of the user's goals and objectives. I love Nielsen Normal Group's framework for Journey Mapping as it's easy and it works; if you're just getting started, NNg's site is a great resource for this topic plus persona development.

Once the journey is created, ask yourself a few questions:

1. What are the key moments that matter to users based on the research we've done on personas and in developing this map?
2. Where in the journey did users have an experience that is a possible opportunity for improvement or that is inconsistent to the experience you want to deliver?
3. What are the user's emotions or expectations at each point along the journey based on our research? Look for positive and negative aspects.
4. Why did the user have that emotion or expectation? Again, here, think about the persona.

Insights & Analytics:

Nearly all Customer Experience teams are delivering some level of customer insight, whether through quantitative or qualitative methodologies; hopefully, they're using both. Agile teams, similarly, need constant user feedback in order to support user stories and features, constantly look at their backlog to create greater efficiency in prioritization, and measure their progress. CX teams need to be partnering with their Agile stakeholders to set up and implement ongoing feedback channels that capture customer insights, you guessed it, through the journey aligned to those moments that matter.

Where do analytics come in? Use sentiment and text analytics aligned to the journey as a way to measure progress and further enhance the team's ability to deliver customer value. And if it's not quantitative data the team is looking for, put the the activity in #JIRA to capture qualitative feedback from your customers. Don't take my word for it, this was a mind-blowing moment for me while interviewing Duena Blomstrom about CX & Agile disciplines. Never again will you get, "I can't speak to customers as it takes too long to do and I only have two weeks."

Design Thinking:

Design thinking is an iterative process that you and your team can use to understand users/customers, challenge internal assumptions, redefine problems you face every day, and create solutions to prototype and test with your users. There are five phases—Empathize, Define, Ideate, Prototype, and Test. The process is most useful to tackle problems that are ill-defined in your company. What do these five phases mean? Let's explore more below:

Empathize: Gaining an empathetic understanding of the problem you’re trying to solve through user research is how to think about this phase. Empathy is crucial to a human-centered design process like design thinking because it allows you to set aside your own assumptions, or those of the business, about users and gain real insight into their needs. Have #SMEs that know what the customer needs? Start here.

Define: Analyze the observations in the Empathize phase and synthesize them to define the core opportunity/ies you and your team identified. Turn these into "Opportunity Statements" (please don't use "Problem Statement"!), and use the personas created to keep your work human-centered before graduating to the next step.

Ideate: You've now done all of the work needed to innovate outside the box, and, frankly, inside the box (just as relevant and important btw). Whiteboard, get people out of their seats thinking critically — horizontally and vertically — and look for ways to think differently about the opportunity statement you've created. More ideas the better and do not, I mean seriously never, shoot down any idea.

Prototype: Now the fun part. Experiment and build the best possible solutions for each opportunity you've uncovered. Do this on the cheap, using paper, LEGO, digital tools or whatever is at your disposal. Just make it usable enough to put in front of your users. And do not —I repeat, DO NOT —worry about appearance right now.

Test: Now to have even more fun...put the prototype in front of users. Use their feedback to further refine the prototype or re-define the opportunities you've uncovered. And it's okay to go alllllllll the wayyyyyyy back to "Define" if you need to. I did mention this is iterative, right?

The point is that each of your Agile teams need designers embedded. If you have formally trained designers, all the better. And if the can hire for UI, UX, and design strategy, you're cooking with gas.

CX and Agile are different disciplines, but they are brother and sister in my book. If you are leading a CX team and have not bought lunch for your head of Agile, or invited them to a Zoom call recently, set up a strategy session now. Oh, and don't forget to ask their designers to facilitate the session for you.

How are you incorporating CX into your Agile efforts? Have a better way? I don't pretend to have all of the answers and am all ears, so PLEASE comment below.

[all opinions are indeed my own.]