Stephan Schwab - outsourcing tag

Outsourcing for start-ups?

Wed, 05 Mar 2008 02:26:45 GMT

This is a re-post of something I wrote earlier on the old blog of my company. I just read a discussion about the topic Outsourcing for start-ups on LinkedIn and although the text is written to attract and convince prospective clients, I think it may spark some interesting comments.

What seems to be the prevailing point of view seen in the LinkedIn discussion is that, if the start-up is a technology - read software - company, you should not outsource your R&D. That's kind of obvious. ;-)

On the other hand some seem to think about outsource in terms of offshore to some cheap labor country and fear the loss of IP rights. Isn't there a difference between offshore and outsource? You can outsource to a team located just down the street and that may make a lot of sense.

I really like the comment Peter Nguyen gives:

I teach strategic business design to entrepreneurs, and one thing I stress is to be clear on what your business model is. Unless your startup does software development, it's a good idea to outsource. However, keep in mind that IT is such a central part of any business organization that, as I mentioned before, it's important to outsource to the best IT companies, regardless of where on the planet they come from.

Here is the re-post about New Product Development:

Traditional Software Development does not work

Software Development is not an easy task. In over 20 years many projects have failed and a lot of money and opportunities have been lost due to wrong expectations and bad project management. Unlike common belief development of a software system is not an exact science. Although the term “software engineering” is commonly used, it’s more a union between art and engineering. Good software engineers have developed a feeling for good systems design due to their long-term experience. What we do is more comparable to the art of playing a violin than the work of an engineer who can leverage norms, standards and mathematical models. Such clear rules do not exist in software development to the same extend. Further teams frequently struggle to deal with a great number of unknown factors, such as unclear specifications, changing requirements, and simply unforeseeable requirements, while being expected to deliver functionality on time, on budget, and with high quality.

Agile Development is a dialog with the client

In recent years a new idea is getting more and more adapted by forward thinking software developers and companies. Instead of following the failed “Waterfall” development model, which made us belief that we can design a huge system upfront and then have programmers write the code according to the specification, “Agile” teaches that it’s better to develop in short iterations and embrace change with each iteration completed. Instead of big upfront design, we design enough to produce working code for a limited set of functionality and have the user see and try it to give us more guidance. Instead of working out of sight, we enter into a process of continuous conversation with our users and learn more and more about their business while we build software for them.
Calculating development costs

Clients want to know/need to know when the new software will be ready and how much it is going to cost. Agile Development allows us to answer both questions more honestly. We can only estimate something we know and understand. So instead of promising all and everything to our client, we calculate the price for the product iterations. Neither the client nor we can possibly know how many iterations will be needed to development the new product the client is looking for. Instead of exposing the client to a huge risk or accepting the full risk ourselves, we lower the total risk and allow for corrective measures from the beginning.

Scrum Sprints

Caimito uses the Scrum methodology for all projects. Development in Scrum is done in sprints of a fixed length. The duration of a sprint can be one week or up to four weeks. Each sprint will deliver a new product increment, which is running code that could be used. Before a sprint starts the development team plans the work it wants to do and commits to the goal it defines for the sprint. After the sprint the team conducts a meeting with the client to demo the new product increment and gathers feedback.

Before a sprint starts team and client know exactly what the product increment will be. There will be no surprises in terms of unexpected results, lack of features or raising costs.

Depending on the size of the team and the complexity of the project we suggest short sprints and small team sizes to further lower the risk. Misconceptions can easily be handled when detected after one week, while the same problem will get costly after four weeks.

Client Representative

We understand that our clients are busy with their own business and frequently can’t afford to dedicate too many resources to the much-needed dialog with the development team. Usually agile practices ask for a client on-site who works with the team each day. Unfortunately that doesn’t work for all clients and we’ve come up with an alternative.

In our adaptation of Scrum there is the client, a client representative and the team. Facing the team the client representative acts as Scrum Product Owner and is responsible to administer the product backlog, which is the list of requirements for the product in the form of user stories, change requests and bug reports. Facing the client the same person represents the team and communicates to the client the achievements of a sprint and gathers new requirements.

The skill set of this person includes that of a business analyst with experience in the client’s industry or at least the ability to learn quickly, but as well languages, as clients not necessarily speak the same language as the development team.

Currently Caimito supports clients in English, German and Spanish.

Domain Driven Design and Unit Tests

Software developers are experts in software engineering, but can’t be experts in the client’s domain. The challenge we face is to create a working solution that optimizes processes in the client’s business without fully understanding a business foreign to us. Domain Driven Design (DDD) is a relatively new technique, which allows us to model the important parts of a client’s business with objects in code and shape the solution by adding functionality incrementally. Backed by automated tests we can assure that things that have worked before keep working while we add or modify code to build or extend the system.

Continuous Integration, Integration Tests and test coverage

Some programmers crank out code at high speed and leave testing to a QA (quality assurance) department. We don’t believe in this approach. Instead we perform continuous integration using an automated build and test environment where all tests that were ever written for the project are executed with each hourly build of the entire code base of the solution. That way we will know immediately, if new code breaks something and can fix it, before more valuable time has been wasted following the wrong track.

Our Integration Tests are end-to-end tests that span from the presentation layer down to the infrastructure layer and further down to a real SQL database, if such a data storage technology is part of the solution. Tests on the presentation layer are performed with automated testing tools that simulate users working with the user interface of the application and are part of the automated tests run with each build hourly.

Tests do not serve any purpose, if they don’t cover enough scenarios. As part of the automated build we run a tool that reports on test coverage per package, per class and per method. We make sure that we have a coverage of more than 90% on a per method level.

A code base with very good test coverage, an easy to run automated build process and good integration tests is easy to maintain and extend in the future. Even a new development team can work successfully with little ramp-up time. The investment in extra time to improve test coverage or maintain it high pays off fast in the form of reduced costs and greater stability of the overall solution.

Re: Silicon Valley is looking to do business in Latin America

Tue, 14 Aug 2007 20:22:08 GMT

This post is in response to a blog comment I received.

Henry Johns in his comment to Silicon Valley is looking to do business in Latin America:
The challenge of getting South and Central America competitive in offshore outsourcing is two fold. Available talent pool, and available talent pool with English language proficiency. It is easy to staff a project team of 50 developers in India. Try doing that in Panama or even Brazil without leveraging English speaking project managers or team leaders with Portuguese speaking developers. Sounds like a plan except many of the developers will not be able to read the project support documents.

The language barrier certainly exists in all places and India has been lucky to have adopted English as an intermediary language even amongst their own citizens. Being fluent in English is definetely their primary competetive advantage. Still I believe it all depends on the type of work to be done and who the clients are.

If the goal is to extend a company's workforce, then the offshore workers need to speak the same language as their onshore colleagues. English helps Indians with the American market. But their advantage diminishes in Europe, as not all and every European speaks English well enough or feels comfortable working in English for that to work out.

I cannot speak for businesses like call centers, help desks, systems support, etc. My topic is software development. Based on experiences with my clients my opinion is teams that were assembled ad-doc by recruiters or other staffing organizations usually don't work well. As in sports a good team needs some time to train together and learn how everybody ticks. Nobody in their right mind would hire a group of guys who have never played together and expect them to win the World Cup. It doesn't matter whether all players are superstars within their respective home teams. Still in software development exactly that is done and then people wonder why it doesn't work and projects fail.

Not everybody on a development team needs to be able to discuss details directly with the customer. But everybody should be listening to what the customer has to say. Not necessarily has this to happen in a classic meeting or conference call in real-time. In my opinion customer feedback is best processed after it has been written down and be read several times regardless whether it's been written in one's mother tongue or a foreign language. And not only is it easier for humans to truly understand the meaning of written text, it can also be machine translated. It's amazing how good Google's English/Spanish machine translation is. I expect it to work even better with more formal content than newspaper articles or blog posts. What is usually missing is a tool that helps the English speaking stakeholders and the Spanish speaking developers to communicate effectively.

My company is working on an agile project management tool called Savila. We are currently investigating how to integrate machine translation for user stories.

Henry Johns adds in his blog comment:

Many countries in Latin America could do the same thing as Microsoft is doing in Canada. Bring in foreign high tech workers to jump start small offshore outsourcing businesses. I get resumes from professionals in India often who want me to sponsor them with an H1b work visa in the U.S. Why not bring them to some place like Panama?

This refers to Microsoft's move to open a development center in the greater Vancouver, Canada, area - just on the other side of the US/Canadian border across from Seattle where Microsoft's headquarters are.

That's certainly an interesting idea. But the language barrier still exists and it is probably even higher. Actually there is a group of Indians teaching computer topics here in Panama. They are employees of the Indian outsourcing and consulting company Tata and their presence is kind of a gift from the Indian government to the government of Panama. All classes are given in English and I have some doubts whether that's entirely useful. For someone without years of speaking a foreign language it's certainly easier to receive the initial training in the language they've grown up with. It's hard to learn two things at the same time and even harder, if thing A is the condition for mastering thing B.

What indeed might make sense is to offer the English speaking Indians a place where it's easier to immigrate to than the US and still be closer to the US than India. Certainly a better idea than to anchor a ship off the coast of California.

Research study tells who really makes the iPod

Fri, 29 Jun 2007 19:07:35 GMT

Just found this pointer to a research study, which explains who really is making the iPod. That means the manufacturing. The idea and design is Apple's.

International Herald Tribune in Who really makes the iPod?:
Their study, sponsored by the Sloan Foundation, offers a fascinating illustration of the complexity of the global economy, and how difficult it is to understand that complexity by using only conventional trade statistics.

Indian CIOs have to offshore work

Thu, 28 Jun 2007 15:13:48 GMT

Now that's interesting news:

Network World in Indian CIOs have to offshore work, says Gartner - Network World:
Indian CIOs will have to consider outsourcing offshore, because of the shortage of IT skills in the country, and inadequate services standards of local service providers, according to research firm Gartner Inc.

People who really know what they are doing are rare to find. In the IT industry good skills are not easy to obtain. A good developer or SysAdmin needs to live the job and not just do the job, because he needs money to feed himself and his family. The ever evolving technology demands that one is passionate about the topic and willing to learn constantly. Just performing a certain set of tasks over and over again will cause falling behind and in the end become useless.

Fostering good skills in its people is as well a responsibility of the company. For example in my own company I follow a bit the ancient pattern of apprentice, journeyman and master. The education kids receive in the local Universities here in Panama is not bad, but they lack guidance and practice. So I give them a chance and over the course of a few weeks I decide whether they are made of the right stuff or not. Once I found one who is, I put the new apprentice to work on real tasks that contribute to a real project and after a year he should have gained enough knowledge to solve some tasks on his own. Currently I have Fidel, who has been doing Java development since 1.5 years, and Enrique who is about to graduate from UTP. Currently Fidel, my "journeyman", helps me teaching Enrique and I expect Enrique to do the same in one or two years. It takes time, but I feel it's the only way for a company to grow in a sane way and have skilled people who can actually satisfy clients. Of course sometimes one can find a guy who has learned everything on his own, but I consider counting on that or hoping for the rare find a bad idea.