The Magic of Organizing around Customer Journeys - and How to do it

Amazon can deliver your package in 30 minutes. Most banks take weeks to deliver a simple loan or service.

Why you should organize differently

A real life story: I needed to send some money to a friend who was working for a bank – a bank other than mine. We agreed that I would download Swipp, his bank’s app, for easy payment and money transfer, and then transfer the money. First, I needed an account at his bank, and I found a different app that I could use to get an account. I downloaded it and used it to send a picture of my driver’s license, etc. Easy!! Next day I received an email with a link to a webpage where I needed to register information about my "financial habits" as an anti-fraud mechanism. The webpage crashed. I called customer service, and got some very helpful advice, but ran out of time. Later that day, I walked by a branch of this bank, went in thinking, "YES, talking to someone in person will speed this up". After expressing my wish to get an account and get Swipp, the nice guy told me, "It’s easier online". Sigh…!! Long story short: I had a total of 12 interactions with the bank and it took me 1.5 months to get my account and Swipp set up.

Later over a beer, I suggested to my friend that his bank take a closer look at the end-to-end customer onboarding process. His answer: "We have that down. We have an onboarding team. They’re in the digital program, and they made the app you used. Didn’t you like it?"

Sigh!!!

The week after I was in Minnesota looking after our grandkids. Busy family – empty fridge – tired and hungry kids. What to do? Amazon Prime, of course. They knocked on the door with our groceries 30 minutes after I hit enter.

The onboarding team at the bank was cross-functional, able to deliver the app without being dependent on others. But they were organized in a digital program, and should probably have been organized in an onboarding program together with the other teams taking care of the other elements of the onboarding process. Then, they would have been organized around what I, as a customer, was looking for: getting onboarded fast so I could get access to an easy way to transfer money.

By contrast, how do you think Amazon organizes their teams in order to go through the individual steps, from getting an order placed online until they hand the package to the customer?

Channels are not customer journeys

Digital or self-service are important channels for delivering your services, however they are not customer journeys by themselves.

In most cases, like the bank onboarding process, customer journeys are not 100% digital, and therefore becomes scattered customer experiences if they are the main responsibility of a digital program, who typically has little or no interest in the non-digital elements of the customer journey.

While the above is not rocket science, why do so many large organizations still have departments and programs with names such as "self-service" and "mobile"? We believe there are two main reasons:

• Understanding the benefits of organizing around customer journeys (aka value streams) has not always been top-of-mind. We’ve seen this understanding emerging only over the last decade or so.
• For a company to start developing competencies within a new technology, the natural thing to do is to establish an organizational entity and hire people who have the competence, or who will learn in the new department.

It sounds like common sense - but it isn’t easy

Organizing around the value delivered to the customer may sound like common sense. But just because it is common sense does not mean that it is common practice. It requires a maturity in the organization that needs to be built up over time.

We see eight typical steps that companies are taking in order to mature towards the end goal of becoming a true enterprise agile organization.

The eight steps and how to move up the ladder

Of course, each organization is different, and far from all follow these steps. Some skip a step or two, some take two or three steps at a time, and some even take the steps in a different order than we are describing.

[Click on the image to enlarge it]

Step 1 - From functional teams to full-stack teams

Most companies have bought into the idea of minimizing hand-overs by having all the required IT competencies present in a full-stack team – moving from having "the testing team in India", "the development team in Lithuania," and "the business analyst and project managers in Denmark," into having teams that have all the needed competencies to design, develop, test and implement together.

Moving in step 1 requires you to think about aspects such as virtual and global collaboration tools, as well as helping your employees gain T-profiles, in order to better understand and help each other in the team. Having as many people with the needed competencies to deliver speeds things up drastically, because suddenly the team is wasting zero time coordinating with and handing over to other teams.

However, if you stop your journey at this step, you will still experience a large amount of dependencies on the business, the operations and other teams – therefore, you need to proceed to step 2.

Step 2 – Cross-functional teams

While the terms full-stack teams and cross-functional teams for some are synonyms and used interchangeably, there is a subtle, yet important, difference between the two: when people talk about full-stack teams, it is often linked to the "Technology Stack," a cross-functional team seen from an IT perspective.

Moving on to step 2, cross-functional teams, you need to have all the competencies necessary to build and implement a release on your teams. This usually includes subject matter experts and others from the business, and your colleagues from operations; sometimes people from marketing, or doctors, if you’re in healthcare, or lawyers if you’re building services where legal plays an important role. Because without them, you will still be dependent on people outside your team in order to deliver a service, which almost always slows you down and often results in solutions that are out of sync in the context in which they will operate.

Step 3 - Long-lasting, cross-functional teams

Many companies organize their development efforts by moving the right people together to work on a certain project or challenge, and keep the people together just long enough for them to finish. After they finish (or sometimes before they have actually finished), people are then reassigned to the next project.

This is "moving people to the work."

Some refer to this as organizing "in projects," and while this way of organizing has its benefits, it is mostly done because "we’ve always done it this way" and has some severe drawbacks:

• It’s difficult to create ownership of the services we build for our customers. Yes, there may be a "system owner" somewhere in the organization, but not a team who builds, loves and runs the system or the services. This often results in products and services that feel dated, compared to our competitors’ products and services which are being kept up-to-date by a long-lasting team, who keeps tending to them and keeps them fresh.
• Just when the people start to get to know each other and gel as a team, they are moved on to work with someone else. They never get through the team development phases (forming, storming, norming, performing) to become a high-performance team. Short-term, that may not seem so important, however long-term, we’re missing out on the substantial benefits of having a development organization consisting of high-performing teams.
• As human beings, we have a deep need to feel connected to others – this is why belonging to a team feels good for us. When we know each other and really know where we stand in a team, our brains are able to focus better because we are not constantly wondering whether the person we work with is a friend or foe. Source: Wired to Connect, Matthew D. Lieberman, Professor at UCLA Department of Psychology, Psychiatry & Biobehavioral Sciences

If we change the way we organize to create long-lasting teams, we turn every single one of those drawbacks into an advantage.

This is "moving the work to teams of people." and, of course, is a primary tenet of Agile ways of working.
We create the environment where teams have a good chance of becoming high-performing, who love their solutions, nurture them and keep them up-to-date and alive, so the customers continue to love them. Just look at smartphones. Why do so many people buy a new expensive phone every year? Because the new phones have some features that we absolutely cannot live without? Or because the new version is cool and feels fresh and updated?

Step 4 – Long-lasting, cross-functional teams in a virtual cross-functional organization

In step 4, we get more ambitious about the way we form the teams. In step 3, the ambition was "just" to have the right mix of competencies (both IT and business) - and in step 4, we want each team to work toward a specific goal that contributes to the overall strategy of the business.

In the drawing, you see a group of people pointing to a target, representing IT, business, and operations leaders who agree on the strategic direction and goals of their (virtual) cross-functional organization.
In other words, we become more ambitious in our organizational design, which is not just about getting the right people together, but getting the right people together in the context of the organization’s mission and vision.

One example is the mortgage services in a bank, where we organize one or more teams around serving our customers when they want to borrow money for buying or improving their homes.

Step 5 - Value stream, cross-functional organization

In step 5, we’re getting even more ambitious. With customer journeys and value streams, we are trying our utmost to understand the individual steps that our customers go through in order for them to fulfill their needs – seen from the customer’s perspective, that is.

This is illustrated in the drawing by the two wiggly lines representing a value stream / customer journey, taking its ups and downs in the experiences on the journey.

We have learned that this is more difficult than it seems. One might think that identifying the steps of a value stream seen from the customer’s perspective is just to ask the customer "What do you want?" and "What are the steps you go through to get it?"

We have learned that it takes a tremendous amount of listening, thinking out-of-the-box and empathy to understand how we design a value stream to delight our customers, partly because we can’t expect our customers to think about how we can make the full end-to-end customer journey better and better. As Henry Ford famously said, "If we’d asked people what they wanted, they would have said faster horses." So we need to listen very closely to our customers, and also listen to what they’re not saying; be creative and experiment with things that delight them even more.

Taking the mortgage example to the next step, we might realize that mortgage is actually a product, more than it is a customer journey. One might argue that mortgage is a result of an inside-out perspective. In a more holistic view, the customer does not need a loan. Rather, he is wishing for a new house or to improve his existing house with a new bathroom. In a more holistic and outside-in perspective, you want to help your customers with "housing," including a mortgage and other things, that will make it nice and easy for your customers to have a house.

An example: my friend’s Sony cell phone had just crashed. When I finally got in touch with him, he complained how he lost a lot of contacts and data. Then, I was thought about my new iPhone that identified my old iPhone as soon as I turned it on, and helped me get all my contacts, apps and data on the new iPhone. I loved that, but would probably never have thought of it if Apple had asked me what else I wanted in the next generation phone.

In his Cynefin model, David Snowden explains the difference between challenges that are complicated, and those that are complex. Complicated challenges can be handled by thinking rationally and analyzing them. It may be difficult, but if we have the right competency, we can figure it out. Sense-analyze-respond is a good strategy in the complicated space. Complex challenges are different and more difficult, because there is not a direct link between cause and effect, between action and result. The sense-analyze-respond strategy that works well in the complicated space does not help us in the complex area, because analysis in the complex space is a waste of time. Rather, probe-sense-respond is a good strategy in the complex space; "sense" meaning using your gut-feeling and trusting your insights, rather than trying to analyze the un-analyze-able in the hunt for certainty, which is actually nothing other than a false feeling of certainty.

Having worked with value streams for quite some years, we’ve come to realize that it is not just complicated to figure them out; they are also complex. So if you (like us) have been frustrated about not being able to "figure them out," don’t beat yourself up. Rather, realize that deeply understanding how we can make customer journeys or value streams better and better is something that we need to experiment and explore, following Snowden's probe-sense-respond strategy.

Finally, when you think you have managed it (for now, that is), test your hypothesis by organizing your teams and programs around your value streams, and let them dive deep into making the customer journeys better and better.

In step 5, we now have teams and programs virtually organized around customer journeys. And until we align our HR organization with our virtual organization, our programs will need to fulfill the needs of two different organizational "systems" – both the virtual program organization and the HR line organization, which can be solved by taking the next step.

Step 6 - Value stream HR line organization

At some point in your journey, it will become tiresome to work in a virtual set-up – a hybrid version of the organization – the reason being that you constantly need to protect your virtual bubble from the outside silo-thinking structures and processes that threaten to tear your bubble apart. In most areas, we see this happening by placing an adapter, usually consisting of 2-4 people, who ensures that reporting, investments, and steering committee meetings, etc., which the outside organization still expects to happen in the "old" way, are met and delivered. In practice, our experience is that this requires 2-4 people to ensure protection and working peace for the virtual organization. In order for you to be able to remove this adapter, you need to embark on the journey of actually changing processes and structures. In many large organizations, many of these are built around the HR lines. Therefore, changing them is a massive step towards truly creating cross-functional collaboration on the teams, where they no longer need adapters; where they will not constantly be disturbed by the outside world.

This step is not easy. Some companies, like ING and ABN AMRO bank, have chosen to implement a big bang – with an overnight change in all HR employees in a new cross-functional development organization. However, a key learning from this has been that it has proven very difficult to nail the organizational build of customer journeys and end-to-end delivery teams up front, as experimentation and trying out different scenarios is needed. For this reason, we recommend trying out your virtual organization and re-evaluating this set-up once or twice, before actually changing the HR lines.

Step 7 - End-to-end, value stream HR cross-functional organization

In the prior steps, your teams may not be responsible for rolling out their products to the internal or external customers. Maybe they are just handing it over to someone else in the organization, who would then be responsible for getting it in the hands of the users.

In this step we’re getting rid of that handover. Rather, the teams now become responsible for the whole end-to-end life of features in the product – from idea until the users are getting the highest possible value out of it, which may include marketing, teaching and supporting the users in their day-to-day use of the product.

In order to cover this whole end-to-end life, the technical aspects of having and running a product also become the responsibility of the team. If the solution contains IT, this will involve the technical elements that used to be the sole responsibility of IT operations. So rather than having IT operations as a stakeholder, we now marry development and operations in a DevOps setup, with continuous integration and continuous deployment to production.

Prior to his step, development was pushing for change, and operations had a natural resistance to change in order to maintain stability. With DevOps, we find the synergies, automate everything, and make recovery after shutdown a priority. That enables us to shorten lead time by releasing often without jeopardizing stability, because the system recovers itself if a release causes problems or shutdown.

Allowing teams to extend their responsibilities to also bring their products into the hands of the users and to ensure that they work at all times allows them to truly own what they are releasing.

Step 8 - Enterprise Agile

[Click on the image to enlarge it]

During your maturity through the steps, you might have already begun your preparations for this last step, as many of the processes are typically linked to the HR organizational structure in large organizations. However, for you to be able to reap the full benefits of working Agile centered around customer journeys, this last step is critical.

You want to enable your new end-to-end value stream leadership to be empowered to set the direction, define the outcomes, and be accountable for the progress. For them to truly feel empowered, you must ensure that the surrounding processes support and enable them to make decisions and set the vision for their area. If investments are still prioritized at C-level, with the upfront promises of specific deliverables, the value stream leadership is not really empowered to prioritize their backlog. If your risk processes are hindering the early releases, your technical platform does not support shared code-ownership and a state-of-the-art test environment, and you do not establish easy access to customer feedback, the full benefits of the above maturity journey will not manifest.

Lastly, for you to reach enterprise agility, planning, involvement and transparency should be happening in alignment sessions across your different value streams: by having high-level demos, feedback sessions and open discussions, as opposed to formal reporting at steerco meetings; having PMOs facilitating cross-enterprise coordination, rather than consolidating status reports from various programs; having a stronger focus on face-to-face organization-wide interactions rather than on processes and templates; and by fostering a mindset where decisions might follow the formal organization, but where information flows freely between employees.

Summary – things to think about

Referring back to the key takeaways, here are our suggestions:

1. Challenge the level of cross-functionality in your cross-functional teams. Are some teams dependent on people who are stuck in their silos, and is it time to experiment and include some of those people in the cross-functional teams to further reduce dependencies and move through the steps?
2. Ask yourself how well your teams are working together across the organization. Is it time to rethink whether they are – or how they are – organized in programs of teams in order to establish and/or improve how you’re supporting a certain customer journey?
3. If you have a digital, self-service or mobile program, is it soon time to move some or all of those people into the customer journey programs, in order to make a more seamless experience for your customers?
4. If you’re about to include AI or robotics in your business model, are you about to create a new silo by organizing them in their own department? And if you are, how are you planning to harvest the full benefits of these new technologies? By having some of the specialists working closely with (or being a part of) your value streams?
5. If you sense you are ready to mature your organization into a value stream focus, which step might be your next step?

Depending how far you are on your scaled Agile journey, these changes will most likely make your customers love your services even more.

It might almost feel like magic.

About the Authors

Ole Jepsen is the founder of goAgile and an enterprise Agile coach. Using his expertise in Agile methodologies, intent-based leadership and facilitation, Jepsen works with companies and leaders to create development organizations where people thrive and deliver value. Jepsen is a founder of Agile Leadership Network, Agile Coach Camp Denmark and an Agile governance think-tank. He is currently writing a book about how leaders involve and engage to create ownership, and he is active in the international Agile community, speaking at conferences and consulting worldwide. In addition to numerous Agile certifications and the SAFe® SPC4 certification, Jepsen is a certified Intent-based Leadership™ trainer, and a certified Strategic Play® with LEGO® Serious Play™ facilitator.

Maria Ebro Andreasen is Head of the Agile Structures team in one of the largest Agile Transformations in Scandinavia – in Danske Bank. With a Masters Degree in Psychology and Philosophy, a coaching degree, a SAFe-, Scrum master-, CAL1- and Organizational Development Certificate in her backpack, her energy and focus lies on how transforming organizations and implementing agile ways of working is really about changing how people think and changing the culture. Understanding the psychology behind this, helps build the change strategy that truly affects and engages the employees to change. Ebro has been a speaker at the International Institute of Learning, Agile & Scrum Conference in New York, and will be speaking at several conferences during winter and spring, on the concept of how psychology and culture is affected by working agile.