In Scrum, should we be billed for defects and unplanned activities?

Question

My company is the client. An offshore company is developing our product. We pay them on a monthly basis. They send us an invoice with a fixed rate per full time resource. They also send us a breakdown of all tasks done by each resource.

1. Should we be paying for non-planned things that are neither a part of our requirements nor are a change request from our side (i.e. deployment to staging server not working, updating codebase to support newest iOS version, etc.)?

2. After user acceptance testing, should we be paying for the development team to fix defects we find in features they delivered as complete?

Please note our contract doesn't say anything about handling these issues.

Answer 1

TL;DR

Yes. Under your current contract and within your current process, you should pay the vendor for all work completed. Unless you have a fixed-price, fixed-scope contract, all the problems you've described are process issues for which your company (rather than the vendor) is responsible.

You are having difficulties because you are treating the offshore company as an external vendor, rather than actively collaborating with them during each iteration. The Agile Manifesto values:

Customer collaboration over contract negotiation[.]

Both problems are resolvable by better agile collaboration. In the meantime, as a purely pragmatic matter you should probably pay the invoices if you wish to continue using this company as a vendor. Treat it as a sunk cost and improve your process as you move forward.

Scrum Scoping and Deliverables

Based on the following statement, you aren't leveraging the Scrum framework in your current process. You ask:

Should we be paying for non-planned things that are neither a part of our requirements nor are a change request from our side (i.e. deployment to staging server not working, updating codebase to support newest iOS version, etc.)?

This question highlights several issues with your current process, including:

1. Your company should either be providing the Product Owner for the process, or actively collaborating as a stakeholder through a Product Owner on the vendor's side.
2. You mention of "unplanned work" indicates that Product Backlog Items are not being properly decomposed and planned out at the start of each iteration.
3. The failure to expect the unexpected, especially in IT, violates the core agile principle of embracing change, and generally indicates a lack of sufficient slack and iterative planning in your process.
4. The mention of "requirements" and "change requests" indicates an organizational mindset focused on upfront specification rather than truly iterative or collaborative development.

To fix these sorts of problems, you will most likely need a fundamental shift in how you work with your vendor. At a minimum:

1. There must be a clearly-defined Product Owner role, and both the stakeholders and the development team should actively collaborate with the Produc Owner to manage scope and prioritize deliverables.
2. The work for each iteration must be taken from a prioritized list of work items (the Product Backlog) and decomposed into tasks for the Sprint Backlog. This just-in-time planning is essential to proper scoping and identifying knowable (but potentially unplanned) work that will impact the current iteration.
3. Your process must contain sufficient slack to handle a reasonable amount of uncertainty. IT development is an inexact science, and expecting 100% certainty or 100% utilization will serve you very poorly in your planning. An immature Scrum process should generally target only around 60% of team capacity in order to handle the vicissitudes of software development.
4. The process must begin treating Product Backlog Items and the Product Backlog as an ongoing conversation between stakeholders and the development team. The backlog is not a list of fixed specifications; each item on the backlog is a starting point for iterative planning and collaborative development.

Testing, Defects, and the Definition of Done

You can't expect anyone to hit moving target. When you say:

After user acceptance testing, should we be paying for the development team to fix defects we find in features they delivered as complete?

you are implicitly saying that you reserve the right to move the finish line after you've already agreed on the Definition of Done for an increment of work. Don't do that!

The question shows that there is a lack of test-first development in the current process, and that you and the vendor are not actively collaborating on the Definition of Done for Product Backlog Items. In order to resolve this, the process must change from subjective, post facto testing to objective (and ideally executable) criteria for measuring success.

To address the gaps in the current process, carefully consider the following:

1. Collaborate with your development team on the acceptance testing criteria before they do any development. This ensures that everyone agrees on an objective definition of "potentially shippable" for the increment.
2. Work that doesn't meet the agreed-upon criteria isn't defective; it's simply "not done."
3. If you have a lot of work that ends up "not done" at the end of each Sprint, this is ideal process-improvement material to discuss in your Retrospective.
4. If work meets the agreed-upon criteria, but you need refinements or changes, then this is future work that belongs on the Product Backlog for prioritization and planning. Being imperfect is not a defect; it is a transitional state for emergent designs within an iterative development process.
5. Even if you find out after the fact that everyone agreed on the wrong criteria, it was still the increment of work agreed-upon at the outset. The development team shouldn't be penalized because the stakeholders and the Product Owner asked them to build the wrong thing.

Inspect and Adapt Iteratively!

There are certainly other issues with the current process that need to be addressed as well. Make sure that you and the vendor collaborate on a joint Retrospective, and work together every iteration to continuously inspect and adapt your process until it runs more smoothly for both of you.

Please remember that "smoothly" doesn't mean perfect! It just means that the overall process operates within defined tolerances, and that the project management controls perform as expected.

Answer 2

The answer to this question has nothing to do with Scrum or any other type of development method. It's a contractual issue. A fixed rate per individual plus a listing of tasks is a time and materials agreement. That means, every burned hour against a task to your product is your liability. However, it also means that you should be involved on a daily basis about those tasks instead of being surprised at invoice time. You have a seat at the table regarding what tasks should be performed and by whom because you are paying for it. If you don't like this type of risk, then establish a fixed price contract next time around. However, with a fixed price, you can expect to be charged on the higher side of the range in order to cover their risks of the unknowns.

EDIT to answer question in comments:

1. UAT is part of the SDLC. It is part of product development as a quality risk mitigation to help improve the product before go-live. To try to create a scenario where liability of a defect needs to get paid for by the vendor will create behavior that is inconsistent with the goal of improving quality. The vendor will defend itself against defect identification and you will spend a lot of time--and money--trying to get a defect acknowledged and worked on. Also, you can expect the vendor to take way more time--and charge you way more money--to build the product before UAT to reduce its risk of penalty.
2. Known unknowns and unknown unknowns are a certainty in projects. Who is liable for them is a contractual issue. If you don't want to pay for each surprise, then pursue a fixed contract; but don't fool yourself, you will pay for these surprises in the fixed price in some fashion. If, under a T&M, you try to push the liability of these surprises to the vendor, then you can expect the vendor to protect itself by 1) not reporting the issue, 2) focusing blame on other causes, 3) rerouting its best talent to other more profitable work and committing mediocre talent to your project, 4) increasing hours rates a the next period of negotiations, or a combination of these.

I think you want to pursue a partnership with your vendors for a win win solution. Protecting yourself on one side might mean you're going to pay dearly on the other side.

Answer 3

Yes, you want these things to happen, thus you should be happy to pay for them.

By paying for time rather than features you are relieving yourself of the burden of having to specify every little detail of the thing you want done and relieving them of the burden of having to estimate and each feature including a budget for unexpected overruns. Overall it should end up being cheaper.