En Scrum, ¿debemos facturarnos por defectos y actividades no planificadas?

TL;RD

Sí. Según su contrato actual y dentro de su proceso actual, debe pagarle al proveedor por todo el trabajo completado. A menos que tenga un contrato de alcance fijo y precio fijo, todos los problemas que ha descrito son problemas de proceso de los que su empresa (y no el proveedor) es responsable.

Tiene dificultades porque está tratando a la empresa offshore como un proveedor externo, en lugar de colaborar activamente con ellos durante cada iteración. El Manifiesto Ágil valora:

Colaboración con el cliente sobre la negociación del contrato[.]

Ambos problemas se pueden resolver mediante una mejor colaboración ágil. Mientras tanto, como cuestión puramente pragmática, probablemente debería pagar las facturas si desea continuar utilizando esta empresa como proveedor. Trátelo como un costo irrecuperable y mejore su proceso a medida que avanza.

Alcance y entregables de Scrum

Según la siguiente declaración, no está aprovechando el marco Scrum en su proceso actual. Usted pregunta:

¿Deberíamos pagar por cosas no planificadas que no son parte de nuestros requisitos ni son una solicitud de cambio de nuestra parte (es decir, la implementación en el servidor de prueba no funciona, la actualización de la base de código para admitir la versión más reciente de iOS, etc.)?

Esta pregunta destaca varios problemas con su proceso actual, que incluyen:

1. Su empresa debe proporcionar el Propietario del producto para el proceso o colaborar activamente como parte interesada a través de un Propietario del producto del lado del proveedor.
2. Su mención de "trabajo no planificado" indica que los elementos de la cartera de productos no se están descomponiendo y planificando correctamente al comienzo de cada iteración.
3. El hecho de no esperar lo inesperado, especialmente en TI, viola el principio ágil central de aceptar el cambio y, en general, indica una falta de planificación iterativa y de holgura suficiente en su proceso.
4. La mención de "requisitos" y "solicitudes de cambio" indica una mentalidad organizacional centrada en la especificación inicial en lugar de un desarrollo verdaderamente iterativo o colaborativo.

Para solucionar este tipo de problemas, lo más probable es que necesite un cambio fundamental en la forma en que trabaja con su proveedor. Como mínimo:

1. Debe haber un rol de propietario del producto claramente definido, y tanto las partes interesadas como el equipo de desarrollo deben colaborar activamente con el propietario del producto para administrar el alcance y priorizar los entregables.
2. El trabajo de cada iteración debe tomarse de una lista priorizada de elementos de trabajo (el Product Backlog) y descomponerse en tareas para el Sprint Backlog. Esta planificación justo a tiempo es esencial para determinar el alcance e identificar correctamente el trabajo conocido (pero potencialmente no planificado) que tendrá un impacto en la iteración actual.
3. Su proceso debe contener suficiente holgura para manejar una cantidad razonable de incertidumbre. El desarrollo de TI es una ciencia inexacta, y esperar un 100 % de certeza o un 100 % de utilización no le servirá de mucho en su planificación. Un proceso de Scrum inmaduro generalmente debe apuntar solo a alrededor del 60% de la capacidad del equipo para manejar las vicisitudes del desarrollo de software.
4. El proceso debe comenzar a tratar los elementos de la cartera de productos y la cartera de productos como una conversación continua entre las partes interesadas y el equipo de desarrollo. El backlog no es una lista de especificaciones fijas; cada elemento del backlog es un punto de partida para la planificación iterativa y el desarrollo colaborativo.

Pruebas, defectos y la definición de hecho

No puedes esperar que nadie alcance un objetivo en movimiento. Cuando tu dices:

Después de las pruebas de aceptación del usuario, ¿deberíamos pagar para que el equipo de desarrollo corrija los defectos que encontramos en las funciones que entregaron como completas?

implícitamente está diciendo que se reserva el derecho de mover la línea de meta después de haber acordado la Definición de Terminado para un incremento de trabajo. ¡No hagas eso!

La pregunta muestra que hay una falta de desarrollo de prueba primero en el proceso actual, y que usted y el proveedor no están colaborando activamente en la definición de Listo para los elementos de la cartera de productos. Para resolver esto, el proceso debe cambiar de pruebas subjetivas post facto a criterios objetivos (e idealmente ejecutables) para medir el éxito.

Para abordar las brechas en el proceso actual, considere cuidadosamente lo siguiente:

1. Colabore con su equipo de desarrollo en los criterios de prueba de aceptación antes de realizar cualquier desarrollo. Esto asegura que todos estén de acuerdo en una definición objetiva de "potencialmente entregable" para el incremento.
2. El trabajo que no cumple con los criterios acordados no es defectuoso; simplemente "no está hecho".
3. Si tiene mucho trabajo que termina "sin terminar" al final de cada Sprint, este es un material de mejora de procesos ideal para discutir en su Retrospectiva.
4. Si el trabajo cumple con los criterios acordados, pero necesita refinamientos o cambios, entonces este es un trabajo futuro que pertenece a Product Backlog para su priorización y planificación. Ser imperfecto no es un defecto ; es un estado de transición para diseños emergentes dentro de un proceso de desarrollo iterativo.
5. Incluso si descubre después del hecho de que todos estuvieron de acuerdo con los criterios incorrectos, todavía era el incremento de trabajo acordado desde el principio. El equipo de desarrollo no debe ser penalizado porque las partes interesadas y el propietario del producto les pidieron que construyeran algo incorrecto.

¡ Inspeccione y adapte iterativamente !

Sin duda, hay otros problemas con el proceso actual que también deben abordarse. Asegúrese de que usted y el proveedor colaboren en una retrospectiva conjunta y trabajen juntos en cada iteración para inspeccionar y adaptar continuamente su proceso hasta que funcione mejor para ambos.

¡Recuerde que "suavemente" no significa perfecto! Simplemente significa que el proceso general opera dentro de las tolerancias definidas y que los controles de gestión del proyecto funcionan como se esperaba.

La respuesta a esta pregunta no tiene nada que ver con Scrum o cualquier otro tipo de método de desarrollo. Es un tema contractual. Una tarifa fija por individuo más una lista de tareas es un acuerdo de tiempo y materiales. Eso significa que cada hora quemada contra una tarea para su producto es su responsabilidad. Sin embargo, también significa que debe involucrarse diariamente en esas tareas en lugar de sorprenderse en el momento de la facturación. Usted tiene un asiento en la mesa con respecto a qué tareas debe realizar y por quién porque está pagando por ello. Si no le gusta este tipo de riesgo, establezca un contrato de precio fijo la próxima vez. Sin embargo, con un precio fijo, puede esperar que se le cobre en el lado más alto del rango para cubrir sus riesgos de lo desconocido.

EDITAR para responder a la pregunta en los comentarios:

1. UAT es parte del SDLC. Es parte del desarrollo del producto como una mitigación del riesgo de calidad para ayudar a mejorar el producto antes de su puesta en marcha. Intentar crear un escenario en el que el proveedor deba pagar la responsabilidad por un defecto creará un comportamiento que no es coherente con el objetivo de mejorar la calidad. El proveedor se defenderá contra la identificación de defectos y usted gastará mucho tiempo, y dinero, tratando de que se reconozca un defecto y se solucione. Además, puede esperar que el proveedor se tome mucho más tiempo, y le cobre mucho más dinero, para construir el producto antes de UAT para reducir el riesgo de penalización.
2. Las incógnitas conocidas y las incógnitas desconocidas son una certeza en los proyectos. Quién responde por ellos es una cuestión contractual. Si no quiere pagar por cada sorpresa, busque un contrato fijo; pero no se engañe, pagará estas sorpresas en el precio fijo de alguna manera. Si, bajo un T&M, intenta imponer la responsabilidad de estas sorpresas al proveedor, entonces puede esperar que el proveedor se proteja 1) no informando el problema, 2) enfocando la culpa en otras causas, 3) desviando su mejor talento a otro trabajo más rentable y comprometer talento mediocre a su proyecto, 4) aumentar las tarifas de horas en el próximo período de negociaciones, o una combinación de estos.

Creo que desea buscar una asociación con sus proveedores para obtener una solución beneficiosa para todos. Protegerse por un lado puede significar que lo va a pagar muy caro por el otro lado.

Sí, desea que estas cosas sucedan, por lo tanto, debe estar feliz de pagar por ellas.

Al pagar por tiempo en lugar de funciones, se está liberando de la carga de tener que especificar cada pequeño detalle de lo que quiere que se haga y aliviando a los demás de la carga de tener que estimar y cada función incluye un presupuesto para sobrecostos inesperados. En general, debería terminar siendo más barato.