The system

I was happy. Finally, after six years of terrible user experience, I was going to close my bank account. The prerequisite for doing this was to repay the mortgage, which I had already done the previous week. Why during COVID was I still going to risk my health and visit the bank branch? Why not close my account online? It’s because they don’t provide this feature. Why? It must be too complicated.

I went to the large, empty bank building. I hate it, with neither signs nor staff to help me. As soon as I entered, all the employees immediately started looking elsewhere, trying not to make eye contact. It’s a Polish bank, and I’m Polish: I know the drill.

I found a queue where I had to wait - lucky me.

"Next!" the clerk said
"I'd like to close my account please," I said
"Did you withdraw all the money, so the balance is zero?"
"No, I left a few Polish zlotych to cover some fees or…."
"You must take out all your money before you close your account."

I went to the next window, withdrew my ten polish zlotych (£2) and after 15 min re-queueing I broke the sad news (for the bank) that I was going to leave them - it just wasn’t working out between us anymore. Unfortunately, there was some problem with the system. How did I know? Because the lady was clicking away like crazy. I doubt she was playing Solitaire because there’s not so much clicking involved.

"What's your phone number?" the clerk asked.

This was the culmination of six years of bad customer service and a lot of time wasted by visiting this and other branches all over the country. I was a Senior Customer, an expert in this bank, who knew precisely that even stupid questions must have a profound reason, that the system is asking them to ask me about this. Yet, today I was not in the mood, so I politely and sincerely enquired:

"Why do I need to give my phone number, which you already have,
which I've already given to you a million times when I just want to 
close the account and say goodbye?"

"It's required by the system."

I knew it! The system.

Broken process

Ten years ago, I applied for a job. I was in my 3rd year of a Computer Science degree. I dreamed of being a professional programmer and to stop living in a dorm room and eating junk food. I applied to a large Polish IT company who had won all the contracts for the banking systems in the country. They were the most dynamic years of my professional career. I learned a lot.

The banking system we were building was a clone of another. This meant that every new bank could inherit the codebase from the previous one, so every new bank theoretically became better. What was amazing, and I will remember this forever, is the fact that from first days (after three months training) I was a developer who directly talked to the client from the bank. Whenever I implemented something, it was tested by somebody from the bank. If something did not work like it should, I received a phone call at my desk and I fixed it. This way of working replaced structured planning, as the requirements were always cryptic.

Early feedback was necessary to close the contract - people had to be happy to sign it. Those from the banking side who gave early feedback were subject matter experts, an oracle who says that we correctly understood and implemented what they envisioned.

Nevertheless, the user of the system was never part of any of the conversation. Input from the users was never planned to be recorded. The contract had been finished, the system delivered. Win-win, both sides were happy. Although, not the clerk and I, who just wanted to close the account.

"My phone number is +447914…," I said
"Oh, so you have a non-Polish phone number."
"Yes, I have been explaining this for six years, every time I talk with somebody
from your bank."
"If you are not going to stay in Poland and you had told me this, the account closing process would 
have been faster."
"…", I couldn't find words to reply
"You know what? Let's start over, and I'll select that you're going 
overseas so closing the account will be much faster."
"Much faster? Brilliant idea!" I replied.

Why does nobody collects feedback from these people? It’s a real gold mine for data! If only some decision makers had been in my shoes and seen how much time and frustration it took to “start over” (removing the old closing account application and starting again, but this time entering my British phone number), I bet the application form would be more user friendly.

What’s the essence of Software Development?

Software development has to connect two groups of people: the developers who code and the users who use it. Developers implement what they were told to do. And after one week, the clerk uses it. The developer sits next to the clerk and sees, hears and feels the entire experience. The developer must feel an awkward moment of silence when the clerk tries to do something which takes forever. Meanwhile, the customer sits on an uncomfortable chair and waits for a simple request to be finished.

It was not a problem that the system had already been badly implemented. The problem is that those bank clerks have no power to impact the next project road map for a tool they will use for a large part of their professional career.

Some say that this is because large contracts are negotiated in the Waterfall manner to estimate the costs and plan the budget. Fair enough, no company is sued, but the final effect is far from ideal. Why not do both: nobody is sued, and both groups (users and developers)actually like the product?

Five steps to improve quality of final product

Below is a list of five straightforward steps which dramatically improve any large project. More importantly, they are independent so that you can deploy one or more separately.

Step 1. From the company, allocate to the development team one or two people who will use the application, who will directly use the product (e.g. bank clerks). They’ll meet or dial in every day. Their job is to test what the developers have built. The dev team would hear and learn from the feedback, the gains and pains. As a result ,they will flag a lot of errors in the feature requirements so those mistakes will never have to be implemented (saving time and money for both parties).

Step 2. When it comes to UI (User Interface), ask random members of public. Pay them for their time. Give them the latest release to use, ask to proceed to, for example, removing account and record their feedback. It’s how UK Government projects are developed. Taxpayers are able to fill in a participation form and are selected to test the product, while earning some money. It’s incredible how much it improves all government websites.

Step 3. Measure the satisfaction level, not only from the customer’s point of view but more importantly, from the workers who use the application. Those workers are almost always ignored. Usually they are put in front of the ready product, and then they are told to use it. Initially they think they’re stupid because they don’t know how to do simple things, and more experienced colleagues have to help them. But soon they realise it’s not them, it’s the software that is stupid.

Step 4. Forget the sign-off. The system must be developed iteratively, not from A to Z until sign off. Merge the two worlds of large contracts. One world must be defined in the agreement precisely and in a large number of requirements (the so-called Waterfall), but you cannot forget about the most crucial part, the weekly iterative approach before and after the sign-off. And no, it’s not about bug fixing. The features must be delivered every week, not every year. Impossible to write down in the contract? Just choose a different provider, not the cheapest one who only guarantees the first part and bug fixing.

Step 5. Own the code from day one. Own the process from the very first day. Have a computer in your organization where you’re able to start the whole application on your own. The software provider must know that you can run it, so you can replace them at any time if you’re not happy with the quality. There should be one script which starts everything on a brand new computer, with no knowledge required.

Clerk driven develpoment

Even the best developers and the best bank staff won’t be able to create a decent system without early feedback, lean process and tight collaboration.

"You're a very important client to us. 
That's why it takes so long to close your account." The clerk said.

Only because you have such great employees who can make up for the mistakes made in this project, is this bank still alive.

To all people managing IT projects, especially in a non-IT organization: Do you think that once you outsource your projects, that’s the end of your problems? Actually, it’d be even harder, as you need to make those two separate organizations work together iteratively.

Furthermore, yellow sticky notes are not Agile. Agile is when a bank clerk, shop assistant or a nurse is able to give feedback on every single feature delivered, and when this feedback is heard by the developer who implemented it. It can be a simple ‘good job’, or ’the client who wanted to close the account had a non-Polish phone number and I had to start over to make it faster. Can we change the phone number at any point on the closing account workflow?’