Reduce amount of required hotfixes without technical knowledge

Question

I'm a software developer who suffers from the regular hotfixes that are required to an application I've developed.

The application I've developed didn't had many infrastructure requirements from the start but over time those requirements became more and more. This is only one part of the problem because when such an new requirement comes it is expected for me to make a hotfix outside of other planed work. Because the project managers already promised a working application.

I want to reduce the amount of hotfixes I have to make, as this would let me concentrate on the task I'm currently working on and the project managers won't have to apologize when the product isn't working from the start.

Most of those infrastructure requirements have to do with authentication and authorization (active directory, support cross domain, impersonation, etc.).

I think neither the product owner nor the project managers nor I know enough about the technical specifics to build a requirement catalog from the start.

The product is developed with Scrum as the project management ideology. (I'm also part of other Scrum Teams.)

How can a small business without this knowledge prevent such hotfixes?

I know that not promising a working solution and having reserved time for tests and corrections would solve this. But is there another way this could be prevented? Or should I try to have a talk to the project managers and try to change their way?

Answer 1

If I've understood you correctly your goal is to have a more steady development experience. Less "drop everything and get X to work".

Your problem stems from several factors:

• Customers are promised your product can do something it cannot
• You (personally and the company) don't know well enough what requirements are expected
• You sales people or managers are not willing to wait for these features
• You are not shielded from these shortcomings to a sufficient degree

What would help?

• Acquire the necessary domain knowledge. Either through a developer, product manager, power users or if necessary consultants. Having someone who knows what kind of expectations your product will face would allow you to work on these features preemtively.
• Stop sales from claiming your product already does everything. This is very difficult because right now what they are doing is working just fine from their perspective. You either have to convince them that not doing so is better of have someone with enough political clout put his foot down for you.
• Get sales people and your PO to build a stronger partnership with your customers and to better understand their needs. Transition to a more open approach where you are honest about what your product can do right now and how long it will likely take to add any given addition.
• Get your PO, SC and yourself to put your foot down against these rush jobs. You said you're doing Scrum. You don't do rush jobs in Scrum. This is risky as refusing to do these tasks on the side might cost you your job if your organization is not comitted to doing Scrum. And from everything I've read they don't seem to be. You might be able to negotiate this "freedom" by offering shorter sprints (ie. less waiting before a new task gets picked up) Your ability to offer shorter sprints is however limited by how long you as apparently a single developer needs for any given feature. One alternative would be to abandon Scrum and do Kanban instead. You have ONE active task that you are working on until it is done. Then you do whatever they think is the next most important task.
• Quit or get moved to a different product. It seems like you are a single developer working only part of the time on this product. This would indicate that there's not a lot of investment into the product and the company treats it with the attitude "get as much money out of this thing as you can with minimal effort." If so that's not a position you want to be in long term

Answer 2

I know you say you're following Scrum, but are you doing so by the book?

• Are you creating a potentially releasable product at the end of every Sprint?
• Are you reviewing the product with the stakeholders at the end of every Sprint during the Sprint Review meeting?
• Are you incorporating feedback you receive in the Review into the product?

If not, that would, I think, be a good place to start.