Roles Scrum en Profundidad. ScrumMaster, Product Owner, Team

Transcripción

1 Roles Scrum en Profundidad ScrumMaster, Product Owner, Team

2 Interdependencia entre Roles El verdadero proyecto lo llevan el Product Owner y el Team, mientras que el Scrum Master facilita la interacción. PO: representante de los intereses de los stakeholders (customers). Responsable de definir funcionalidades para entregar valor de negocio y priorizarlas. T: equipo de desarrollo y testing autosuficiente técnicamente. Responsables de implementar funcionalidades y de todas las decisiones técnicas. SM, responsable de cuidar que la comunicación entre estos ocurra fluidamente. Las Reglas Scrum son las que producen que el proyecto avance. Seguir las reglas es la misión del SM.

3 Adoptando la Filosofía Scrum Uno de los elementos más difíciles de adoptar en una empresa es el cambio de paradigma: El Jefe de Proyectos ya no es el jefe, es el ayudante o facilitador. El Equipo ya no recibe órdenes de un jefe, tiene autonomía y responsabilidad directa. El Dueño del Producto tiene vías claras y definidas para opinar y entregar su input y no tiene línea abierta 100%, mientras que es responsable por aclarar sus puntos y participar activamente en la comunicación. Clave: la colaboración entre Team y Product Owner.

4 Ejemplos y enfoques Aplicando la filosofía Scrum en el trabajo diario de: Scrum Master Product Owner Team La realidad de las empresas y los aspectos de la cultura organizacional, así como los paradigmas más tradicionales. Ejemplos provenientes de Agile Project Management with Scrum, de Ken Schwaber.

5 ScrumMaster Caso 1: ScrumMaster inexperto en Trey Research. Reunión Daily Scrum: El SM fue al sector de cubículos y fue uno por uno preguntando. Las preguntas: Hiciste ayer lo que te pedí? Estás listo para empezar lo definido para hoy? Cuáles fueron los problemas en este caso?

6 ScrumMaster Caso 2: ScrumMaster inexperto en Litware Empresa desarrollo productos de software con varios ingenieros y enfoque cascada. Se decidió adoptar Scrum y designar al gte. proyectos, John Chen, como ScrumMaster. El SM no asistió siempre al curso de certificación al que fue invitado. El día de planning definido, envío en su reemplazo a su segundo, con excusa de compromisos importantes. John Chen fue reemplazado por su segundo en rol SM. Cuáles fueron los problemas en este caso?

7 ScrumMaster Caso 3: SM Aprensivo en Contoso.com Empresa con proyectos de portales, decidió varios proyectos con Scrum y SM externo (consultor). Se definieron planes y fechas. La fecha de una reunión importante se interrumpió por orden gerencial, organizando un picnic corporativo para mejorar el espíritu de equipo del personal. El SM reclamó enérgicamente la importancia de no cambiar el plan y la necesidad de las reuniones. Finalmente, el directorio decidió liberar al ScrumMaster de su labor. Más importante la reunión o el espíritu de equipo?

8 ScrumMaster Caso 4: Lobos en MegaFund Empresa administradora de fondos para proyectos. Necesidad de conectar a sistemas legacy, proyecto se alargó y trancó a los 9 meses. Se adoptó Scrum para resolver obstáculos. El JP se adaptó al rol SM y manejó reuniones correctamente. Uno de los directores, orgulloso del avance con el nuevo esquema, vio la oportunidad con un cliente de hacer una demo de una funcionalidad particular. Fue donde uno de los ingenieros, quien no pudo decir que no al incluirla en el Sprint. Al sig. Daily Scrum saltó a la vista que el ing. trabajaba en algo diferente a lo definido. Se habló con el director haciéndole ver la importancia de la filosofía. Lo pensó y decidió que no era tan importante para alterar el Sprint.

9 Product Owner Desafíos: Ser claro y participar en la comunicación con lenguaje uniforme (compartido entre todos). Estar integrado al equipo. Ser responsable de sus decisiones: definición de funcionalidades y priorizarlas. Participar en los eventos de Scrum en forma correcta (Sprint Planning, Daily Scrum, Sprint Review). Estar disponible para consultas.

10 Product Owner Caso 1: Involucrar a la gerencia en Service1st. Fundada por dos dueños, tenían enfoque directo al cliente cuando partieron. Con crecimiento, se adoptó formalidad y estructura (Gantts, reportes, documentos). Se adoptó Scrum y los 7 grupos planificaron Sprints para terminar el mismo día. Se prepararon las 7 presentaciones conjuntas en área de QA. Cada Team mostró el resultado de sus proyectos en un corto y preciso tiempo. La gerencia observó, opinó, participó de cada uno de los proyectos, opinando directamente y conversando con los miembros de los diferentes Teams. Qué se había perdido en el crecimiento de la compañía?

11 Product Owner Caso 2: Recuperando XFlow en MegaFund XFlow producto Workflow creado a partir de un código licenciado, usado internamente y luego vendido con sus otros productos. Con el tiempo, el grupo de venta, los usuarios internos, y desarrollo se disociaron y XFlow empezó a perder su valor interno y de venta. Se organizó una reunión para conciliar visiones. Llevaban 1 año sin juntarse usuarios internos, comercial y desarrollo. Desarrollo presentó la última versión con sus funcionalidades. Clientes internos plantearon uno por uno sus necesidades y se analizó en una pizarra la intersección. Luego se presentó el plan de mejoras, también comparándolo, luego ordenando y conciliando éstas con las necesidades y se pidió un mes de paciencia. Al final del mes, se presentaron las funcionalidades desarrolladas (algunas completas y otras faltaron), pero los clientes internos vieron que había valor de negocio entregado para necesidades internas y una versión totalmente vendible. Cuáles fueron las claves en este caso para lograr entregar valor de negocio?

12 Product Owner Caso 3: Metas de TechCore Desarrollador hardware de comunicación, con varios PhD del MIT. El dueño aún quería hacerlo todo, por su conocimiento del negocio y de la tecnología. Logró definir un Prod. Backlog, focalizando energía en lo más importante para el próx. mes. Daily Scrums permitieron descubrir que en el proceso de fabricación, se perdía tiempo en cadena de adquisición de componentes (tiempo perdido de los ingenieros más valiosos). Se contrataron ingenieros junior para la adquisición y así se focalizó la atención. Se ordenaron los Daily Scrums y en particular los Spring Meetings y así, el dueño pudo participar en todos ellos, aportando directamente sus conocimientos y visión del negocio. Cuál(es) fue(ron) la(s) clave(s) para lograr destrabar el proceso?

13 Team Desafíos: Self-Manage. Lograr pasar de un esquema dirigido a un esquema autónomo. Dimensionar tareas correctamente. Pedir lo que se requiere para completar las funcionalidades. Entregar funcionalidades limpias en 30 días. Daily Scrum es entre ellos y no reportando a un jefe.(inexistente), Adoptar buenas prácticas de desarrollo (típicamente XP).

14 Team Caso 1: Formando equipo en Service1st. Se propusieron cambios en espacio físico y de personas. Algunos se siguieron. En Daily Scrum se detectó que el Team no indicaba tener problemas y que al responder las 3 preguntas miraban al Scrum Master (antes un JP). Se les pidió que al reportar, miraran al resto del Team y obviaran al SM y otros. Qué les faltaba a los miembros del Team?

15 Team Caso 2: Mejor Ingeniería en Service1st En un Daily Scrum un miembro pidió ayuda para validar unas modificaciones a código fuente que no había hecho. Aunque había un Code Mgmt System, el código no había sido chequeado en varios días. Se explicó que al término del Sprint, todo código debería estar limpio (codificado, corregido y testeado, refactoreado y estandarizado). Se vio que comenzaban a limpiar aprox. día 23. Qué prácticas de XP se pueden aplicar exitosamente para este problema?

16 Team Caso 3: Aprendiendo auto-organización en Service 1st. Primer sprint: mucha funcionalidad comprometida que no alcanza a ser desarrollada. Se define Sprint Backlog y se estima al ojo el esfuerzo involucrado. En algunos Teams, el Sprint entrega funcionalidad sin limpiar rompen regla Scrum. En el segundo Sprint, el Team pasó más tiempo planificando en detalle. Qué prácticas de XP se pueden aplicar exitosamente para este problema?