Haut Tech » outsourcing

Lean Software Product Development in 4 Phases

Michael Dunham — Wed, 24 Feb 2010 18:55:59 +0000

When you develop products in a repeatable, production fashion, you have to step back occasionally and take the long view so you can properly discuss the process with clients. We’ve been involved in that exercise recently and I thought it might be useful to share the what and why of our approach to software development for online products.

First, there is one basic idea that informs all of this:

We define “Big Bang” development as:

A basically black box project where significant work is done up front to develop extensive requirements documents which detail the features and functionality in great depth for a software development project that typically lasts from 12 months to two years.
The time expended on requirements development is expected to provide developers with a very specific vision of the product that can be put out for bid, will put a box around scope, cost and time, and will last through out the project.
On release, the exhaustive feature list is expected to drive market adoption and leapfrog existing competitors.

This technique of specifying software product development has been used for years by companies that want to somehow reduce risk on a project they cannot do in house and often because of the technology and complexity, where they cannot provide granular oversight during the project. But regardless of those worthy aims, these projects continue to fail because:

Controlling scope over the life of a project becomes increasingly difficult as the project complexity and time span grows. Prediction accuracy degrades geometrically over time – yielding a project plan that can be relied on at a high level at best.
Technology continues to respond to Moore’s Law. The longer requirement development takes, the longer the project goes on, the less likely it is to meet the expectations of the market on delivery. User expectations, informed by other products they have tried, have moved on. In addition, the technology assumptions at the beginning of a project don’t always work out when development actually takes on the complexity of integrating them. So the choice of a tool, framework, or library may seem like it solves a lot of problems at first, but in practice may turn out to be a black hole into which resource time disappears.
No matter how detailed requirements are – they are limited by two things: point of view (the classic story of the blind men and the elephant is the common point of reference) and actual feedback from end users of the resulting application. No matter how carefully feedback from end users is brought together for requirements, it is only as good as their vision of the final product. As we and others have said many times – if you asked people at the start of the 1900′s what they wanted for personal transportation – the requirements would only lead to better horses. In addition, it is rare for requirements to both anticipate user needs correctly and the complexity of delivering them in a particular way. The risk in requirements actually increases the more detailed they become – if they cannot respond to end user feedback early in the development process.

So – what is the alternative? Consider “Lean Product Development.” We have a general assumption of software product development we have formed over several projects and across several industries:

Lean Product Development (Click on the image to see it in detail)

The phases and their aims break down this way:

Sprint 0 – During this phase, requirements are verified, technology choices are made in detail (architecture, stack), user stories are built (we use Agile development techniques – user stories are roughly equivalent to use cases), and the user experience (more than just interface, how a user will use the product) approach is developed to set interaction standards. The outcome of this phase is a set of technical specifications, personalities (roles to a degree), and prioritized user stories with effort estimates for each story.
Alpha Version – During this phase, the underlying framework is built and core functionality is developed for key end-users. The point of this phase is to verify the product vision with the key audience of the application – the end users who perform the most critical tasks and use the application most. This means the alpha version needs to be actually be tried by the core end-users. This usually requires client partners – which in the case of a new vendor requires getting out into the market and bringing in some early adopters. The outcome is to lower risk. The cost at this point is low, compared to the whole project, so changes can still be absorbed without loss of large portions of developed code and sunk costs. Also, at this point, the approach of the development team in carrying out the vision of their client can be verified early – so that adjustments can be made and trust between the client and the development team can grow. This approach follows the sage advice articulated by Steve Blank - the point of early user validation is to get out your “dark room” and get in front your audience early so they can inform development before costly mistakes are made.
Beta Version – This phase produces the first cut of the market version of a product. It is important to understand that the scope of this version is intentionally limited to just what is necessary to deliver value to end users. In other words – deliver just what they will PAY FOR. This is a critical assessment that is informed by both the vision of the subject experts and the feedback from the Alpha Version. The problem is however, no matter how good the vision and feedback are, there will be additional feedback when the product hits the many different contexts of actual target end-users in the market. The release of the beta version also provides the “kick off” of internal operations for the provider – and in the case of most products – support, sales and marketing. The lessons learned from beta release then inform the next phase so that beta adopters are rewarded (and retained) and operations delivers the message and services needed to drive new customers and user adoption. Because of the incremental nature of Agile release cycles, the actual point when sales are made during this phase varies a lot between products – but development doesn’t stop. What changes is that development is now more directly informed as new customers come on and participate in the beta. Some companies test pricing and marketing more aggressively at this point than others – but the general recommendation is to establish pricing early and test it against the perceived value from users. The outcome isn’t expected to be an adjustment to pricing directly but rather an adjustment of features or packaging to better align with perceived value.
Market Release – This phase marks the release of the full market product and the beginning of “normal” product enhancements to continue to grow functionality in alignment with user feedback. We sometimes add a phase for development up to market release itself that is separate from beta – but for general purposes – development has now slipped into an enhancement mode, rather than full out development unless there is a significant difference from what is planned for release to beta customers and the general market. The outcome of this phase is a product informed by target user feedback, tested business operations and a change of focus from getting the product “out the door” to getting customers and continuing to enhance features and functionality. It is not an end point – it is just the start of the natural evolution and “pull” of a “consumerized” online product.

The outcomes of this process are:

Early release and feedback from the people who count – the users in the field.
Early validation that both the vision and the requirements are resulting in a product that delivers value and will meet market expectations.
Lower up front risk and lower time to profit. Waiting over a year to put a product in the market with real users is a recipe for disaster. Getting into the market, proving operational assumptions and kick starting cash flow as soon as practical is key to success. A good reference on this Joel York’s SaaS Metrics Rule-of-Thumb #4: Company time to profit follows time to break even. You can’t prove your assumptions around operational costs and customer acquisition cost (CAC) until you get into the market. The sooner you get into the market, the more time you have to adjust to reality before your startup cash pile is burned up.
Simple – a higher chance of success measured by what counts – adoption, cash flow from customers and retention of users.

A lot of our customers though face a little more difficult situation – they have an existing product in the field that started life as a traditional premise-based product and is now being pulled to adopt a more dynamic online model. That brings an additional set of issues:

If the development cycle is long, existing clients may jump ship before the full online version is available.
Support and maintenance of the existing product can overwhelm the key members of the product team that need to be available to shape the new product. Finding a point when transition can begin in an orderly fashion, without cannibalizing existing sales is critical.
The new direction provides an opportunity to develop new markets, adopt new pricing levels and transition to a pull-driven feature model (rather than the push of traditional product releases) but timing is key. For a complex product meeting the needs of the top of a vertical market this becomes a huge exercise and is frankly very difficult to break down into manageable pieces.

To deal with that we have a general model that takes the new product template above and turns it into a phased development of a suite of products. In the diagram below – you can think of each of the blue boxes as a modified run of the our typical product develop cycle:

Progressive development for a suite of online software products (Click on image for more detail)

The major steps in this are:

Sprint 0 – A holistic project-level requirements, technical specifications and feature breakdown that sets the stage for the entire project – but doesn’t lock assumptions down. The point of this entire project is as before, get products out early, get feedback and cash flow as soon as practical. This also includes a more detailed look at the first product in the suite.
Web Enhancements – This part of the first product release is optional but worth considering as a way to ensure existing customers stay onboard for the long run and can see the long vision early – so they will become key in feedback as the product progresses through the lifecycle. What form this product takes varies, but the idea is to enhance the existing product with features that suit the Internet environment particularly well and extend it in ways not possible before because of technology or restrictions inherent in the on-premise version.
Broad Market Version – To allow early feedback and to get into the market as soon as possible, the first product needs to be a focused subset of the expertise expressed in the legacy product that addressed the top of the market previously. Generally, this means providing a set of features that will provide value for the 2nd and perhaps 3rd tier of the market. Again, all the points of a typical product release as we first described need to happen in this release so the product is informed by actual end-users in the target market – which coincidentally is a new market for the vendor.
Professional Version – Building on the same code base as the Broad Market Version, the professional version targets the features which will satisfy 80% of their installed base. This sets the stage for migration and broadens potential adoption by a group of customers who will pay significantly more for the value the product delivers. This also marks the point where legacy support and maintenance can begin to turn the corner and clearly move toward the new product.
Enterprise Version – Again, on the same code base, enterprise functionality is added and now the entire “product suite” has reached levels of functionality never achieved in the legacy version. Users pick levels by feature packages within the suite – so if properly architected – there is a lot of variation in pricing and packaging possible to meet needs in different markets.

It should be said that the timeframes proposed here are generalizations and will vary, but – they are based on the assumption that development should focus on delivering features with value to end users. Everywhere else, the simple rule “less is more” should be followed with the leverage of services and frameworks where ever practical. The architecture needs to allow those services to be used as long as necessary, but to be replaced as growth provides the option to drive down the cost of service. It should also be said that features and customization in this approach come from choices of what is made available to roles in market packages and configuration – not separate versions.

Now, I’ll admit this is a big vision and a lot to absorb in any context – either as a startup or a software company with legacy products in the market. And – it is a big shift in how we have looked at software product development. It comes from our own experience of the issues we find repeatedly in the market. I can’t say it is an approach that every development group can provide successfully. It depends on making clear choices that will provide these outcomes and not waffling with half measures.

What do you think? Can you see your company going down this road? Can you see the benefits? Let me know…

Outsourcing: The Nearshore Customer Experience

Luis Aburto — Sat, 07 Mar 2009 03:05:25 +0000

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”.