Plan a visit with your offshore development team

First time I went to see my team in India (see reports from that trip here and here) I did not know what to expect. We were 4 Product Owners going and we prepared, had expectations, worked together and somehow it all went well. Next time I was more prepared and had this long list of what I wanted to achieve. The schedule was unrealistic and I achieved just some of my goals.

This time I made a list. I divided it into must do and nice to do. And I emailed it ahead. Knowing by now that

1. It wold change
2. Items would pop up
3. Items would disappear
4. They also had things they wanted from me/discuss with me
5. It would all come together at the end

In the beginning i was frustrated over that it seemed so hard to do a schedule

On Monday I arrive, on Tuesday we go over UI, on Wednesday we plan sprint x…

That never worked. That’s the Swedish way. And to be honest, we work in different way, I sometimes find it hard to understand the funny people on that little British island. And my neighbors the Danes, don’t get me started. So off course we are wired different in Sweden and India.

So now i make a list and email it. Pursue a couple of items each day, and feel confident that by the end off the week all must dos and most nice to dos are done. They seem to be done even without that detailed schedule I seem to want. Swedish and Indian way of working actually goes well together, we just need to be aware of how the other do stuff.

So accept that we do things different, learn how others do, and adapt. Its all about give and take and understanding. Without that you will fail.

Outsourcing to India, don’t believe the non-believers

I am sitting in the Chhatrapati Shivajiinternational airport in Mumbai, India while writing this an pondering the comments i read in a Swedish newspaper regarding the news that Indian companies had happy outsourcing customers. Most of the commentators did not agree, and some said that they did not know of a single happy case of outsourcing to India. So here is one just for them. 

I started using SCRUM 20 months ago, and I started with an Indian team. At that point it was just 4 people in it. They had never seen the platform we were building on, and to say that I was an expert on it would also have been a lie. We had never met, but hey, we started.

Now, 20 months later. I have had team sizes of almost 20 people. At the moment I have 2 teams of 8-9 people each. They have gained both platform and domain knowledge, and we cooperate. True, doing most of the meetings over Internet and only meeting in life once every 4 months is hard. But it can be done. My teams make the most of the time I am in Mumbai to ask questions, pitch ideas and make sure they understand what I want.

We have had one major release and are on our way with our second release. And its going well.

So what can we learn from this 20 months?

1. Always be prepared
2. Go there
3. Don’t even try to follow all the rules of how to do local scrum, doing it over Internet is a totally different thing.

Always be prepared

You need to have a clear vision, be able to communicate it and be able to explain how each story is striving to that goal. The team will tell you when a story needs splitting, but as most meetings is over Internet, don’t expect the workshop atmosphere you can gt when all is the same room.

Go There

You need to meet the team. I do it once every release to get the whole release talked through, all stories estimated and to get input in which order stuff is best being done from a technical standpoint. The team will help you, but you need to know what help you can expect. They are the technical wizards, and will help you with that. You are the domain experts and need to communicate the vision. Over time that will become more and more easy. and the team will come back to  you with more suggestions than in the beginning. But you need to sometimes just be in the same room, be available for instant chat. You cant do that all the time, but make sure you do it at least once per release

Don’t follow rules

And the distance is why we don even pretend to make each sprint a deliverable product. We group them to releases. Meet team once per release, and carry over stories from one sprint to another within the release. The backlog grooming with the team does not work. You are on one continent and the team on another.

But if you enter this cooperation with an open mind, are willing to bend rules and know that a meeting over Internet never will be the same as a face 2 face meeting, then I see no hinder for success.

Use Agile

Last, but not least, I think our success is part due to using Agile. I do not write a long requirement specification ad then go silent for 9 months and see what happens. I communicate with the team constantly. Using Skype (voice and text), emails and Internet meetings. Solving problems, discuss design, answer questions, reviewing test cases. As all that is an ongoing process I never end  up being surprised. One of the most boring meetings we have is the sprint review. I in my role as Product Owner have seen it all before the review. we have already decided what needs changing and what is Ok. The review ends up as the team showcase for our documentation team, other PO:s, product enablement and those groups.

So outsourcing product development can be done, and if you do it humbly and with an open mind you can do it successfully,. 

Sales dont know what’s best for them!

If I were in sales and a product manager said “how can I help you”I would be happy.

I would NOTignore it

But hey, that’s just me.

If I were in sales and the product manager asked me what I needed from the product manager I would start doing a list.

So why does that not happen? Could it be they are so used by us stopping them and us not delivering what they think is the must crucial feature? Have we come to a point where expectations are low and trust lower? If so we need to fix it.

• Lets make sure we always give reasons
• Lets make sure we never ignore a request
• Lets make sure we really understand their reality

  Let us start, and just maybe next time you say “how can I help you” to sales you get a meaningful answer.

Information is key to everything

If you are a successful product manager you already know that information is the key to everything. To have it, to use it and to spread it. But on the other hand you read my blog, so how successful can you be:-)

 

What I want to explore is how to handle the information in a world of agile where each sprint should reach a deliverable version and where we can change our minds between each sprint. Should we then make sure the team has all information they need for one sprint, or is there a better approach?

 

You should have not only a sprint goal. You probably have a backlog with epics. But do you have a long term goal? Hopefully yes, and you should use that. A team with information about the long term goal can make informed decisions and do design in sprint 1 that not only makes sense in sprint 1 but also in sprint 1, 2, 3, 4 and 10. A good team can use your long term goal to influence their short term planning. Turning out usable increments that also are future proof so you won’t have to spend a lot of time doing redesign later.

 

Make sure you are building your parts incrementally but also that each part you build is built in a way that is along the long term vision, with the necessary blocks considered from the start.

 

Doing agile is no excuse from doing a good design at the start. Even when we do agile we need to do a good design and make assumptions at the start. Yes we might later change, but the cost of these changes are likely to be lower than the constant redesign we will get into without a good design from the start.

 

One way of making sure you consider most mid and long term goals in initial design is to start by looking into reporting.

 

• What info is needed for reports?
• What are the purpose of the reports?
• Who will need reports?
• Is the a difference in requirements on reports first year and year 5?

 

Another thing to consider is if a subset of reporting is usable or not? Do we need all info or can we make a first report version that delivers part of what we need? Whatever the answer one thing is certain. The team need to know your vision and need to get this info so they can design it with intelligence.

 

So once again. Know your goal and make sure you communicate it to the team. Dont be an information hoarder.

 

 

 

Noble art of saying no

Noble art of saying no, thats where people see us, and why is that. Probably because its right. The mathematics are against a yes most of the time.

Disclaimer: I am on holiday and this post is more a look back at the life and my experiences, dont expect any valuable take aways.

As a product manager you have realised that you get demands from everyone. You probably started out trying to make everyone happy, but realised it just cant be done mainly of 2 reasons.

1. The requirements contradict each other
2. The resources are to few

And there we get to what I call “the noble art of saying no”

So as we admit no is a very useful word we could be better at using it, and we could be more creative. But as a friend once said “a firm no today can save a lot of trouble tomorrow”. While that is true we can say no without being seen as the eternal nay sayer.

Here are some examples:

• Yes, interesting idea. I will investigate it
• It currently not on the roadmap but will look into it later
• Not at the moment
• Can you elaborate on that and get back to me with more info
• We may have a workaround that might be interesting to look at
• Its definitely on the roadmap, just not planned into a specific release

These  can be categorised into the ones that is a no with more words, the ones that gets you more job and the ones that gets the person wanting something more job. Be careful about the last one. If you always do that and then later always say no anyway people will learn that. So use it with caution.

So what is the solution? I did not say I had one.But being active and ahead of the game is usually a good way of getting out of these situations. Good luck with that, if you find out how to do that all the time, let me know;-)

Why Swedes make better product managers

So its about swedish product management, but why is it better, or more importantly are Swedish persons better product managers?

Off course we are, what a questions, let me explain it to you.

 

Have a look at this map

Here we see a map of the world based on two factors.

1. Traditional – Secular rational values
2. Survival – Self expression

In order to be a good product manager you need to be rational above all else. No guessing about what the customer wants based on your own views and beliefs. Go out there,

• get to know the market
• get to know the customer
• get to know the competition

Then you make your decisions based on factual input, nothing else.

The second is the survival or self expression factor. You might think that the survival is the best, but actually no. The survival is for people who don’t think about the product but

• Think about being liked
• Think about the long term employment
• Think about tomorrow for its own sake and security

The good product manager is  in reality so convinced that he (or she) is right that they tell everyone what is right, and don’t think about the self preservation survival. If they don’t get it the product manager finds new company that gets it. He (or as it may be, she) is the one person who truly knows it all and tells that to everyone. (the manner in how they tell it is important but that is for another blog post)

So the perfect product manager is

• Rational
• Good at expressing its own opinion

And what do we find in the upper right corner of the map?

quod erat demonstrandu:-) 

Mumbai once again, visit the team add local presence

As you know I have a bunch of clever developers and QA in Mumbai. For the fourth time in a year I just was to visit them. It is sometimes so good to just be able to talk directly, chat, whiteboard with the ones you work daily.

Happy Product Owner

This time I was there to plan next release and the sprints leading up to it.  I had prepared the stories, thought of “everything” and just needed estimations and planning. Or so I thought.

When I sat down with the team, starting by presenting my short and long term vision (to get everyone aboard so to say) and then discussing individual forms, features and stories the number of stories grew. The complexity grew and new ideas entered the discussions. When sitting down with our designer some new ideas, better ones, emerged.

Can you set a price on that?

Once again I will stress that whatever you do. Skype, phone and live meetings is never enough. There is no substitute to actually sit down and discuss, see facial expressions and get responses. My 4 days with the team now means we have a common understanding for the next version. Any small issues can then be solved remotely as we have solved all big ones when at the same place. As we all share the vision we can together and independently work to reach our goal. As a product owner its worth gold to have a team that does not only follow a spec. They also understand where we are going and why we do certain things. (thats actually a key requirement in good SCRUM, but one that is probably not always implemented).

We also have identified a number of dependencies that I had not thought about. Made some clarifications in the stories and changed any inconsistencies found. All through face to face discussion.

So from face 2 face you will get

• Better understanding all around
• More interactivity with team
• A more knowledgeable team
• A more committed team (if you understand and share vision you will commit)

Happy Scrumming out there