Wednesday, October 22, 2008

Customer and Project Team Bill of Rights

The concept is brilliant. The first time I read it I said: “Yes, this is really what I always felt missing!”

Steve McConnell, in his excellent book Software Project Survival Guide, mentions a set of rights that should be respected for both the project team, and the customer who owns the product. Please spend some time reading them carefully; this is a prescription for project success.

Customer's Bill of Rights

I have the right:
  1. To set objectives for the project and have them followed
  2. To know how long the software project will take and how much it will cost
  3. To decide which features are in and which are out of the software
  4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
  5. To know the project’s status clearly and confidently
  6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
  7. To have ready access to project deliverables throughout the project

Project Team's Bill of Rights

I have the right:

  1. To know the project objectives and to clarify priorities.
  2. To know in detail what product I’m supposed to build and to clarify the product definition if it is unclear.
  3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software’s functionality.
  4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
  5. To approve effort and schedule estimates for any work that I will be asked to perform. This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project’s requirements change.
  6. To have my project’s status reported accurately to customers and upper management.
  7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

It is top priority for managers to spread this atmosphere of mutual recognition of rights. Customer, as well as project team, sometimes denies other’s rights. The customer should ensure that he is available to answer the team’s questions. Many a time, I keep waiting many days to book a meeting with the customer or even get an email feedback from him. On the other hand, customers sometimes suffer from project teams not reporting to them the true status of the project. Many things like that take place, resulting at the end of an unsuccessful project end.

Monday, August 18, 2008

Why Requirements Change?

Requirements change because this is the norm. We should never think that frequent requirements changes are sign of poor analysis capability of the team. This is one of the killing mistakes that managers used to do with the development teams!

Two reasons govern this change:

Rule #1: No Customer fully understands the requirements. At best, the customer understands the business problem; and in most cases, he cannot articulate it. What should be done is to implement part of the requirement (potentially the user interface), and let him work on it for a while to get a feeling of the solution, then start a second round of analysis.

Rule #2: the Customer is not a single person. This is always overlooked. This is why RUP says that the customer community should be dissected into groups, and each group should have at least one representative in the customer group.

The project leader/manager/master (call it whatever you like) is the responsible person to enforce these two rules. For the first rule, he should break down the vague requirements into small ones and plan for several iterations, after each of them, he goes back to the customer and get more feedback. For the second rule, he should make sure that all groups of users are represented in the customer group.

Monday, August 11, 2008

Pulling Requirements Analysis out of the project lifecycle !

The question is: Should requirements analysis be part of the software project lifecycle?

The answer is yes and no. It is very important to distinguish two types of analysis, Business analysis and software analysis.

Business analysis should be a fast, lightweight, and continuous activity. The outcome of this activity is semi-analyzed requirements which are ready to be developed. Also, these requirements should be fully characterized in terms of customer priority, marketing impact, and technical risk, and any other requirement property that the organization sees important for planning. These requirements are backlogged till the team (customer and development) is ready to work on them.

Next, once a new project is to start, several requirements are pulled out of this backlog and they start getting developed. The strategy of selection depends largely on the business priority, and the technical risk. In other situations, it may depend on other requirement attributes, like the size, stability, et cetera.

What I have described so far is all analysis work that should not be considered part of a software project, and in the meanwhile, it constitutes about 60% of the analysis work.

On the other hand, there is still some analysis work that should be done on the project. This work is done by the developers who are going to work on design and development of the requirement. They should work face-to-face with the customer or may be a subject matter expert to dig into the details of the business, They should also make some prototyping and simulation to verify that the non-functional requirements will be met.

In all cases, they need to develop an iteration, deliver to the customer, and recieve feedback. This is all part of the analysis effort. See this post for more details.

Sunday, July 13, 2008

Regression bugs, are they really a sign for bad quality, or for innovation and improvement?

The definition for a regression bug may vary from one organization to another. In this blog, I will use the definition of the regression bug as appears in the Wikipedia:
“Regression bugs occur whenever software functionality that previously worked as desired, stops working or no longer works in the same way that was previously planned. Typically regression bugs occur as an unintended consequence of program changes”
In all organizations that I worked for, a regression bug is a big scandal. KPI's are set to count number of regression bugs for every developer, and for every component or business area. There may be another grouping level to categorize regression bugs before and after deployment. While we should acknowledge that a regression bug gives a very bad impression about the development team and the product quality, we should also ask several questions:
  • In which context was this bug opened? Was this a refactoring effort for improving the code? Or was it a side effect of normal day to day development?
Rod Johnson, in one of his excellent lectures: "Why J2EE Projects Fail", identified 10 reasons why projects fail. One of these was not being open for refactoring and change. If regression bugs are due to improvement, or refactoring effort that is done to enhance to code, then, this bug should not be counted against the development team.

Counting such bugs against the development team, and evaluating them accordingly, will effectively kill the open atmosphere for change. If the project old code is never touched, and the team is intimidated not to do so, then the product code will deteriorate over time, the level of complexity will rise, simple bugs will become complex, and complex bugs will become sever. At one point of time, maintaining the product will cost so high and customers will search for other solutions.

Ok, what should be the solution? Here is the key:
  • Never do a refactoring for a component except after writing automated unit tests for the component functionality. This is like writing a contact with the code. If the code does not keep this contract, simply do not deploy the code. For a simple guide for stages of refactoring legacy code, refer to my later blog: Measuring the Progress of Code Refactoring.
  • Write automated test scripts for old bugs. Bugs show a tendency to be reproduced. The reason is that developers think the same way. If a component is refactored or re-written, the bug that the first developer fixed sometime ago and never wrote a test script for it; this bug surely will be reproduced by the developer who is refactoring or re-writing the component.