[#ALM] 3 Sprints, eso es lo que necesitas para poder comenzar a ser “serios” (y claro … vamos vamos Argentina !!!)

Hola!

Este año, he combinado eventos orientados a developers, con eventos de un calibre más orientado a negocios. La diferencia es grande, sin embargo es increíble como puedes hablar con “el jefe” de un hospital y que vea un framework como SCRUM, que entienda las bases y que en 15 minutos podamos comenzar a hablar sobre como la transparencia puede ayudarle en su día a día.

Nota: lo de “el jefe” es por su presentación personal, resulta que esta persona es el director de uno de los hospitales de más renombre en Europa y tanto CTO, CIO, CEO, CXXXXO la verdad que marea.

Pues eso, que hablando con esta persona me preguntó un clásico de la gestión de equipos,

¿Cuanto tarda un equipo en comenzar a “trabajar bien” bajo este marco?

La pregunta tiene historia. Por lo general, para que un marco como SCRUM funcione, el equipo que adopta este marco debe implementarlo correctamente. Sin embargo, es casi más importante que la organización / empresa o contexto dentro del que trabaja este equipo también crea y adoptelos valores de SCRUM. Alguna vez escribí sobre cómo en una organización es más difícil SCRUM para adentro que SCRUM para afuera.

Dicho esto, y teniendo un equipo que comprenda y adopte los valores y prácticas de SCRUM, la mayoría de los expertos coinciden que 3 sprints es la medida ideal a partir de la cual, un equipo y su contexto comienzan a ser productivos. Esto es idependiente de la duración del sprint, puede ser 1 semana o 4 semanas; lo importante es que las prácticas asociadas al mismo se cumplan y que se realicen bien las retrospetivas, que los POs comprendan su valor al momento de armar y priorizar el Product Backlog, etc. Si has podido trabajar en un equipo durante más de 3 Sprints, verás como la métrica de la velocidad realmente comienza a tener sentido y como el ritmo de trabajo del equipo comienza a ser más dinámico.

Volviendo a eventos de negocio, esta semana estuve en Niza en un evento orientado a empresas de Telecomunicaciones. Y una vez más, me sorprendí al ver como en el mundo de las TELCO, la medida de 3 semanas también se aplica para esos tipos de proyectos. Estuve comentando un tema similar con unas personas que se dedican a crear una capa de … ¿software? sobre unos “routers muy especiales”, y al momento de plantear la posibilidad de publicar sus APIs sobre AZURE API Management, coincidimos en cómo sería necesario un ciclo completo de varios Sprints para poder comenzar a tener una idea seria de un equipo coordinado de trabajo.

En este momento me tocaría “llorar un poco” por mi caso particular. Donde trabajo en proyectos muy rápidos, y donde un mismo objetivo llevado adelante por más de 3 Sprints es una utopía, y ni hablar de un mismo equipo trabajando más de 3 sprints seguidos (equipos elásticos les llamo yo).

Mi experiencia para este caso particular me baso en lo siguiente:

Si bien las personas cambian, es importante tener una o más personas que sean las que lleven adelante las buenas prácticas aprendidas del equipo. Nunca, repito NUNCA, deberías cambiar por completo los integrantes de tu equipo.
Las personas cambian, pero las lecciones quedan. Implementar una Wiki o un repo similar es importante. En nuestro caso, lo que tnemos es un OneNote compartido en OneDrive y la verdad es que da resultados muy buenos.
A menos que conozcas las consecuencias, no fuerces las buenas práctias. Por ejemplo, si decides no implementar un ciclo de CI, debes ser consciente de las consecuencias que ello trae. En mi caso he aprendido estas lecciones de mala manera y tirando muchas horas durante noches para sacar adelante errores personales. Hoy que conozco el contexto y sé a lo que me atengo, un Scrum Master me ayuda a llevarlos adelante.
Es fundamental que la defnición de hecho (Definition of Done, DOD) esté clara para todos, equipo, Product Owner, la señora de la limpieza e inclusive para tu madre. Los equipos cambian, las user stories evolucionan, pero la calidad de lo que se espera entregar NO PUEDE CAMBIAR.
Tampoco es una mala práctica cambiar el DOD. Eso sí, solo entre Sprints, nunca debes cambiar un DOD en medio de un Sprint.
La deuda técnica (Technical Debt) es algo con lo que todavía no me centro. Sé que hay partes de una solución donde estoy sacrificando hoy para pagarlo mañana, y también en determinados momentos nos obligo como equipo a no sacrificar nada. No lo tengo claro. (creo que lo expresé de la mejor forma hace 3 años en Pintando muros, cambiando Pañales, y la Deuda Técnica)
Por último y fundamental, impulsa la comunicación fluida dentro de tu equipo. Utiliza herramientas como Skype o Lync, intenta que sea en su mayoría face to face, etc. Salvo que estes programando SKYNET, seguramente estarás creando una app para personas, y trabajas con personas … todo dicho no?