Scrum software development is by nature a team effort, with cross-functional groups working in “sprints” to incrementally tailor the software to a customer’s needs.

But the product owner has perhaps the most important and challenging role in a scrum project. Responsible for the project’s overall success, the product owner sits at the center of the constant collaboration, problem-solving and rejuggled priorities that make scrum (when done right) faster than traditional waterfall software development methods.

The product owner must collaborate closely with the team on an ongoing basis, guide it in the right direction, and make critical decisions. He or she is the voice of the customer, and is responsible for the product backlog (the “to-do” list of “user stories” or requirements) that must be satisfied before the software is ready for use. His or her role includes clearly describing the product backlog items, setting and changing their priorities as the project evolves, and ensuring the back log items are clear and understood by all scrum members.

In my experience, the cardinal qualities a good product owner must have are:

• Excellent communication skills to pass information among customers and the scrum team.
• A thorough and in-depth understanding of the customer’s requirement and vision of the product.
• The ability to proactively manage stakeholders such as those who pay for, and will use the application.
• The power to make critical decisions such as reprioritizing work items and
• Enough understanding of the software development cycle to guide their decisions.

Whenever our team struggled on velocity (the pace at which we delivered desired features) it was because product owners either lacked the power to make the decisions at the right time or lacked the true vision of what the customer needed from the application to make the right choice.

For instance, in one project that involved enhancing an existing portal, we were led by a product owner who was relatively new to the role and had only basic Scrum training. During sprint planning poker sessions, we added a complicated user story that required adding 15 fields to an existing page and complicated logic to auto-populate some of the fields.  The acceptance criteria for this user story were too basic and did not include an adequate analysis of all the relevant factors (such as which user roles could access or edit these fields, the different data that users might add and all exception scenarios such as error messages). Here, the product owner did not make sure he understood the story and its purpose.

In the early stages of the sprint, these gaps didn’t seem to be a problem, as the development team was new to the portal and very few of these details were discussed during the daily sprint planning meeting. But as the sprint progressed, the developer responsible for that story started raising questions in the daily scrum meetings, which the product owner didn’t attend due to other commitments. My scrum master had to email the product owner an email asking him to join the daily scrum and address the queries, but even then it seemed like he was not sure about the exact criteria and always asked for some time to discuss with the business users.

The product owner had to meet with users and the developer to figure out the missing details, all because he had accepted the story from the users without pushing to understand its purpose and business value. As a result, the developer was unable to deliver anything for the two weeks of work he spent on this story in one sprint, and had to continue work on it in the next and final sprint.

Not only must a product owner be vital and decisive, they must devote enough time for the team. While some people think that the product owner need not be present in daily scrum meetings, I think it really depends on the project environment and criticality of the requirements. In every project, there will be some impediments or queries which can only be cleared by the product owner. At the very least, he or she should be present in all planning, review and retrospective meetings, where the team reviews their work on the last sprint and applies lessons to the next.

As the proverb says, “a good beginning makes a good ending.” Choose a product owner who has the power and knowledge to make tough decisions and get the information the team needs, and you’ll deliver more business value more quickly.

Harshal Sanjay Deole is a software developer with seven years experience in outsourced software development using both waterfall and agile scrum methodology.

By Robert L. Scheier

Q: Are you seeing any slowdown in business as a result of the global downturn?

SV: The strength of the local economies is easing the impact of the slowdown and global uncertainty. For example, the downturn has had very little impact on Brazil, which has an unemployment rate of less than five percent. So Latin America is still a big market. And in the event of a downturn, budget cuts at large North American companies would increase the demand for services from less expensive Nearshore providers.

Q: In what areas does Latin America excel as an outsourcing destination?

SV: Two major advantages are the multiple language skills and the time zone proximity. The wide availability of bilingual English and Spanish-speakers makes Latin America a very cost-effective way to provide BPO services for Spanish-speaking customers in North America.

We have found the time zone proximity – being within an hour or two of the customer’s clock versus 12 hours – really helps our customers achieve the cost and time savings they want from agile development methodologies. This is just as true for more general business process outsourcing. Working in the same, or a very close, time zone tends to increase productivity because customers or co-workers can get faster, more immediate answers to their calls or emails.

The U.S. and Latin America also both have less formal cultures than in India, and this makes everyday communication easier. For example, is a person from India is speaking with someone from the U.S., and there is a dog barking in the background, they might be taken aback and asked what happened. Someone from the U.S. or Latin America will ask the other person on the call if they need to take a minute from the call to take care of the dog. This level of flexibility and understanding can ease professional interactions.

Finally, many business processes such as those for home loans, credit cards and even customer loyalty programs are much more familiar to Latin Americans than to Indians. This reduces the time, effort and cost required to bring staff up to speed on outsourced business processes.

Q: Is the Nearshore a good place to outsource mobile application development?

SV: Brazil has gotten more use of this technology than other Latin American countries, and is thus in a good position to lead in the development of mobile applications. For example, consumers there often use mobile apps to pay taxi bills and charging the fee to their mobile account.

Q: Does TCS focus its delivery centers in Uruguay, Chile, Mexico, Brazil and Colombia on different types of work?

SV: No. We have sufficient capability to deliver any project on a “location agnostic” basis, combining our knowledge of the local market with the global best practices we have developed for other customers.

Given that, however, we are focusing Brazil more on the domestic market rather than doing any Nearshore work because Brazil is a huge market. What’s more, current labor costs mean there’s no cost advantage for doing work for North America from Brazil. But cost is most important when deciding where to perform commodity services. For example, we have one North American customer who is choosing to have work done in Brazil not for cost reasons, but because TCS has staff there with extensive knowledge of capital markets. Even though it is more expensive than some other regions, for that type of engagement, you do have to have that sort of talent available.

Q: What other trends are you seeing?

SV: Cloud computing of course is one big area that can provide a lot of value to our customers. We’re involved in every aspect of this, using our deep understanding of customers’ application portfolios to help them decide which parts of their infrastructure to migrate to which type of cloud platform. Sometimes we help the customer define their strategy, sometimes we help them make the actual move to the cloud, and sometimes we do both.

We’re also seeing a general trend for customers to diversify the locations of their service providers. They are doing this both to utilize as broad a pool of talent as possible, and to mitigate the impact of natural or man-made disruptions on their business.

Last year one of our clients got the bad news that an important application under development for her company would not be completed by the deadline. But it was not a complete surprise to either her or us because her end users had made so many changes as they saw the new application take shape, and the development team in Argentina had kept her informed about the impact of these changes on the schedule.

At our recommendation, the client  switched to an Agile process that uses short software development sprints to deliver the highest priority features every two or three weeks. A fixed-cost for developing the final application went out the window but this client realized how impossible it was to define what “final” really means. She became comfortable using an agile method because:

• She trusted our partner in Argentina because they haddemonstrated high Agile velocity during the initial development. Velocity is the number of features (often described as story points) added to the software in each sprint. They were able to add over 20 story points to the software in each sprint and that built  trust with the client because she could predict what the development team would  do going forward.At one point a less-productive team member was replaced with a more experienced programmer. Since this was a dedicated agile team working for the client, she was part of the decision. That’s insight and power a client does not usually have in a fixed-price project.

• Costs were not excessive. Our client could budget for a reasonable number of sprints that ultimately would give her the functionality needed by her end users. You might ask, “How much budget is enough?” Let’s look at some numbers. Typical cost for highly skilled, intermediate to senior software development talent nearshore is about $5K USD per programmer per month. If you need a four-person team to make good progress then your burn rate will be $20K per month. If the team creates your application in five months the total cost is $100K.

• If spending $15K to $25K (or more) per month on a brand new software application is possible for your company then an agile approach will work. For this client, there was much greater value delivered by the completed application than the amount required to create it. They did not fool themselves by thinking that paying a lower fixed-price for an incomplete application was better than creating the full-valued application they really needed.

• Our client had close collaboration with the Nearshore team and stayed involved, usually on a daily basis, to monitor and contribute to progress.  It also helped that the partner works hard on their communication skills and have significant U.S. workday overlap from Argentina. Good communication means asking questions, “pushing back” on the need for features that seem odd or inconsistent with the rest of the application and making pro-active technical recommendations. For example, our partner recommended the use of the ASP.NET MVC framework, a technical approach the client had not considered. That was a good technology recommendation that led to faster implementation.

Getting started with agile can require what feels like a leap of faith, especially when outsourcing. But is agile more risky than fixed-bid projects?

No. In fact, fixed-bid outsourced software development is more risky because you will waste both time and money if the outsourced team is not good. You almost always have to make a down payment for a fixed-price project and you’ll kiss it goodbye after wasting time with an ineffective outsourced team.

Changes in software development are inevitable because you cannot anticipate all requirements of your users. Will you ignore them because it was not in your original plan? Bad idea. Instead, embrace change as you plan each new software development sprint using an agile methodology – but only with a good outsourcing vendor you trust.

Steve Mezak is CEO of Accelerance, which helps companies find offshore outsourced software developers, and is author of  Software without Borders. Watch the webinar Over the Waterfall and into the Rapids – A Better Way to Manage the Risks of Outsourced Software Development, on the Accelerance website and hear the full story of this client’s transition to Agile software development.