Why is the software we built not the software we wanted?

When an organization sets out to build software, the software that actually gets built is not necessarily what the executives picture in their heads or the product manager put on the roadmap. It might be just what users said they wanted, or it might not. What it will definitely be is this: what the developers writing the software understand that it is supposed to be.

It doesn't matter what anyone else's understanding is - the developers will have to make hundreds of detailed decisions that all have impacts, and they can't ask about each one individually or no code will get written.

So, how can organizations get their developers the best possible understanding? I certainly don't have a perfect answer, but I have seen these approaches help in the past: 

1) Enable developers to become domain experts

Is the software going to be used by the sales organization? Send the developers on sales calls, and have them sit in on (or conduct) user interviews with the sales teams. Is this a new product for dog shelters? Have the developers spend a day at a shelter. Will customer service agents use it? Have developers spend a day taking customer service calls.

 Every time a developer makes a user-impacting decision, the goal is that it would be the best decision that the user or domain expert within your organization would make... the closer the developer is to a domain expert, the more likely this is to happen.

2) Review decisions (and software) with others in the organization early and often

 Reviewing software at the end of a sprint is standard practice in agile development methodologies, and definitely helps. Reviewing design decisions before they are actually implemented just tightens the feedback loop even more. This has to be balanced with respect for the time of others in the organization - for that reason, the most frequent reviews often happen with a team lead, project manager, or business analyst. Regardless of the role, the key is that this person has to have a very good sense of what users and the rest of the business understand about what the software needs to be. If someone will be frequently playing this role, then it is essential that this person do everything she can to become a domain expert. 

3) Recognize early when developer decisions are creating business trade-offs and get additional input

 Some decisions are more important and others are less important, and it is not always easy to tell the difference. This is an area where an experienced team lead can pay big dividends, if some of the developers do not have a lot of domain experience, as is very often the case. The team lead can correctly flag the decisions with the biggest business impact so that others in the organization can weigh in on them early in the design process. It is also useful to put more focus on decisions that cannot easily be changed.

4) Make sure that people in the organization with a forward-looking focus review the decisions and software

 In a large organization, it is surprisingly easy to meet with lots of people who are all focused on the question "how will this help me solve my pain points today?" The organizations' plan for a year or two down the road might eliminate those problems with process changes, though. Or, there might be a focus on a different set of customers. If no one with that knowledge is consulted, the software will soon solve the wrong problems. It is important to make sure that someone who knows the organization's desired future state has the opportunity to weigh in.

5) Allow enough time in the schedule to do all of the above

Developing software that will be used by other people to do things that you don't regularly do yourself is highly challenging. It is more successful when an organization makes it a priority to be sure that developers have as accurate an understanding as possible about what it is like to be a user, and how the organization plans for the software to impact its business.

Agree? Disagree? Have other suggestions? Let's start a conversation below

(This is just one of many answers to the title question... look for future blog posts about others)