When I’m working with a development team, I’ll often start by having them walk me through what business need they’re solving for. I’m less interested in the code or the architecture until I’ve first understood what problem we’re trying to solve.
Sometimes we have teams who have no understanding of the actual product and who are just building features. Other times, we have teams who have a deep understanding of the product and the customers and the problems that their product solves for those customers.
I’m sure you can guess which of those teams are more likely to be solving the right problems.
The teams who understand the larger context are far more likely to build the right things than the teams that are just following orders. They’re both writing code but one of them is focused on solving problems for their customers, and the others are just being busy, doing what they were asked to do.
That’s not to say that the teams are necessarily unhappy just building features. There may be very interesting technical challenges in that, to keep them interested. The point to remember is that development teams are very expensive to run and if we’re not sure whether they’re delivering the right value, then we have a real problem.
Asking teams what they do, can be an enlightening experience. If they immediately dive into technical details of what they’re doing, then they’re likely disconnected from the real problems that they’re supposed to be solving, and there’s a very good chance that they’re building the wrong thing.
For example, I recently attended a demo about a web service that a team had built. They went into detail on what the service did and what information it returned, and yet couldn’t tell me who would call that service or what they would do with the information they got. What are the odds that this service will do what’s actually needed?
If you’re confident that it still would have been the right thing, because after all, we had detailed specifications, consider this other example from a huge financial company. One team had built a web service to be called by another team. Over a period of months, they’d built the service and gone through multiple rounds of governance and approval to get it deployed into production. It was only then, months later, that the team who had requested it, tried to use it. At this point, they discovered that the service required as input, a piece of information that they didn’t have. The new service was completely useless to them and months of effort had been complete waste.
So what things might we want to hear from a team, to give us confidence that they’re actually building the right thing? We’d like to hear them talk about outcomes, not outputs. What are the problems they’re trying to solve, rather than how they chose to solve those problems. Here are some positive examples:
- One developer I talked to at a telecommunications company, said that his job was to reduce inbound calls to a call centre. He was doing all kinds of fascinating technical things in order to achieve that, but when I asked what he did, he talked first about reducing calls, not technical details. “I implemented this change which reduced calls from X to Y”
- At a large retailer, I asked one team what they did and they took me for a walk through one of their stores. We walked up and down the aisles and they pointed out specific things in the store and explained how their software helped with the things that the store staff needed to do. They were hyper focused on what their customers needed to do and how their software helped with that.
These are both examples of individuals and teams that are really focused on delivering value. They know who their customers are, and are focused on delivering value that helps those customers.
Unfortunately, these stories are fairly rare. It’s more common to find teams that are just feature factories. Someone tells us what to build and we do it. Is that thing valuable? Maybe. It’s hard to tell.
A good place to see if the team is focused on value is in the demo to the stakeholders. Is the demo focused on the value of the changes that were made or on the technical details? Did we solve real problems for the people using the system or were we just busy?
It can be enlightening to ask the audience at a demo if they’re getting the right level of detail. You might be surprised how often they aren’t, and yet they don’t speak up unless explicitly asked.
How much does your team understand about why we’re building the products we are? We tend to assume that they all understand the big picture, and yet that’s not always true.
Update: Within hours of posting the above, I had a poor shopping experience that illustrates the concept really well, so I’m adding it here.
My hiking shoes needed to be replaced and I’d been particularly happy with the ones I’d previously had, so I went back to the website of the same store where I’d purchased the first set, with the intention of reordering. I easily find the order I’d placed and it showed me the description of the shoes I’d bought, although strangely, the image of the product that should have been shown was just a broken link.
Searching the store, I quickly discover that they don’t carry this brand of shoes anymore. Not because they explictly say that anywhere, but because they just aren’t present in the search results.
So I went to one of their competitors and bought the shoes there. I thought at this point, that I was done.
This morning, I have an email in my inbox asking if I wanted to finish my purchase. They’d noticed that I’d looked at a product but didn’t buy it. A product that they no longer sell.
Just like the order page had, the email had the correct description but a broken link where it should be showing me an image of the product.
This is a great example of a feature factory at work.
Clearly a team had been told to build an email reminder to send to people the next day but nobody had actually thought through how the customer would be using it or what edge cases might be present. Certainly nobody had considered that I might have looked through past orders at an item they don’t sell anymore.
The lesson here is that we need to be focused on solving problems for our customers, not just churning out features. We need to consider how this will improve things for them. Sending an email to suggest that I buy a product they don’t sell, is not helping the customer in any way.