Archivo de la categoría: Scrum

Reimplementando Scrum

Duke Trabajando
Duke Trabajando

Hace ya 2 meses que cambié de trabajo.

Hasta ahora los posts relacionados a la implementación de Scrum en este blog habían sido siempre en la misma empresa. El cambio de trabajo debe ser uno de los momentos en que queda más evidente la utilidad de haber hecho este blog plasmando mis experiencias con Scrum.

Si bien no escribí tanto como me hubiera gustado desde mayo cuando empecé el blog, hay muchas cosas útiles que vi en su momento, que aprendí, que apliqué, que me pueden servir hoy en el nuevo trabajo. Links, recursos, artículos y demás. Si bien no ha sido tanto como esperaba, algo se ha ido guardando.

En este nuevo trabajo estamos por empezar una nueva implementación de Scrum. Por lo tanto, a partir de ahora, reimplemento Scrum.

Una de las ventajas es que trabajo con otro Scrum Master certificado. Ya han habido ideas de Scrum y agilidad en la empresa, pero aparentemente no se ha llegado a hacer una implementación completa.

Prometo en esta nueva instancia de implementación de Scrum, comentar más experiencias en el blog.

La esencia de Scrum – Tobias Mayer

Esta es una definición muy buena de lo que hace a la esencia de Scrum. Está escrita por Tobias Mayer y traducida al español por Angel «Java» Lopez:

Scrum comenzó su vida como uno de las nuevas formas Agiles para construir software. En estos días, se lo considera una forma que puede ser usada para mejorar el mundo del trabajo, en un sentido más general, y así, cambiar la forma en que los individuos piensan e interactúan con otros en situaciones de trabajo. El potencial completo de Scrum está por explorar.

En resumen, Scrum es una manera simple de manejar problemas complejos, proveyendo un marco de trabajo para soportar la innovación y permitir que equipos auto-organizados entreguen resultados de alta calidad en tiempos cortos. Scrum es un estado de la mente; en una manera de pensar que libera el espíritu creativo mientras se mantiene firmemente apoyado en principio sólidos y largamente respetados, incluyendo el empirismo, la emergencia y la auto-organización.

Empirismo se refiere al proceso continuo de inspeccionar/adaptar que permite que tanto trabajadores como gerentes tomen decisiones en tiempo real, basado en datos actuales, y como resultado, puedan responder rápidamente a  condiciones siempre cambiantes que se presentan en el ambiente, como por ejemplo, el mercado donde el software a construir es vendido o distribuido.

La Emergencia surge de una aproximación empírica. Implica que todas las soluciones a todos los problemas se volverán claros a medida que trabajamos. No se volverán claros si simplemente hablamos de ellos. El “Big Up Front Design” (gran diseño de antemano) sólo producirá un “Big Wrong Design” (gran diseño erróneo) o a lo sumo un “Big Working But Totally Inflexible Design” (gran diseño que funciona pero totalmente inflexible). Cuando permitimos que las soluciones emerjan es siempre la solución más simple y apropiada, para el contexto actual, la que sube a la superficie. La emergencia junto con el empirismos nos guiaran a la solución más apropiada y flexible (es decir, que podemos cambiar).

Auto-organización se refiere a la estructura de los equipos que crean el producto. Se les da poder a pequeños equipos multidisciplinarios para que puedan tomar decisiones importantes, necesarias para 1) crear un producto de alta calidad, y 2) manejar su propio proceso. Acá la idea es que aquellos que hacen el trabajo conocen mejor que nadie cómo hacer el trabajo. Estos equipos trabajan de una manera altamente interactiva y generativa, donde el producto emerge del diálogo continuo, de la exploración e iteración. La auto-organización funciona cuando hay objetivos y límites claros.

Además de estos principios, Scrum se apoya en dos mecanismos principales: priorización y “timeboxing” (poner límites de tiempo a una tarea).

Priorización simplemente significa que hay cosas que son más importantes que otras. Esto es tan obvio que se olvida muchas veces cuando pensamos “necesitamos esto AHORA”. Scrum nos ayuda a poner el foco de vuelta en seleccionar cuáles son las cosas más importantes a hacer primero, y entonces, a hacerlas! Tomándose el tiempo para priorizar, y siendo rigurosos sobre eso, es esencial para el éxito de Scrum.

Timeboxing es un mecanismo simple para manejar la complejidad. No podemos imaginar el slistema completo de una vez, todo junto, entonces, tomamos un pequeño problema y en un corto espacio de tiempo, digamos una semana o un mes, trabajamos en solucionar ese problema. Los resultados de esa acción nos guiaran entonces a una solución para el próximo problema, más grande, y nos dará más conocimiento sobre las necesidades del sistema en conjunto.

Cambio organizacional

Con Scrum, las jerarquías de gerencia de las organizaciones tienden a ser niveladas y los equipos de desarrollo tienen más contacto directo e inmediato con los clientes. El ambiente de trabajo se vuelve menos “comandar-y-controlar” hacia un estilo más colaborativo. Se promueve el diálogo regular y abierto sobre la documentación extensiva, y el acuerdo negociado es preferido a los contratos de trabajo formales e impersonales.

Las cualidades de apertura, honestidad y coraje son fomentadas en todos los niveles, y la ganancia individual se vuelve secundaria ante el avance colectivo. Un ambiente Scrum es uno que soporta a la gente, donde las personas de todos los niveles muestran respeto y confianza entre ellos. Las decisiones se toman por consenso, más que por imposición de alguien de más arriba, y todo el conocimiento es compartido, de una manera transparente y sin recelos.

Scrum va en contra de lo que hacen muchas compañías de la industria del software, donde una forma en fases acoplada con un alto grado de micro-gerenciamiento, y una insistencia en procesos definidos y documentación extensiva, se han hecho la norma por treinta años. Muchas compañías se basan en el miedo y el dinero como motivaciones claves para sus trabajadores. Esta forma de trabajo ha mostrado éxitos a corto plazo, pero más y más compañías están comenzando a entender que no es una buena estrategia para el largo palzo. Sin embargo, el concepto de cambiar a algo tan radical como Scrum aterroriza a muchos corazones de ejecutivos y gerentes de nivel medio.

Scrum está aún en la etapa de los “early-adopter” (los que abrazan tempranamente las nuevas ideas). Tomará muchos años para que la mayoría de las compañías reconozcan los beneficios de crear más lugares de trabajo, llenos de confianza. Sin ese cambio, muchas compañías de software se irán hundiendo bajo el peso de sus procesos pesados, y fuerzas de trabajo sobrecargadas. Otros, aquellos que abracen el método liviano, ágil, de Scrum, tendrán la gran oportunidad de sobrevivir y prosperar. Para aquellos que pasen a Scrum, y lo abracen completamente, la vuelta atrás a a los viejos días de trabajo será impensable. Un cambio de paradigma está ocurriendo en el lugar de trabajo, y Scrum es una parte importante de ese cambio.

Nota: el término Scrum proviene de un “paper” titulado The New New Product Development game de Hirotaka Takeuchi y Ikujiro Nonaka. En rugby, un scrum es una forma de recomenzar el juego, luego de una infracción accidental o después que la pelota salió de juego. La práctica de Scrum en el mundo del software incluye reuniones regulares diarias y cortas donde los miembros del equipo se juntan para comunicar su progreso. Debido a la similitud entre la pausa del juego (trabajo), y habiendo los jugadores (miembros del equipo) armado la reunión, ésta se conoce comúnmente como el Daily Scrum. Jeff Sutherland, John Scumniotales y Jeff McKenna son los responsables de haber introducido el término Scrum en el mundo del desarrollo del software en 1993, mientras trabajaban en la Easel Corporation, una compañía de herrmientas de software de Massachusetts. Ken Schwaber escribió el “paper” original sobre Scrum, SCRUM Development Process, que fue presentado en la conferencia OOPSLA en 1995.

Otras referencias:
Scrum: its place in the world
Scrum for Software Development

Columnas en el Task Board

Uno de los temas a la hora de implementar Scrum, es qué columnas se van a usar en el task board. Algunos separan el task board en 4, 5 o más columnas. El task board debería ser una representación del estado del proyecto, que muestre a simple vista la situacion actual. Debería ser una referencia para saber en qué va la cosa con solo mirarlo. Por lo tanto, habría que tratar de mantener el nivel de complejidad al mínimo posible. De todas formas, como todo en Scrum, su implementación debería irse adaptando a las necesidades del equipo de trabajo.

Al principio de mi anterior implementación de Scrum, usábamos el pizarrón como Task Board. Más adelante, usamos un espejo que había en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida, pero ahora lo enfrentamos con más experiencia y otro conocimiento.

Usamos post-its de distintos colores para diferenciar tipos de tareas.
Referencia de colores:

  • Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint.
  • Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo.
  • También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre.

Todos los movimientos en el Task Board se relizaban únicamente en el Daily Meeting, de manera que todo el equipo estuviera al tanto de lo que sucedía con el proyecto, y por el compromiso que implica llevar una tarea a la columna de “finalizado”.

Así fue como decidimos usar el task board en ese momento, y era lo que nos sirvió. Cada equipo debe adaptarlo a sus necesidades y aprender de la experiencia en su uso diario.

Certified Scrum Coach de habla hispana

Xavier Quesada Allue es el nuevo Certified Scrum Coach (CSC) de la Scrum Alliance de habla hispana. Así lo anunció en foro-agiles:

Hola a todos,
Quería comentarles con mucha alegría que la semana pasada (durante Agile 2009 en Chicago) fue aceptada mi postulación a Certified Scrum Coach (CSC) de la Scrum Alliance. Es un honor y un privilegio ser el primer CSC de habla hispana y de Iberoamérica.

Siguió su correo comentando un poco de qué se trata este título:

Para que se den una idea, dentro de la Scrum Alliance la certificación CSC tiene el mismo nivel de importancia y prestigio que la de CST (Certified Scrum Trainer). Pero claramente no es lo mismo ser un Trainer que un Coach. Hay similitudes, pero tambien diferencias. Ambos se complementan.

Las principales diferencias a nivel certificación son:

  • la certificación CSC es más nueva
  • no habilita a dar cursos certificados
  • hoy en día es más difícil de obtener que la de CST*

Probablemente por los 3 motivos anteriores, hay muchos menos CSC que CST (21 CSCs en el mundo vs. más de 100 CSTs)

Para postularse a CSC hay que:
a) tener 1500 horas de coaching en Scrum comprobables en los últimos 5 años
b) tener dos referencias escritas de clientes destacando un alto desempeño como Coach (resultados comprobables)
c) haber contribuído en forma demostrable a la comunidad Scrum/Agile internacional durante los últimos 3 años (por ejemplo participando en listas de correo, hablando en conferencias, escribiendo artículos o en un blog, etc)
d) haber sido CSP (Certified Scrum Practitioner) durante un año
e) completar un formulario bastante largo y complicado, que cubre desde conocimientos de Enterprise Scrum hasta aspectos de facilitación y coaching
f) pagar 100 dólares

Luego de todo esto, la postulación es evaluada por otros seis coaches CSC, que deben aceptarla unánimemente. El titulo debe ser luego revalidado cada tres años.

En resumen: esta es la certificación más alta y rigurosa que existe en el mundo ágil hoy en día, y el intento de hacer una certificación «bien hecha» por la Scrum Alliance, una organizacion sin fines de lucro que carga con el peso de haber creado el programa Certified ScrumMaster (CSM) que es altamente criticado por su escaso valor (solo certifica que se asistió a un curso de dos días – pero ver más abajo sobre el futuro del programa).

Un aporte importante para la comunidad ágil hispana:

A partir de este momento me sumo a Alan Cyment en la responsabilidad de comunicar a la comunidad hispanoparlante las novedades de la Scrum Alliance. Ante cualquier pregunta, no duden en contactarme.
Saludos cordiales,
Xavier

No se pierdan su blog: Visual Management Blog

Rol y perfil del Product Owner

A raíz de la entrada anterior: Sprint heroico – Planificación y Task Board me dejaron comentarios y enviaron un mail Victor y Ana:

Hola Fernando, en la empresa para la que trabajamos con Victor, estamos investigando sobre Scrum porque queremos implementar esta metodología.
Tenemos una duda respecto al rol de Product Owner, ese rol lo cubre un empleado del Cliente? y Cuál es el perfil de la persona que cumple este rol?
Desde ya agradecemos la infomación que nos puedas facilitar
Saludos

Primero que nada, veo que la empresa está muy interesada en implementar Scrum, ¡felicitaciones y bienvenidos al mundo ágil! Gracias por acudir al blog para despejar sus dudas, les recomiendo que acudan también a Foro agiles, la comunidad hispanohablante de metodologías ágiles de desarrollo.

Ya que me estaba extendiendo mucho en la respuesta en los comentarios, lo convertí en una entrada nueva, aprovechando que a alguien más le pueda servir. A continuación mi humilde aporte, espero lograr responder lo mejor posible desde mi conocimiento y experiencia personal:

El Product Owner

El rol del Product Owner, puede venir de parte del cliente o dentro de la empresa misma, depende. Generalmente no se aconseja que el Product Owner sea parte también del equipo de desarrollo, o el Scrum Master mismo, sus intereses se pueden ver enfrentados, pero esto puede variar según el caso. Por defecto, probablemente venga de parte del cliente.

Como Product Owner representa al cliente, y es el encargado de negociar con el equipo, con el Scrum Master por medio como facilitador, la prioridad del trabajo a realizar. Esto desde una perspectiva del retorno de inversión para el negocio.

Una de las analogías que nos comentaron durante el curso de CSM, es que el Product Owner sería como un embudo. En un extremo están los «stakeholders» o interesados: director de Marketing, de Finanzas, otros directivos, etc. El P.O. debe juntar y filtrar las necesidades de cada uno y hacérselas llegar al equipo, priorizando según el retorno de inversión.

En mi caso en particular, estoy en un desarrollo propio para la empresa donde trabajo. El rol de Product Owner es asumido por el jefe, ya que es quien tiene la visión general del producto.

Según la definición de la Scrum Alliance de los roles en Scrum, los roles del Product Owner son:

  • Definir las características del producto;
  • Decidir sobre las fechas de lanzamiento y contenido;
  • Ser responsable de la rentabilidad del producto (ROI);
  • Priorizar las características según el valor de mercado;
  • Ajustar las características y prioridades por iteración, según sea necesario; y
  • Aceptar o rechazar resultados del trabajo.

Debe estar presente entonces en las reuniones de planificación de Sprint, para priorizar las tareas del backlog. También es el encargado de llevar a cabo el review del producto, para aceptar o rechazar los resultados, según el concepto de listo. Viendo todos estos datos, espero estén en condiciones ya de responder qué perfil debe tener la persona a cumplir con este rol, y quién sería la más adecuada.

Se puede obtener entrenamiento para certificarse como Scrum Product Owner de la Scrum Alliance.

Espero haber aclarado el panorama, aunque agradezco cualquier aporte de lectores con más experiencia en el asunto. Desde ya les deseo mucha suerte con la implementación de Scrum, y espero compartan cualquier experiencia, duda y demás tanto con este blog, como la comunidad hispana de metodologías ágiles que pueden encontrar en: Foro agiles

Actualización:

Desde Foro ágiles justamente, tengo más material para comentar respecto al rol del Product Owner. Xavier Quesada Allue respondió sobre este post, y agregó la siguiente información:

Otra página similar para tener en cuenta es la del sitio Proyectos Agiles de Xavi Albaladejo:
http://www.proyectosagiles.org/cliente-product-owner

Recordemos que el Product Owner o bien es el Ciente, o bien representa al Cliente. En este ultimo caso a veces se lo llama ‘Proxy’ Product Owner para distinguirlo del Cliente real. Ser PO de un proyecto mediano/grande suele ser una dedicación full time, o como mínimo requiere tiempo de respuesta rápida durante el Sprint si el equipo te necesita. Muchas veces el Cliente o Senior Manager no está disponible cuando lo necesitamos y por eso hacen muy malos Product Owners.

Product Owner Anti-Patterns
Tenes un mal Product Owner si…

  • El PO no viene a la demo
  • El PO no viene al sprint planning
  • El PO no puede explicar bien las historias durante Sprint Planning
  • El PO no está disponible cuando el equipo lo necesita durante el Sprint
  • El PO no está manteniendo el Product Backlog actualizado y en perfecto estado
  • El PO no está autorizado a priorizar el backlog, y tiene que andar validando todo lo que hace con el cliente o un gerente a nivel micro-management
  • El PO no tiene autoridad suficiente como para negociar entre todos los stakeholders, en el caso de hacer de ‘embudo’

En cualquier caso en el que el PO no esté en total control del Product Backlog, o no lo esté manteniendo por falta de tiempo o ganas, o no pueda explicar lo que está pidiendo, o que el equipo sienta que está teniendo que tomar decisiones que debería tomar el PO… tenes un mal Product Owner.

¡Muchas gracias Xavier por la información!