How bad requirements are born

A case for getting rid of the tools

I was born in the age before there were any tools to manage requirements or workflow. Lucky me.

When I started working with systems the person who interacted with the customer was the one responsible for defining the need and giving it through to the developers. Usually using conversations, occasionally followed up with an email if it was really complex. It wasn’t seen as a separate role, it was merely seen as a feedback loop as part of the development process.

It made sense and it worked. The person that became aware of the customer need was the one to raise it. The team I worked with didn’t need processes to drive our decision making. We all had common sense, took responsibility and spoke to each other daily. Mostly because we liked speaking to each other and either putting our heads together to solve a problem, or dream about what-if scenarios. There wasn’t any Facebook or LinkedIn at the time either. Our connections were real.

And we had so much fun! We couldn’t wait to get together and save the world with technology. No problem was too big and no requirement not taken up seriously. It was better than any badge or leader board to know you were responsible for solving a customer’s problems, feeling like hero’s everyday.

The good

I accidentally got involved in a software development project that was close to impossible at the start of my career. I was young, inexperienced and testing and requirements were part of development, there were no courses or roles that separated it from software engineer.

3 months, 3 people to deliver one fully integrated and compliant casino monitoring and controlling system.

The next 3 months we spent mainly chatting to each other and soon became friends. The genius front-end developer and the Iranian (or was he Iraqi? I always got it wrong which fueled a passionate discussion on the difference) who handled the firmware and hardware integration.

We came from diverse backgrounds and had different interests and we cared little about what nationality we were, our political or religious views. All we cared about was building something awesome and solving a problem that everyone thought couldn’t be done.

We spent more time talking than working but somewhere between these conversations we spent a few hours working each day and 90 days later we successfully shipped. We easily made the impossible possible without any stress or overtime and soon the product was released worldwide and became the flagship product of the company.

The bad

Fast forward. The system is running in a casino for the first time in the world and to my dismay I’m the only one who knows how it works and able to support it, which ends up being needed every 5 minutes due to some new issue that is discovered. What worked perfectly well in the lab suddenly was a crisis on the floor. I recall a period where for months I literally only went home once every 24–48 hours for a quick shower and maybe get a few minutes of sleep before the next urgent phone call woke me.

After this experience I never looked at documented requirements again, especially highly legislated ones, for the rest of my career, realizing how worthless they were compared to real life.

Integration can only happen when you’re connected

Looking back I’m still amazed at what we did in such a short time though. The system was a fully integrated end-to-end solution. Slot machines were monitored to make sure that not a single event is missed and all coins are accurately accounted for in the accounting system. It interfaced with the security system, the loyalty system and the food and beverage system, totally independent third party systems and departments within the casino.

From a user point of view, however, from the moment you swiped your loyalty card to gain access to the casino until you left, it was a seamless and exhilarating experience. If anyone understands what a User Experience is really about, it’s the entertainment industry. Profit are directly related to the amount of customers that choose to spend their money there rather than on anything else.

Compared to the rest of the world, gaming was on the cutting edge of what technology had to offer and the place to be for anyone who really loved technology.

That was nearly 20 years ago when internet access was a scarce resource accessed by a dial-up modem and 5 email accounts for the casino. Today, with the majority of society having permanent access to social media and internet, finding an integrated experience is hard. Just try to contact the bank with a problem on your account or make an insurance claim to find out exactly how disconnected the world is. It always seems to be someone else’s fault.

The bad

Comparing requirements management then and now, here is a list of the reasons how bad requirements are born and how to prevent it.

1. No relationships

Requirements are all about conversations. That’s why they call it user stories.

We spent more time chatting than doing work during those 3 months of development, yet, we did more work than the rest of the company combined. What was done was done right because we really understood what was being done and why. And we liked each other. The Aussie, the Iranian (or is it Iraqi?) and the South African.

We spent hours talking where after it took a few minutes to get the work done and I could immediately check it and give feedback. Agile didn’t exist yet, but this was better than agile. No tools, no rules. Only responsible people who cared.

The work was done quickly and correctly because we loved solving problems with technology, wanted to help each other and understood each other and what needed to be done. The engineers understood the requirements and I understood the technical constraints and together we easily problem-solved if there was a discrepancy.

And there was no-one bugging us to find out how we’re doing and how long it will take or having to update a workflow system.

A workflow system effectively stops the conversations from happening.

If you don’t want to drink a beer or grab a coffee with the people you work with, you’re in the wrong team. Please go.

When people don’t like each other, errors are introduced to the software and bad requirements are born and built. Building relationships is the most important tool that any product owner can have. All the fancy features and reports in Jira or the real-time access of Trello doesn’t even get close to a just a 5 minute chat with the team.

Get rid of the tools and start building relationships.

2. No customer interaction

I was surprised when I realized that what worked in the isolated lab environment didn’t work in real life.

After however spending literally 24 hours per day on site and on the casino floor the first few weeks after launch to sort out these birthing hiccups, I understood why. I never once spoke to a customer in the lab, only relying on the legal requirements and the engineer’s skills.

I now spent a lot of time crawling on the floor between the cables and talking with the slots technicians between 2 and 4 am in the morning as this was the quiet period. I loved it. It felt connected and it felt real.

I was never too busy to engage in conversation, partly because I didn’t have to go and update a workflow management system, partly because I thrived in being able to solve people’s issues. I felt like wonder woman. It was awesome.

If you’re job doesn’t excite you, please go. If you don’t like speaking to the real users, please reconsider whether the industry is for you. If you don’t care about what the customers need, please consider a different career. I’d rather be friends and work with a passionate barrista than a mediocre CEO.

During these mostly informal interactions I received more insights into what is important and what not than any amount of documentation or second-hand messages ever provided. And when there was a need, it was done within minutes.

There was never a need to create a backlog. Either it was important or not. If it was important, it was done. Immediately. You only need a to write something down when you take too long and can’t remember the details anymore. If you call yourself really agile, you don’t need a backlog.

I discovered that it’s not only the punters that use the system and the IT team that serve them. The slots technicians, the PR team, the waiters and the surveillance staff in fact use it much more than the punters and their needs directly affect the ability to serve the paying customers and the user experience.

I figured out that error code 87672x000 means nothing to anyone, including the developers who wrote it. I figured out that accounting is useless if there is not a report to interpret the information. I figured out that even if the information on the report is perfect but it can’t be printed or is not available when you need it, it’s useless. I figured out that a customer doesn’t know the difference between a Bally or an Atronic or an IGT slot machine or where the machine stops and where the system starts and they shouldn’t either. All they cared about was getting their payout.

The core role of the product owner is to spend time with the customers to understand their needs. The real users. Not the ones selling it, but the ones actually using it. If you’re not getting your hands dirty and dealing with customer complaints, you are not doing your job as product owner.

Bad requirements are born when you don’t understand who actually uses the system and what they need.

3. Always agreeing

One day, I was struggling with a very serious problem involving jackpot payouts. Every time a jackpot was hit all the servers had to be restarted, rendering the casino off-line for a few minutes. During peak hours, this was every few minutes. This would be a very good example of a blocking issue, I learned.

The IT manager with his god-complex did what managers do. He kept blaming and nagging, wanting to know why we didn’t pick it up earlier and when it’s going to be fixed. He had right to be upset because it was a very serious issue, but we were there within minutes from the time it was reported, spent the next 48 hours without any sleep troubleshooting, immediately flew an engineer from Austria out to assist us and had Australia on the line literally 24/7 trying to resolve the issue.

He was being unreasonable and he was making it impossible for me to get any work done. After weeks of little to no sleep, I couldn’t take anymore and lashed out at him and in front of everyone told him to fffuuccckkk off. In those words.

I continued to explain to him why he was being an asshole and that I was doing my best and that he wasn’t helping at all. I also explained that physically, we couldn’t have done anything more and there was no way to prevent the issue in the first place. The only way to test a jackpot is either by emulating it, which we did with each manufacturer, or spending months playing a real machine from each manufacturer hoping for the 1 in 16 million chance that it will hit. We tested it as good as we could and there was no way that we could have known that there would be a difference between the emulated jackpot hit and a real one. Theoretically, it should have been the same.

He quietly and shocked listened to every word as I spoke, not saying a word because he knew I was right and he was being unreasonable. He left me to do my work and within a few more hours the problem was solved.

At first my colleagues were shocked as you don’t speak to a customer like that, especially if it’s the IT manager, effectively the most important person in the casino. Even if they’re wrong. I am however not like that. I don’t care what your title is. Whether you’re the CEO or the cleaner, if you’re being an asshole I’m going to tell it to you. You earn my respect by being good at your job, not the title you wear. When they however came to me afterwards, they couldn’t stop laughing and congratulated me for standing up to him. I said what everyone was thinking, even though I was the youngest in the team.

Our relationship after this encounter was better than ever. There was a level of respect that wasn’t there before. But I never again relied on emulations or harnesses to verify whether something works or not. I only ever tested the real end-to-end workflow.

Bad requirements are born when you care more about keeping your manager happy than making sure the software works and focusing on the actual problem.

Equally, bad requirements are built when you rely on theory, not reality. Labs are not real.

4. Not understanding the problem

In most cases, what the customer wants is already in the system, they just need someone to show them how to use it or where to find it. It’s the product owner’s job to understand why customers are asking for what they are asking before just reacting and putting it on the backlog.

Usually, what they are asking for is not what they want or what they need, but they are trying to find a way to express themselves best they can. When you say yes to everything you’re being asked, you don’t understand the value of why it is being developed.

The primary role of the product owner is to find the value.

What benefit does this new enhancement have? What is the impact of implementing it? Is it really useful to the actual users?

If you don’t spend time with the customer where they show you why they need something, it is not possible for you to understand their need. Understanding a problem has two sides though.

Sometimes, what is a quick win for a customer might be a very expensive development task, and at other times, what the customer sees as really difficult, is technically easy and cheap. Your job is not only to understand the customer’s need, but also the technical implication and what it will take to build it.

Bad requirements are born when you build something without first finding the value.

5. Formalized processes and hierarchy

The best work I did was in the most informal settings. During our 90 day challenge, we didn’t have any daily standups or formal processes.

Here’s the thing. If you’re employing talent, they want to work and be productive. They don’t want to spend their days updating tickets just so that someone in the ivory tower has a false sense of security feeling more in control. They want to feel like hero’s saving the day with their skills.

The requirements were discussed verbally and feedback was given when it was needed. There was not a single meeting enforced on us during the three months and no-one cared whether the requirements were documented in a system.

When you need to schedule conversations, there’s a problem. Conversations should happen in the moment, not when there’s a spot available in your calendar.

When I wasn’t clear on something, I walked to the developer. Actually, I spent more time with the developers in the lab than at my desk. When the developers were unsure about something, they would ask me. When the customers later needed something, they phoned and I immediately reacted. Everyone was happy. The developers, the managers, the customers.

But then things changed. We got a team manager. He was good at what he does and a nice guy and constantly reminded us that management is so important and necessary now that the company is growing. We sort of believed him. For a while. Irony is that the only growth in the company was the addition of him and a marketing manager.

We attended his kids birthday parties and liked each other but things were never the same again. He did everything managers do. The first, introducing a weekly team meeting and a monthly meeting with the customers. I was however too junior and was no longer allowed to speak directly to the customers and his friend was chosen as the customer proxy. She was nice and I loved her, but she didn’t understand anything about networks or techie talk so not really a practical person to have in these meetings. When the word database or operating system popped up, her beautiful blue eyes would cross with confusion. She was however very good at making hot chocolate and teaching people how to use a computer mouse, so she was very valuable in the team as no-one else wanted to do that and we all really loved her. But customer service started declining as more and more requirements were misunderstood or unnecessary due to the new process that was introduced.

The customers started complaining, the team started bickering. Our wings were clipped, unable to fly anymore.

Suddenly, we had a schedule to be on-call for customers and had to be available at certain times. The customers couldn’t phone us directly anymore and the team was constantly arguing. Previously it was a non-issue with everyone always being available because they loved being needed by the customers and able to show their talent in the real world.

We started having performance appraisals where we were told where we’re not good enough and everyone hated it but no-one said anything, silenced by the constant reminders of how this was better for the company. In truth however, that’s what killed the culture and was far from good for anyone, including the company.

Then, one day, the gaming board phoned and asked for me. I spent an hour on the phone explaining something and in the process fast-tracked the certification process to the benefit of both the customers and the gaming board. Absolutely no benefit to me personally. But my manager was furious, a mere junior team member wasn’t allowed to speak directly to the most important role players in our industry, even though I was really the only one who knew the answer and they personally asked for me. I was reprimanded for not following the process he so carefully designed.

My passion was killed instantly and I was no longer motivated to spend weekends at work or do anything more than what was required. Management killed my ability to service our customers and it killed my productivity. I hated it. I hated not being able to connect directly with the customers anymore. I hated not being able to solve problems and use my talent productively.

Where previously I felt I was making a difference, now I felt caged in. I finally resigned in search of a workplace where I could get some work done and play less political games.

Bad requirements are born when you care more about the roles and hierarchy of control than the work and making a difference in a real user’s life.

Conclusion

Good requirements naturally happen when there are good relationships. The more control you try to impose, the less natural a relationship is, the worse the requirements become, the more error-prone and disconnected the system gets.

If you want to be really agile, throw away the tools and the processes and focus on the relationships in your team and the work.

Originally published on Medium: https://everydayagile.com/how-bad-requirements-are-born-2795c2132bf9