Last week I took a CSPO training with Michel Goldenberg. It wasn't a by-the-book course but a customization for Globo.com. Before this I had a rather romantic view of the Product Owner role and even tough that has flown out of the window, I still think that this is the most exciting role in the Scrum framework.
I always knew that the Product Owner was responsible for maximizing the return of investment (ROI). Since I never got to experience playing this role, it all seemed a little hazy, I couldn't really grasp it.
First, what is ROI? ROI is how much business value you can deliver given a teams velocity. Oh, okay. How about velocity? In an over simplified way it is how many story points/complexity a team can deliver in an iteration. I won't get into how it changes or what complexity really is. If you get your business value and divide it by the complexity you'll have the return of investment.
So how can you maximize the ROI? All you have is two numbers: business value and complexity. You can't randomly change your business value, that will probably get you building the wrong product. You don't get a say in the complexity either, that's given by the team. The team estimates the complexity to build a piece of product based on their technical skills and business knowledge.
Given that you have the right team to build your product, that they have the required technical skills and knowledge to solve problems, we are left with the business knowledge. How does a team get to know more about the business and the product? They can learn once they start working on it and also with the amount of information the PO gives them. Here is the hidden gem of succeeding. Give your team enough information so they can perceive the problem as something less complex. If they do that they'll be able to build a part of it. They will learn some and you will bring more information. The complexity gets reduced and they are ready to build for more pieces of product. This process is as iterative as all the rest.
I'll give you a real life ROI maximization experience that has nothing to do with software or business for that matter. Do you know the Weight Watchers points program? It's very simple. Based on your height and age you get a certain amount of points to eat per day. They have a list with all the food and the points per portion. You can eat anything you want within your daily "velocity". Now, you don't wanna be hungry, right? So what you do is prioritize the food that coasts less and won't leave you starving. When you do that you're maximizing your menu, your ROI. Simple, huh? Weight Watchers has an uber-agile process when you come to think of it.
The Product Owner is responsible to help the team understand the problem so they can tackle the complexity. The Product Owner has to be able to communicate very well with the team, be there for them. The Product Owner has be able to get more information from the stakeholders. The Product Owner has to keep his backlog alive otherwise he may not know that the product building is actually done.
Today I'm flying to Motevideo, Uruguay. I'm Brazilian so I speak Portuguese. I also speak English. But Spanish? Not so much. Which is making me a little nervous.
So I found my sit and buckled up my seat belt. I noticed an add stamped on the back of my dining table. It's in Spanish. Then the stewardess comes giving out immigration forms. It's in Spanish. She asks me, in Spanish, what's my final destination.
I choke for a second. Most people assume that Brazilians speak Spanish too because of the similarities but it doesn't really work like that. My brains finally responds "Montevideo" in the thickest Carioca accent.
Even though they sound alike, Portuguese and Spanish differ a lot when it comes to the musicality of the pronunciation. "Montevideo" is the same word in both languages but we couldn't pronounce it more differently.
And this gets me thinking. Isn't that a bit like what happens when your learning a new programming language? I started to compare the aspects of learning a new language and a new programming language.
Special characters
I attended my first year of high school in a Jewish school. It required all students to take basic Hebrew. I loved the experience but it was unbelievably hard. Not only I was learning a new language, with new words, and new rhythm and new phonetics but I had to learn a whole new set of characters to able to write.
For me this is like learning a new programming language syntax. It's the most basic stuff you need before you can start writing code. It's not the hardest step because is more mechanical but it is there and it does add some complexity.
Vocabulary
To express ourselves we need to know the words, the vocabulary. Otherwise we don't get anywhere. The richer our vocabulary is the richer are the experiences we have.
I know that my experience in Montevideo won't be as rich as my experiences when traveling to US for instance.
In a programming language the vocabulary are the reserved words, the native types and objects and their methods. When learning we usually start with baby steps. Loops and conditional statements and collections APIs.
Grammar
Grammar connects the syntax and the vocabulary. With a good vocabulary you'll probably read code with no problem but when it comes to writing it... it won't be so easy and you will make mistakes.
I think we can consider, memory allocation, metaprogramming and how parameters are passed on to methods as part of the language's grammar.
Accent
In programming languages the accent is the language's way of doing stuff. Pythonic, Java way, Ruby way. If you don't have the right accent people are going to understand you and you'll still be able solve problems but it makes very hard for the community to accept you.
Don't get me wrong, I'm not saying that accents are less important than vocabulary. Depending on you pronunciation it may be really hard for a fellow programmer to understand what you mean.
I'm not a programmer of a specific language. I speak Java and a bit of Ruby and some more of Python and yes I have been discriminated against for my accent. At the time I was kind of pissed off because someone said my code was "wrong". With this metaphor in mind, I understand what they were trying to tell me.
Embracing the accent of a language depends on how much you want to be a part of it's world.
And remember that there are regionalisms too. They can vary from company to company, from team to team and so on.
Getting proficient
To become proficient we need to enhance our vocabulary and be sharp in our grammar. There are situations where a vast vocabulary and an elaborated structure is needed to solve the business problem. To code right. I have seen bugs that were lack of vocabulary, lack of grammar knowledge, lack of understudying of the language. Same thing happens with languages.
We can try to build these skills with training but that takes a lot of time. Just like the express English course which takes us about 4 years to complete. Or we can do an immersion, work with the technology, along people who are proficient already. Read about it. Lots and lots. And not be ashamed to ask.
Conclusion
Those who know me personally know that reflecting on metaphors like these is one of my favorite pastimes. I just really love to mix stuff that are apparently unrelated and re evaluate my own concept, vision and values.
For sometime I used to say that a programming language was just syntax. Now I see I couldn't be more wrong. Thank God I don't speak much Spanish!