Thinking about Quality

It's said that the first step towards recovering from an addiction is to admit that you have one. This idea applies squarely to change management. If a new idea is being introduced into an organization, frequently it starts in some part of the organization where the team has had the collectively realization, that we have a problem. Once that realization occurs there is a natural receptivity towards changes in behavior that would fix the problem.
The trouble begins once everyone decides that the solution is a really good thing and everyone should be doing it. Namely, once the solution is applied to other teams, the people in those teams may not have felt the full force of the initial problem equally. Maybe they weren't as affected by it, or they weren't aware of it, or are distracted by other issues. Either way, they don't see what's wrong. Hence they are reluctant to change their behavior, because they don't perceive themselves as being sick. There is a natural tendency then to impose the solution on the basis of "it's a standard", or "because we said so". The trouble with that is, it fails to get the deep buy-in that accompanies really internalizing why the idea is so good and how it helps.
What to do ? Here one needs to try some gentle education. If the problem is truly generic, then the solution is to be implemented not only as a curative, but as a preventitive. Once needs to make everyone aware that (a) the problem is bad, (b) the problem could happen to them, and (c) that the solution can prevent and cure it. As often in life, there's no magic answer, just a matter of a patient education and persuasion.

One of the big challenges with offshore development is protection of intellectual property. Of course intellectual property protection is a major issue for onshore development too. Domestically there are two main layers of protection: internal controls, and legal controls. Internal controls are by their nature preventive, whereas the legal controls are remediative. The problem is that with offshore development, even if the foreign country has reasonable laws, they are rarely easily enforceable, which means that prevention is even more important. Of course one way around this is to use a partner with a domestic presence who can be held accountable locally. Naturally, that works only if one is using a partner (outsourcing), rather than having one's own operation. Let's explore a bit what the issues are for protection intellectual property with offshore development.
As a start, let's look at some good references:

• Offshore Security begins onshore by Samir Kapuria
• Offshore Outsourcing in Today's Global Economy: Defining and Executing an Effective Strategy by Leland D. Shaeffer. - This document includes a lot of good information on setting up and running an offshore center.
  

These documents emphasize a number of important points:

• Process Issues
  • If you don't have good security onshore, you won't have good security offshore.
  • A formal IP Risk and Security management process needs to be designed and implemented from the beginning, not retrofitted.
  • In general easily trackable IP (eg. patented or trademarked items) are easier to manage than merely copyrighted items (eg. source code). This in turn suggests aggressive use of patenting to protect key innovations. Careful thinking about the nature of IP issues can help govern what areas get sent offshore, as well as what extra measures (eg. patent applications) should be expedited to protect key areas.
    
• Technology Issues
  
  • Access should be defined and partitioned so that everyone only has access to what they need to have access to.
  • No one offshore should have access to everything. Offshore teams should have a compartmentalized view of the world.
    
  • Really critical IP should simply not be sent offshore.
  • Maintain physical control over source control and networks. As much as possible use domestically located servers and equipment.
    
  • Use firewalls to block transfer emailing certain kinds of documents.
  • Maintain physical control over premises.
  • It is desirable to make the system sufficiently modularizable that it's security aspects can be mapped, and that work and legal protection boundaries match reasonably technological boundaries in the system.
    
• Vendor Issues
  • Work with vendors to ensure that security over premises is maintained.
    
  • Adherence to stated security/risk management process has to be built into the contract.
  • Use our own local manager to help monitor and enforce compliance with the process.
    
• Employee Issues
  • Minimize turnover through adequate compensation
    

I've been a busy a bit while we shipped our latest release. Like all endgames, it was a lot of work. However, it felt much different from previous releases. In particular, the focus we've had via our agile process on keeping the system running at all times really paid off towards the end. Rather than a frantic rush to kill large piles of fundamental defects, things were really quite measured and calm. The system stayed in good working order the whole time. We did get into a panic towards the end. But once the smoke cleared we realized that the scope of our panic was much different from what it was in previous releases. To wit, we were worrying about much more trivial issues than before. We had actually raised the bar.
On the whole looking back on it, the agile project for all its seemingly unplanned character was actually much smoother than any of our carefully planned releases in the past. The main thing that could have been done better was that we had overbooked ourselves in one of the middle iterations, and that causes a ripple effect through much of the cycle. The thing that snagged us was fixing defects from previous releases, which is a fairly anonymous background activitity that is not as visible as new features, but just as important, and can be hard to measure in terms of comparing effort to results. Scheduling this task is what gave us most of the fits in terms of over-allocation.
That notwithstanding, the serenity of this project is just in amazing contrast to the nervous tension that filled our previous non-agile projects. Full success!