Interview with Joe Rainsberger, Canadian Software Development Consultant

Luxoft Traibning interviewed Joe Rheinsberger, Canadian software development consultant and author of many IT work.

For his contribution to the development of flexible methodologies, he was awarded the highest award from the Agile community - the Gordon Pask Award in 2005 (in the first year of creation of the award). He is the founder of XPDay (North America). JUnit Receipes: Practical Methods for Programmer Testing, a book by Joe Rainsberger, has become world famous. Joe has been practicing flexible methodologies since 2000, and during that time his articles on Agile development have been published in leading developer journals, including IBM DeveloperWorks and IEEE Software. In IEEE Software magazine, Joe is the editor of the “Not Just Coding” column.

Further abbreviations are used in the text.
KM - Kurek Maciej (Agile Trainer at Luxoft Training)
JB - Joe Rainsberger

KM
Hello JB. Or Joe? How do you prefer?
')
Jb
I have no particular preferences, so as you like.

KM
Good.
First of all, nice to meet you. My name is Maciej, I am an Agile coach at Luxoft and am very happy to have the opportunity to talk with you today. We met in Kiev about two and a half years ago, when Mr. Cockburn was preparing for certification on the Scrum-master, it was before the Agile Central Europe conference.

Jb
Similarly, it was in Eastern Europe, I remembered. I spent some time in Alistair’s classes, after I finished mine.

KM
Right, and I was there.

Jb
Oh cool! It's nice to see you again and to be able to personally say “Hello!”, And not to wave your hand from the other end of the hall.

KM
For sure. I learned that you will conduct a training called “Value-Based Approach in Software Development” . It will be online training, right?

Jb
Yes, we are planning it. This is a course that I usually spend in one or two days, so we want to conduct it in the form of two online sessions for half a day in March.

KM
Great.
My first question, in fact, is caused by the name of the training - “Value-Oriented Approach in Software Development”. To be honest, when I first read it, I immediately thought: “Aha! Can be reduced to VDPD (Value-driven product development). Another fashionable jargon and another keyword in my dictionary. ” Could you briefly describe what it is? Is this a common concept with fundamental principles like Scrum, or is it something completely new?

Jb
The name actually arose in response to the fact that the market did not really like my first one - “Product Sashimi”. In fact, I started this course about five or six years ago called Sashimi products. And of course, I wanted it to be funny, I thought it would be great if the audience heard something unusual and thought: “Oh, Sashimi products!” I sort of understand what this means, but what is it really? " In Agile, we say that delivering products in stages is a good idea. But we didn’t have enough effort to explain how to do this. And Sashimi products is my style of research and product delivery in a phased manner. And of course, "Sashimi" refers to thin slices.

Sashimi looks something like this.


After several years of promoting the idea of ​​Sashimi products, I finally decided to listen to the market in the fact that people do not like the name. And we changed it to “Value-Oriented Approach to Product Development,” because it sounds like something that most companies will understand. It is an idea to explore and deliver products, focusing on creating the most valuable parts first.
You can call it either Agile product development, or product development in stages - I think it's all the same. The phrase "value-oriented" simply stresses that we make a decision to a greater extent based on the understanding that, in our opinion, it will be more valuable for our clients, and not, for example, that it is easiest or cheaper to create first queue and so on. And yes, you are right, every time someone uses “driven” in the title, there is a risk that it will become another fashionable jargon. But I am ready to accept suggestions on how to make the name even better. For now - this is the second version.

KM
Clear.
Let's focus now on the word “value.” Value is a very subjective concept. And in my experience in small and large companies, I note that now not one person is responsible for the product concept. Usually this is a group of people, isn't it?

Jb
Yes.

KM
And these people have different goals, therefore the value for them is very subjective. Based on your experience as a consultant, what are the key factors to consider when determining value in a particular situation?

Jb
Yes, as you say, the value of different people is different. So I do not think that an attempt to come up with a single, widely applicable definition of value will be very fruitful. Instead, we must recognize that there is a group of people who have different ideas, which is valuable for them. And we have to find a way to help them figure it out.
And I know that it sounds like a kind of excuse, like an answer, which in fact is not an answer.
But in most cases it is. Whenever we have a group of people who disagree about something, trying to teach them what they have to agree on will never work as well as teaching them how to articulate to each other what they have in mind, helping them focus on how their ideas are similar and different. And therefore I would not like to suggest to anyone: “You should focus on this value”, “Always focus on revenue”, “Always focus on profit” or “Always focus on quality”, etc. I think this is wrong. There is one common feature for all of us, thanks to which we are generally interested in any Agile concepts, namely: whatever value means to everyone, we want to get it as much as possible and as early as possible. And this, in my opinion, is a global philosophical feature of value, thanks to which Agile is different from other approaches. No matter what we mean by value in Agile software development, we know that we must get this value as early as possible.
This usually means something like “getting cash to our bank account before.” But also “get more revenue earlier, even if it costs more” or “get more profit earlier, even if revenue is less”, or “eliminate more technical risks earlier, even if it defers revenue”. But whatever it is, whatever way we determine the value, most likely we want to get as much value as possible as soon as possible, instead of investing more to get more value later.
I think this is the biggest difference. It seems to me that in the value-oriented approach everyone should decide for himself what type of value is meant. But our common goal is to invest less and create more value sooner rather than invest more and create more value in the long run.

KM
Unlike the cascade model?

Jb
What makes a cascade model cascade? This is something that we are more willing to invest earlier and get a refund later. Because we think that this will increase the return over a long period: from three to five years, or from five to ten years.
In turn, Agile is flexible because our type of thinking is more focused on turnover of funds. I do not mean only the need for cash. But our thinking is more attuned to the turnover of funds: we want the flow of value to start earlier. Since we believe that getting value earlier, it will be easier to invest for a long time, instead of collecting all the money, investing it all and hoping that it will pay off in five years.
And these are two fundamentally different ways of investing. The same will happen when investing in software, real estate, securities and anything. Need to decide what is more important. Can I invest more money now and wait for them to return longer? Then I will choose an approach that looks more like a cascade model. Or do I need to invest less now to create more value right away so that I have more money for long-term investments? This is a phased approach, or a flexible (Agile) approach.
And value-oriented product development involves the use of a mindset that is tuned to a turnover of funds, instead of a mindset that is tuned to long-term investment.

KM
It is very interesting.
Is it appropriate now to create a product concept in one step at an early stage, or if you say that most teams supply software in stages and iteratively, then creating a product concept should be a repetitive process?

Jb
Of course! It seems to me that the same question arises in many aspects of Agile software development: in software design, product design, in the creation of a product and company concept. When we talk about stage-by-stage, iterative work, people sometimes get the impression that we advise them: “Do not think ahead”. They have the impression that we give them advice not to plan, but to create everything on the go. And I think this is a big mistake. Even when we choose a phased and iterative approach, for example, to create a product concept, we still need a point of reference - we still have to come to an agreement as a group. It seems to us that right now, based on the knowledge at the current time, the concept of the product should be as follows. We should be able to say at the start: “We have this product concept. And this is our first guess about the direction we want to go, based probably on our understanding of where the market wants us to go. ”
In fact, even though I say this, it may be wrong.
Sometimes we make decisions about the concept of a product based on market information, and sometimes we make decisions based on the idea of ​​one person about how to change the world. This may be an approach a la Steve Jobs or an approach based on market research. I don't care which one. I think we have seen wonderful examples of both. It’s important for me that we don’t choose a product concept and pretend that we can never change it. Of course, you should not change the concept of the product every 10 days. It takes a moment from which to begin; we must make a decision in advance. "In general, we are going to move in this direction, provided that we are ready to change our concept, if we learn something important and new that will change our approach." I think that we will make a lot of mistakes, if we learn about something, everyone will agree with the need to change the concept, but we will not change it. I think this is one of the main differences between the long-term investment approach and the cash flow approach. With the long-term investment approach, we do not want to change our concepts, our big ideas, even if everyone agrees that they need to be changed. While in the case of the money turnover approach, if we find out, for example, that our market is not at all what we expected, or that one of our competitors is doing something to make it four months ahead of us on the market, if we find out about this, then a mindset that is tuned in to the turnover of funds will make it easier to make a decision: “Yes, we will change our concept.” Even in spite of the fact that changing the concept is expensive, scary and changing the concept disrupts order. The mindset type of thinking about the turnover of funds says: “We have not invested all our money. We can still invest some part. Yes, changing the concept will be a bit costly. But we did not invest too much at once, so we can do it. ”
I think this is a big difference.
Yes, we need a product concept, and it can be complicated if a lot of people are involved in its creation. It is important that we do not pretend that this decision can never be changed. We must remain open to changing this decision if we agree that something important has changed.

KM
Yes Yes. And speaking of creating a product concept. I tend to look at software teams, whatever it is now, through the prism of three roles that Scrum defines: the product owner, the Scrum master and the team. Who do you think should be involved in creating the concept? Should this be a product owner — a person representing business needs? Or should the other members of the Scrum team also participate?

Jb
I do not know if I have a general rule for this. I would say that when we consider the concept of a product or, to make it clearer, when we talk about the concept of a product, we are talking mainly about the market component, and not about the technical ... Although I say this, I think it is wrong. Even though we are talking about very high level ideas, it’s obvious that we need marketing. We need to know what our market is. We need to understand why people will pay us money for it. Will they buy this product now or will they buy something else from us later? And will this product allow us to build trust in the market? and so on. But we still need to get some technical information, because we do not want to make the classic mistake of developing a concept that has no chance, which is technically impracticable, right?

KM
Right.

Jb
We should at least know that the product is possible to create. You need to know that we will not spend 50 million euros on a product that will bring 5 million euros. Thus, rather than thinking about who should be involved, what roles, it is more important to understand that we have a tendency (most people have a tendency) to underestimate the contribution of technical information to the concept.
I think everyone understands that information is needed on marketing, on sales, and perhaps on management, because you need to imagine whether it will take five years to create, or one year, or we can do something in three months. But you still need technical information, you need senior technical staff, whose job is to say: “Wait, guys, we don’t know how to do it at all”, or “Wait, guys, the technology to do this is not invented yet "Or" Wait a minute, guys, we do not know how to do it quite well. We need to hire new people or invest a year in research and development to see if this is possible. ” We risk missing these questions if we do not involve technical staff in creating the concept.
What should be the ratio of marketing personnel and technical: 20/80 or 80/20 - I do not know. I think it depends a lot on the type of project. Is this project a la Steve Jobs when we create a completely new product that has not existed before? Or do we create the next generation of services we sell? Or create the next generation of our product that we have already offered? Then this ratio will be different. If this is an evolutionary change, then we are probably already well aware of the technical issues, and focus on how it will affect the market and whether people will want to pay us so much more for this little evolutionary change.
If we are trying to create a new iPad, or a new phone, or some new thing, without which no one can survive, then, perhaps, we need someone who will say: "This is technically completely impossible, for this we need a significant technological breakthrough." , - before we even think about which market is potentially ready to buy it.
I do not know what it will be. But I think that if we create, for example, the house of the future, then we will need much more technical participation at the concept stage than marketing participation, since we are creating technologies that do not yet exist.

KM
Sounds like a feedback force - feedback must occur in the early stages and be constant.

Jb
Yes, therefore I think that it is not necessary to decide in advance who should be in the room, if we can pay attention to what we are doing, what we are talking about and what we have already decided, and we will constantly ask ourselves the question: “What can we miss out of sight? ".
Whenever I do this kind of work, it always seems to me that we are missing something. I am always looking for what may be missing. "It seems like a great product, but we didn’t check if anyone would like to buy one." Or this: “It sounds like a great concept, but we didn’t check if we could create it.” Or: “The product seems attractive, but we don’t know if someone can already create it at this moment.” I think one of the most useful skills is the ability to be open to the question: “What can we miss?”. “Do you know what could happen so that all the wonderful conversations in this room would become completely meaningless?” This is one of the standard tricks of business strategy.
For example, “What could we create to completely eliminate ourselves from the business?”. And maybe we should create it? Therefore, let us always have the skill to think: “What can we miss?”, “What we are doing seems too simple - what have we missed?”. These questions can be asked by people from marketing, sales, technical staff, anyone.

KM
Does this mean that your role, when you are invited to the company to help create a new product or change an existing one on the market, comes down to the formulation of good questions?

Jb
Exactly.
, , , – : « , ».
. … , . . , , – .
, , . . , , . . , . , . .
, «- » , , , , , , « , ?».

KM
Yes.

JB
, , , , , , . : « , … ..», « , ?», « , ?». : « ». , , . , ; , .

KM
, . . , , , , , .

JB
Yes. . , , . , . , , . , : « , ?». : « ». . - , , , , . .
, , . , : « , », – . , . , , . , , . .
– . , . « ; , , ». – . : « , ? , ? ?». , . : « , , … : , . , , , ? -?».
, - , , , . , . . , , , .

KM
, .

JB
- . , , : « ? - , , ? 27 , -, 60 20 ?». , , , , , .

KM
, 80/20, . : , , - , , , ?

JB
, , - – , , Agile- – , , .
, , , . . . , , .
, . , , , . , « ?», . , , , 180 , , 97- – , 107-. , - – . , . , , , , , , . , Scrum, , . , 10 20 , , , , , . , , , , , .
, , , , 80 .
, . . — 80 . . It does not matter. , . , - , .
. , – . , , , . , , , .
, , , . , , , , .
, , – , . , , , . , , , , . , – . . . : «, , ; , ? , , . ? , ».
, , .
, , , , , Scrum.

KM
, , , ?

JB
, :)

KM
Clear.
- , , . .
, – ? – , , , ?

JB
, , — .


KM
.

JB
, . , – , – . , , – , — . .
, , - . , – , – -, , . . 8 , 10 , 12 . , , . , . – , -. , , «» , , . , , . , . , - , « ». , , . , , , , .
– , , , «» . , , , , , , , , : « , . ?». , , , , , , . , . , - « ». . , , , . , , , , , .
, , . : «, , , ». , . « ? ? ? ? ?». , , , , , ; . , .

KM
, .
, , , ? - ?

JB
, , , . , , , , . , , . : «, , . - . , , ». , , , . , . , . : « , , , , ». , , . , , , , , , , . , - . , , . .
, «», - . , . , . - .
. 65 . .
, , , . : - . - . — . , . : , , , — , . , .
. , , , – . , – . : « , , , ». , . , , .
, . . , , , - , , « , », , . , , , . , , , , - . – , , - – , . , . , - . , , . . , - , , – , , . , . , , – , . , . , , – .
, , . , , – . , « » , , . . , , , .
— , . , .

KM
Clear. , , « », « » « ». , ?

JB
Exactly. - JB. ( , , ) , . , . , . , , , . , , – . . , . – . , -. .
, , . « », « » .. – - .
« », : «». . , , , . , , .

KM
, , . , . , ?

JB
Yes and no. « ». , , , , , , , , - . , , « ». , , , , , .
. , - . . , , . « » – , . , « ». . : « X». : «, X, ?». « » : «». «! X! ?». : « , Y». : «». « ». «! Y, ?». « ».
, . « », . . — , . : , — - .

KM
Great.
, ?

JB
. , . , - – , . , . : , , .
« », , , , , – .
This is actually the case. : , , . . , . , . , , , , X. , . , , . . , , , , .

KM
.
Thank you very much for your time. It was very interesting to learn a little about product creation and the value-oriented approach. I look forward to the opportunity to participate in the training.

JB
Well, thank you very much for the questions and for listening to my wordy answers. I look forward to our meeting and working together in March. I think it will be fun.

Joe Rinesberger’s online training will be held on March 18 and 19 in English. Read more here .