The only way to reduce the risk of these misapprehensions taking hold is by building a foundation of trust between the Product Owner and the team.
This begins with a human relationship between the two. One of the most critical steps for the success of a distributed Scrum project is for the Product Owner and team to come together in person at the beginning and spend quality time sharing key project information and building a relationship with each other.
This is particularly important at the beginning of a major project; in addition to starting the relationship, there is also a large amount of information that needs to be communicated. First, the Product Owner needs to provide the team with a clear and comprehensive understanding of the overall vision, purpose and goals of the project; this context give the team a strong foundation for their day-to-day work, and also helps build their motivation and drive. Next, the Product Owner and team will have an opportunity to go through the items on the Release Backlog (the subset of the Product Backlog targeted for the nearest release), and discuss in detail the features and functionality required. This gives the team a vastly deeper and more nuanced understanding of the project requirements than they could ever derive from a written specification along. This conversation will also provide more "subtle" information and understanding; for example, about the values, attitudes, and mindset of the Product Owner and team members.
The major objection to this is the cost of the trip in time and money. But let us take a moment to analyze this objection further.
Let's consider the example of a Product Owner in San Francisco flying to visit her team in Sofia, Bulgaria:
| Flight, US to Bulgaria | US$3,000 |
| Comfortable hotel accommodations and meals for 4 days | US$1,500 |
| Ground transportation, visas, other incidentals | US$500 |
| Total cost of trip | US$5,000 |
This hypothetical Product Owner is kicking off a 1-year project:
| Cost of project | US$500,000 |
The cost of the trip is just 1% of the total project cost. Will an in-person project kickoff, knowledge transfer, and relationship-build improve the results of the project by more than 1%? Guaranteed. In fact, anecdotally, the overall project ROI improvement this produces is probably more on the order of 30-50% or more.
Still not convinced? Let us go further with our analysis. The cost of the project is US$500K, but that is not the value of the project. What is the business value this project is going to be producing? What is the cost to the business if this project fails? Likely an order of magnitude greater than what it will cost to complete. Let us assume this hypothetical project, if successful, will enable $4 million in new revenue and $1 million in cost savings; its total potential value is $5 million. Compare that to the cost of the Product Owner making the journey to India for the project kickoff:
| Value of project | US$5,000,000 | 100% |
| Travel cost for project kickoff in person | US$5,000 | 0.1% |
The bottom line is that there is just no excuse for the Product Owner not to join the team in person for the project kickoff. If the project matters, that is – and it is worth noting, the willingness of the Product Owner to come in person for the kickoff sends a very clear message to the team that "this project matters".
To be really useful, this project kickoff must include more than just workplace interaction; the Product Owner and team should plan informal outings away from the office, to give them the opportunity to interact not just as co-workers but as people. The ideal itinerary for "human meshing" could include group outings to tourist sites, a bowling outing, dinners together, possibly even a visit to one of the team members' homes. (It is important to note that these excursions are for the Product Owner and the team to bond – not for senior management to dazzle their client.) The bonding experience can be particularly important when the Product Owner and team are from very different cultures. Sometimes, accentuating some of the cultural differences can have benefits. For example, a team in Bangalore took their Product Owner Phil, who was visiting from the US, to a local temple for a Puja (religious ceremony) to bless the success of the project; it turned out to be both a very memorable experience for Phil, and also a strong bonding event for the entire group. Management needs to understand that while this looks like "non-work time," it is actually a critically important investment in the vitality and success of the project.
In addition to the human bonding, the in-person visit by the Product Owner can achieve other goals as well. First, it lay the groundwork for bridging some of the cultural differences between the two locations. For example, in the business culture of many Asian countries, there is a taboo against sharing bad news bluntly, or appearing over-emotional. In other countries – the US, for example – frankness is more the convention. For example, when a team in Delhi says to their Product Owner, "we have a bit of a concern about X," what they may really be expressing is "we see a very serious issue with X that needs immediate attention"; unfortunately, what their Product Owner in Silicon Valley hears is "this is a minor worry, let's not waste time on it". Similarly, when the Product Owner in Silicon Valley says "The situation with Y is a complete disaster!" what he may be trying to convey is "There's a problem here, let's really focus hard on solving it," but unfortunately the team in Delhi interprets the statement to mean "Go pack up your desks, you're all out of a job!". None of these people are intentionally misleading – rather, they're expressing their thoughts using the norms of their particular locale.
One final benefit of the Product Owner traveling to the team's location is for him or her to experience first-hand some of the challenges the team experiences working in their location. A Product Owner from the US who is used to a 30-minute commute to the office, uninterrupted power, continuous air-conditioning in the summer, and fast, reliable broadband likely assumes his counterparts on the other side of the world experience the same. After an in-person visit, though, he might realize that his team faces a 2-hour commute in each direction, power and broadband connectivity that comes and goes, government-mandated bureaucracy for purchasing hardware, and a host of other daily challenges.
Apart from this initial visit by the Product Owner, it is also important that the entire group co-locates again every 3-4 months, or after logical milestones have been achieved. If the Product Owner has traveled to the team's location for the project kick-off, then it may be helpful for the team to travel to the Product Owner's location after the first release, and spend an entire Sprint (or at least a week) together. This time together is used to re-emphasize the "big picture" vision and goals, kick off the forthcoming release, discuss any major issues or upcoming decisions with their colleagues, and generally re-sync the two locations with each other. It will also be very helpful if the development team members from the offshore location get to interact with business stakeholders and end-users of the software they are building; this provides them with a better understand the real context of their work, and goes a long way towards reinforcing a common goal and "one-team" mindset.
In addition, team-members who join the project at a later stage should also travel to the onshore location at the first opportunity; it is enormously helpful for them to hear the context, business-drivers and vision of the project from the Product Owner and other important stakeholders directly.
The second part of building a relationship of trust is developing openness and honesty between the players. Teams are often fearful about being open with the Product Owner, especially if that person is the customer; the team worries that if they raise a difficulty or concern, the customer will be upset or disappointed, and may even complain to management. As a result, many teams invest a significant amount of effort in trying to create the appearance that everything is going well. Indeed, the less well things are going, the more effort has to be invested in maintaining this appearance – effort which, ironically, would be much better spent trying to solve the problem. Teams are often afraid to even ask questions, concerned that their uncertainty will be perceived as incompetence – and as a result, questions go unasked and the team makes assumptions, produces the wrong thing, and ultimately creates the very perception they were trying all along to avoid!
So how does one avoid this syndrome? The Product Owner must communicate to the team in no uncertain terms that he or she wants to hear good news as well as bad, that nobody will be punished for honesty, and that the only "dumb" question is the question that goes unasked. Then after "talking the talk," the Product Owner must "walk the walk" – he or she needs to constantly press the team to ask questions and raise concerns, and when the team does bring up problems (which will happen tentatively at first), respond in as positive and solutions-oriented a way as possible.
|
Tom was becoming increasingly concerned about his team in Shanghai. The project they were kicking off was going to be extremely challenging technically, and they would be working in a new domain and using tools that were new to them. But what concerned Tom the most was the fact that the team was expressing no worry or doubt about this at all. On every call they seemed to have the stance of "we don't see any problem at all; we're fully confident that we will be able to master these new areas, and we don't have anything to worry about." Tom felt this attitude was unrealistic, almost to the point of being irresponsible; if the team truly had no worries, then they were living in a fantasy land! In reality, of course, the team was very concerned. But the last thing they were going to do was communicate this to their customer. If Tom found out that they were concerned, who knows what he might do! Complain to management? Try to cancel the contract? They certainly did not want to find out. Tom tried giving subtle hints and suggestions, but in the end, he decided to really share what he was thinking during a call with the team. "Guys, there's something I'm really concerned about, that I really need to talk to you about." Hearing these words, the team stiffened. "On every call with you guys, all I hear is "things will be fine". But let me tell you, this is a big project with a lot of risk. I'm losing sleep over it, and we're not even a month in. And what worries me most is that I'm not hearing any of the same concern from you guys. That's making me wonder if maybe I'm the only one who sees how hard this is going to be. Do you guys get it? Are you guys at all concerned about this?" There was silence. Then Lee Wei, the most experienced of the developers, responded. He sounded a little tentative. "Of course Tom, we have some concerns…" Tom felt a little relieved that the team was acknowledging what he was saying. "Okay, so tell me about your concerns." There was more silence, and then Lee Wei continued. There was a major issue the team had been worrying about for some weeks now. "One concern we have is that the database may not give the performance we need under heavy loads." This caught Tom off-guard. At no point in the discussions so far had there been any mention of performance worries. Tom's first instinct was to respond with "Why the heck didn't you bring this up sooner!," but he caught himself. He took a deep breath. "Okay. Guys, I have to admit, I'm pretty surprised to hear this. I didn't realize that there was a concern here, and this is something potentially very serious." There was silence, and the the team braced themselves for what came next. "But I have to say, I am really happy you guys shared this with me. Now that I know about it, we can do something about it. Great performance is make-or-break for this project, so we need to get to grips with this issue. So what could we do to answer the question now? Let's create an item to go at the top of the Product Backlog..." |
To establish a foundation of trust at the beginning of a long-distance working relationship, it can be very helpful to have an open and direct conversation about what everyone is committing to, and what each expects the other to do. This could simply take the form of a conversation, or it could come in the form of a "working agreement" between the team and the Product Owner.
Some examples of such commitments among real-world Scrum Teams are:
- We commit to be honest with each other. If we have a concern, a doubt, a worry, or if we see a problem, we commit to surface it to each other immediately.
- If we are unhappy about something that has happened, or something that the other has done, we commit to surface this immediately to each other.
- We commit not to escalate a problem to upper management without first trying to work it out with each other. If an escalation does become necessary, we commit to letting each other know in advance, so it doesn't catch anyone by surprise.
- We recognize that people make mistakes and have misunderstandings, and that the important thing is to find and fix the mistake or misunderstandings as quickly as we can. For this reason, we commit to each other that there will be no retribution for surfacing a problem or a concern, a mistake or misunderstanding, or for speaking honestly.
