lunes, 24 de noviembre de 2014

¿Cuál es el mejor soporte para escribir las historias de usuario?

Como en todo lo referente a agilidad el mejor formato es el que se adecua al equipo/proyecto/empresa. Si el equipo es distribuido, el formato ha de ser digital, igual que el tablero kanban. Pero en este post hablamos de equipos locales con pizarras kanban físicas.

El formato ha de ser el que le resulte más cómodo y útil al Propietario del Producto para la organización y gestión de su pila de producto. Algunos Propietarios de Producto gestionan su pila digitalmente, con un excel, por ejemplo. Otros tienen su propio tablero kanban con su propio flujo de trabajo y por tanto tienen sus historias de usuario escritas en post-its o tarjetas.

Utilizar post-its es muy ágil, pero cuando los campos de las historias de usuario que tratamos siempre, o casi siempre, son los mismos, vale la pena utilizar tarjetas preimpresas, ya que nos ahorramos de escribir los nombres de los campos y aumenta la sensación de orden (Algunos escribimos como los médicos y así al menos se sabe de qué trata lo que hemos escrito :-P).

Googleando me encontré una empresa americana, Braintrust, que ha diseñado sus propias tarjetas, muy bien diseñadas, con los campos recomendables y que adicionalmente dan un look profesional. Están preparadas para que se escriba la historia con el patrón "Como [rol del usuario], quiero [objetivo], para poder [beneficio]" y la aplicación del método de aseguramiento de calidad INVEST.

Aquí os dejo una imagen de las tarjetas, a mi me encantan...

Tarjetas para historias de usuario de Braintrust

viernes, 21 de noviembre de 2014

¿Cuál es la diferencia entre valor, prioridad y orden en la pila de producto?

Uno de mis alumnos, un jefe de proyecto PMP, participó en el curso de forma muy proactiva y llegados a la pila de producto no entendía la diferencia entre prioridad y orden, y le dimos bastantes vueltas al tema...

El campo prioridad es uno de los que se consideran necesarios en las historias de usuario y se podría definir como un sistema de priorización que nos permite determinar el orden en el que las historias de usuario deben de ser implementadas.

El campo valor, normalmente numérico, representa el valor de negocio que la historia de usuario aporta al cliente o usuario. El objetivo del equipo es maximizar el valor y la satisfacción percibida por el cliente en cada sprint. Este campo servirá junto con la estimación del esfuerzo, que mide una mezcla de tamaño y complejidad técnica de la historia, para determinar la prioridad con el que las historias deben de ser implementadas. 


Una forma para el Propietario del Producto de guiarse y determinar la prioridad es a través del ROI, la división del valor por el esfuerzo. Además en base al ROI obtenido podrá preguntarse si vale la pena construir una historia de usuario, o si hay varias opciones podrá decidir la mejor opción teniendo en cuenta la perspectiva económica.

El orden representa la urgencia de una historia, deriva de la prioridad que fuerza al Propietario del Producto o cliente a refinar el entendimiento de la pila de producto: solo puede haber una sola historia siguiente más importante. Resaltar que si mostramos las historias de usuario en formato de lista, la columna orden resulta claramente necesaria para cuando valor y esfuerzo de diferentes historias resultan en el mismo valor de prioridad.

Relación entre valor, prioridad y orden
Comentario en off: tengo de la absoluta convicción de que cualquier lista, desplegable, listado, select... deben de estar ordenados, por el criterio que sea, pero siempre estar ordenados.

viernes, 14 de noviembre de 2014

¿Qué significa eso de "cambio cultural"?

Los valores de Scrum
El cambio cultural en la transformación hacía la agilidad son los cambios de mentalidad que se deben de producir en la forma de pensar y de hacer de aquellos, que habiendo trabajado en grupos de trabajo, en que cada miembro solamente se responsabiliza de su parcela de trabajo, no hayan experimentado el verdadero trabajo en equipo. El cambio consiste adquirir los valores de Scrum, valores que tienen relación con los pilares Lean de trabajo en equipo y mejora continua. Son valores que crean equipos ganadores, valores de los que depende el equipo y a la vez se crean en el día a día de:
  • Foco: Poniendo el foco en unas pocas cosas a la vez, conseguimos entregar antes, trabajamos mejor juntos y obtenemos resultados de mayor calidad.
  • Coraje: Formando equipo, sintiendo el apoyo de este, aceptamos nuevos retos confiando en que podremos alcanzar el resultado deseado.
  • Franqueza: Expresamos con sinceridad cómo lo estamos haciendo, y manifestamos nuestras preocupaciones y dificultades con las que topamos.
  • Compromiso: Tenemos la sensación de controlar nuestro destino y nos comprometemos con el resultado esperado.
  • Respeto: Al trabajar juntos, compartiendo éxitos y fracasos, promovemos el respeto mutuo.
Valores -> Scrum, gracias Alejandro
Estos valores construyen sobre el propósito, la motivación intrínseca más potente que se produce en las personas que trabajan con Scrum. Ese sentimiento de estar participando y aportando valor con nuestro trabajo a lo que nos rodea, la compañía, el negocio, los usuarios... es el mayor impulsor de creatividad y calidad.

Estos valores los podéis encontrar en documento Core-Scrum de Scrum Alliance.

Si queréis indagar un poco más alrededor del tema os invito a que echéis un vistazo a los principios activos del artículo de Juan Palacio: "Excipientes y principios activos de la Scrum".

martes, 11 de noviembre de 2014

¿Cómo implantar agilidad en una empresa?

Agilidad - Scrum
El tema de la transición de gestión de proyectos de metodología tradicional (predictiva) a agilidad (evolutiva) es tema de amplio debate e interés en los cursos. No se trata de un simple cambio de metodología, de nuevas reglas y prácticas, sino que va acompañado de un cambio cultural muy profundo que ha de producirse en la mentalidad de cada uno de nosotros.

El cliente ha de ser consciente de que parte de una visión incompleta de lo que necesita, sabe lo que quiere pero no lo que necesita, y por tanto no ha de pensar en términos tradicionales de cerrar en alcance-plazo-coste. El enfoque ágil es construir a cachos, con entregas frecuentes, de manera que entre cacho y cacho pueda redefinir según le marque su mercado. Construirá mientras los cachos le den valor a su negocio o mientras el presupuesto lo permita. Hay que cambiar esa forma de pensar que trata de buscar un proveedor como si de una "novia" se tratase, para luego "casarse" con ella y darle el proyecto. Hay que aprender a buscar un partner, alguien que camine a nuestro lado y nos haga crecer. La confianza y el compromiso se irán construyendo con cada sprint, y si no engarzáramos con ese partner, hay que ser ágil y buscar otro partner. Todo ello sin prejuicio para ambas partes, simplemente cliente y proveedor no han engarzado.

El proveedor ha de ser partícipe de la misma perspectiva; no ofrecer un proyecto a alcance-plazo-coste cerrados, sino dar la bienvenida a los cambios y dar respuesta rápida en la puesta en el mercado de lo que le da valor al cliente.


La estructura se vuelve más plana, un jefe de proyecto si tiene cabida y sabe adaptarse se vuelve básicamente facilitador, ya que para un equipo comprometido y autogestionado el rol del jefe de proyecto puede anular al equipo ágil. También los miembros del equipo han de cambiar su forma de pensar, han de sentir que van en el mismo barco, que están comprometidos con el objetivo y éxito de todo el equipo, no solo con el particular. No ha lugar a especialistas con su reino, se requiere actitud de colaboración y compartición de conocimiento, tanto técnico como funcional. Hemos de estar abiertos a ser un equipo multifuncional, especialistas en lo nuestro pero interesados en lo que nos rodea.


Visto lo anterior se puede comprender que no es trivial transformar en una empresa ágil. La agilidad se basa en 
cambiar de mentalidad, implementar gestión de personas (motivación, compromiso, fidelización...), rodar, coger experiencia, revisar, adaptarse y mejorar continuamente, por tanto se trata de empezar para ir evolucionando y madurando hacia la agilidad.

Ese punto de partida es donde entra Scrum
. Scrum se concibió como una marco de trabajo para llevar a las empresas hacia la agilidad. Todo los elementos de Scrum, sus roles, sus artefactos y sus reglas están pensados para iniciar a las empresas en la agilidad y crear el ambiente propicio para que se den los cambios de mentalidad necesarios. Las propias reglas de Scrum, como no poder intervenir en el equipo durante un sprint, ya se encargarán de "romper" los hábitos culturales.

Por tanto es tan simple como suena, tomar la decisión de implantar Scrum y aplicarlo al 100% (al 100%, no al 99%...), sus reglas son pocas y fáciles de entender, de hecho pensándolo un poco son de sentido común.

¿Qué ocurrirá? Que de repente habrá entregas cada dos semanas y eso hará que el estrés propio de un proyecto se traiga al principio del proyecto. De igual manera todos los riesgos se trasladarán al principio del proyecto, de pronto habrá una fecha a la vista en que posiblemente habrá que subir algo a producción, si no es en el primer sprint será en el segundo o tercero. Todos, interesados, negocio y equipo entrarán en una fase de aprendizaje en que todos los problemas se harán visibles y se deberán de resolver a corto. Eso es algo buenísimo, porque equivocarse al principio permite aprender, mejorar y crecer, aunque al principio siempre va a haber mucha resistencia al cambio.

Los beneficios de Scrum no se hacen patentes enseguida, usualmente sus bondades se ven a partir del tercer sprint. Los beneficios son muchísimos, entregas cada dos semanas, con lo que todos los ciclos se reducen a dos semanas, cada segundo viernes el equipo se va a casa para el fin de semana con sensación de trabajo bien hecho y acabado, lo que redunda en equipos motivados, igual que los clientes y negocio que sienten que el producto avanza y que tienen el control sobre rumbo del producto. Una vez maduros, los equipos habrán incrementado su productividad en hasta un 400%, y eso ¡sin sobreesfuerzos!

El mensaje que quiero dar es, que aunque Scrum sea muy fácil de entender y hagamos todos los preparativos estratégicos, puede ser muy difícil de poner en marcha, eso dependerá de la cultura de la compañía.
¡La cultura se merienda a la estrategia!

Se puede poner en marcha de hoy para mañana, habrá un bajón en la productividad pero como mucho durante 2 sprints. Lo importante antes de iniciar Scrum es dotarse de un Scrum Master experimentado, asegurarse de formar a los equipos, al Propietario del Producto y al cliente, y muy importante, abrir canales de comunicación entre equipo y cliente/usuarios, y no me refiero a nada tecnológico, sino hacer que se conozcan, si no es en presencial hablándoles a unos de los otros. Es importante que usuarios y equipo sepan quien hay al otro lado, que sientan empatía los unos por los otros, eso abre canales y hará que tomen mejores decisiones.

Una vez la empresa haya rodado y esté madura en Scrum, será el momento de introducir nuevas prácticas ágiles que hagan que las cosas funcionen aún mejor y hagan que Scrum se adapte a la empresa. En Scrum Manager conocemos estos dos estadios como Scrum técnico y Scrum avanzado, estos están representados en el cuadro de Niveles de Scrum que se encabeza con la frase "Has aprendido a avanzar en scrum cuando sabes romper las reglas".

Cierro con un texto del libro Lean from the Trenches de Henrik Kniberg que resume la vivencia de empresas y equipos una vez han transicionado a agilidad.
Henrik Kniberg - Lean from the Trenches

jueves, 6 de noviembre de 2014

¿Qué hacer con los móviles en la reunión de planificación de sprint?

Planning poker en baraja y como app
En el último de los cursos que di, hice, como siempre, el ejercicio de la estimación de póker. Saqué la baraja de planning poker y repartí los ejercicios. Los alumnos siempre se lo pasan muy bien, es un ejercicio ameno que suscita mucho debate, pero esta vez vi a uno de los alumnos que tenía la baraja intacta y ponía boca abajo su móvil cada vez que estimaban una tarea... Estaba utilizando la aplicación planning poker para Android de 10 pines

Una forma de ganar tiempo y conseguir que te dejen tranquilo es dar trabajo, sea con un compañero o con un cliente. De forma análoga, para "silenciar" los móviles en la reunión de planificación de sprint, una buena opción es "ocupar" el móvil, en este caso utilizarlo como herramienta para la estimación.

Estoy valorando proponer en mis cursos futuros utilizar el móvil en vez o a la vez de la baraja, creo que amenizaría aún más el ejercicio.

sábado, 1 de noviembre de 2014

¿Qué hacer con los móviles en la reunión de diaria?

Móviles aparcados
Una Scrum Master me comentó en un curso presencial que estaba desesperada con la gente que en plena reunión diaria estaba por el móvil. Tiene ganas de prohibirlos, pero claro, no puede tratar al equipo como si fueran niños...

Es un tema complicado, el equipo son profesionales responsables y puede haber llamadas urgentes que requieren ser respondidas, o llamadas o mensajes de trabajo que sean importantes... por tanto no se pueden prohibir directamente. Hay hacer algo pero dejarles una vía abierta hacia el móvil.

La idea que le propuse fue hacer que los miembros del equipo dejasen el móvil en una pila, y el primero que cogiese el móvil durante la reunión debía de invitar al resto a copas al finalizar la jornada de trabajo. Quedan exentas llamadas de trabajo urgentes o mensajes realmente importantes. :-)