Wednesday, May 11, 2005

 

Knowing you have a problem

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.

Saturday, May 07, 2005

 

Intellectual Property Protection for offshore development

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:
These documents emphasize a number of important points:

Friday, May 06, 2005

 

A short break while we ship

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!

Saturday, March 26, 2005

 

Perceived Software Quality Introduced

All competent companies engage in testing of their software. When this testing is completed, and the software meets the agreed upon quality criteria, the software is viewed as being good enough to release to customers. Let's dissect this further. Typically a quality plan specifies a basic set of regression tests describing the base functionality of a product, a set of new test cases for new features, and certain generic cases covering reliability, performance and scalability. In essence we have an enumerated set of behaviors, and if the software matches those behaviors, then we say it is of good quality and we release it.
And then what happens ? Will the customer also think this a high quality product ? Obviously the customer will appreciate the product's quality only if the customer's exact use cases are exactly covered in the test cases run back home. Ideally, no matter what the customer tries, everything works exactly as it should. Then the customer will no doubt be well pleased. In real life of course, some customers are never happy, and few customers are always happy about everything.
The question is, what is the perceived quality of the product, and how does map to the formal quality measured in engineering ? How can we quantify the perceived quality of the product ? If we take steps to improve the formal quality of the product, how can we measure the improvement in perceived quality ?
One obvious dimension of perceived quality is reliability. That is, the set of customers perceives each instance of a defect as an atomic thing. So even if there is only one defect, if it occurs every 15 minutes, it will be perceived as many, many incidents. In that sense perceived quality is influenced by reliability, that is, the distance between occurrences of defects.
A subtler question is, who are the customers ? For an enterprise software product, in many cases the actual end users hardly have a voice; it is the perceptions of the executive sponsor that matter. In a call center, quality is more about what metrics of call center efficiency show, than about what the agents think. The answer to who is the customer that perceives quality may also change over time. While the software is being sold, its demo quality as perceived by sales people and prospects matter. When it's being implemented, partners and professional services determine quality. When the software is in production, sometimes end users, and sometimes their managers determine the perceptions.
This means that we need to formally study the reliability of the system as it applies to different classes of users at different phases in the life cycle of an implementation in order to characterize the perceived quality of the system.
We'll dig deeper into this next time.

This page is powered by Blogger. Isn't yours? Feedback by backBlog