Geoffrey Slinker
v 1.1
October 2004
|
Accesses: |
|
Maverick Development |
Offsite development consists of telecommuting, satellite offices, near-shore teams, and offshore teams. The key to any offsite development is based in two areas. Trust and communication. Without trust in employees there will be time consuming tasks devised by management to attempt to ease management's distrust. Distrust is exposed through reports and the "cry" for measurability. You may find yourself in a position where trust cannot be established. Be prepared for increased costs in your policing efforts.
Communication is always an issue. It happens with onsite development. It is the reason for documentation processes. It is the reason for modeling languages. It is the reason for stand-up meetings, reports, and the reason for many layers of management. For off-site development to work you must learn what is important to communicate and then try to perfect the medium of communication to reduce the misunderstanding of the communiqué.
Offsite development may be a reasonable approach for many reasons. Employee costs is the most common reason. Many companies choose off-site development because the costs are cheaper elsewhere. The off-site location might be in a different city or even a different country. Facility rates may be cheaper in a near by suburb. I know of companies that have moved as little as forty miles and saved significantly on the cost of the building lease. If the office location is in a downtown area it may take your employees a long time to commute because of traffic conditions. If your employees are spending two hours or more a day commuting their quality of life is greatly diminished. It might prove advantageous to allow your employees to choose either Friday or Monday to work from home. This will decrease their stress and will relieve part of the traffic congestion for others. In Maverick, people are first. The right people will be concerned with the bottom line and the company can fully trust that if an employee needs to come in on their "work at home day" they will do it because it is the right thing to do.
One thing that remains constant with on-site and off-site development is that the software still has to be developed and all of the tasks and all of the steps of software development must be carried out. Location does not change this fact.
Nothing can beat a small-collocated team for efficiency. In my opinion that should be the preferred approach for any software development. However, if the costs for development are more than the budget can allow then a less than optimal approach must be considered. But remember this, the scope of the product will have to be reduced if the release date is fixed. It will take more time to develop the product in an off-site approach. How much more? It might be only a few weeks. If the product is estimated to take one year to develop with five engineers at $100,000.00 salary (ignoring insurance and other costs of total compensation) then it will cost you $500,000.00 to develop the product. If you can hire five engineers for $25,000.00 and it takes you 14 months to develop the software the total costs will be around $146,000.00. The savings in this oversimplified example is clear. I want to be clear that the reports I have read concerning offshore development have not shown these types of savings. As a matter of fact the savings attributed to the offshore development usually are attributed to the streamlining of the development process, the adoption of more current methodologies, more current tools, and more careful and deliberate communication. That said the five man on-site team with the improved work environment might have developed the software in five months time at a cost of $208,000.00. In that scenario the $62,000 in cash savings cannot compare to the nine months in time saved. The future value of the cash must be considered!
For any type of off-site development to work a certain level of trust must exist. If your company has over invested in process management then the management team will resist any proposal for off-site work. Their arguments might include such things as, "How do we know if they are really working?" or "How can they be working efficiently?", or "They convinced us that pair programming was cost effective and now they want to work from home, how can both be productive?", or "We can't allow the source code to leave the company for security reasons.", or "We can not open up the network to outside access because of security reasons." I could come up with scenarios for days!
In the following scenarios of off-site development, each builds upon the other in that the following scenario suffers from all of the preceding scenario's difficulties plus additional ones.
If the software development teams are large enough that they are located on different floors, or in different buildings then the issues of communication become an issue. The logistics of talking with someone starts to consume time.
Sometimes you find that once you have walked or drove to the location of the office and found the person you would like to talk with they are busy coding and do not wish to be disturbed. All of us that are programmers know that when you are in the "zone" or in a rhythm an interruption can be disastrous.
Also it is presumptuous to take what is clearly a difficult problem to someone and dump it on them without warning and expect a thoughtful and complete response. Off the top of the head solutions usually end up being justified with statements like, "You asked me if it would be alright to do X and you did not mention that you where also doing Y. It is not my fault that the database is corrupted!"
I personally like to use email to notify the person that I have a serious question and the details of it and that I will be coming by to discuss the problem or if they are free could they come by my desk at their convenience. They may respond with an answer in the email. Thus giving you a paper trial and context for further discussion. They may be the type that never reads their email. So when you go to their desk and you discuss the issue you can bring up the email so that you don't miss or forget any points. The email is like a small meeting agenda.
There is no need to be offended if the person cannot see you when you want. Everyone has deadlines. Maverick development points out that many companies only rate performance on features completed and not on helping others. If your company does not recognize that helping others is part of work then you will have to wait until the person you want to meet with has a spare moment of time. If you are dependent on this person and your features are slipping then it becomes a management issue.
Other tools are very handy in communication. There is a thing called a telephone. Learn to use it. Also, there is instant messaging. An instant message works great. The users can set the status so that they are not interrupted and the message can be delivered the next time the log in.
Asking the question is only the first half of communication. The response is the second half of the communication and it contains the part that is of use and that is the answer. Many times the person has flooded me with so much information that I forget half of it by the time I get back to my desk. Sometimes you cannot take notes fast enough or complete enough. This is one of the areas where working together really pays off. Having the person come back to your desk and monitor the implementation of the solution can save on mistakes due to oversights.
Working from home is an option if certain criteria are met. Access to the intranet must be provided and this is typically done through a secure virtual private network.
If the software being developed is of a nature that it can all be hosted on the development machine then telecommuting is simplified in that access to the revision control system is all that is necessary.
If the software is a distributed solution then it is less likely that the developer will be able to configure a network of hardware at home that accurately represents the target environment. In that case a remote connection into the real network is required.
Walking over to a person's desk is not an option. Telephone calls, emails, instant messages become the core communication method instead of face-to-face conversations. The amount of communication needed to develop the software is the same as if the team members where on site. The rate of communication has been diminished.
Once again I find an email that contains the question to be a good starting point. Then call the person and have them open the email and go over each point. Have them type the responses to the questions and reply to the email as you take notes over the phone. This can also be done with instant messaging.
To reap the benefits of pair programming software tool can be used to share your workspace. With the shared workspace appearing on both machines you can implement the solution as described and they can monitor your implementation while considering broader issues that may not be apparent. With such tools working off-site can be nearly as productive as on-site development.
I would like to see a study that compares the costs of setting up shared works space tools, VPNs, and the cost of telecommuting as compared to the cost of leasing or owning a productive office space that is large enough to keep development teams in close proximity and a comparison of the productivity of the off-site team to the on-site team. I have a feeling that as the cyber-space, chat room, web-cam generation comes of age that the efficiency of the off-site team will equal and eventually surpass the on-site team. Remember that during the time of these Generation X'ers come to dominate the workforce the development tools and methodologies will not be standing still but will be improving as well.
What about meetings? There are parts of the development process that involve large groups of people. The defining of the requirements for a product or iteration usually involves many people. If a shared workspace tool is used to do this meeting one will find that those who have mastered the tool will control the electronic conversation. It is much like those that master their native language can control a spoken conversation. It is not advantageous for one to dominate the "game" just because they have mastered the user interface (all of you that have played a game like Warcraft will know what I mean).
Off-site development has the advantage that the development team is collocated. This improves the productivity of the off-site team greatly. But this improvement is only seen during the stages where communication is at a minimum. The benefit of having a customer representative available to the developers for face-to-face communication is not possible on a day-to-day basis.
There are factors that must be considered that did not apply in the previous scenarios. Time zone, cultural differences, lack of common metaphors, language barriers, legal issues, and issues of State are all factors to be considered.
The time zone can be the greatest difficulty. If the "home" site and the offshore site only share a couple of hours of the working day then all communication must be constrained to fit with in that time. Communication should be as free and spontaneous as possible. Time zone issues are very serious.
Near-shore development is done in places where the time zone difference is usually at most three hours. If you are based in Atlanta Georgia and it is decided that development will be done outside of the United States then consider countries that are still in the same hemisphere such as Canada, Mexico, or the Central American and the South American countries. This will prove much easier for communication during the business day than it would if the offshore team was in India, China, or the Philippines. Also, finding fluent French, Spanish, or Portuguese speakers may be easier than for other languages.
Time zone not only affects communication, but also influences the costs for travel. Traveling to India costs more and takes much more time than it does to travel to Quebec or Belize.
Off-site development may be chosen for reasons other than financial costs. A very valid reason for setting up a development office in China is to take advantage of their growing economic freedom and strength. The potential for customers in China is great. If you have had an office in China for ten years your company will be seen as a local company instead of a foreign company and will reap the benefits of consumer loyalty to local products and services. But don't forget the growing economic strength in Central and South America!
Foreign policy, trade agreements, and various laws must be considered. No one would ever want ties to the United States and China to crumble and fall apart. But reality of such things as the nuclear capability of North Korea and its ability to destabilize global relations must be considered. The same goes with South American countries that have unstable governments, out of control inflation, and have the reputation of being controlled bug Drug Lords. Current events must be considered. If your executive staff needed to travel to the off-site facility are there risks that they would be kidnapped? Maverick development wants you to consider everything and make decisions based on all relevant factors. Nothing is as simple as the examples used when describing scenarios.
The development team is collocated and there is an onsite customer representative. Iterations are well planned. Continuous build process is used. The team size is five to eight people. Every member of the team is trustworthy.
The development team is collocated but is off-site. There are continuous builds and short (one or two week) well-defined iterations. A VPN exists, and the work is stored on secure servers. If a foreign language is involved then a fluent language speaker that understands development and product management is needed. Minimal time zone difference of three hours is best. Communication tools such as cell phones, instant messaging, video conferencing, and shared virtual white boards and computer workspaces are provided and there is no scrimping on the communication budget. Every member of the team is trustworthy.
The key to the optimization is the development team is together, collocated, working and helping each other. No matter if the development methodology is based on pair programming or on code reviews the developers have to come together. Face to face is better than other forms of communication. Remember this section is concerned with optimal.
For both of these scenarios the members of the team are capable of carrying their weight and towing the line. That means there are no "for loop" programmers (a derogative term for someone that can not design or think) and it also means there are no heroes or empire builders. Every team member is concerned about the success of the other team members and the completion of the task above their own agendas.
If the decision to hire an off-site development is largely based on cost then has there been due diligence performed in understanding what are the costs of software development? Bluntly stated, why is it that the software engineer's salary is always the concern?
From my studies of offshore development teams the real savings occurred through the revamping of the software development process in preparing it to go offshore. The revamping alone may have been sufficient in realizing the necessary costs savings. I recently read an article that said something to the effect of "A leader is needed when you are doing something new. A manager is needed when everyone knows how to do the job." I truly believe that the number of managers can be greatly reduced (and their salaries are just as draining on a budget as a programmer's salary). If you have set up the right team, a team made of people you trust, a team of people which are concerned about each other more than themselves, a team of people that care about the quality of the work then they do not have to be managed. They just need a leader.
Look at the reports and documents that your current process requires. I am serious; I really want you to look at all of them. How many of them have been read recently? Count the pages and for simplicity's sake lets say each page represents an hour of work. Divide that by forty and find out how many weeks of work where used to generate the documentation and reports. When the reports where presented how much time was given to the report in the reporting meeting? I have seen ten to fifteen pages presented in a meeting in around fifteen minutes. The pages where so loaded with "stuff" that I soon quit trying to even read them. At the end of the meeting another developer hit me with a pen to wake me up!
How are the reports and documents used? Too often they are used for defensive arguments. Remember this simple statement, "Excuses NEVER out weight performance." If you had the right team in place there would be no need for cover you butt tactics. Too often changes in the requirements document is used to defend missed deadlines. The right team would have reset the dates when the requirements changed. There would not have been a Product Manager that was concerned about his bonus in the loop that was saying the requirements have changed but the dates cannot. It would have been everyone working together in a realistic and professional manner.
Thinking of cost saving techniques and bonuses I do not believe there should be any bonuses unless everyone gets a bonus. They rarely motivate the masses and therefore it is money that is not well spent. Having the right team means everyone carried their weight and everyone is an equal participant. If someone is not carrying their weight then the Maverick review process will remove them from the company.
Having the entire development team together in the same facility is optimal. On-site teams will have the advantage of being collocated with the Product Managers and other employees. Near-shore teams are better than offshore teams because of time zone differences that interfere with communication. One of the underlying goals of every software methodology I have ever seen is that of improved communication. Good communication must be a high priority. Near-shore teams do not require as much travel time and are therefore less stressful on those that travel to the off-site location.
The best communication tools are a must. I worked with an off-site team that had one ethernet connection and one cell phone in the office. This was because the expense for these luxuries where high compared to the rather inexpensive and resilient communication services found in the United States.
If the off-site team is in a country where there is a foreign language involved then find someone that speaks that language fluently that can act as the customer representative for the product and that knows the complete software development process. Since this person speaks the language he or she will be more amenable to extended stays at the off-site facility because the will not become depressed from the feelings of being cut off and surrounded.
Use an iterative approach to development with a very short cycle. Have a continuous build so that you can view the state of the product at any given time. Consider agile development approaches because they are test driven streamlined approaches.
Hire and maintain what I refer to as the right team. These are people you can trust. Management is at a minimum and leadership as at a maximum. Reporting is accurate and is as minimal as possible. A member of the right team will not come up with the same old excuses that we have heard for years like, "The requirements changed so we missed our dates, but it is not our fault because you can clearly see here in the requirements document what we originally agreed to." It will be obvious that the dates were missed. If the team is made of the right people the new requirements were reviewed and shown to be needed and therefore had to be included. If you have the right team you will know that everyone worked hard and that even though the desired release date was missed there was nothing more that could have been done so there will be no more discussion on the missed dates. When you have the right team you do not have people trying to be heroes or empire builders. Lay-offs and saving your own butt will not be at the high level of concern as it currently is in the software development industry. These fears cost a tremendous amount of money.