.png)
Last year I published a few articles on the subject of cross-functional value stream teams. On the back of some work I was doing with a client, I struggled to find good reading material I could recommend to help people understand the changes they were experiencing. To me, the subject was underrepresented in literature.
You may have come across the excellent book Team Topologies which is based on a number of the same principles as value stream teams - but it effectively stops at organising technical teams. Even if your team is working in close collaboration with the business, it remains a technical team with dependencies and hand-offs to others in the organisation for decisions, input or direction - all of which slow down the speed and agility at which you can deliver value.
In my view, where the real magic happens is when you bring a diverse set of people together with all the skills needed to deliver value. This usually goes beyond technical skills to encompass Sales, Marketing, Legal, Compliance, Finance - you name it. With such a truly diverse team a few unique challenges arise, which is why I started this blog series.
So far I’ve covered:
What is BAU?
Today I want to talk about the pesky subject of “BAU”. Business-as-usual can mean a number of things to different people, but for the purpose of this blog series I intend to cover all aspects of work that are not primarily concerned with delivering a feature roadmap (which you shouldn’t do anyway - but let’s face it the perfectly groomed, pre-planned, multi-sprint backlog is alive and well in many organisations).
Specifically I want to look at how to handle:
Requests coming in via customer support
Continuous improvement efforts and technical debt
“Other” work that doesn’t fit your agreed business outcome but is still supposed to get delivered somehow (sound familiar?)
If you are considering implementing value stream teams, or already have, you’ll most likely start with a new initiative or a new product that you are hoping to bring to market. Pesky questions like how to deal with bug fixes and legacy code are quite possibly far from your mind at this stage - but from the moment you go out into the wild (whether that is internal or external) these curveballs will come your way, so we may as well give it some thought!
Or maybe you’re a senior stakeholder and you want to embrace the idea of value streams in your organisation but you’re wondering how on Earth “all the other work” gets done - what if it doesn’t fit into the value streams’ defined outcome?
I will start by looking at how to integrate customer support into value stream teams, how to prioritise the work that is generated through that channel and what not to do. Technical debt and stakeholder “pet projects” will be covered in subsequent posts (subscribe below to not miss updates!).
Customer Support and Value Streams
If you take a moment to mull this over, you will hopefully recognise that the work that is generated on the back of customer queries or error reports is directly linked to the value being created for them - or maybe the lack thereof.
If you have framed your outcome correctly (in that it describes the impact you’re looking to have on your customers, rather than a set of features you want to deliver) then any queries that are coming back will be a signal for the quality of the work you have produced, or whether your solution is adequately addressing the problems you set out to solve.
Is your solution riddled with bugs and thus stopping people from achieving the outcome they were hoping for? Then you clearly haven’t done enough to generate the impact you set out to achieve.
Do you have lots of customers ringing up because they can’t navigate your product or are unsure how to even begin? Again, you are clearly not having the impact you could have.
So how do you prioritise what to fix and what to leave behind under the ubiquitous “this is by design” excuse, ehem, explanation? What if your team is busy implementing the next iteration of your product while your customer support team is struggling to placate frustrated users and is creating a ticket queue longer than your spoilt nephew’s Christmas list?
It all comes down to, you guessed it, the outcome you are hoping to achieve and how you measure your success. Maybe your success criteria didn’t effectively capture the intended outcome after all, so you moved on to the next goal thinking you had achieved what you set out to do previously.
Or maybe you were so eager to finish and move on that you convinced yourself the metrics were good enough, and now you are finding out the hard way that this isn’t the case. No matter how you got here, there are a number of positive steps you can take to bring you back on course.
Assess the Failure Demand
Any queries the customer support team receives from your users that aren't requesting new functionality is considered failure demand. This is demand on your time that is created because for whatever reason your product failed to create the desired impact - maybe it’s full of bugs, maybe it’s hard to navigate, maybe it’s not particularly performant.
Consider the severity of your failure demand - is it stopping your customers from using your product altogether? Is it creating a damaging reputation in the marketplace that may impact the amount of revenue you can expect to make from your product? Are you failing to keep your customers or their data safe, are you possibly even in breach of regulation?
All of these things may be considered severe enough to justify pivoting away from whatever else you are currently doing and re-focusing on addressing these issues.
Don’t Be Afraid to Pivot - If You Must
But maybe the queries that are coming in aren’t quite as severe, maybe workarounds exist to deal with a bug or bad design, or some level of instability is expected and tolerated for a product in the early stages of adoption.
Ask yourself how your current goal and initiatives compare to the benefits you can create by fixing what’s already there. Maybe it can wait, maybe you decide it’s not important enough to ever fix. Don’t assume that everything that is being raised must necessarily be implemented! Also consider non-code routes to resolving issues: maybe better documentation goes a long way to alleviate the pain your users are experiencing, at least in the short term. As with anything in life, there is a trade-off and it helps to discuss this openly within the team, and with stakeholders.
You may decide to continue as you are for now, but use the next quarter to double-down on customer satisfaction and improve what is already there rather than blindly adding more stuff. Remember that your work is about the value you create so this concept should stay at the forefront of every conversation.
If you find yourself going back to something you thought you had already delivered, make sure you take some time to run a proper retrospective so you can understand how you got here. What made you move on prematurely? How would you prevent this from happening again? What safeguards can you put in place to prevent a repeat performance? Are there technical practices you should be adopting to improve the quality of what you deliver? Make sure you make room for these conversations or you run the risk of repeating the same mistakes over and over again.
Embedding Support into the Value Stream
We’ve looked at how to assess customer queries and how this may affect your decision-making in the short and medium term. But how do you best integrate the customer support function into your cross-functional team? How do you ensure that this demand is even heard in a timely manner?
Ideally those that take calls from real-life customers are part of the very same team that creates the product that customers are calling about. We want to measure our success based on the impact we’re creating so having this immediate feedback loop in place creates invaluable data to determine how to evolve the product. But unless you are very small and only have one product this setup is probably not all that realistic.
More likely you’ll have a centralised support team (it seems to have become fashionable to call them “customer success”... what’s that about?) that needs to field calls on a variety of subjects and products. But what we don’t want to do is to turn these poor people into automatons that mindlessly raise Jira tickets into an anonymous queue where they go to die.
Instead, think about how you can align your support team with the respective value stream teams - for instance, can you segment the team so that different individuals specialise in different products or facets of the product (think playlists in Spotify vs searching for songs) and route customer calls accordingly?
You may have to try a few variations to find something that fits your context but whichever way you slice it, your goal is to shorten the feedback loop between the call coming in and the right team becoming aware. Support team members should feel like they’re part of the team that can genuinely support the customer - sometimes that is through better design, through fixing a bug, through enhancing functionality or simply through better education/training. Whatever it is, we want to create an active dialogue between the real world and the value stream team. We don’t want a Jira queue, backlog grooming meetings and customers left waiting for a solution in vain.
An effective way of embedding real life customer learnings back into your value stream team is to set up a rota the other way, i.e. get value stream team members to shadow and/or help customer support agents. This could be for a day or a week at a time. For this to be effective your customer calls will have to be routed according to some pattern - there is little value to be gained if “Team Mortgage Application” has to sift through credit card queries in search of relevant customer insights.
Hopefully this has given you some food for thought in how to handle customer queries. There is a ton of valuable information coming in through the proverbial door all day long. If you can learn to leverage it rather than treat it as a nuisance, you’ll be head and shoulders above the competition in no time.
Have you already implemented this successfully in your organisation? How did you go about it? Share your story in the comments - or get in touch if you’d like help in creating the sort of organisation that improves on the back of customer feedback! There is evidence aplenty that we need more of those around!!
Comments