Next in my interview series on the topic of quality and how to integrate it from the start, I talk to experienced product owner, business analyst, requirements engineer and Agile coach, Benjamin (Beni) Wyss.
(The following conversation has automatically been translated from German).
Pia: Hi Beni, I'm glad you took the time to chat with me today about quality and Built-in Quality.
Beni: Hello Pia, thank you very much for the invitation, I am very much looking forward to the conversation.
Pia: Wonderful. Before we start, please introduce yourself briefly. Who are you and what do you do for a living?
Beni: Benjamin is the official name, but I like to be called Beni for everyone. I am 37 years old and have been working as a Business Analyst, Product Owner and Agile Coach for almost 20 years.
I currently work for Infometis. We are a consulting firm in Zurich and are committed to establishing and implementing quality and automation for our clients.
In 2004, after my apprenticeship as a banker, I started my career in IT as a business analyst in classic waterfall projects. After a few stations in the financial industry, I finally came into contact with an agile project for the first time in 2011/2012. As a business analyst in a Scrum team, I immediately had enormous fun because I could finally combine my passion for technology and analysis even better.
My next station took me to a software development company as a product owner. I quickly had to learn to deal with questions like:
"How do I deal with it when I have too many stakeholder demands and great delivery pressure? How do I make that work when I have to keep quality high?"
to deal with.
I learned a lot back then and now pass on this knowledge at Infometis in client projects and as a coach.
In my private life I am married to a wonderful woman 😇 and a very curious person. I love to read. Be it about physics, chemistry, psychology or a thriller. When I'm not reading, I love to do sports.
Pia: Thank you very much. You have already hinted at how it comes about that we are both sitting here today. Yes, we are married and because you are a great husband and like to support me on the one hand, and on the other hand we are here today because of our common passion for good software. We met at work and therefore have many professional points of contact. We also like to exchange ideas.
This is for the information of our readers, in case the tone becomes too familiar in places. This fact certainly does not make our professional discussion any less interesting, at most a little more entertaining to read.
Tell me, Beni, what do you think of Built-in Quality?
What is your personal interpretation of it? What do you think others in your business environment understand by it?
Beni: First and foremost, I am very happy that this term exists. I "grew up" with the term "testing". And testing is the last phase before the release. The quality gates beforehand are often of a formal nature, such as does the specification and design meet all formal criteria? Is the budget available? Etc.
But what happens if something doesn't work as expected? Or if expectations change during testing? I often had to negotiate whether something was a mistake or whether it was "working as discussed". But that always made me feel insecure: What if we discussed the wrong thing?
With Built-in Quality, I like the fact that quality is seen as part of the product throughout all phases.
In 2006 I did the IREB Requirements Engineering Certificate. In the course we talked about the value of requirements engineering (RE). One of the main arguments was: avoid error costs. If we do good RE, fewer errors will happen. At that time, everything was very focused on errors.
It may well be that we build the wrong product, feature etc. (technically) completely correctly. It's about two things: "building the right product" and "building the product right".
Built-in Quality sums up my world well here. We have to think quality from the beginning to the end. But what does quality actually mean? We have to talk about that, and we can only do that together.
Pia: I'd like to get back to classic requirements engineering. You said it was about getting it right from the start, avoiding any mistakes. How did you see that in the past and how do you see it today?
For me, it is an unbelievable amount to ask of a person, as a business analyst or requirements engineer, to consider everything from the very beginning. Is that realistic at all? Does it make sense to try to do it alone?
Beni: No, it's not realistic and no, it doesn't make sense to do it alone.
RE means talking to stakeholders in particular. In the past, people thought they knew exactly what they wanted.
This is also evident in the quality feature of a specification: "completeness".
I am of the opinion that this is not possible. That it always needs iterations and feedback loops. And these should not (only) relate to specifications, but to executable software that is as close to production as possible.
When I use something, I know whether I want it or not. I see if it solves the problems I have, if it is user-friendly, if I find the functions, if I am successful with it.
I was told by a stakeholder, when asked to review my use case diagram, "I am not paid to understand this".
That had a strong impact on me. The stakeholder wants software that helps her do her job well, not check my chart.
That's why I'm not a fan of up-front RE and a big friend of continuous RE.
Continuous RE, however, brings other challenges. On the one hand, I have to be able to deliver software continuously in order to determine the next requirements based on it. I also need the commitment of the technical specialists. They must have the flexibility to continuously question the requirements with the team. This requires time and commitment. Both are not always easy to come by.
In the long run, however, I save time and resources by reducing waste. A once important requirement may not be so important today. The most urgent problems and most promising ideas are implemented promptly. New, better ideas emerge.
This requires collaboration, across silos and departmental walls.
Pia: Absolutely, I am totally with you. What I still experience too often today is what you also described. The organisation is already agile, but there are still these walls.
In terms of testing, for example, testers or QA specialists throw test cases over the wall for review. Or these people are obliged to have their test cases reviewed by business analysts. Personally, I often think the same thing that your former stakeholder said: "I'm not paid to review your test cases".
Do you know this too? How do you deal with it?
Beni: I was once the bad guy and had test cases reviewed.
Pia: You wrote them, or a tester gave them to you, and you had someone else check them?
Beni: I'll come back to that in a moment.
Having something reviewed, throwing it over the wall, emailing it is incredibly inefficient. I am of the opinion that what is discussed may be written about, but everything that is "officially" written must be spoken about.
If, as a business analyst, I also write the test cases for the sake of "efficiency", this is counterproductive. I deprive the specialists of the creativity to find more effective and better test cases with good questions, I influence them, and I become a bottleneck.
Often this kind of discussion is seen as a waste (the testers don't test; the programmers don't programme). But what is 15 minutes of discussion compared to opening an email, looking at Excel and trying to understand what the sender wants from me?
Such discussions also foster explicit shared knowledge. Often, we have implicit shared knowledge. That is, we think we understand the same thing or interpret a thing in the same way, but that is often not the case.
With explicit, shared knowledge, the risk of being wrong is not zero. But the probability of recognising a misunderstanding is much greater in personal conversation.
Or as it says in the manifesto for agile software development:
"The most efficient and effective way to communicate information to and within a development team is face-to-face."
In a former project there was a so-called "test case service". In terms of cost efficiency, this was located abroad. We had to send the specifications and got test cases back in return. So, I sent my finished, released specification. What came back was the sheer quantity of 250 test cases. The external service was also paid according to the number of test cases written. I was moderately motivated to review 250 test cases. So, I decided to write my own test cases. This was much faster than reviewing everything.
At that time, I missed discussing and challenging my specification with QA professionals and then letting the specialists design the test cases with full confidence.
Pia: It's a tough story and I hope we don't experience situations like this anymore and that it goes in the direction you described. You want to have specialists at your side who support and challenge you in both requirements elicitation and testing.
I would now like to talk about value. People like to say that a user story must bring (business) value.
What does value mean to you? What is the value of a user story?
Beni: That's almost a philosophical question...I'll try 😊
Personally, I find it difficult to give user stories a concrete, absolute value in iteration-appropriate sizes.
When discussing the value, the value model helps me. This says that on the right-hand side there are the "lagging indicators" that are easy to measure but difficult to influence. For example, for a video platform "number of minutes played per user". I can't simply decide that users need to watch videos longer. But I can easily measure it. On the left side are the easy to influence, difficult to measure "Leading Indicators". This could be "Users can earn bonus points for every minute they watch". This Leading Indicator can be implemented.
The hypothesis is: "With the bonus points, we increase the number of minutes played per user and thus the advertising revenue". That's the (business) value I'm hoping for. In order for me to achieve this, however, the users must also have a "value" from the bonus points. Be it a ranking with awards, vouchers or the like.... That would be the "user value".
Value is therefore always a question of perspective. What is the "value" of implementing the cookie banner on my website? For the user, in the best case, transparency; for me as an entrepreneur, that I am acting in accordance with the law. That is also a kind of business value. Or if I reduce my maintenance costs with a redesign. That can also be a business value.
In the case of stories, the team should therefore talk about it: Who enjoys the implementation and how? And because one man's joy is another man's sorrow: How can we prevent any negative side effects?
Pia: Yes, what you say makes perfect sense. However, what I often encounter in my daily work is that everyone is so fixated on business value that technical stories are not considered.
If, for example, as a tester in the team I create a story for a new test data set and I don't spontaneously manage to make the connection to the business value, my story ends up at the very back of the backlog.
How do you deal with this as a product owner?
Beni: That was a learning process for me. It's the classic feature trap. We always want to build new features because we are often measured by them. That's when the clientele sees how "hard-working" the team has been.
But functions are only the tip of the iceberg. If we try to define quality, and here I like to orientate myself on ISO 25010, functionality is only one attribute of many that make up the quality of software. There is also maintainability, security, usability, etc. If you tell me as a tester that we need X to be able to test automatically, this clearly pays off for maintainability for me and has just as much value as the functional requirements.
These often non-functional things under the surface of the water absolutely must be done, even if no direct business value is apparent. If we don't do these things, we will soon no longer be able to deliver any business value. Nobody wants to buy an insecure application. A non-maintainable application costs too much.
As PO, I am responsible for the whole product. And all these quality attributes support me in delivering concrete business value. In addition, the costs for a feature tend to be lower if I have a stable basis and also maintain it.
We are also welcome to spend time in between to streamline our own product with re-factorings, i.e., removing functions that are no longer needed, tidying up redundant tests, etc.
I have not always seen the non-functional quality attributes in this way. In the meantime, however, I think that these things should be prioritised at least as high, if not higher, than some functional requirements.
Pia: Absolutely, and it's good to hear that from someone in your discipline. As a QA specialist, I often feel like I'm talking to a brick wall.
Finally, I would like to come back to a topic that you have already briefly mentioned: Implicit and explicit knowledge and the discussions in the team that are needed to make knowledge explicit.
I often see that discussions in the team only take place within one discipline. For example, I see developers only discussing among themselves. They often don't dare to question you as PO or other disciplines. The same is true for testers and other roles in the team.
How do you encourage discussions in the team so that your colleagues dare to question you?
Beni: An incredibly good question.
I have experienced this many times. In a team I once said somewhat exaggeratedly: "Guys, I'm stupid. Help me. I'm not the all-knowing one."
As a business analyst, I love details and often think a lot about details and solution ideas very early on. Also, in the role as PO. Nevertheless, in order to influence the team as little as possible, I have the following tactics:
I don't immediately share all my thoughts with the team. I deliberately leave out details at the beginning and focus only on explaining the problem. Then I let the team discuss possible solutions. Sometimes I also leave the room and let the team show me their ideas for solutions afterwards. Then we compare and discuss my and their approaches. You have to be aware of that as a PO. You have to explicitly demand these discussions and ideas for solutions and also design the room accordingly so that the team is not pushed in a certain direction.
Pia: Absolutely, yes! I hope that many product owners will read our conversation. I think many don't dare to. Many think they have to know everything. I think that's a shame. I think that everyone, no matter what position or role, benefits from discussing things as a team and getting better together. I think it is an absolute strength to be able to say that you don't know something and to encourage others in the team to actively contribute with their important skills and to deal with the product.
To round off today's topic, could you summarise for our readers what the most important things are for you in terms of quality and Built-in Quality? What should be taken into account? What should you adhere to?
Beni:
Number 1 for me is the team sport idea, which I can actively promote as a PO or BA.
This is communication, working together, building cool software together and exchanging ideas about quality and its meaning in one's own context.
Number 2 is the idea of lean functions and applications.
Solving problems with simple means, not solving every problem and removing the solutions for problems that no longer exist from the application. Staying lean is the motto.
Number 3 is continuity. Slow is smooth and smooth is fast.
I.e., what we do, we do right, with all the quality features that are important to us. We promote a stable application. This is what we build the business value on. We do this continuously and at a pace that we can maintain in the long term, not under constant time pressure.
Pia: Excellent, thank you very much for that. I endorse it 100%. Thank you also for the wonderful picture with the iceberg. It definitely helps me, and I hope it helps our readers too.
If someone asks me in the future where the (business) value is, I will refer to the iceberg. If we always concentrate on the top, we cannot satisfy our users and stakeholders in the long term.
Beni: Then we would perish...
Pia: I hope not like the Titanic....
Thank you very much for the super exciting interview.
Is there anything else you would like to share with our readers?
Beni: Thank you very much for allowing me to share my personal opinion and experiences here.
Oh yes, and:
The minute is important. The second often backfires.
