Is your project opinion or data-driven?

“Do what I say.” Sounds harsh, doesn’t it?

How about: “This is our strategy”.

“The Management decided…”

“To let us grow…”

“This is for the sake of our project”.

“I’ve done some research, and here is what we’ll do…”.

Opinions

Project decisions, those regarding the choice of tools, testing methods, or which direction we are going, should be made based on data.

Unfortunately, the longer I work on IT projects, the more often I get the impression that most of the important decisions are authority-driven or opinion-driven. I love the term HIPPO (Highest Paid Persons Opinion) from Gordon Guthrie’s post.

First things first – opinion is always OPINION. No matter if it’s good or bad. Somebody made up his/her mind. Period.
Data are independent. They are just figures, numbers, and graphs. Without emotional connections, biases, or social influence.

Our brains are extremely self-centered and suggestible. Moreover, each of us wishes to see our information bubble. Even when we try to be objective, it turns out, that when making decisions we do not take into account all the options available. I recommend to my Polish readers the book by Miłosz Brzeziński: “Wy wszyscy moi ja”, in which this topic is presented in detail.

In short, we operate much more efficiently, both in private and professional life, if we can consult our ideas with other people. I mean people with more, similar and less experience than ours in a given field. This approach allows us to look at the problem from many angles that we would probably never have thought of ourselves.

We must remember that a wrong decision means a cost. Money is not always a cost. This can be technical debt, loss of customer or team trust, and the introduction of adverse changes to the system that will be very difficult to reverse in the future.

Example

Let me give you an example.

A testing team grows.
They select tools and skills to let themselves work better and more effectively.
As they are not widely experienced, they try to work on a solution, that would serve their needs.

They choose the toolset, direction, and plan for the future.

Unfortunately, they have a manager, who “knows better”, a manager, who “done this before”, “used another tool before”.

pexels.com

In the end, our solution-seeking test team must use a tool that they don’t understand or that doesn’t quite match the specifics of the project, struggle with the technology that they don’t want to use, and are simply frustrated.

Why of why

I try to find good intentions in people. It’s not that the decision-maker is trying to make someone angry. The problem is that our cognitive limitations inevitably simplify the world, and give us ideas that we already know instead of those, which fit the situation.

Additionally, I know managers who are so attached to their position in a corporation, labeled with a grade number, that they don’t look below that level and don’t seek value in talking to the teams.
They are guided by “experience” and “good intentions”.
And yet, it is the communication, exchanges of views, or even quarrels that bring value, open up new spaces for discussion and project development.

How to prevent opinion-driven development and minimise the risk?

Luckily, all of us can prevent opinion-driven management.
How to do it?
When you are a team member – start by asking the question WHY. Don’t give up and keep repeating it.
What is more, no matter if you are a manager or not:

• Collect project data
• Collect metrics and share the among team members and with your managers
• Talk to everyone – confront your point of view
• Don’t invent the wheel – there are plenty of examples – which you can start from
• Everyone can be mistaken from time to time, it’s ok to fail – It’s important to learn from it.

Those may be the data collected from sprints, Excel sheets, figures calculated over your work. All of those matters. Analyze them and make wise decisions. Keep trying.
Eventually, no tool, methodology, language o approach is given forever (I hope) 🙂

It may sound like a paradox but, as professor Adam Grant says, people, who try over and over again are not afraid of trying, get better results than those, who plan in detail and then act or do not even try.

I recommend you his TED speech:

https://www.youtube.com/watch?v=fxbCHn6gE3U

And how about you? Do you collect data? Do you use them?

The Tester will not leverage the quality of your project

Imagine a project, in which code quality is not the biggest priority. What is then, you’d ask. The top five are usually:

Features.

Market.

Competition.

Clients.

Revenue.

The first problem

As I wrote in my previous post, all of the above come first until the first major system malfunction. What comes next: revenue losses, reputation losses, long outages, and a significant decrease in trust.

At this point companies tend to stop, look around and come up with this brilliant idea: “Let’s hire a Tester“. When the concept itself it’s not so bad, there is usually more to be fixed than just a staffing issue.

The problem is, that the companies, who have never paid much attention to their product quality, focusing on new feature releases, assume that hiring one person will solve all the quality problems in the organization.

My project experience proves that a single Tester will not leverage the quality of your product.

How to produce good software

Let’s stop here for a moment. What is a software product? I’m generalizing here: – it’s a concept, the code, and a blend of marketing. I assume, that when a company wishes to advertise and sell the product, this product needs to be good. Not only well-promoted but also based on some good coding.

The code that is considered good when:

• Does what it should.
• Follows a consistent style.
• It is easy to understand.
• Has been well-documented.
• Can be tested.

As you can see, the act of testing is just a piece of the puzzle.

Good coding makes a good app. That’s why the companies hire the best Software Engineers, pay them good salaries and benefit from their knowledge.

It doesn’t mean that when the company employs great Developers – your project doesn’t need Testers. It probably does.

The biggest blocker for project quality is not the lack of Testers. It’s the unwillingness of learning. Continuous learning requires feedback loops, where testing plays a key part in it.

The Tester

A Tester, Quality Engineer, Quality Assurance Specialist, or however you name the role can point you in the right direction. Emphasize the flaws in the process, argue with bad practices and embrace some positive changes. Unfortunately, it will only happen when you allow the quality into the project. When you employ a single Junior Tester to save money and count on the spectacular results, you may be surprised.

I like this saying: “if good testing is expensive – try bad testing”.

I do not think of Tester’s salary (which, in my opinion, shall not differ from the Developer’s one) only. Good quality is expensive because it takes time. Good software quality helps the project to run in the correct direction, and avoid major system malfunctions, but it is expensive.

Why?

When the quality comes first:

• the developers spend more time on coding because they discuss potential good solutions – they don’t chase who pushes code first into production without testing
• there are Unit Tests beside the application code
• there is an infrastructure that allows testing before pushing to production
• there is room for improvement
• the developers pair to catch the obvious mistakes on the fly and learn from one another
• TEAMS ESTIMATE tasks, taking quality and risks into account
• potential risks in the systems ARE MINIMIZED – not left alone

and finally – the application is tested – not only by one automated or manual test – but by the set of different functional and non-functional test scenarios. The tests are regularly reviewed, adjusted, and observed.

Sounds idyllic – right?

So when I hear “let’s hire a Tester to improve the quality of our product” – I do understand and don’t understand at the same time.
I shall repeat over and over again – quality is the whole team’s responsibility.

Quality takes time – AND THAT’S OK.