¿Qué tienes en tu Backlog (y en tus Sprints)?

Una adecuada gestión del Backlog es crucial para el éxito del trabajo realizado por el equipo. La responsabilidad de dicha gestión es del Product Owner (PO), quien es la última palabra en cuanto a su contenido, al Orden de ejecución y a la definición de cada "pieza de trabajo". En "Gestión eficaz del Backlog" se indican 14 criterios que en conjunto se podrían utilizar para determinar dicho Orden de ejecución. Normalmente el PO se apoya en el equipo de desarrollo para gestionar el Backlog y para decidir el contenido de cada Sprint pero no deja de ser su responsabilidad. Pero hay un aspecto que muchas veces se pasa por alto o sin cuestionarlo demasiado: ¿Qué tipo de trabajo debería contener un Backlog o Sprint?. La respuesta inmediata podría ser: Historias de Usuario (HU). Scrum denomina "ítems" a los elementos del Backlog y de los Sprints, yo prefiero llamarlas UT (Unidades de trabajo). Pero más allá del nombre lo importante es a qué representa una UT. Es en esto en lo que me centraré en este post.

En el método ágil Extreme Programming (XP) se propone tener un Backlog con Historias de Usuario que a su vez se dividen en Tareas de programación. Es decir, se proponía tener dos niveles de gestión, uno al nivel de HU para la planificación y seguimiento visible para el cliente y otro al nivel de las tareas técnicas para los desarrolladores, llevando en cuenta que el término de todas las tareas asociadas a una HU conlleva el término de la HU. 

En la Guía de Scrum solo se habla de "ítems". Sin embargo, se indica lo siguiente: "For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less.". Es decir, puede haber una descomposición de los ítems en otros más pequeños pero no se indica explícitamente si se trata de tareas técnicas o si deben ser ítems "legibles" por el PO. Sin embargo, Scrum enfatiza que el PO es responsable de la gestión del Backlog con lo cual dichos ítems deberían ser definidos desde un punto de vista del cliente o usuario (no como tareas técnicas).

En cualquier caso, si trabajamos con dos niveles de descomposición del trabajo (nivel de UT y nivel de las tareas técnicas asociadas a cada UT) podríamos tener la mala tentación de, por ejemplo, preocuparnos de que la estimación de una UT que representa un requisito, se corresponda con las estimaciones de las tareas técnicas en las cuales de descompone. Digo "mala" porque estas estimaciones y registros de tiempo invertido en dos niveles probablemente nos complicarán la gestión del trabajo sin ganar significativamente mayor precisión :-).

Vamos ahora al grano en cuanto al contenido del Backlog y de un Sprint. Podemos identificar al menos cinco tipos de trabajo en el contexto de un equipo encargado al desarrollo y/o mantenimiento de un producto:

• Tipo 1. Cambios en el comportamiento del producto: implementación de Nuevos requisitos, Mejoras en requisitos ya implementados o Correcciones de fallo.
• Tipo 2. Tareas técnicas asociadas al proceso de cada cambio en el comportamiento del producto. Por ejemplo, Especificar requisitos, Diseñar, Programar, Probar, etc., actividades realizadas para cada uno de dichos cambios.
• Tipo 3. Tareas técnicas asociadas a la arquitectura del producto. Por ejemplo, cambios puntuales en el front-end, back-end, o en el esquema de la BD. 
• Tipo 4. Tareas técnicas que no cambian el comportamiento del producto pero están en su contexto de trabajo. Por ejemplo, refactorizaciones del código (aquellas que no se asuman dentro de las implementaciones de cambios de comportamiento en el producto), cambios en la infraestructura hardware o software de los entornos de desarrollo o producción, tareas de automatización de procesos, tareas de automatización de pruebas, migraciones de datos, etc.
• Tipo 5. Otras tareas: investigación en nuevas tecnologías, formación del equipo, etc.

Claramente, el trabajo de tipo 1 lo podría solicitar y gestionar el PO (en su perspectiva de cliente del producto), es decir, este tipo de UT debe estar en el Backlog o en Sprint.

El trabajo de tipo 2 es la dimensión ortogonal a la dimensión de los contenedores (Backlog y Sprint), es decir, una UT al mismo tiempo que está en un contenedor estará en una cierta actividad de su proceso (en cierta columna de un tablero kanban). Ver "Organización ágil del trabajo: Dos dimensiones" Con lo cual, estas actividades NO tiene sentido incluirlas como UT en el Backlog o en Sprint, pues son las actividades por las cuales pasará una UT en su procesamiento y que son parte de un workflow, plasmado en un tablero kanban.

El trabajo de tipo 3 es una descomposición técnica de lo que conlleva la implementación del trabajo de tipo 1. Estas serían las tareas de programación a las que se refiere XP. Pero este trabajo de tipo 3 no lo  debería gestionar el PO, son los desarrolladores quienes al momento de abordar una UT de tipo 1 decidirán la conveniencia de una descomposición desde una perspectiva estrictamente técnica. Estas tareas deberían estar "embebidas" en las UT de tipo 1 para que no compliquen la gestión desde la perspectiva del PO, pero que al mismo tiempo puedan gestionarse por los desarrolladores. Por ejemplo, una UT llamada "Facturas pendientes de pago", que muestra en un formulario la lista de facturas pendientes de pago, puede que cuando llegue a su actividad "Programar" sea descompuesta en tareas en paralelo al estilo: "implementar front-end", "implementar back-end", etc. Incluso en el caso de tener desarrolladores full stack puede que estas tareas técnicas las pueda realizar todas un mismo desarrollador, con lo cual puede que ya no sea tan interesante descomponer el trabajo técnico de programación.

La siguiente figura ilustra el trabajo el trabajo de tipo 1 (en la vista del PO) y tipo 3 (en la vista de los desarrolladores). 

Las tareas de tipo 4 y tipo 5 no son gestionables por el PO pero es importante que se vean explícitamente como parte del trabajo del equipo pues al momento de realizarlas le restarán Capacidad, lo cual requerirá un acuerdo con el PO al momento de que se realicen. Bastaría con tener un filtrado sencillo de estas UT para que las pueda visualizar el PO o el equipo cuando estimen conveniente.

He visto con sorpresa en algunos equipos (y en repetidas ocasiones) que trabajan con un Backlog o Sprints donde en su gran mayoría solo hay UT del tipo 3. Los desarrolladores trabajan "cómodamente" con objetivos técnicos, y usualmente muy desconectados del resultado final (el cambio de comportamiento en el producto, el incremento que se espera y el valor aportado). Además, dicho resultado se ve postergado hasta integrar varias UT de tareas técnicas, que en el peor de los casos podría ocurrir después de varios Sprints. Scrum establece que el resultado de un Sprint debe ser un incremento del producto que potencialmente podría pasar a producción, es decir, aunque puede que no esté completa la funcionalidad, lo que ya está implementado debe ser operativo. Cuando esto no se cumple se está perdiendo una de las grandes ventajas que ofrece el trabajar con Sprints: la validación continua y frecuente del PO. Por ejemplo, si en un Sprint solo se ha conseguido implementar una parte back-end del producto el PO no puede validar nada. O si solo se ha conseguido implementar parte front-end pero no está operativa porque falta implementar e integrar con una parte back-end tampoco permitiría hacer una validación completa. Pienso que estos escenarios suelen darse en contextos donde el PO básicamente es un Jefe de Proyecto tradicional embestido de PO :-), el cual sigue repartiendo faena técnica a los desarrolladores y él lleva aparte la gestión de los compromisos con el clientes o los usuarios, probablemente en otro Backlog y Sprints :-). 

Para terminar y asociado a la anomalía antes comentada os dejo un texto extraído desde https://www.scrum.org/about

Fighting “Flaccid Scrum”

By early 2009, more organizations were using Agile processes than waterfall processes, and of those employing Agile 84% were using Scrum. However, less than 50% of those using Scrum were developing in incremental iterations, which are the heartbeat of Scrum. Martin Fowler wrote in his blog that he was encountering many instances of "Flaccid Scrum." Teams were using Scrum vocabulary but weren’t able to create a potentially shippable increment of functionality within a single Sprint.

Patricio Letelier

twitter.com/yopolt
linkedin.com/in/letelier
agilismoatwork.blogspot.com

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

 

Evaluación y mejora del desempeño en un contexto metodológico ágil

 

En este post os presento un modelo que he desarrollado para la evaluación y mejora del desempeño de equipos y de sus integrantes en el marco de una gestión ágil del trabajo. 

Contexto: llevo bastantes años refinando este modelo en dos asignaturas de Ingeniería Informática en mi universidad, donde los estudiantes trabajan en equipos usando un enfoque ágil para desarrollar un producto software. Cada semestre lo aplico en alrededor de 15-20 equipos de 4-6 integrantes, con lo cual está bastante rodado aunque siempre es mejorable. La idea es comenzar a aplicarlo también en un ámbito de empresa donde se trabaje con el enfoque ágil. Vamos al tema ... 

La evaluación y mejora del desempeño de los empleados de una empresa y de los equipos de trabajo es un asunto importante y en general me atrevo a decir que no está resuelto satisfactoriamente ni en un ámbito de gestión tradicional del trabajo ni en uno ágil. De hecho, hasta donde he podido averiguar no existen propuestas específicas para el enfoque ágil y se da la paradoja que en empresas donde se trabaja con métodos ágiles la evaluación de su personal se hace normalmente de forma "tradicional", me refiero a que no está integrada y adaptada a la dinámica de los equipos que trabajan con una metodología ágil, suelen centrarse solo en la evaluación de las personas, no incluyen la evaluación del equipo, y esto en un contexto ágil podría romper la dinámica ágil del equipo.

 

Al decir "evaluación de equipos que usan una metodología ágil" inmediatamente podrían surgir expresiones como "No es necesario hacer evaluaciones porque los equipos son autogestionados" o "Es el PO (Product Owner) el que evalúa al equipo en cuanto a su satisfacción con los resultados y el valor aportado". De forma similar, respecto de evaluaciones de integrantes del equipo podría decirse "Eso ya lo estamos comentando cuando surgen problemas". En parte estas expresiones son correctas pero en la práctica hay bastante margen de mejora respecto de cómo hacer dichas evaluaciones y cómo sacarles provecho.

El principal propósito de una evaluación de desempeño debería ser el orientar al personal hacia una mejora de su desempeño. Sin embargo, una evaluación de desempeño puede tener otros usos adicionales asociados a recompensas o penalizaciones para el equipo o sus integrantes. Con lo cual, en cuanto a la "justicia" de la evaluación, es conveniente que se formalice y sea transparente para todos los involucrados.

Es importante destacar, que a lo largo del tiempo un equipo y cualquiera de sus integrantes puede tener variaciones en su desempeño. Lo deseable es que el desempeño mejore, o si ya es satisfactorio se mantenga, y que los defectos en el desempeño se detecten y resuelvan oportunamente. Por esto, sería conveniente que la evaluación de rendimiento esté siempre abierta, es decir, que se pueda modificar en cualquier momento según las evidencias (positivas o negativas) que se vayan manifestando. Sin embargo, el análisis de las evaluaciones debería tener cierta frecuencia o podría estar alineada con hitos del trabajo (finalización de Sprint y/o de proyecto, entregas de trabajo, etc.), de manera que la detección de anomalías y puesta en marcha de acciones correctivas se haga oportunamente.

En la propuesta de roles de Scrum (accountabilities = responsabilidades, renombrado así en la última versión de la Scrum Guide) no existe la figura de "Jefe". El PO es la última palabra en lo que respecta a decisiones de negocio, el equipo autogestionado es quien decide respecto de lo técnico y el Scrum Master tiene autoridad en cuanto a la definición y aplicación de la metodología pero no es la última palabra ni en lo de negocio ni en lo técnico. Con lo cual cuando existen deficiencias en el desempeño del equipo y/o de sus integrantes, o cuando existen conflictos dentro del equipo y/o con el PO (o con el Scrum Master) se echaría en falta alguien que tuviese la autoridad para intervenir. Una opción razonable sería dejar esta tarea en manos del Scrum Master pues, aunque de forma indirecta, los problemas de rendimiento y conflictos son impedimentos para conseguir el máximo desempeño del equipo. De esta forma, el Scrum Master es quien debería también revisar periódicamente las evaluaciones y comentar posibles anomalías en la Reunión de Retrospectiva.  

¿Pero qué es el desempeño?. La respuesta no es tan obvia como parece, pues son varios los interesados o posibles evaluadores del desempeño, y cada uno tiene una perspectiva diferente. Es decir, el contenido, forma, y frecuencia (el qué, cómo y cuándo) de la evaluación podría ser diferente. 

En el marco de las responsabilidades propuestas por Scrum la siguiente imagen ilustra , se muestran las posibles evaluaciones de desempeño que podríamos establecer. 

El PO evaluaría el resultado conseguido por los desarrolladores. Podría hacerlo después de cada Sprint o cada cierto período de tiempo, y adicionalmente, si se trata de un proyecto, se podría hacer cuando termine el proyecto. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del PO.

El resto de las evaluaciones tiene ya un espacio bien definido en Scrum; son las Reuniones de Retrospectiva, que deberían realizarse al finalizar un Sprint o si no se trabaja con Sprints, debería hacerse con una cierta regularidad.

La evaluación por parte del Scrum Master estaría orientada a detectar y resolver impedimentos, y a establecer mejoras en la metodología de trabajo del equipo. Por contraparte y opcionalmente, el equipo también podría evaluar el desempeño del Scrum Master. En cuanto a los impedimentos, el Scrum Master y el equipo tienen la oportunidad de detectarlos en las Reuniones Diarias (Daily Meeting) pero aquello que no tenga una solución sencilla o inmediata se puede trasladar a la Reunión de Retrospectiva. La evaluación hecha por el Scrum Master estaría asociada principalmente a la gestión de las prácticas ágiles aplicadas por el equipo en su trabajo, orientando respecto del refinamiento de las prácticas ya implantadas. 

Además, sería responsabilidad de Scrum Master el establecimiento de un adecuado sistema de evaluación de desempeño, ya que es parte de lo que se espera de él o ella en cuanto a ofrecer un buen servicio de apoyo para mejora de los métodos de trabajo.

La Autoevaluación y Coevaluación interna de los Desarrolladores deberían estar alineadas, es decir, tanto en contenido, forma, y frecuencia podrían coincidir, la diferencia obvia es que una evaluación representa cómo se ve una persona y la otra es cómo la ven sus compañeras/os de trabajo. Estas evaluaciones podrían actualizarse regularmente en cada Sprint o cada cierto tiempo, pero es importante que además estén disponibles para su modificación en cualquier momento para poder reflejar alguna evidencia puntual durante cualquier día de trabajo.

Resumen de esta propuesta de modelo para evaluación de desempeño:

• Es un sistema de evaluación y mejora orientado a equipos y sus integrantes, trabajando con un enfoque ágil.
• Se trata de una evaluación continua, las evaluaciones y su análisis lo pueden hacer en cualquier momento los interesados.
• Se basa en baremos específicos configurables según los intereses de los evaluadores. Esto permite enfrentar dos aspectos clave: los equipos evolucionan (Modelo Tuckman para explicar el desarrollo de los equipos), y por otra parte, las personas pueden tener diversas fortalezas (y debilidades), lo importante es que en conjunto se complementen para formar un buen equipo (Roles de Belbin). No es necesario ni conveniente forzar a que una persona destaque en todas las competencias, y por contraparte, sí que es importante verificar que todos los Roles de Belbin sean cubiertos al sumar los Roles de Belbin de los miembros del equipo.
• Incluye evaluación del equipo por el PO y el Scrum Master, opcionalmente considera la evaluación del PO y Scrum Master por parte de los miembros de equipo, e incluye autoevaluación y coevaluación entre los colaboradores en un equipo.
• Considera la posibilidad "no evidencia" en algunos aspectos de los baremos de evaluación. Es decir, puede que en un cierto momento un evaluador no tenga suficientes evidencias para valorar algún ítem del baremo.
• Aunque podría utilizarse en un nivel directivo la intención original es evaluar equipos y personas en el nivel operativo.
• No es un sistema para evaluación uniforme, no lo es respecto de los baremos de evaluación, ni tampoco lo es respecto de las propias valoraciones. Esto último se debe a que es muy difícil garantizar una total objetividad, y menos que una evaluación de equipo o entre personas de distintos equipos sea comparable.
• El propósito es detectar e intentar resolver situaciones anómalas oportunamente. Sin embargo, este sistema podría utilizarse para recompensar o penalizar a las personas pero hay que tener en cuenta la posible lo anteriormente indicado; la no uniformidad de las evaluaciones, especialmente entre distintos equipos.
• La evaluación realizada por los colaboradores es anónima, cada Desarrollador no conoce las evaluaciones que le han hecho sus compañeros, solo ve el promedio ponderado. Sin embargo, el Scrum Master sí que tiene toda la visibilidad y con ello puede moderar una parte de la Reunión de Retrospectiva donde comente con el equipos las evaluaciones individuales. 

Tenemos gran parte del modelo ya implementado en una herramienta que hemos utilizado ya los dos últimos años. A continuación, se muestran algunas de las principales funcionalidades ya cubiertas.

La siguiente imagen corresponde a la interfaz en la cual cada persona evalúa a sus colaboradores directos, que corresponden a sus compañeros en los equipos en los cuales participa. Cada uno de sus colaboradores aparece como una columna. 

El baremo de evaluación se estructura en Competencias y Dimensiones (primera columna de la imagen). Tanto las competencias como sus dimensiones son configurables, en este ejemplo se han establecido cuatro competencias y cada una de ellas con tres dimensiones. La evaluación puede hacerse por rúbricas (guías para otorgar cada valor de la escala) o como en la imagen, simplemente planteando una afirmación y ofreciendo una escala de Likert para evaluar. Las rúbricas y valores de escala de valoración también son configurables.

En la siguiente imagen se muestra la evaluación que haría un Scrum Master al equipo. A la izquierda se muestran las evaluaciones globales de cada Sprint, y seleccionando un Sprint se ve el detalle de la evaluación según el baremo establecido para ese Sprint. Como se observa, los ítems del baremo pueden tener diferentes pesos y de esas valoraciones se obtiene un promedio ponderado para cada Sprint.

Finalmente, cada integrante del equipo puede visualizar en una interfaz como la que se muestra a continuación con las evaluaciones que ha obtenido de sus colaboradores.

En la parte izquierda puede ver las evaluaciones que tiene su equipo en cada Sprint, y la evaluación promedio de sus colaboradores. En este caso, para ajustar la evaluación de la persona en un Sprint, se aplica una recompensa o penalización según la diferencia entre su evaluación ponderada de competencias y la evaluación promedio de sus colaboradores. Es decir, la valoración final contempla una recompensa por destacar positivamente o una penalización por destacar negativamente. Dado que la evaluación se mantiene abierta durante todo el proyecto, las personas que tengan un mal desempeño tienen la oportunidad de mejorar posteriormente pues la evaluación final es la que se considera para dicho ajuste.

Me atrevo a decir que en el contexto académico el modelo aquí ya ha demostrado ser eficaz. Más allá de permitir otorgar una calificación justa a los estudiantes, el modelo está permitiendo detectar tempranamente defectos en el funcionamiento de los equipos, ofreciendo orientación respecto de lo que se debe mejorar y motivando a hacerlo en los Sprints siguientes. Además, los resultados de una reciente encuesta hecha para recabar la opinión de los estudiantes respecto del método de evaluación arrojó los siguiente resultados (sobre 94 respuestas): el 87% está de acuerdo o totalmente de acuerdo en que el método de evaluación es justo, el 66% está de acuerdo o totalmente de acuerdo en que el método promueve la mejora en el rendimiento del equipo e individual (un 20% está indeciso), y el 94% está en desacuerdo o totalmente en desacuerdo en que el método creó algún conflicto en su equipo.

Por último, estamos recolectando la información del histórico de cambios en las evaluaciones, con lo cual pronto se podrá visualizar la evolución de las evaluaciones a nivel de competencias y dimensiones para cada persona.

Patricio Letelier

twitter.com/yopolt

linkedin.com/in/letelier
agilismoatwork.blogspot.com

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com 

 

Nuestro Product Owner NO cumple con sus responsabilidades ¿qué podemos hacer?

La respuesta rápida y fácil a una situación en la cual el Product Owner (PO) no acepta o no favorece la aplicación del enfoque ágil es: "no podemos aplicar el enfoque ágil". Sin embargo, esta decisión es demasiado radical, esta situación desfavorable aunque supone limitaciones, no tiene por qué implicar no aplicar nada del enfoque ágil. Para consuelo, la buena noticia es que en esta situación al menos tenemos identificado al PO :-), pues siempre será peor no tenerlo claramente identificado. La definición e importancia del PO la podéis consultar en mi post "Se busca Product Owner ...".

Para evaluar el impacto de tener un PO que no cumpla con sus responsabilidades podemos repasar las prácticas ágiles que están estrechamente asociadas al PO, analizando qué supondría que su participación no fuese la esperada, y ver hasta qué punto se pondría en riesgo la efectividad una práctica, y por ende una menor eficacia de la transformación ágil. 

Tomaré como referencia las prácticas ágiles de nuestro catálogo Agilev-Roadmap (en este enlace encontraréis la lista de prácticas y una explicación de cada una de ellas) y comentaré qué prácticas ágiles podrían verse más directamente afectadas por no contar con un PO "óptimo" según la definición de sus responsabilidades, y daré además algunas recomendaciones al respecto.

PRA01. Promover la sencillez en todos los aspectos. Ofrecer la solución más simple y mínima que pueda ser satisfactoria para el cliente. Estrategia MVP, y PRA02. Abordar trabajo de forma incremental.

Comentemos estas dos prácticas en conjunto pues están estrechamente relacionadas. Si el PO solo ve como alternativa las opción más ambiciosa en cuanto a todas las características del producto y/o en cuanto a cada una de ellas, es muy complicado llevar a cabo un desarrollo incremental del producto. En cada incremento del producto tendremos características grandes (Épicas) que por dicha ambición dejarán poco espacio para incluir otras características. Esto es extensible al global del proyecto, es decir, será difícil poder desarrollar todas las características cumpliendo con las restricciones de plazos y costos. El equipo de desarrollo puede intentar ayudar en esta reflexión al PO para conseguir acotar el alcance del proyecto y de cada característica, sin que la solución sea insatisfactoria, pero la decisión y responsabilidad en última instancia es del PO. 

PRA03. Realizar entregas frecuentes de unidades de trabajo terminadas.

Si el PO NO acepta que se hagan entregas parciales y solo quiere poner en producción el producto una vez esté totalmente terminado se acumularán riesgos hasta ese momento. Las entregas frecuentes (parciales) permiten validar que el proyecto va en buena dirección y no se aumenta la tensión hacia el final cuando ya queda poco margen de reacción. No es solo una cuestión de validar que estamos construyendo el producto correcto para el usuario final, sino de detectar posibles inconvenientes "externos" de forma oportuna, por ejemplo: carencias de infraestructura, de formación de los usuarios, desafíos de integración con otros sistemas, problemas de migración desde sistemas actuales, etc. Todos estos elementos suelen presentar imprevistos que a veces son difíciles de prever y necesitan esa entrega parcial para ponerlos en evidencia. Una entrega parcial no tiene por qué ser un paso a producción como tal, sino que si esto no es posible o recomendable podemos acotarlo a, por ejemplo, un paso a un entorno de preproducción donde usuarios potenciales lo prueben, o una versión Beta disponible, o un paso a producción para un conjunto acotado y controlado de usuarios.     

PRA04. Realizar reuniones de planificación (y replanificación) frecuentemente (frecuencia de pocas semanas no meses). Planning Meeting.

En las reuniones de planificación el PO acuerda con el equipo el trabajo que espera que se complete en un cierto período de tiempo (en un Sprint o en el Proyecto). Además, en estas reuniones el equipo puede resolver dudas respecto de cada ítem de trabajo para asegurarse que lo interpreta correctamente. De esta forma el PO se hace protagonista en cuanto a las decisiones de negocio. Si estas reuniones de planificación no se realizan con la frecuencia necesaria se corre el riesgo que el equipo asuma decisiones de negocio y/o se vea bloqueado para continuar esperando que se establezca o confirme la planificación. En contextos de trabajo poco planificables, por ejemplo, en mantenimiento de aplicaciones (donde con frecuencia lleguen imprevistos y de carácter urgente), puede que en lugar de reuniones de planificación sea más efectivo que el PO establezca pautas detalladas respecto a priorización y forma de actuar ante los ítems de trabajo que llegan al equipo, de forma que no se requiera la intervención del PO salvo para excepciones. Si el trabajo es más bien planificable (tendrá  sentido invertir tiempo en planificar pues normalmente esa planificación no cambia significativamente) se pueden establecer la fechas de fin de Sprint con antelación, de forma que intentemos garantizar la participación del PO en esas fechas. 

PRA09. Gestión continua y multicriterio del trabajo pendiente para que esté siempre debidamente priorizado. Gestión del Backlog.
El PO por definición es quien debería gestionar el Backlog pues allí están ordenados todos los ítems de trabajo que irán incrementalmente completando el producto, todo desde una perspectiva principalmente de negocio, aunque podría tener ciertos condicionantes técnicos recomendados por el equipo de desarrollo. En esta gestión del Backlog suele ser necesario que el equipo le ayude al PO a identificar y organizar los ítems del Backlog, pero con la confirmación el PO para que esto no conlleve que el equipo tome decisiones de negocio.

PRA17. Product Owner en estrecho contacto con el equipo y altamente disponible.

Aparte de las reuniones programadas con el equipo (Reuniones de Planificación y Reuniones de Revisión) el PO debería estar altamente disponible para resolver dudas y validar el trabajo del equipo de desarrollo. La no disponibilidad provocará posiblemente bloqueo en algún ítem en el que se está trabajando y obligará a trabajar en otro ítem menos prioritario mientras se resuelva dicho bloqueo. Además, las interrupciones asociadas a dejar un ítem sin finalizar y luego retomarlo para continuar perjudican el rendimiento del equipo. Se deben establecer canales y protocolos de comunicación que reduzcan al máximo la espera del equipo por disponibilidad del PO, aunque no necesariamente tenga todo que resolverse por reuniones presenciales con el PO, hay que tener aprovechar también mensajería instantánea, comunicación telefónica y videoconferencias, todo en su justa medida respecto de lo que se requiere comentar con el PO.

PRA18. Perfil cliente del Product Owner. Una persona que prioriza el trabajo del equipo y es un buen representante de los clientes/usuarios.

Scrum define con precisión el perfil esperado del PO, que además de una persona (no un comité) requiere ser un buen representante de la parte cliente (y usuarios), y ojalá con un nivel de autoridad en ellos para impulsar el uso del producto. Si el PO no cumple con estas características puede ser un gran inconveniente puesto que podría orientar el desarrollo del producto en una dirección incorrecta, que no satisfaga las reales necesidades de los usuarios. Por esto, si el PO tiene ciertas debilidades al respecto tendrá que hacer un esfuerzo por buscar apoyos en la parte cliente que complementen su perfil pero manteniendo su papel de PO hacia el equipo de desarrollo, es decir, que esta situación sea lo más transparente posible para el equipo.  

PRA19. Realizar reuniones de revisión del trabajo entregado. Review Meeting.

Similar a los que sucede con las Reuniones de Planificación, en las Reuniones de Revisión el equipo necesita la participación del PO para validar el resultado (aunque aun sea parcial) de su trabajo. Además, estas reuniones deberían también servir para mantener la motivación del equipo cuando el PO confirma que su trabajo está siendo satisfactorio. No debería ser un problema asegurar la participación del PO en estas reuniones si se establece con bastante antelación las fechas de finalización de los Sprints, al menos de los más próximos. Desgraciadamente, en muchos casos, y particularmente cuando se trata de la revisión de una versión que pasará a producción, una revisión detallada no es factible hacerla en puntualmente en una reunión, y requiere que la confirmación del PO se realice después de que haya aplicado pruebas interactuando con la aplicación en un entorno de preproducción. Lo importante es intentar que el equipo de desarrollo no tenga que seguir avanzando mucho más que el próximo Sprint sabiendo que hay una versión de Sprint anterior aún por confirmar en cuanto a posibles flecos. De no ser así, y teniendo varias versiones por confirmar, la gestión de cambios puede complicarse y añadirse ruido durante los Sprints por incorporación tardía de flecos de versiones previas. 

PRA21. Jefe de carácter líder y facilitador en lugar de actitud del jefe autoritario y controlador. Perfil gestor del Product Owner.

Así como el PO debe tener un perfil de cliente, también debe tener un perfil de gestor del trabajo (o del proyecto). Entre las responsabilidades que propone Scrum para el PO encontrados típicas tareas realizadas por un Jefe de Proyecto en cuanto a la gestión de alcance, plazos y costos. Sin embargo, por otra parte se enfatiza que el equipo debe autogestionarse en lo técnico. Por lo tanto, se necesita un PO que sea líder y facilitador más que un jefe autoritario, pues de lo contrario afectaría dicha autogestión que se espera del equipo en cuanto a decisiones técnicas. Es un gran desafío en una transformación ágil la conversión del típico Jefe de Proyectos hacia un perfil acorde con lo que se esperaría de un PO y/o de un Scrum Master. En el caso de PO, ya no debería existir esa autoridad vertical en cuanto a los aspectos técnicos, solo se mantendría en cuanto a las decisiones de negocio y a la gestión del trabajo desde esta perspectiva. En el caso de una conversión hacia Scrum Master, es más desafiante aun pues además de transformarse en apoyo (sin relación de autoridad ni en lo técnico ni en lo de negocio), requiere para ello un profundo conocimiento y experiencia en el enfoque ágil y cómo llevar a cabo la trasformación ágil del equipo.

PRA24. Establecer y comunicar al equipo la visión del producto o servicio y reforzarla regularmente.

Este es otro ingrediente del perfil PO que es muy importante para la orientación del trabajo del equipo de desarrollo. El PO puede mantener el compromiso y motivación del equipo comunicando de forma efectiva su visión del producto y  su estrategia respecto a cómo abordar su desarrollo incremental. Especialmente cuando se producen cambios de prioridades, postergaciones o interrupciones es importante que se expliquen al equipo para mantener alineada la visión técnica con la visión de negocio. Además, el equipo necesita pistas para poder discriminar en su inversión de esfuerzo qué ítems son más críticos para el negocio, y a ellos dedicarle más esfuerzo, ya sea en especificación, en programación y/o en pruebas.  

PRA27. Trabajo centrado en satisfacer pruebas de aceptación acordadas con el Product Owner.

El criterio de éxito al terminar un ítem de trabajo debería estar establecido por la satisfacción de sus pruebas de aceptación, pruebas que el mismo PO podría comprobar, pues se refieren al comportamiento del producto desde una perspectiva externa, de uso del producto. Es más, las propias pruebas de aceptación deberían ser la parte esencial de la especificación de requisitos del producto y según esto deberían estar establecidas antes de llevar a cabo el trabajo de ejecución/implementación de un ítem. n un entorno ideal es el propio PO quien debería especificar en suficiente detalle cada ítem de trabajo que ejecutará el equipo de desarrollo. Sin embargo, lo usual es que el equipo ayude al PO a establecer esta especificación de requisitos y especialmente las pruebas de aceptación que comprobarán que el trabajo realizado ha sido satisfactorio. Cuando no se establecen claras pruebas de aceptación quien ejecuta el trabajo no tiene un "contrato" con lo cual se corres el riesgo de hacer más o menos de lo que se espera. Las pruebas de aceptación acotan el trabajo que debe realizarse. Además, obviamente sirven de guía en para comprobar exhaustivamente que el resultado obtenido es satisfactorio.     

Comentarios finales

Hemos analizado 10 de las 42 prácticas del catálogo Agilev-Roadmap, las más estrechamente asociadas a responsabilidades del PO. Las 10 prácticas son muy importantes de cara a conseguir un mayor y mejor resultado en la transformación ágil. El no poder aplicarlas o no al menos de forma total supondrá una merma en la efectividad de la metodología pero no conlleva que no aplicar el enfoque ágil en su totalidad. Además, como hemos comentado, hay algunas medidas que pueden contrarrestar deficiencias en el PO. Por otra parte, las otras 32 prácticas tienen independencia del desempeño del PO y pueden ser aplicadas por el equipo y con el apoyo del Scrum Master.

"Ser ágil es aplicar prácticas ágiles", mientras más y con más intensidad se apliquen mejor. Pero cuántas prácticas se apliquen y en qué intensidad se aplique cada una de ellas es una cuestión que depende del contexto de trabajo (no todas las prácticas pueden/deben aplicarse). Además, también dependerá del punto en el cual se encuentre la transformación ágil, pues se trata de un proceso un que debería ser progresivo, pues cada práctica conlleva sus desafíos y refinamientos durante su implantación (lectura recomendada: ¿Revolución o evolución hacia la agilidad? ¿Cuál es tú estrategia de Transformación Ágil? ).

Patricio Letelier

twitter.com/yopolt

linkedin.com/in/letelier
agilismoatwork.blogspot.com

agilev-roadmap.tuneupprocess.com/

www.tuneupprocess.com