Etiqueta: agile

Hay veces que es mejor decir que No

Hay veces que es mejor decir que No

Hace un tiempo me contactó un cliente para pedirme que le de una mano acompañando a uno de sus equipos en un proyecto que estaban por empezar. Me adelanto algo de información por mail y agendamos una call. La información del mail ya me levanto algunos warnings: un proyecto de 3 meses con 12 personas en el equipo de desarrollo (demasiada gente apilada en para tan poco tiempo).

La idea del cliente era que yo colaborara haciendo coaching del equipo pues tenían la intención de realizar varios ajustes en la forma de llevar a cabo el proyecto incorporando prácticas ágiles. Ya en la call el cliente comentó que las fechas estaban fijas y que el alcance también estaba bastante fijo. A esta situación se sumaron dos factores importantes: el equipo de desarrollo estaría distribuido y el proyecto era de vital importancia porque era el primero con un nuevo cliente y el éxito de este proyecto definiría la realización o no de siguientes proyectos.

Si bien el proyecto parecía desafiante decidí no aceptarlo porque me pareció que no se daban las condiciones para hacer coaching (al menos como a mi me gusta hacerlo). Cuando acompaño a un equipo (no me gusta el término coaching, me gusta más hablar de acompañamiento) trabajo en la mejora del equipo y eso implica un proceso de aprendizaje que requiere tiempo para experimentar y posibilidad de equivocarse. Pero este proyecto que me proponía el cliente no contaba con un contexto favorable para experimentación y aprendizaje, había una presión muy fuerte para el éxito del proyecto y un conjunto de restricciones que limitaban mucho el margen de acción ante imprevistos y equivocaciones.

Sobre la Agile Practice Guide

Sobre la Agile Practice Guide

Recientemente en un charla con un estudiante surgió el tema de la «documentación oficial de Agile». Con esto el alumno apuntaba a algo así como PMBoK o el SWEBoK pero de Agile. Esa consulta me motivo a escribir estas líneas.

En primer lugar lo que tenemos es el manifiesto ágil que dice y de forma bastante genérica (pero lo que dice es importante). Por otro lado tenemos libros sobre métodos y prácticas específicas escritos por sus propios autores (obviamente también hay libros escritos por terceros, pero el hecho de que estén escritos por los autores podría llegar a darle un peso diferente). Un ejemplos de esto son los libros de Beck sobre XP y TDD. En el caso de Scrum tenemos la Guía Oficial de Scrum escrita por Schwaber y Sutherland y avalada por varias «organizaciones de Scrum».

Pero más allá de métodos en particular, existe la Agile Practice Guide, un libro de unas 180 páginas publicado hace un par de años. El mismo surgió de un esfuerzo conjunto del Project Management Institute y la Agile Alliance. Esta guía es de acceso gratuito para los suscriptores de la Agile Alliance (y estimo que también para los del PMI) pero también puede comprarse en Amazon.

Debo admitir que antes de leerla tenía cierto prejuicio sobre su utilidad y el nivel de «humo». A pesar de eso, la leí y me sorprendí. Personalmente no me aportó mucho pero creo que puede ser un punto de partida intersante para gente que recién se acerca a agile. Más aún, en un punto creo que podría ser una lectura obligatoria. Me pareció muy sano que el primer capítulo es muy explícito sobre las limitaciones de agile en el sentido de que:

  • no es una bala de plata
  • no aplica a todos los contextos/proyectos
  • requiere de ciertas pre-condiciones

Por otro lado también debo decir que tiene un foco en temas de gestión. Apenas menciona a la pasada algunas prácticas técnicas y sin entrar en detalle en ninguna de ellas.

Algunos puntos interesantes que incluye esta guía y que me parece vale la pena destacar son:

  • Trata el tema métricas
  • Dedica una sección importante al modelo de equipo haciendo incapié en Servant Leadership y hablando incluso del rol de Project Manager
  • Provee algunas herramientas de assessment

Agiles 2019: un espacio para los autores latinoamericanos

Agiles 2019: un espacio para los autores latinoamericanos

Tanto en la conferencia Agile, organizada anualmente por la Agile Alliance, como también en la XP, suele haber un espacio de «librería» donde se venden libros de los oradores de la conferencia y también clásicos de agile.

Me gustaría ver algo así en Agiles2019 pero con una vuelta de rosca.

Dado que en la comunidad Agile de Latam hay varios autores de libros de sobre agile y afines, planificaría una sesión (estableciendo de antemano día, horario y sala) para que cada autor presente su libro en 5 minutos (tipo lightning talk). Luego de la sesión cada autor podría vender o regalar sus libros.

Para que esto ocurra es necesario que la organización haga dos 2 cosas:

  1. Difundir la idea ANTES de la conferencia para que cada autor pueda preparar su lightning talk y también para que pueda organizarse para llevar libros en formato físico o para subirlos a algún medio digital.
  2. Reservar el espacio en cuestión (tanto físico como a nivel agenda)

Me parece que en términos de costo/beneficio esta iniciativa sería muy positiva:

  • El costo para los organizadores es mínimo (yo mismo me ofrecería a hacerlo si me dieran acceso a la lista de participantes).
  • Me parece que también es bueno para que los autores puedan difundir su obra
  • Creo que es un aporte de valor para los asistentes, ya que los libros en castellano sobre agile no tienen gran difusión y escuchar sobre un libro de la voz del propio autor creo que siempre suma.
  • Finalmente, si esta sesión se hiciera el primer día de la conferencia podría funcionar como disparador de otras sesiones en torno a alguno de los libros presentados.

Como realmente quisiera ver esto materializado, ya le escribí al grupo organizador de Agiles 2019 para ver si puedo conseguir su apoyo para llevar esto adelante.

Preparando sesiones para Agiles 2019 (invitación)

Preparando sesiones para Agiles 2019 (invitación)

Estamos a prácticamente 3 meses de la conferencia pero no aún no se sabe mucho aunque, dado que es en formato Open Space, tal vez tampoco haya mucho que decir. Será en el Salón Metropolitano de Rosario del 19 al 21 de Septiembre, se esperan unas 1000 personas, será en formato Open Space y ….. listo. Hay algo más de información en el sitio, pero es más bien metadata. Yo ya compré mi entrada en el primer early bird, la misma incluye una remera pero no el almuerzo.

Personalmente no me terminan de convencer las conferencias en formato 100% Open Space. Y mucho menos en la comunidad Agiles Latam, principalmente porque he visto varias sesiones con un exceso de improvisación y muy bajo nivel/calidad.

A grandes rasgos la propuesta es:

  • Lanzar la convocatoria de participantes de esta iniciativa (este post)
  • Hacer una primera sesión online para explicar conocer la iniciativa, confirmar los participantes y definir los sesiones/temas a preparar. A partir de esto empezamos a preparar las sesiones.
  • Hacer una o dos sesiones online de seguimiento y coordinación para asegurarnos de llegar Agiles con las sesiones pulidas y sincronizadas.
  • El punto de partida e hilo conductor de las sesiones será el libro Accelerate, o sea: las sesiones tratarán algún tema del libro
  • Durante la conferencia realizaremos las sesiones planificadas y generaremos el/los entregables.

¿Te gusta el plan? ¿Queres sumarte?:

Volver

Se ha enviado tu mensaje

Sobre Scrum Masters & Project Management

Sobre Scrum Masters & Project Management

Continuando con la cuestión de planteada previamente (el sospechoso rol del Scrum Master…) sobre las responsabilidades extra que suelen recaer en aquellas personas que ocupan el rol de Scrum Master en las empresas de desarrollo de Software, hoy quiero referirme puntualmente al Project Management.

Antes que nada hago algunas aclaraciones sobre Management según Agile:

  1. El manifiesto ágil dice explícitamente que el equipo es auto-organizado, lo cual implica que la estrategia de management es distinta a la tradicional (muchas veces taylorista) y que varias tareas de management recaerán en el propio equipo. No está completamente claro cuales de las tareas de management toma el equipo y cuales caen fuera, eso habilita a que cada equipo/organización lo maneje de forma distinta.
  2. Más allá de que el equipo sea auto-organizado es razonable que el equipo tenga que interfacear/reportar/coordinar en algún punto con la organización a la cual pertenece. Una cuestión clave aquí es como de implementa esa interface respetando la auto-organización del equipo.

Más allá de de estas cuestiones conceptuales lo que suelo encontrarme muy frecuentemente en empresas de desarrollo de software es que una misma persona concentra el rol de Scrum Master y también varias tareas de management. En particular hay 2 escenarios muy comunes: 1) Scrum Masters haciendo Project Management y 2) Project Managers haciendo de Scrum Masters.

1) Sobre Project Managers haciendo de Scrum Masters

Esta es gente viene de una experiencia de Project Management y que ahora que «el mundo es Agile» se metió en Scrum y adoptó el rol de Scrum Master. Como ya tiene una experiencia en management no le resulta difícil tomar las tareas de management que le pide la organización. El gran desafío aquí es que esta persona pueda dejar de lado algunas practicas de management porque está trabajando con un equipo auto-organizado. Situaciones típicas en este escenario son:

  • La Daily Standup convertida en un reporte de estado
  • Ver al Scrum Master asignando tareas
  • Tracking y reporte en término de horas
  • Micro-management
  • Percepción del Scrum Master como Jefe del equipo

2) Sobre Scrum Master haciendo Management

En este escenario tenemos gente que se formó/entrenó como Scrum Master y que adicionalmente se encuentra con que debe cubrir tareas de management para las cuales no tiene formación. En este escenario estoy hablando de personas que llegan a ser Scrum Master luego de haberse desempañado como Developer, Tester o algún otro rol pero no Project Managers. En estos casos, si el equipo no tiene la experiencia suficiente para auto-organizarse vemos sufrir al proyecto: no hay métricas, el equipo no tiene una velocidad de delivery predecible ni estable, el cliente ve mucho post-its que en lugar de ayudar a la gestión generan una sensación de desorden y extrema informalidad, la gestión de riesgos es bastante endeble (si es que se hace), y el equipo no tiene la habilidad/capacidad de manejar imprevistos de ningún tipo, etc.

Como ya mencioné no me convence la estrategia de concentrar las tareas de management y Scrum Master en una misma persona, pero si alguna organización piensa hacerlo, espero que al menos tomen la precaución de asegurarse que esa persona que ocupe el doble rol tenga la apropiada formación tanto para las tareas de Scrum Master como también para las tareas de Project Management.

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

El sospecho rol del Scrum Master en las empresas de desarrollo de Software

Una situación que veo recurrentemente en las empresas de desarrollo software para terceros es que conforman sus equipos poniendo una persona en el rol de Scrum Master y asignandole también algunas otras tareas. Esto genera que en términos generales que la persona en el rol de Scrum Master termine concentrando 3 grupos de tareas:

  • a) tareas de facilitación propias del Scrum Master que podemos resumir como ayudar a que el equipo siga la propuesta de proceso de Scrum, removiendo potenciales impedimentos, etc
  • b) tareas típicas de la gestión del proyecto desde la perspectiva de la software factory como ser: seguimiento del presupuesto, planificación del equipo a mediano/largo plazo, seguimiento de la facturación, gestión de riesgos, etc. Aclaro aquí una cuestión importante: la gestión de presupuesto y del plan son responsabilidades del Producto Owner cuando vemos el proyecto desde la perspectiva de la organización que es dueña del producto, pero estas cuestiones también están presentes desde la perspectiva del proyecto de la software factory.
  • c) tareas de gestión internas requeridas por la organización(software factory) respecto de los miembros del equipo como ser evaluaciones de desempeño, coordinación de licencias, etc.

Lo que me resulta sospecho es la concentración de estos tres grupos de tareas en un misma persona porque me parece que puede haber cierto conflicto. Un caso puntual a modo de ejemplo: se supone que el Scrum Master debería generar un contexto de seguridad para que el equipo y sus miembros puedan hablar en confianza sobre sus dificultades, equivocaciones, etc, pero al mismo tiempo esa persona Scrum Master tiene que evaluar el desempeño de los miembros del equipo ¿cuan seguro puede sentirse un miembro de equipo para hablar de sus equivocaciones cuando ese Scrum Master es también la persona que evalúa su desempeño?

Lo que yo recomendaría en estos escenarios es tener dos personas distintas: una con el rol de Scrum Master (que estaría presente en el día a día del proyecto ) y otra con el rol de gestor de proyecto (con una presencia mucho más esporádica).

Historia de un proyecto (no tan) ¿ágil?

En este momento estoy participando en dos proyectos, en uno tengo un rol técnico y en otro un rol más de gestión. A este segundo caso quiero referirme.

El objetivo de este proyecto es reemplazar una aplicación de escritorio con una aplicación web de manera que esta aplicación web ofrezca algunas funcionalidades adicionales. El equipo tiene varios developers y un tester. Yo me sumé al proyecto meses después del primer release (que llevó un 1 año) con el objetivo de intentar mejorar el flujo de trabajo ya que el equipo venia con algunos problemas de estimación, planificación y ejecución. Si bien el propio equipo decía estar trabajando «de forma ágil» en mi opinión no era así, pero a mi parecer esto no era un problema, ya que trabajar de forma ágil no lo veo como un fin en si mismo, sino como un medio para un fin. Desde la perspectiva del cliente el producto entregado estaba muy bien en términos de usabilidad, calidad, etc, pero el proyecto no estaba tan bien ya que el avance era lento y la fecha de fin de proyecto estaba retrasándose recurrentemente. El proyecto tenia una infrastructura de CI con muy pocos tests automatizados, pero con una importante cantidad de casos de pruebas de ejecución manual. El proceso de deployment estaba automatizado.

Lo primero que hice al sumarme al proyecto fue lo mismo de siempre: observar, preguntar y medir. Luego propuse algunos experimentos en la forma de estimar y planificar. A continuación propuse establecer una cadencia en el proceso de desarrollo, hasta ese momento el equipo hacía iteraciones de 10 días hábiles de desarrollo (coding y testing), lo cual hacía que los dias de review y planning cayeran en días variables. Ajustamos esto y establecimos los lunes (cada 2 semanas) como día de review+retro+planning. Todo esto ayudó a establecer un ritmo estable, predecible y facilitó la interacción con los usuarios. Estos cambios también fueron muy bienvenidos por el Product Owner. Antes cada cambio propuesto volvimos a medir para confirmar si se había producido una mejora concreta o no. La semana pasada acordamos establer una cadencia de release haciendo 1 release por mes.

Continuará…

Sobre el State of Agile Report 2019

Hace un par de dias se publicó este reporte surgido de la encuesta que realiza anualmente la empresa Version One. Los resultados no me soprendieron, al contrario, me resultaron muy familiares respecto de lo que veo en mi día a día.

En el resumen ejecutivo se destacan tres puntos.

1. Scrum (y SAFE) sigue siendo el enfoque agile más popular

No me sorprende y en un punto me parece esperable ya que más allá de las bondades de Scrum, es el enfoque ágil con mayor marketing: Scrum Alliance, Scrum.Org, Certified Scrum zaraza, etc

2. La cultura organizacional es el mayor impedimento para adopción y escalamiento de agile

Me parece esperable considerando que agile es un mindset, una forma de hacer las cosas e incluso un forma de pararse frente a los problemas y desafios

3. DevOps es cada vez más relevante

Tengo la sospecha que esto se debe a que mucha de la gente que trabaja con Scrum, hace en realidad un Flaccid Scrum, o sea, solo aplican la parte de gestión de Agile. Pero en un punto toman conciencia que sin prácticas técnicas varias «promesas de Agile» no son posibles. Pero como ya se gastaron todo el presupuesto de Agile en tomar los curso de «Certified Scrum/Agile XXXX» ahora necesitan otro buzzword para conseguir presupuesto y ahí está DevOps al alcance de la mano.

Libro de Desarrollo Ágil de Software by 10 Pines

Fede Zuppa junto a otros colegas de 10 Pines están escribiendo un libro sobre desarrollo ágil de software. El libro está aún en proceso de escritura pero periódicamente Fede publica versiones preliminares. Tuve la oportunidad de leer una de esas versiones y a pesar de ya estar familiarizado con los temas abordados me pareció un material muy valioso.

Las explicaciones son claras y los distintos temas están presentados desde la experiencia práctica de 10Pines. Aquellos que gusten darle una leída las versiones preliminares pueden encontrarlas aquí.

Libro: Agile Software Requirements

Por estos dias estoy leyendo el libro Agile Software Requirements, de Dean Leffingwell, un libro que compré el año pasado pero que en aquel momento leí apenas algunos capítulos. El libro pertenece a la serie Agile Software Development de Addison-Wesley cuyos editores son Alistair Cockburn y Jim Highsmith. La edición física es excelente, es un libro tapa dura con un formato de página muy ameno a la lectura.

El autor, Dean Leffingwell, ha cobrado cierta popularidad en los últimos años por ser el creador de SAFe, uno de los enfoques de escalamiento de Agile más difundidos en la actualidad. Sin embargo yo ya conocía a Leffingwell por un libro anterior que escribió a fines de los 90′: Managing Software Requirements: A Unified Approach.

El libro propone un enfoque ágil para el manejo de requerimientos a distintos niveles: empresa, programa y equipo. En cierto modo el enfoque propuesto es como una precuela de SAFe (digo esto sin conocer demasiado de SAFe). Aunque aún no terminé de leerlo, me parece que el enfoque propuesto es muy completo sobre todo teniendo presente que inicialmente el foco de los métodos ágiles estaba a nivel de equipo. Me parece importante destacar que el libro no se queda solo en el tema de requerimientos, sino que también tiene capítulos enteros dedicados a temas como arquitectura, planificación y testing entre otros.