At Scio, we use Innovation Games with our clients in several contexts, from new product definition to ongoing product management. For a new product design, the games help us work with our client team to uncover customer requirements that are still loosely defined, as well as to help our development team understand the key selling points of a product. For ongoing product management, the games help us work with client product managers to come up with new ideas, develop and prioritize their product roadmap and identify issues hampering their success.

Innovation Games are a series of serious games developed by Enthiosys, an Agile Product Management consultancy based in the Silicon Valley. Enthiosys developed these games to drive innovation by facilitating communication between clients, users and the development team in a structured but fun approach. By using a “game” approach, the activities remove personal agendas and psychological barriers that frequently exist when trying to reach alignment between stakeholders. Luke Hohmann, CEO of Enthiosys, has written a book about the games and methods behind them – Innovation Games: Creating Breakthrough Products Through Collaborative Play.

We recently started a project with a new client from the UK to develop a SaaS application for them using SaaSGrid (SaaSGrid is a SaaS Application Server developed by Apprenda). As part of the project kick-off and Product Design phase, three members of the client team spent a week at our Development Center in Mexico including the their product owner, the project manager and a development manager.

The visit was part of Sprint 0 (product definition and design), which is the first phase of our Agile Development process. The visit had five key objectives:

• Finalize the high-level product requirements.
• Define the technical architecture.
• Define the UI approach and look & feel
• Finalize the project execution plan.
• Get the development team underway with the certainty that they had an accurate understanding of the project goals, the product key features and the overall vision and expectations of our client.

During this visit we used Innovation Games to reach some of the objectives we had in mind. We used four games:

1. Product Box – day 1, morning
2. Start your Day – day 1, afternoon
3. 20/20 Vision – day 3, afternoon
4. Remember the Future – day 4, morning

Our client provided their application requirements as part of their development partner selection process and those were used to estimate project scope and provide our price quote. It was understood at the beginning that the requirements were not 100% complete and some ideas about new requirements or the approach to implementing some elements had changed since the  document was written.

We began our games with Product Box. Our aim was to quickly surface the key features (and key selling points) of the product. After reviewing what came out of that game, we discussed in more detail the full set of application requirements, the company goals, and the overall project expectations.  We then followed with a session of Start Your Day. In preparation for this game, we had printed daily, weekly and yearly calendars on full poster-size paper. We played the game for all Personas, and with this activity we wanted to identify patterns of use for each persona.

On the third day, after we worked on defining user stories in greater detail and across all modules, we played 20/20 Vision. We printed all the features (each feature contained one or more user stories) on letter-size paper, and with masking tape, we started to place them on the wall. The client team went through an iterative process of placing features on the wall and moving them up and down, where the features at the top were deemed to provide more value to end users, and the ones at the bottom less value. This exercise helped us prioritize the product backlog. This prioritization, together with technical dependencies, is used to define the sequence of application development for the user stories.

On the final day of the visit, we worked with the client team in the Remember the Future game. The scenario we set for the game was: “The date is exactly three months after the launch of the product, what will the ideal situation look like?”. This brought up expectations about the number of paying customer they would have, the quality and performance of the application, etc. Then we asked, “what will each of our teams have done to make that happen?”. We worked backwards to bring out all the activities and milestones in marketing, development, testing, etc. that will be needed to get to that ideal situation.

Using Innovation Games was very productive for this project.

• Product Box it helped us see that some of the requirements that we thought were secondary were actually part of the key selling points of the product.
• In Start your Day we realized that some users will concentrate their usage of the system to specific hours of the day, where they will need to process data in batch modes. This suggested that we needed to design a UI optimized for sequential data capture for those users. Additionally, we discovered that we will have peaks in some batch processes, such as invoicing, at certain times during the month, as well as some reporting that needs to be generated once a year for tax return purposes.
• 20/20 Vision was useful to prioritize features using end-user value, rather than how cool a feature would be or how attached a member of the client team was to a piece of functionality.
• Remember the Future helped us see the dependencies between the work that each of us (Scio and Client) has to do to make the project successful, as well as establish a timeline that we will need to adhere to.

When as part of the agenda for the visit, we mentioned that we were going to use “Innovation Games,” our client was of course, curious about the idea. It is easy to imagine a “game” but not necessarily the business value behind it. We explained that the games are strong facilitation techniques that would be fun and productive, so they engaged with enthusiasm and played along happily. The results were great, and at the end of the week we all agreed that we accomplished a lot.

Although it is possible to obtain similar results using other facilitation approaches, using Innovation Games is a more engaging and fun approach to exposing all the different aspects of a product that surface during the games, which would otherwise be missed or discovered too late.

So let’s keep on playing – Serious games that is.

In this article, “Nearshore” refers to outsourcing software development to providers that are located in foreign countries in the same or adjacent time zones or that are geographically close to a client’s home country. For U.S. companies, this term describes outsourcing to providers located in Canada, Mexico and Central and South America. For companies in Western Europe, nearshore providers are logically located in Eastern Europe, the Middle East or North Africa. At Scio, we work primarily with customers in the U.S. using a combination of U.S.-based and nearshore resources from our Delivery Center in Morelia, Mexico.

The other day I was reading an article about the “Experience Economy.” In the language of economists, the Experience Economy is the next step in the sequence from an agrarian economy, to the industrial economy and the more recent service economy. A basic premise of the Experience Economy is that competitive differentiation between service providers will emerge from positive and memorable customer experiences. In this view, customers will begin to take for granted that top-notch quality of service and work products are widely available. They will begin to make purchase decisions and maintain loyalty based on the quality of their experience of working with a service provider.

After considering the subject, I realized that one of the main advantages of working with readily accessible teams is precisely that it helps provide a better customer experience.

I have found that in the context of software product development, given a choice, people invariably prefer to work with local team members (either internal employees or consultants). After all, the ability to interact face to face greatly enhances the richness of communications, which in turn helps productivity and improves quality. It is usually the promise of lower costs that persuade companies to go through the additional effort of working with a remote team.

Although working with a nearshore team is by no means the same as working with an on-site team, it does provide the possibility of much richer communications between all team members than is possible when the remote team is in opposing time zones. For most practical purposes, it resembles very much working with a team in a neighboring city or state.

A typical day for one of our outsourced product development clients starts with the Daily Scrum Meeting (we are an Agile development shop based on Scrum). Our nearshore team joins the client team in a web meeting and conference call where progress is communicated, plans are updated and action items are identified and assigned. The rest of the day goes by with direct communications (through email, instant messaging or phone calls) between individual members of the Scio team and their counterparts on the client team. When issues arise, the combined team is typically able to address them in real time and resolve them quickly. During planning and review sessions, the client and Scio teams can brainstorm and provide feedback to each other to improve the next Sprint (the name given to iterations in Scrum). So, while these interactions are not as rich as working at the same office, they do provide a level of team integration, rapport and ownership that is far superior to what is possible when the remote team gets all their communications through a designated offshore team representative.

The fact that the entire nearshore team is present during the daily Scrum calls means that there is no loss of fidelity in conveying client ideas and requests to the team; they were all there. Both team and individual team member concerns can be addressed directly. Likewise, the ability to communicate and interact in real time (instead of waiting overnight for a response) helps to foster relationships between the client team and the nearshore team, and thus reduces the time required to reach agreements, and overall helps both teams to get the desired results more quickly and satisfactorily.

With a closer geographical location, a closer cultural affinity also typically follows. For example, in Morelia, Mexico, within ten miles of our Delivery Center, there are local franchises of McDonalds, Burger King, Kentucky Fried Chicken, Domino’s Pizza, Subway, Sam’s Club, Applebees, Chili’s, OfficeDepot, OfficeMax, Costco, Walmart, Nextel, BlockBuster, and others. So, while we could discuss whether globalization takes away from the personality of a city, it is also true that in this particular case it helps create a shared context that enhances communications and mutual understanding.

Television is another example of a medium that creates a shared cultural experience. Cable and satellite TV in Mexico play basically the same shows as in their counterparts in the U.S.; even public broadcast TV channels in Mexico play shows like Desperate Housewives and Lost. (Yes, they are one season behind, but the point is that it is another factor that creates a shared context.)

This is not to say that the national cultures involved are exactly the same. There are significant cultural differences between the US and Mexico that come into play and need to be accounted for (see Geert Hofstede’s Cultural Dimensions for a good comparison of different country cultures), but the cultural gap is much smaller than with more distant countries.

Another element that enables a nearshore team to provide a better customer experience is that by working during similar business hours, the quality of life of the client team members is not affected. There is no need for late-night or early-morning conference calls to be able to synch up with the remote team. Likewise, it is not necessary to wait anxiously all day for a remote developer to finally arrive to the office to be able to talk to her about a particular issue.

Granted, since our engagement model may include nearshore resources, my opinion is biased. And I fully recognize that a nearshore location alone is no guarantee for good quality or better results. However, I think that given two providers that are equally capable, where both have proven methodologies, committed team members and a results oriented attitude, but where one is on a similar time zone and the other is in an opposite time zone, the perceived experience of working with the nearshore provider will overall be better than with the offshore provider.

What is your experience? Do you agree?

Postscript:

It has been brought to my attention that in the last few weeks there has been frequent coverage in the media about the violence in the vicinity of the U.S./Mexico border, arising from the war on drugs. This, naturally, can be of concern to those considering nearshore outsourcing in Mexico.

The situation is indeed very serious in that region and without a doubt it is affecting the ability to conduct bi-national business in the area. However, even though it may seem that the whole country is in a state of emergency, in reality the problem is mostly concentrated in a few locations, like Tijuana and Juarez.

Morelia, where our Delivery Center is located, is about 800 miles away from the closest border point with the U.S. Morelia is the capital of the state of Michoacan, and it is pretty much a college and government town of about one million people. Although some incidents have occurred here, life in the city goes on ordinarily, with its characteristic lively, dynamic atmosphere.

A fact of modern life is that there are no completely safe and risk-free places anymore. From the recent terrorist attacks in Mumbai, India, to the attacks in New York, Madrid, and London, it is becoming difficult to think of places where safety can be entirely and permanently guaranteed. Nevertheless, the risk of being the victim of violent acts is still very small compared to the risk posed by car accidents or unhealthy life habits. So, while it is only common sense to stay out of places where violence is rampant, we must all go on with our lives, striving to make the world a better place.

Going back to the issue of working with resources in Mexico, as Datamonitor put it in a recent article, “it would be futile for both outsourcers and their clients to forsake this country in light of recent worrying media reports, considering its clear advantages and history as a delivery hub”.

The adoption of Agile approaches in software development has grown very rapidly in recent years. I remember that a couple of years ago a lot of people in the IT world hadn’t even heard about Agile. Today, most of the development groups I talk to claim to adhere to Agile, at least to a certain extent. But the reality is that many of them are not realizing the benefits in productivity and quality that they expected.

The truth is, many groups are really using Agile as an excuse to take shortcuts and avoid doing the things they didn’t like to do in the first place, so there is no surprise there that Agile is “not working” for them. However, other groups are making conscious efforts to adhere to Agile principles and they are still failing to realize the benefits they expect. Because of this, Agile advocates like James Shore are becoming concerned that Agile might be getting a bad reputation , and that the movement may be in decline despite its popularity.

For us, it took two attempts to “get it right”. As with many other software groups, when we learned about Agile we were very attracted to its promises. As a team dedicated to developing software for external clients, we saw in Agile both a way to give better, faster results to our clients, and an approach that would actually make it more fun and rewarding to do our jobs. So we started using Agile with a pilot team. After reviewing the alternatives available, we selected Scrum as our framework. We studied the literature, defined the processes and artifacts we would use, and implemented it on a new project. At the beginning it was very exciting to be working with Agile. We were doing everything by the book and we felt ahead of the curve. However, after a few weeks, our burn rate chart showed very little progress. In the daily Scrum meetings the typical report was that the team would try to finish today the tasks they were supposed to finish yesterday. But the next day the report was still the same. We abandoned Scrum on that project after 6 weeks and moved back to a waterfall approach. Needless to say, it was a very disappointing experience.

…fortunately, we persisted.

Despite the disappointment of the first attempt, we were convinced that the principles of being Agile could work for us and our clients. So we analyzed what had gone wrong, not only in the first Scrum project we had, but in all of the projects where we had had challenges. We arrived at the conclusion that most of the problems in projects arose from “people issues”, not because of the flavor of the project management approach we were using. People issues ran from communications, to visibility of goals, to commitment. So we set to work on those issues, realizing that as a growing company we had to reinforce the culture of participation, collaboration and commitment that was so natural for the founding team, but that was probably not so obvious to the stream of new team members we were integrating to the company. This time, Agile fit like a glove. It provided the framework to foster those precise values and attitudes we identified that needed improvement. And I am happy to say that moving to Agile delivered on its promises. Our customers are getting better quality, better control, better visibility and faster results. And our teams are more motivated, getting recognition from customers and internally, working in a more integrated way within the company and with the customer team, and overall, more satisfied with a job well done.

So in our experience, as long as the behavioral and attitude principles behind the spirit of Agile are present, Agile will deliver the expected results. And that is where I think the challenge for most organizations lies. Following an Agile methodology “by the book” will always fall short of expectations if the people involved in the process don’t work as a collaborative team of peers, with the needed visibility, and taking responsibility for their individual pieces of the puzzle. So moving to Agile is more than changing methodologies, it really requires a cultural shift.

For more on the topic, please see When Agile Projects Go Bad – and Good Luck in your efforts!