Mis respuestas sobre Scrum (III)

En anteriores ocasiones (I y II) he dado en este blog respuesta a cuestiones que se me han planteado sobre Scrum. En los comentarios de uno de estos post anteriores un lector me ha dejado una serie de cuestiones que me parece interesante contestar en este post. Las cuestiones del lector aparecen en cursiva y mis respuestas a continuación. Espero que os resulten de interés y que mis repuesta habran la puerta a nuevas preguntas. También me gustaría que todo aquel que quiera aportar algo lo haga.

¿Se pueden realizar paralelamente multiples SCRUMs para multiples proyectos de desarrollo distintos?

Por supuesto. La situación ideal es un Scrum Master, un Producto Owner y un Equipo por proyecto. Esto no siempre es posible, sobre todo cuando un mismo equipo debe atender a varios proyectos. La táctica más empleada en este caso es acortar los sprints (a 10 días habiles habitualmente en lugar de los 20 días habiles comunmente empleados) y que el Scrum Master y el Producto Owner lo sean para todos los proyectos que el equipo aborda. Es importante recordar que durante un Sprint un equipo no debe encargarse más que de un proyecto, entendiendose como proyecto el conjunto de requisitos que forman parte de un mismo Producto Backlog.

¿Pueden ser los actores de un SCRUM parte de otros SCRUMs que se estén realizando al mismo tiempo?. ¿Que actores pueden ser parte de múltiples SCRUMs y que actores no?

La respuesta directa es NO. Pero como siempre no hay blancos y negros en esto. Igual que decía antes la relación correcta es un Product Owner, un Scrum Master, un Producto Backlog. A veces los proyectos no tienen entidad suficiente por si mismos y es necesario que el equipo trabaje en más de un proyecto. Esto se debe evitar en la medida de lo posible ya que cada vez que cualquier de los actores cambia del contexto de un proyecto a otro se produce inevitablemente una perdida de tiempo. Por esto mismo, para evitar perdidas de tiempo en cambios de contexto es importante que durante un Sprint el equipo este centrado solo en un proyecto, a lo sumo en dos.

Es viable en mi opinión, que el Product Owner y el Scrum Master alimenten y den servicio a más de un proyecto si los proyectos son de pequeña envergadura. Eso si lo que me parece dificilmente viable es que un equipo este trabajando en más de dos proyectos a la vez. La táctica ideal es establecer la duración del Sprint de manera que sea posible mantener al equipo centrado en un solo proyecto durante la duración del Sprint.

¿Hay un número minimo posible de personas para un SCRUM? sé que lo recomendable es 8 personas, pero ¿hay un minimo?, por ejemplo en un pequeño proyecto de desarrollo ¿podría haber una persona por cada rol?

Ocho personas es el número máximo, no el recomendable. Un rol clave en Scrum, es el Equipo. ¿Puede haber un equipo de menos de dos personas? Por definición no. Pero tampoco en esto sería yo estricto. Es posible tener un equipo de una sola persona si el proyecto es pequeño.

¿En el mismo caso de antes puede una persona cumplir mas de un rol en el SCRUM?

Si efectivamente, aunque no sea lo ideal, es posible que una persona cubra dos roles. La única incompatibilidad clara es que nunca el Product Owner sea parte del Equipo. El Product Owner debe ser el representante de los intereses del cliente en el proyecto. Los desarrolladores a menudo olvidamos en parte los intereses del cliente y perseguimos nuestros propios intereses: aprender tal o cual tecnologia, implementar tal o cual patrón, utlizar tal o cual herramienta de desarrollo… si bien los intereses de los desarrolladores son legitimos deben quedar siempre supeditados a los intereses del cliente y a lograr el mayor retorno de la inversión en el proyecto. También es cierto que, si un desarrollador tiene que priorizar que caractarísticas implementar, es posible que priorize las más interesantes de desarrollar, las más divertidas, en lugar de las que más valor aporten al cliente. Esto hace evidente que no es buena idea que quien guie el desarrollo desde el punto de vista de seleccionar y priorizar las características a implementar sea parte del equipo de desarrollo.

Lo comentado nos deja en la situación de que el rol ‘comodín’ en Scrum es el Scrum Master, que aunque repito no sea lo ideal, puede actuar como Product Owner o como miembro del equipo de desarrollo.

¿Debería el Product Owner ser de nivel jerárquico superior a los miembros del equipo? ¿Algun nivel recomendable?

Las jerarquias existen en la empresa, no hay duda, pero no son relevantes para Scrum. En Scrum todos los participantes son iguales en lo que al proyecto se refiere. Tienen diferentes responsabilidades si, pero todos juegan un papel de igual importancia. Dicho esto es cierto que contar con un Scrum Master que tenga peso dentro de la empresa puede ayudar a que sea más efectivo en su labor de eliminar impedimentos.

¿Debería ser el Product Owner o el Scrum Master del área informática (informático) necesariamente?

No. A la hora de elegir al Producto Owner lo más importante es que sea capaz de representar los intereses del cliente, que conozca el producto que se quiere construir y las prioridades del cliente. Es importante que sepa determinar, expresar y priorizar los requisitos.

El Scrum Master debe ser un buen jefe de producto y sobre todo debe conocer Scrum a fondo. La principal carácteristica que debe presentar es la capacidad de formar y guiar equipos, debe ser un excelente mediador y un gran facilitador.

¿Debería ser el Product Owner del área usuaria?

Es lo ideal. El Product Owner debe ser la voz del cliente en el proyecto y debe ser capaz de conciliar los intereses de todos los stakeholders del proyecto. Se hace evidente que un Product Owner que pertenezca área usuaria, entendida como la parte de la empresa que usará el software desarrollado es una excelente oportunidad.

¿En la empresa donde yo trabajo se desarrollan o corrigen partes o modulos del sistema que utiliza la compañía, estos nacen de un requerimiento del área usuaria, pasan por el área de desarrollo de la Compañía quien evalua el requerimiento y encarga la programación a una empresa de outsourcing. ¿Estoy frente a los posibles actores de un SCRUM?

Sin duda, cada vez más empresas utilizan Scrum en la gestión de proyectos para los que externalizan el desarrollo. En mi opinión tener el equipo de desarrollo fuera de tu empresa siempre es un riesgo importante para el proyecto, pero sin duda es posible usar Scrum en esta situación.

¿Dónde queda la etapa de certificación de un SCRUM? ¿Esta es iterativa como todo lo demás? ¿O solo se certifica al final? ¿En el caso de la certificación los actores cambian? ¿Por ejemplo el área usuaria pasa a formar parte del team?

Efectivamente la aproximación es iterativa. Al final de cada Sprint debemos tener ‘un incremento de funcionalidad potencialmente entregable’. Si para poder entregar nuestro software tenemos que certificarlo (entiendo que pasandolo por un departamente de calidad) este proceso se debe hacer antes de poder considerar un Product Backlog Item (un  requisito) como completado, por lo tanto la certificación es algo que debe hacerse como parte del Sprint.

Es cierto que en ocasiones, cuando se usan entidades certificadores externas o departamentos de calidad externos al equipo de desarrollo a veces se certifican release en lugar de lo entragado en cada Sprint. Es decir se pasa a certificación o verificación en producto de varios Sprints y el proceso se realiza de manera paralela al desarrollo de nueva funcionalidad.

Tambien ocurre que a menudo se utilizan las dos aproximaciones de manera combinada. Un tester o varios forman parte del equipo Scrum y verifican lo implementado en cada Sprint de manera paralela al desarrollo y luego una entidad o equipo de calidad externo verifica releases (lo desarrollado como resultado de varios sprints) en especial equellas que se van a pasar a producción o entregar al cliente.

¿Qué pasa con las reuniones y organización de éstas en periodos donde la gente sale de vacaciones y no puede estar en toda la secuencia? Se debe detener el proyecto?

Generalmente, no hay problema para conciliar las vacaciones con el desarrollo. Si todo el equipo de desarrollo va a estar de vacaciones durante un periodo largo (tipo vacaciones de verano) , simplemente no habrá Sprint en ese perido. Si lo que ocurre es que algunos de los miembros de equipo no va a estar algunos días no hay problema, al calcular la capacidad del equipo para el Sprint se tendrán en cuenta estas ausencias. Si quien falta es el Producto Owner, será el Scrum Master quien ocupe su puesto. Si es el Scrum Master quien falta, será, típicamente algún miembro del equipo de desarrollo quien ocupe su lugar.

Scrum nunca se detiene porque falte alguno de los implicados en el proyecto.