How to deliver software to make customers happy?

Nowadays, many IT companies ask the question „how can we improve software delivery to our customers?”. In Jit Team, we asked ourselves a different question: “what makes our customers satisfied with the software we deliver?”

This question looks simple, but it’s not easy to answer. Jit Team develops IT systems for many different customers. There are more than 400 people involved in these projects. And every person has their own perspective and their own opinion…

To find the answer, I decided to conduct several interviews with my colleagues. I asked them simple questions:

• how do you recognize that our customer is satisfied with our service?
• what do we do to satisfy the customer?
• what is most important in our daily work?
• what do we do differently than other companies?

We had very good conversations! And finally we got a consistent picture of our software development process.

Everything starts with the need to understand the problem of our customer. It’s not enough to get the specification or requirements written by the customer. Usually, we get something like: “please make the calculation, display the results here and summary here”. But we don’t stop at this point. We continuously ask questions: “why do you need it?”, “what problem do we want to solve?”, “what is the reason for having this solution?”

Why do we do it? The reason is simple. If we understand the real problem, we can jointly work out better solutions.

We noticed that it’s extremely helpful to have a good analyst in the project. Quite often, customers know many things about their business context and about the product we build — but they have limited knowledge about decomposing requirements and managing the product backlog. So we want to support them with a person who can decompose and write requirements.

Decomposing requirements is an essential skill here. Alistair Cockburn created the model with 5 levels of use cases:

Very often, customers present requirements on “Very high summary” level (“I would like to have the system for automatic payments”) or “Summary” level (“There should be a report of past payments”). We have to decompose these requirements to “User-goal” level. Only this way we have shared understanding and we can track progress of the project.

If we managed to decompose the requirements, we can estimate the project using reference tasks. It can quickly give us some forecast about the size of the whole project.

All this long description doesn’t mean that we want to have long analysis phase before starting development. On the contrary, we want to start the development and deliver the first version of the system as soon as possible. We have two goals here. Firstly, we want to get early feedback from the customer. And secondly, we want to show the customer that we can quickly deliver the value.

The tools are important. We follow the rule that our tools should serve the customers, not vice versa. For example, we experienced that many customers do not understand Jira. Jira can be a great tool, but there are too many options and buttons for inexperienced users. Roadmaps in Jira look quite technical. So we usually create the roadmap in form of a simple table and we put it in a visible spot. Then, we continuously update the roadmap with current progress. The roadmap must be as simple and transparent as visible.

After every sprint we present not only developed increment, but also we present current progress of the whole project. We want to avoid this situation: we deliver something after every sprint, but we do not move closer to the solution of our problem. It looks like Scrum creators also noticed this need and they introduced Product Goals in the latest update of the Scrum Guide. We tracked our progress to our product goals much, much earlier…

When we present the progress to the customer, we exceptionally care about transparency and honesty. When everything goes well — we say that it goes well. When we have troubles — we admit that. When a question or doubt appears — we raise it as soon as possible. We strongly believe that transparency and honesty build trust. And trust is the foundation of good cooperation.

Our world is changing fast — and that’s why we allow customer to change the scope of the project. The customer can always decide to add a new feature. They can also decide that something is not needed anymore. We add new elements to the roadmap, estimate them, set the priorities. It’s not always pleasant. It’s not easy to remove good pieces of the code or analysis. We did some work, but we have to erase it. But the game is not about the pleasure. The game is about delivering the value.

We care about continuous communication with customers. All members of the team know that every time they encounter some doubt, question or nontrivial problem — they should contact the customer. There are tasks where a programmer contacts customer every day. Sometimes new people are amazed with intensity of these contacts. But later, they admit that the project would have been much harder without this communication.

All these solutions would not be possible without good technical practices. We use continuous integration, code reviews, short-living branches, feature toggles in every project. We propose our customers frequent deployments to production environment. Agile and Scrum are important — but they are pointless if our code does not work.

There are a lot of important elements in this article: understanding customer’s problem, requirement analysis and decomposition, estimation based on reference tasks, fast delivery, adjusting tools, continuous showing current progress of the project, openness for scope change, continuous communication customer, technical practices…

Each of these element could be the topic of another article. But let’s ask ourselves another question: what is the most important element? What element has the biggest impact on success or failure of our projects?

From all the conversations I had, one thing seemed to be the crucial element. It’s creating trust while working on the customer’s problem.

How to create this trust? You need to be honest, open, transparent, you have to present all challenges. You need to know that your goal is to solve customer’s problem, nothing else. You need to be convinced that there’s no room for any games nor understatements.

When I talked with people and heard sentences “we successfully finish our projects”, “we get the job done”, “we are open and honest” — I heard real pride in their voices.

All the things described in this article are not secret knowledge. You can find these practices in agile manifesto, in agile principles, in Scrum, in Extreme Programming… We haven’t discovered anything new. We have no secret ingredient.

But the game is not about discovering the secrets. Everybody knows the theory. The game is about the practical ability to use agile methods. And it’s not easy. Agile and Scrum are easy to understand, but difficult to master.

I started the interviews asking about techniques and practices. But then, we suddenly started to talk about much deeper things. We talked about culture and values in Jit Team.

Some time ago, Jit Team defined four values: Human, Tech, Team and Fair Play. But it’s all. There are no internal trainings about these values. No webinars about them. No exams for employees. No fancy posters on the walls. These values are inside human brains.

How did it happen that people across the organization share the same values? That’s a completely different story…