S'true

In product development in fairly large organizations, there are often rather strict development processes, which sometimes have to be worked around. All such Process Workarounds are evidence of a process that doesn’t fit the organization.

Let me give an example. How many times have you heard this conversation?

Project manager
- May 5th is our feature complete deadline, after that we won't change or create any new features.

Developers
- All right, then we'll do nothing than fixing bugs prep the release after that

Project manager
- Oh, but we still have a couple of changes to the functionality after that

Developers
- But didn't you just say we mustn't develop on features?

Project manager
- Oh yeah, let's file that as a bug!

Developers
- ...

The reason for the feature complete deadline is a common one in waterfall organizations; there is a lot of fear in the organization about (the previously promised) deadlines and thus the project manager has to promise to his/her steering committee that there won't be any changes to the current feature set. This self-imposed limit to the feature set is then worked around by filing changes as bugs.

In this situation I can fully understand the need to have deadlines; it’s very demanding to come to the lean development process where there is flow between the producer and the consumer of a module. However, it’s the workaround that bothers me. Either the change is performed, or it isn’t.

To the developers in this situation, my only advice is to learn to say No. When a process workaround is performed, it’s done by people, and people are the ones who can stop it.

To any project manager in this situation, my advice is to reflect on the why's of filing this as a bug, and the consequences. If you really need the changed feature, you definitely need to be able to sell the change to the steering committee. If you can't do this, the feature should probably not be implemented. Additionally, by filing the feature as a bug, you poison the defect rate measurements.