I received a call from someone new at this design firm about a new client project. It sounded great, and we quickly found a way to work together on it. I was told that they heard about Waverley from another company they work with occasionally. I assumed this was yet another case of the work we do with so many companies in the Bay Area resulting in new business. It was a little odd that the referral didn’t come from inside the big design firm.

Later I mentioned this to my partner Matt, and he pointed out something surprising. Turns out, our friend at the big design firm had referred Waverley to the smaller company for a project some time ago, and that discussion lead to numerous meetings and opportunities. Now the smaller company was acting as the referral source back to a new contact at the large design firm that we’ve already worked with for some time. Just goes to show again what a small world this really is, and it all just goes around in a big circle.

However, there are some strategies that can be employed to accommodate the request for a fixed bid, without giving up design flexibility. For example, with one of our larger clients, Waverley utilizes a multi-stage strategy where we divide a large deliverable into small fixed bid milestones. Each milestone is one to two months of work and begins with a short design phase.  Working together we create purchase orders for a time and materials fund to cover design and analysis work.  The upfront T&M work allows agreement on the upcoming milestone and fixed bid the work with a clear plan that is achievable with minimal risk.

Minimizing schedule risk is one of the biggest factors in creating fixed bid contracts that make sense. In order to make this successful, it’s important to establish confidence from the buyer perspective, so they can see and trust a large scale plan to provide a long term deliverable across several smaller stage milestones that meets their requirements and costs. This is especially true for Agile development in particular.   The project overview can be discussed up front with goals for each milestone and a general understanding of what resources and budget will be consumed to satisfy the long-term requirements of the buyer. With each milestone, risk is reduced and the working relationship benefits from the confidence created during the T&M design phase

I should first point out that your selection could easily be more about what partner you should be selecting. Many outsourcing vendors provide development teams from a variety of geographic locations. Great teams are often found all over the world, so a specific location might not be the deciding factor. Then again, the location could play an important part for timezone, culture, and other factors. You aren’t alone in thinking that location is one of the important questions you should be asking yourself.

The short answer is that location does factor into your decision making, so let me pass on some things we’ve learned. We’ve found and worked with great teams in India and China, but the timezone, language, and creativity have often been a poor match for the quick-paced dynamic types of teams clients often need to augment their internal software development teams. Certainly the talent pool and prices are attractive, but software development clients are usually much more interested in highly efficient, super quality teams even if they cost a little more.

Teams from Eastern Europe often provide the best balance for such clients. In these locations, it’s important to find the right balance of quality engineers, costs, and political stability. The timezone, language, and creativity are an excellent fit for the most demanding software teams. We often have clients that tell us our offshore teams are some of the best engineers they’ve ever worked with, and they are ecstatic to see how well they adapt to working with them exactly as with their own employees. You’ll find countries like Romania, Bulgaria, and surrounding locations are a great source for finding truly excellent software development teams.

Managing Waverley software development teams located worldwide, I’ve learned the importance of MBFA – Management By Flying Around.  Software development is complicated, difficult work.  Often there are unexpected problems and setbacks, so openness, honesty and trust among team members is critical to our success. There’s an old adage that says that the three most important keys to retail success are location, location, location.   Well, at Waverley we believe the three keys to outsourcing success are communication, communication, and communication.

I believe that if engineers and customers haven’t been face-to-face in the past six months, our relationship is probably set back to zero.  My visits (alone, with our Silicon Valley Management team, and with our clients) to our software engineers in their home offices creates goodwill. Flying our engineers to our clients builds relationships. Everyone knows that hiding problems creates problems.  As we all listen to each other, air our concerns, share our solutions we create an atmosphere of transparency and accountability.  And, we create better solutions for our clients.

First, the big contract approach is to establish a multi-year legal structure that defines the areas you wish to outsource combined with various terms to enforce the goals you wish to derive from the relationship. This long-term commitment is highly lucrative for the major outsourcing vendors, but requires you to make remarkable insights into where the relationship will go, and how you must keep the vendor on track. This approach is similar to fixed bid contracts we’ve discussed before, which can be appropriate for some projects, but is often fraught with peril due to the uncertainty of future events and the unknown evolution of your vendor partnership. You want the best terms with your new vendor, but you need to ask yourself how much a huge contract investment and long-term commitment help you to build a truly win-win situation for the two of you.

Another approach is to establish detailed project specifications and contract the outsourcing vendor to execute on these precise plans. This also has many parallels to typical fixed bid projects, but fails to lay a foundation for the building of a relationship with the vendor. Are you just looking to satisfy the short-term needs of a specific project, or are you interested in building a real vendor partnership that can deliver value across many projects?

What you may really want is legal protection for critical issues like pricing and intellectual property, combined with a framework for both you and the vendor to grow to trust each other and build a foundation for long-term work. This approach uses a boilerplate Professional Services Agreement (PSA) combined with simple Statements of Work (SOW) for each project the vendor works on. The PSA makes no commitments on your part to engage the vendor for more than a month or two on termination. The vendor is constantly proving themselves to you each month through the quality of their work. You have the legal and price protection you’re looking for in the PSA, and each new project only requires a new SOW without PSA renegotiation. You start small and build a mutually beneficial relationship with the vendor from the very beginning. As you both grow to get comfortable working together, you can adapt the growing team to the areas that best fit your business. You’ll find the value in this arrangement is substantial.

As you can see, there is a much nimbler and adaptive approach available to you when establishing an outsourcing relationship and contract with a vendor. Use it with your next outsourcing partner for great results.

I’ll cover two key types of data you’re likely to need to backup: databases and files. I’ll assume that your databases are in MySQL, but there are similar tools for working with other popular databases. This same technique can also be used for Linux systems, but I’ll focus on the particulars for the Mac. I’m also assuming that you have root permission (sudo) to perform these commands.

First you’ll need to setup a special database user that we’ll only use for backups. You’ll need to enter your MySQL root password at the prompt, and then replace BACKUP_PASSWORD with a unique and secure password for this new user.

$ mysql -u root -p
mysql> grant select, reload, lock tables on *.* to backup@localhost identified by 'BACKUP_PASSWORD';
mysql> flush privileges;


You’ll then want to create an excludes file to avoid backing up data files that don’t make any sense. My install of MySQL is in /usr/local, but if yours is elsewhere you’ll need to change the last line to the location of the MySQL data files. There’s no need to backup these files as we’ll backup all your databases in a later step.

$ cat >> /usr/local/etc/backup_excludes.txt << EOF
/tmp/
/Network/
/Volumes/
/cores/
/afs/
/automount/
/private/tmp/
/private/var/run/
/private/var/imap/socket/
/private/var/imap/proc/
/private/var/launchd/0/sock*
/private/var/spool/postfix/
/private/var/vm/
/Previous Systems.localized
.Trash/
.Trashes/
.Spotlight-*/
/usr/local/mysql/data/
EOF


Next you'll need to mount the backup drive using the diskutil command. The exact disk name is likely different from my device name disk1s6. You can figure out the device name for your backup drive using the diskutil list command.

$ diskutil mount disk1s6


You then have to turn on ownership settings for the backup volume to ensure you get an exact copy of the files on your source drive. The default for external drives doesn't maintain original file ownership. We'll use the mdutil command.

$ mdutil enableOwnership disk1s6


Now we'll use the powerful rsync command to mirror an exact copy of all your files. There are a lengthy set of confusing parameters you can pass to rsync, but those you need are shown below. Archive mode (-a) makes sure everything is copied exactly as it is on your source drive. Only your source drive will be backed up, it will not cross filesystem boundaries (-x). Sparse files (-S) will be handled efficiently. Extended attributes (-E) and resource forks will be copied as well. Files that have been deleted on the source drive will also be deleted from the backup (--delete). The directories and files specified in the excludes listing we created earlier (--exclude-from) will be skipped.

$ rsync -axSE --delete --exclude-from /usr/local/etc/backup_excludes.txt / /Volumes/Backup/


It's also a good idea to turn off Spotlight on the backup as it's not really needed and only takes up space and time.

$ mdutil -i off /Volumes/Backup
$ mdutil -E /Volumes/Backup


Let's make the backup bootable while we're at it using the bless command.

$ bless -folder /Volumes/Backup/System/Library/CoreServices


Now let's backup all your MySQL databases using mysqldump. You'll need to replace BACKUP_PASSWORD with the backup database username we created earlier. The backup will be archived and compressed using the gzip command. The backup filename will be created using the current date for easy reference if you need to restore things to a previous date. You can read all about doing backups for MySQL here.

/usr/local/mysql/bin/mysqldump -u backup -pBACKUP_PASSWORD --all-databases --lock-all-tables --flush-logs | gzip > /Volumes/Backup/usr/local/mysql/backup/all.`date +%u`.sql.gz


Finally you can unmount the backup drive now that we're done.

$ diskutil unmount /Volumes/Backup


You can take all these steps and turn them into a single script for doing your backups. You can also schedule the script to run at whatever frequency you like. Other steps and ideas you can take next include:

• Rotate multiple backup drives and keep at least one physically at another location.
• Make application specific database backups available to your teams for easy download. Use the mysqldump command and replace DATABASE_NAME with your application's database name:


/usr/local/mysql/bin/mysqldump -u backup -pBACKUP_PASSWORD DATABASE_NAME --lock-all-tables --flush-logs | gzip > /usr/local/apache2/htdocs/backups/DATABASE_NAME.`date +%u`.sql.gz


• Make compressed archives of specific directories available to your teams for easy download. Use the tar command and replace directory paths and file names with appropriate values.


$ tar -C /usr/local/apache2/htdocs -czf /usr/local/apache2/htdocs/backups/appdata.tar.gz application/data


• Use the asr command to clone an exact copy of your disks as an alternative.

You can find more information on each of the commands I've talked about in the Mac OS X Manual Pages section of Apple's developer site. The Mac is an excellent UNIX platform for building powerful server platforms for all your infrastructure needs.

The questions asked by others taking the course really increased the value of the training; their own concerns and past experiences brought out answers and advice that will probably come in very handy in the future but that I would not have thought (or known) to consider myself. Of course our training “exercises” were not nearly the same intensity or complexity as a real-world project, but they provided an excellent combination of getting to “try out” Scrum while having coaches readily available to answer questions and provide guidance.  I am much better prepared to initiate using Scrum with a team after this course than I would be after reading 10 books.

As Waverley’s newest CSM, I recommend that if your company is considering implementing Scrum, formal training is an investment that’s well worth it.

“Halt the development of certain projects temporarily or permanently. If any of these projects are outsourced and your paying the outsourcer for time and materials, stopping the project, even for just a few months, can immediately save you money.”

This may make sense in some cases, but I can’t think of too many. From the perspective of working on high priority mission critical projects, stopping randomly in the middle of development makes no sense because there is as much or more to lose as there is to gain. Firstly, If you’re working with great people, they will not sit around and wait for you – they will move on to other projects where their skills are useful. Outsourcers can’t leave top talent stagnant for months at a time. Secondly, when you’re ready to get going again, you’ll have new knowledge transfer and ramp up time issues to go through and this will delay the end date much more than just the several months you chose to postpone work.

Here’s a much better way to proceed. Rather than stopping and starting, look at your project and focus on delivering value as quickly as possible. It’s pretty well accepted that most of features of a large IT application are not going to be used and not all features have the same value to the organization. Divide up your features, prioritize each feature, then implement the work in small steps and have the project stakeholders evaluate the results at the end of each small step. Be willing to change priorities to match the organization’s goals. This is classic Agile development at work. At some point, you’re going to conclude that you have enough of the project done to meet critical needs and you can stop development and deliver something useful, rather than stopping development with little or nothing to show for your investment to date. It makes a lot of sense for a lot of reasons to keep development teams running smartly towards a goal unless there is a significant mitigating factor, so get the most from your partners but don’t let your project run on autopilot until a crisis occurs and you have to stop before you have something to show for your hard work.

Providing services to large companies is going to require more effort on the part of both the procurement departments, the consumers of the services provided and the vendors they work with. Procurement processes will face increased standards and solutions will need to be scalable across groups when possible. In order to control costs, large buyers are centralizing procurement functions and instituting policies regarding RFP’s and PO’s that help ensure buyers are getting more for their money. Governance will be more important than ever. I expect all vendors will have to provide more information to justify costs, work to creatively address the needs of their customers and actively drive their customers to find new ways of doing more with less. Buying in bulk will become more common and those vendors that can be flexible and scale have an advantage. Operational excellence has been and continues to be critical to the success of the vendor/buyer relationship. I expect the buyers of services to work harder to learn from their vendors and not just buy bodies to fix problems. I also expect more limited strategic vendor relationships. Standing still has never been a path to success and will be even less likely to work in this economic environment. Competition is going to drive relationships to be more effective and productive and the innovation that results should improve our mutual interests. We’ve always worked hard to have the best people, management and process and I think that effort should pay off for everyone.

At the beginning of an engagement both parties typically complete at least some amount of due diligence and agree that the business goals are good for both sides. If through the course of time, high-level strategic communication doesn’t take place, then that due diligence becomes stale and potentially worthless. And you may not find that significant disconnects exist until major damage is already done to the relationship through project failure, or even a complete dissolution of the engagement. These risks can be mitigated by having what I’ll call a Customer Review (similar to what’s known as a QBR) on a regular basis, about 3-4 times a year.

Some customers won’t want to spend the time. The Customer Review process is external to what they’re paying you to do and they can sometimes have a hard time seeing the benefit, but it is crucial for the long term success of the relationship. It’s key that you help them understand that finding strategic misalignment early will save them money over the long run and help verify that you are providing the best service you can to your customer.

The Customer Review should be a face-to-face meeting in a conference room with the management of both companies in attendance. Any sponsor executives as well as direct managers of the project should participate and attend from the client’s side. Following are some of the things that should be covered in the meeting as well as items important to you and/or each of your customers.

Presented by you:

• History of the relationship, accomplishments since last Customer Review
• Your company health, growth of the company, new areas of expertise, etc

Presented by the customer:

• Past project success in the marketplace, lessons learned, health of current project, etc
• Future roadmap, business strategy, product plans

Group input during meeting:

• Issues and difficulties currently hindering productivity
• Action items for next Customer Review

If you meet in this brief, semi-formal way with your customers on a regular basis, you will find you understand them better and can anticipate their needs more proactively, which enables you to provide the highest quality of service.