martes, febrero 23, 2016

Tres preguntas de Nexus

Hola a todos

Hace un tiempo vengo en un proyecto aplicando ciertos principios de Nexus (1), y uno de ellos es la sincronización entre Product Owners, Scrum Masters y Liderés técnicos, entre todos tenemos un grupo de Whastapp (2)  y hacemos  luego de los dailys de los equipos (o sea, diaramente) y a la misma hora, estas tres preguntas:
  1. ¿Qué dependencias se identificaron?
  2. ¿Qué tema crítico necesita ser resuelto?
  3. ¿Qué información desea compartir con otros equipos?
Luego cada cual responde e identificamos un responsable y acciones a seguir.




Espero les sirva, pues a nosotros nos ha servido mucho.

Saludos ágiles
Jorge Abad



Notas, Referencias y Aclaraciones:

  • (1) Nexus es un exoesqueleto para escalar Scrum - es decir, tener varios equipos scrum y un solo backlog -  (ver más acá)
  • (2) Usamos Whatsapp, debido a que tenemos equipos de trabajo en diferentes ciudades.
  • (3) Tweet para compartir la imagen (clic aquí)

domingo, febrero 21, 2016

Equipos Scrum: El equipo es multifuncional, no los team members polivalentes



Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:
  • a verificar el producto,
  • a aprender de estrategia de pruebas
  • a buscar lo que no se ha perdido, 
    • es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
    • adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
    • Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
  • a pensar como usuario
  • entre otras fortalezas de un buen tester
Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:
  • el equipo: pues le reclamarán tempranamente por habilidades que no tiene
  • el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
  • el scrum master: le dirán que por que no removió este impedimento oportunamente
  • el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
  • la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.


Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:
  • Desarrolladores de software
  • Tester
  • Tester automatizador (depende del proyecto y producto)
  • Base de datos (depende del proyecto y producto)
  • Diseñador gráfico  (depende del proyecto y producto)
Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

  •  los testers se apoyan en sus compañeros de desarrollo para probar, 
  • o que desarrolladores enseñan a testers a programar,
  • expertos de bases de datos y desarrolladores
  • etc
 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.



Saludos ágiles
Jorge Abad.



Notas y Aclaraciones:

  • (1) Guía oficial de Scrum (clic aquí)
  • (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores

jueves, febrero 18, 2016

Una reflexión: A mayor presión sobre el equipo, mayor fricción // Una serie de hechos desafortunados


Hola a todos

Les comparto esta reflexión de como nos "perseguimos la cola" en proyectos en crisis, todo comienza cuando estamos atrasados (obvio bajo contexto de alcance, tiempo y costo fijo -llave en mano-) y se decide aumentar la presión sobre el equipo para cumplir compromisos, comencemos pues:



A mayor presión sobre el equipo, mayores carreras
a mayores carreras, mayor fricción
a mayor fricción y carreras, menos creatividad y menor cuidado al escribir código 
menos creatividad y menor cuidado al escribir código, mayores errores
a mayores errores, mayores reprocesos

Opción 1
a mayores reprocesos, mayor demora en generar los entregables
a mayor demora en generar los entregables, mayor estrés y por ende mayor presión.

Opción 2
a mayores reprocesos, mayor desgaste y menos resultados
mayor desgaste y menos resultados, mayor descontento
a mayor descontento, menor cumplimiento del propósito*
y a menor cumplimiento del propósito, mayor deserción laboral**
a mayor deserción laboral, menor capacidad para cumplir el cronograma y compromisos (alcance pactado)
a menor capacidad de cumplir el cronograma y compromisos (alcance pactado), mayor presión sobre el equipo


En últimas a mayor, presión mayor fricción
y en consecuencia menor éxito.

(las opciones 1 y 2 NO son mutuamente excluyentes)



Notas y comentarios:

* El propósito es aquello con lo que nos hace sentirnos conectados con la vida y con nosotros mismos, cuando alguien pierde el propósito comparte expresiones como: "No sé que estoy haciendo aquí", "este luche y luche para nada", etc.

** No falta quien dice: "pues tengamos un listado de personas pendientes por contratar para reemplazar los que se van" convirtiendo el proyecto en una máquina de moler gente. Opinen ustedes si este es el camino

Haz tus proyectos con Ágil
Más #Agile, Más #Scrum

Algunos Tweets sobre Scrum y la Agilidad













domingo, febrero 07, 2016

Otra Responsabilidad más del Scrum Master: Velar por el Proceso Organizacional



Hola a todos

Recurrentemente cuando soy el facilitador/instructor en los entrenamientos de Scrum (de 1, 2, 3 ó 5 días) al profundizar dentro de las tareas y responsabilidades del rol de Scrum Master (1)(2) enumero:

  • Velar por que se cumpla Scrum
  • Ser coach del equipo y del Product Owner 
    • o sea, que cada vez ambos sean mejor en sus roles, tanto en sus interacciones como en las técnicas que aplican
  • Ser líder servicial del equipo
  • Ser removedor de impedimentos
  • Responsable de la fluencia del equipo 
    • que el equipo no se detenga y cada vez tenga más velocidad
  • Agente de Cambio
  • y "Responsable de que se cumplan los procesos organizacionales"
y, ¡oh sorpresa!, todos dicen:

 - ¿como así?,  ¿este último punto también? ¿el scrum master no es como un lobo solitario, un rebelde sin causa en contra del sistema?

Y la respuesta es: - No


Lo cierto es que el SM, en primer lugar vela por que se haga Scrum pero luego no puede olvidarse del entorno en que esta inmerso y debe velar por que el equipo, realice:
  • seguimiento de estándares y procesos de desarrollo, 
  • procesos de infraestructura
  • procesos arquitectura
  • registro de formatos
  • y similares (Nexus, enumera esto como una  de las responsabilidades del "Equipo de Integración Nexus" ) (3)

sin ir en contra vía del manifiesto ágil

Personas y sus interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan (4)

y de el framework de Scrum.



Un buen Scrum Master identificará los impedimentos en esos procesos y herramientas a ser removidos de forma orgánica o paulatina en el tiempo, pero no empezará a decir:

- Como mi equipo trabaja con Scrum, no usamos los repositorios oficiales, ni generamos los registros requeridos, ni seguimos los estándares definidos por la organización, como somos ágiles no tenemos dichas resposabilidades

No, no, no, la agilidad no es anarquía, la agilidad promueve la excelencia desde la autoorganización ydesde la gestión empírica de proyectos basada en Inspeccion y adaptación.


Hasta acá esta corta reflexión.

Hasta la próxima

Saludos Ágiles
Jorge Abad






Aclaraciones y Referencias

jueves, febrero 04, 2016

Todos Terminarán Siendo Ágiles


Hace un tiempo he venido reflexionado junto con mi círculo de amigos de Ágiles Colombia, especialmente con Lucho Salazar (@luchosalazarc) y Leonardo Agudelo (@sweepnoise), sobre que pronto la industria en general, los monstruos de la tecnología, las certificaciones, etc, tenderán hacia el cambio Ágil (Agile) o incluirán en su estilo o títulos algo relacionado con esto (1).


Y el cambio será (esta siendo) relativamente natural y orgánico,  este cambio nace desde TI con:


y nuestro afán en dejar de fallar haciendo en software (pues desde TI, llevamos años y años fracasando y haciéndole perder dinero, tiempo y oportunidad a nuestros clientes, a nuestras empresas y tiempo valioso de familia o descanso a todos los que han (hemos) estado involucrados en proyectos de software) y comenzamos a enfocarnos diferente, a generar valor de forma distinta, a trabajar más en equipo y generar valor en periodos cortos, y este cambio ha hecho que alguien ajeno a TI, diga: "estos locos están haciendo las cosas distinto, por fin funcionan, que podemos aprender de ellos, yo quiero eso mismo para mí y mi equipo".

Pero ¿quién no desea ser exitoso en los proyectos que emprende y usar las técnicas y herramientas más apropiadas?

Y si yo desde otro enfoque, industria, mercado o empresa veo que otros lo están haciendo bien y les esta yendo bien, lo más obvio es que quiera copiar esa buena forma de trabajo y usarla en mi contexto (recordemos que la copia es una forma de innovación).

Ágil, no es sicorigido, es más emergente y orgánico (como lo expresaba arriba) y se va adaptando según se va comprendiendo y se va transformando la cultura.

Si observamos bien:

Entre muchos otros enfoques, vemos que esto no es una moda, que es un enfoque distinto para hacer las cosas y que llego para quedarse.

Yo doy la bienvenida a todos los que se quieran sumar a este esquema, más natural, humano, orgánico, adaptativo y retador de trabajo, enfocado en el trabajo de equipos autogestionados, dirigidos, con propósito, que transforman no solo a las empresas de TI, sino todos los nichos donde se encuentran.

Yo anhelo que hayan muchas empresas que se embarquen en este estilo de gestión y dar resultados más pronto que tarde, tanto por el beneficio de sus empleados como de esos mismos negocios (recordemos que en negocios quien no se adapta y evoluciona desaparece).

Pronto todos trabajaremos con porciones o la torta completa del enfoque ágil, y los beneficios totales o parciales que de este se deriven.

Yo por mi parte me sigo quedando con la parte DEL PRESENTE CONTINUO del Manifiesto Ágil, que reza:

Estamos descubriendo formas mejores de desarrollar
software generar Valor (2) tanto por nuestra propia experiencia como
ayudando a terceros.



Seguiré buscando formas mejores de generar valor, tanto para mi beneficio, los equipos de trabajo en los que participo, como para mis clientes.

Saludos ágiles

Jorge Abad.




Fuentes y aclaraciones:

  • (1) Acuérdense de mi, un día llegará que CMMi tendrá certificación AGILE
  • (2) Modificación que le observé Agustín Villena @agustinvillena
  • Management 3.0. Jurgen Appelo

sábado, enero 30, 2016

Acomodando o Forzando Scrum para Equipos de Testing


Hola a todos (hace tiempo no escribía, discúlpen lo perdido que he estado)

Hoy hablare un poco de como he visto que se hacen proyectos de testing bajo el marco de Scrum o al menos ser ayudados por el marco. Comencemos.


------

PROLOGO

La tradicional forma de ver el software en cascada entre empresas,  en donde:

La empresa “X” construye el software (entregándolo probado),
y la empresa “Y” lo prueba y certifica


Va seguir viva en nuestro entorno por un tiempo más y la causa raíz de esto es sin duda la desconfianza, pues ya sea por procedimiento, requerimientos corporativos de seguridad ponemos a un tercero a que pruebe, generando la calidad de la calidad.*

NUDO

Recordemos, “en Ágil la idea es hacer la menor cantidad de software con calidad que genere el mayor valor de negocio**”, pero muchas veces, debido a estos  esquemas de desconfianza “CASCADIZAMOS ÁGIL” y se cae en que:

  • un equipo hace desarrollo ágil cumpliendo su DEFINITION OF DONE
  •  y otro prueba el DONE del anterior, cayendo en la calidad de la calidad, el proceso y reproceso, y por ende el desperdicio

Bajo esta premisa el equipo adicional de testing – de la empresa “Y” –
dice: “yo voy a probar usando Scrum”


¡ ¡ ¡OMG!!!


Seamos claros, ese equipo usará del framework de Scrum para realizar la gestión del proyecto realizando:
  • Planeación
  • Ejecución
  • Revisión
  • y Retrospectiva
Pero bajo este esquema “LOS EQUIPOS DE TESTING QUE EMPLEAN EL PROCESO DE SCRUM PARA PROBAR, REALMENTE NO HACEN SCRUM” pues Scrum sirve para construir productos, y bajo este esquema solo lo estamos probando.

Pero a pesar de lo anterior, procedamos a homologar lenguaje que equivaldría en este esquema:
  • El Product Backlog es todo lo que hay que probar
    • Casos de uso
    • Historias de usuario
    • Requisitos no funcionales
  • El sprint backlog
    • Es lo que se selecciona a probar durante el ciclo
  • El team es un equipo de testing
  •  Product Owner y Scrum Master conservan sus definiciones.
Entonces cual es la DEFINITION OF DONE de un equipo de testing bajo estas características
  • Todos los casos de prueba de la HU o del CU diseñados
  • Las evidencias asociadas a casos fallidos o exitosos registradas en el repositorio
  • Reporte de incidencias encontradas actualizado.
Y la DEFINITION OF READY:
  • Casos de uso o historias de usuario desarrollados y congelados en un ambiente para testing
  • Documentación asociada congelada.

No dudo que este esquema sea efectivo, lo he visto:
  • Potencializa más el trabajo en equipo, pero no se nota la fortaleza e interacción de un equipo multidisciplinario que construye software.
  • Se mejora la predictibilidad de diseño y ejecución de casos de pruebas

Conclusión

En la medida que hagamos mejor ágil, un mejor DONE (procesos y practicas técnicas que aseguren los productos) estos esquemas comenzarán a desaparecer, al igual que los testers evolucionarán a testers que no solo hacen pruebas funcionales, sino que automatizan, realizan pruebas no funcionales y hacen parte crucial del equipo de desarrollo.



Notas

*si vamos a ser sensatos esto tiene todo el sentido en proyectos donde a la empresa “X” construía el software haciendo cascada, generando grandes cantidades de software, que  talvez entregado a la fuerza y en consecuencia, obligando al cliente a contratar a un tercero que le certifique que lo que le entregaron muchos meses después si sirve.
**y saliendo a producción lo antes posible, para generar el mayor RETORNO DE INVERSION (ROI)