Adrian Carr escribió acerca de la adaptación de la implementación de Scrum de su equipo después de renuncias. Originalmente, el equipo era un grupo de cuatro desarrolladores, un tester, un Dueño del Producto y el Scrum Master. Después de los recortes, el equipo se redujo a cuatro miembros con Adrian como Scrum Master en medio plazo y ningún Dueño de Producto dedicado. La unidad de negocio tuvo el mismo problema de personal que el grupo de desarrollo y, por tanto, fue capaz de proporcionar sólo un "punto de contacto senior que entiende el negocio y está autorizado a tomar decisiones sobre el proyecto." Así que la pregunta que se hizo él fue: ¿Qué partes de Scrum se deberían mantener? El primer intento de Adrian incluyó:
- Conservar sólo las partes de scrum que tienen sentido en un grupo más pequeño: las reuniones a pie diarias, sprints cortos, revisiones, retrospectivas, burndowns visibles.
- Todos en el equipo hacen parte del papel de Dueño del Producto reuniendose con los clientes, usuarios finales, etc, pero Adrián mantiene el Product Backlog y toma las decisiones finales etc
- Eliminar los desperdicios.
- Mantener las cosas lo más simple posible.
- Acreditar sólo los puntos de historias para las funcionalidades colocadas en producción, la expectativa es que esto obligaría al equipo a crear funcionalidades más pequeñas y más manejables. Esto debería conducir a una reducción en el tiempo de las iteraciones y generar más feedback.
- Trabajo bloques muy pequeños de trabajo - sólo dos o tres elementos a la vez.
- Enfocar la entrega de ítems de mayor valor primero.
- Conocer para quien el software se esta desarrollando. Conocer sus nombres, sus funciones y por qué hacían lo que hacen.
- Vigilar los factores externos que frenan al equipo y los saca del camino.
Robin Dymond, de Innovel, tiene una gran preocupación: la ausencia de un Dueño de Producto dedicado. Él dice que para que un desarrollador cumpla esa función tendrá que ser un experto en el negocio, reduciendo el tiempo que tiene para desarrollar. En cambio, recomienda:
Si el personal de negocios está presionado por el tiempo, entonces el equipo de desarrollo puede hacer reuniones pequeñas y frecuentes con ellos, ellos pueden aprobar los criterios de aceptación en lugar de escribir, y pueden centrarse en las prioridades. Sin embargo, ellos necesitan estar en su papel, y asumir la responsabilidad. El equipo no puede hacer esto por ellos, porque el equipo irá inevitablemente a interpretar las cosas de manera diferente, escogiendo prioridades diferentes y tomando decisiones diferentes de las que el personal de negocio tomaría.
En una opinión de Mary Poppendieck (autor de Implementing Lean Software Development (implementando desarrollo de software Lean)), el Dueño del Producto no siempre es necesario o incluso deseable, ya que ella considera que los desarrolladores entienden lo que el cliente quiere y el Dueño del Producto añade una nueva capa y es probable que haya información perdida debido a intermediarios. Para Mary, la clave es tener una medida buena y simple en la cual todos esten de acuerdo con el objetivo, entonces, todas las funcionalidades pueden ser medidas contra el valor entregado a tal objetivo.
Ron Jeffries advierte acerca de la posible falta de claridad entre el equipo, como Dueños del Producto, y la Unidad de Negocio. Si el producto acaba no siendo exactamente lo que el cliente necesita, la unidad probablemente culpará al equipo de desarrollo por sus decisiones. Ron apunta que una de las ventajas de la función del Dueño del Producto / Cliente tradicional es que la unidad de negocios no tiene a quien culpar, además de ellos mismos, si el producto no alcanza las expectativas de los usuarios finales.
