Prontitud

Cuide a sus Desarrolladores de Software

Las condiciones laborales del desarrollador de software se vuelven precarias cuando el proceso en el cual desarrolla software ignora por completo la naturaleza artística de creación de software y la realidad siempre cambiante de los requerimientos.

Es tan común este dolor entre los desarrolladores de software que desde hace años está circulando este video que expresa las frustraciones cotidianas de los trabajadores del conocimiento.

Discutamos en cada uno de los puntos las herramientas que he usado para solucionar o prevenir estos problemas en las empresas en las que hemos proveído Coaching:

0:13 Estamos en el cuarto mes en un cronograma de cinco meses y recibí los requerimientos finales ayer. (¡Y cambiaron de nuevo!)

Esta es por mucho la queja más popular y dolorosa entre desarrolladores. Sin embargo, antes que entendamos el dolor de los desarrolladores, primero entendamos la naturaleza del software como producto:

El único momento en el que se tendrá requerimientos finales (estáticos) es cuando el producto ya no tenga que recibir ninguna codificación.
La naturaleza dinámica de los requerimientos es natural y requiere un proceso orientado a la asimilación indolora de tales cambios que al mismo tiempo asegure una justa compensación.
Al iniciar el proyecto, una definición de alto nivel de los requerimientos permite que sean: 1) suficientemente generales como para que sean flexibles y 2) suficientemente concretos para definir un alcance contractual.

Esto no significa que estamos destinados a vivir en un completo caos y a merced de caprichos. El concepto de interación (o Sprint como se le llama en Scrum) nos ayuda a manejar esta complejidad:

Un desarrollo incremental iterativo con frecuentes ciclos de retroalimentación a varios niveles asegura entregas de incrementos de software cada iteración, empezando con la primera iteración. El producto resultado de cada iteración hará que el cliente tenga más criterios para refinar requerimientos y prioridades. Una iteración de dos semanas por ejemplo, hará que el cliente reciba valor después de dos semanas de haber arrancado el desarrollo.
Aunque al inicio del proyecto se tienen requerimientos de alto nivel, se deben definir los todos los detalles de los requerimientos para la próxima iteración a ejecutarse.
Los únicos requerimientos que no pueden cambiar son los de la iteración en ejecución. Los únicos cambios permitidos y obligados son aquellos que mejoren el entendimiento de los requerimientos entre el cliente y el equipo de desarrollo. Repito: los requerimientos de la iteración actual no pueden ser aumentados en su complejidad o alcance por el cliente o jefe.
Si a mitad de la iteración los requerimientos cambian, el equipo simplemente perdió media iteración en términos de tiempo. El equipo no puede entregar la misma cantidad de trabajo en la mitad del tiempo. El cliente o jefe debe asumir y manejar el la pérdida de ese tiempo, no el equipo. Si por motivos de negocio los requerimientos deben cambiar, la iteración se cancela y se planea e inicia una nueva.
Excepciones razonables: 1) El alcance de una iteración sí puede aumentar en caso que el alcance actual se termine antes de la finalización de la iteración. 2) Se puede sustituir el requerimiento A por requerimiento B en la iteración en curso siempre que el desarrollo de requerimiento A no haya iniciado y que el planeamiento y desarrollo de B tenga el mismo costo que la complejidad de requerimiento A.
Antes de iniciar la iteración, el cliente o jefe debió haber hecho suficiente trabajo para saber cuáles requerimientos son los que quiere ver funcionando para final de la iteración. De nuevo, estamos hablando de una iteración de dos semanas, si no sabe qué es lo que quiere ver funcionando dentro dos semanas, entonces tiene un problema grave de indefinición de negocio que no debe transmitir al equipo de desarrollo.

0:22 Gasto la mitad de mis días en reuniones sobre cómo tener más trabajo hecho (en lugar de estar trabajando)

Reuniones inefectivas se convierten en un costoso desperdicio. ¡Hágalas efectivas! Piense dos veces antes de convocar a una reunión. Ahora bien, las Reuniones de Retrospectiva son ideales para detectar problemas de rendimiento y definir Puntos de Acción respectivos. El formato y la facilitación de una Reunión de Retrospectiva es vital para su efectividad y lograr los verdaderos niveles de hiper-productividad del equipo. La clave es hacer esta reunión más efectiva, no más larga o más reuniones. También discierna si el problema de rendimiento es falta de capacidades o experticia, si este es el caso, la solución no es más reuniones, la solución es traer al equipo esas capacidades.

0:30 Mi jefe leyó en una revista que los desarrolladores que usan el lenguaje de programación "___" son el doble de productivos. Así que nos compró una copia y cortó nuestro cronograma a la mitad

Scrum define tres roles: Scrum Master, Product Owner y Equipo. El Product Owner define el "qué" quiere construir, el Equipo le informa cuánto costara eso que quiere y define el "cómo" lo hará. El Product Owner establece delimitaciones que obedecen restricciones de negocio como: Debe ser en "tal" plataforma y cumplir con "tales estándares". Cuando el Equipo dice que un requerimiento cuesta "X", el Product Owner no puede decir: "Pues tiene que costar X/2 y se comprometerán a eso". Lo que puede hacer o bajarle la prioridad o seguir conversando con el equipo para ver cómo se disminuye la funcionalidad para que llegue a costar "X/2". Quien se compromete a entregar funcionalidad en las iteraciones dados criterios razonables y consensuados es el Equipo. El Equipo se compromete, el Product Owner nunca compromete al Equipo.

0:49 Todos los días mi jefe cambia de parecer con respecto a qué estamos construyendo

Ver 0:13. Si el problema de fondo es más bien que la visión del producto es cambiante, es un problema de estrategia. Si la visión es cambiante, entonces no se ha definido el valor a crear. Un equipo sin una definición del valor a crear nunca será productivo.

0:56 Papá: Las personas siguen pidiéndome que les arregle el e-mail, así que no tengo tiempo para codificar. Hijo: Mi papá no tiene tiempo para mí

El rol del ScrumMaster incluye el solucionar impedimentos y evitar que distraigan a algún miembro del equipo. El Equipo no podrá cumplir con el compromiso de la iteración si es interrumpido. El Scrum Master es un constante vigilante contra las distracciones de los miembros de equipo, lo cual puede implicar abiertas y francas discusiones con las gerencias por causar retrasos.

1:10 Algunos consultores le dijeron a mi jefe que ellos podían construir nuestra siguiente versión en la mitad del tiempo por la mitad del dinero. Él les creyó pero ellos ya gastaron todo el tiempo y presupuesto y están a medio terminar. Ahora ellos se fueron, y su código es un desastre. Tenemos que arreglarlo y terminar lo que ellos empezaron.

Este jefe de nuevo ignora el criterio de estimación del equipo y se apresura a tercerizar el desarrollo sin determinar la calidad de trabajo que estos consultores pueden hacer. Tercerizar el desarrollo de software es un movimiento estratégico sumamente delicado. Una forma de determinar la calidad del oferente es preguntarle por el historial de métricas Scrum de sus equipos y de las procesos y prácticas ágiles que ya tienen implementados.

No hay comentarios »

Tomemos en Serio el Problema de las Reuniones

¿Cuántas veces ha terminado una larga reunión con la sensación que fue completamente inútil?

Estoy seguro que ha perdido la cuenta y que odia cada vez que lo llaman a reunión: desconcentración de lo que estaba haciendo y aburrimiento.

Scrum establece muy pocas ceremonias: Sprint Planning, Daily Scrum (o Daily Stand-up más adelante veremos por qué estar de pie es vital que sea efectiva), Sprint Review y Sprint Retrospective. El Scrum Master se encarga que estas reuniones sean facilitadas. Si estas ceremonias no son ejecutadas efectivamente de la forma más eficaz, el equipo va hacia la deriva y a aumentar considerablemente los costos de operación.

Debido a que esta es una enfermad ("Reunionitis") generalizada en las organizaciones donde se desarrolla software, compartiré con usted algunos fuertes consejos que me han sido útiles.

Pongámonos serios con respecto a nuestro problema con las reuniones

En alguna oportunidad Seth Godin en un artículo que ya no está online había hablado sobre tomarnos en serio el problema que tenemos con las reuniones mediante los siguientes recomendaciones (con algunos comentarios míos):

Si todos los problemas no son iguales, ¿por qué todas sus reuniones son iguales? ¿Cada problema merece una hora? ¿Por qué hay una extensión de tiempo por omisión?
Exija preparación. Dele a las personas cosas para leer o hacer antes de la reunión, si ellos no lo hacen, sáquelos de la reunión.
Remueva todas las sillas de la sala de conferencias. Hablo en serio. [Los Daily Scrums se hacen de pie con el intención explícita de tener una posición corporal que fatigue, de manera que a los quince minutos de haber empezado la reunión los participantes estén cansados. Los Daily Scrums nunca deben durar más de quince minutos.]
Si hay alguien llega diez minutos tarde que la última persona en llegar, tendrá que pagar una multa de diez dólares a ser depositado el “Fondo para el Café” [es un fondo creado por el equipo para comprar snacks y café].
Lleve un Egg timer a la reunión (yo siempre llevo conmigo mi “Cubo del Tiempo”). Cuando se acaba el tiempo en el timer, la reunión se acabo, no es su culpa, es culpa del timer (no tienen idea cuán poderoso es este concepto).
El organizador de la reunión debe enviar un corto e-mail de resumen con puntos de acción (acciones a tomar) a todos los participantes después de diez minutos de haber terminado la reunión.
Cree un espacio público (una pizarra, o un pedazo de poster grande, o hasta una pagina web) donde permita calificar las reuniones en una escala de 1 a 5 (se refiere a usar una escala psicométrica de Likert de 1 a 5, aunque yo prefiero la escala de 1 a 7 pues hace a las personas a pensar mucho más el criterio de evaluación que las escalas de 1-5 o 1-10) en términos de cuán útil fue la reunión. Una simple caja en donde cualquiera puede escribir un número. Observe lo que ocurre.
Si usted no está aportando ningún valor a la reunión, váyase. Siempre puede leer el resumen después.

Adicional a estos consejos, agrego unos cuanto más:

Haga explícito cuánto dinero está costando la reunión. Sume todos las fracciones de salario por unidad de tiempo de los participantes y hágalo saber a los participantes: “Esta reunión tiene un costo de X por hora”.
Sin ningún temor abandone la sala de conferencias cuando ha transcurrido una hora y la reunión ha sido inefectiva.
No espere a su jefe. Hay muchos jefes irresponsables que piensan que el mundo gira alrededor de ellos. En Costa Rica he notado una relación directamente proporcional entre la altura del puesto organizacional que una persona tiene y la cantidad de tiempo que esa persona llega tarde a una reunión. Si su jefe no ha llegado y todos llegaron a tiempo, empiece la reunión.
Al iniciar la reunión repase los asuntos que efectiva y realistamente se pueden resolver durante la reunión.
Al definir Puntos de Acción, recordar que cada Punto tiene asociado una persona responsable de ejecutarlo y métricas asociadas para determinar que efectivamente fue ejecutado y que cuya ejecución solucionó el problema en cuestión.
Al terminar la reunión, repase todos los argumentos alcanzados, los puntos de acción las personas responsables de ejecutar cada punto de acción.

No interrumpa el flujo mental de los programadores

El último consejo tiene que ver con respetar el flujo mental de los desarrolladores de software. El libro Peopleware documenta este estado mental:
"El flujo es una condición de profundo y casi meditativo involucramiento. En este estado, hay un suave sentido de euforia y uno pierde control del paso del tiempo [...] No hay conciencia de esfuerzo, el trabajo parece solo, bueno, fluir [...]"

En este estado es cuando todo el trabajo productivo se hace. Para entrar en este estado, un desarrollador necesita cierta cantidad de tiempo, una vez allí, cualquier interrupción saca a la persona inmediatamente del "flujo", o de la "Zona" como también se le conoce.

Dicho esto, piense dos veces si vale la pena interrumpir a un desarrollador para una reunión (que al final no cuenta como trabajo productivo, si no como gasto operativo). Y si definitivamente es necesario, trate de hacer la reunión en alguno de los siguientes momentos: al inicio del día, antes de la hora de almuerzo, después de almuerzo o al final del día.

Artículos recomendados:

Meetings Are a Matter of Precious Time.
Meetings and More Meetings: The Relationship Between Meeting Load and the Daily Well-Being of Employees [PDF]

No hay comentarios »

Métricas Scrum: Medidas de Valor y Progreso

Una vez que nuestros clientes finalizan nuestros Talleres de Scrum, el reto más común que encuentran es cómo rastrear el éxito de la implementación de Scrum en la organización.

Cuando iniciamos la tarea de escalar Scrum a nivel organizacional, nos es muy útil la información irradiada de diferentes indicadores que vigilan cómo el valor del software se está entregando en todos los equipos Scrum.

La constante vigilancia e interpretación de esos indicadores en la forma de métricas es similar, en palabras de Jeff Sutherland, a volar un avión de caza de quinta generación mientras se leen la enorme cantidad de sensores. La integración irradiada por los sensores es continuamente integrada por los procesadores del avión y por el cerebro del piloto.

Intimidante ¿no? Aunque puede serlo al principio, el éxito de un piloto consiste en interpretar toda esa información y tomar las acciones correspondientes para cumplir la misión. Nótese que gran parte del trabajo del piloto es responder a sus indicadores de vuelo más que cambiar las lecturas que recibe, las lecturas provienen de sensores.

En la implementación de Scrum, las métricas no son un objetivo en sí mismas y están basadas totalmente en ver desde diferentes ángulos la pregunta: "¿Estamos mejorando nuestra entrega de valor?".

Scott Downey ha publicado un conjunto de métricas para Scrum que considero merecedoras de consideración. El material de Scott puede encontrarse aquí.

Con el fin de explicar las métricas que propone Scott, estableceré un escenario concreto sobre el cual explicar cada métrica.

Algunas de las métricas no se pueden entender separadas de las demás, por lo que debemos que integrar todas las métricas para entender lo que está pasando en los equipos de la organización.

Un detalle delicado de varias de éstas métricas es que usan el esfuerzo real que requirió un User Story contra el estimado. El ir rastreando el esfuerzo real es un gasto general más sobre el proceso por lo que sugiero precaución en el sentido de no descuidar el proceso entero de adopción, cuidado del equipo y entrega de valor debido a que se introduce más costos. Scott sugiere que durante los Scrums diarios se le pregunte al equipo cuántos Story Points el equipo le dedico durante el día anterior a cada User Story de manera que así se rastree los Story Points reales diariamente.

Por otra parte, se obtiene mucho entendimiento de lo que está pasando en la organización cuando se mantiene un histórico de éstas métricas y se analiza su comportamiento Sprint tras Sprint.

Story Points

Las estimaciones que veremos a lo largo de este artículo usan Story Points. La estimación en Story Points se basa en la técnica orignada por Barry Boehm y John A. Farquhar llamada Wide Band Delphi.

En este otro artículo examino porqué estimar en Story Points usando Planning Poker es mejor que estimar en horas en la manera tradicional.

Objetivo

El objetivo es desarrollar un conjunto de métricas mínimamente invasivas que ayudarán a los Scrum Masters a evaluar y aconsejar a los equipos que al mismo tiempo provean valiosos elementos para comprender el rendimiento de equipo y un lenguaje totalmente portable para la comparación de equipos a lo largo de una organización.

[Nota: En este artículo encontrará formulas cuyo tamaño quizá encuentre pequeño. Si es el caso, puede hacerle click derecho sobre alguna fórmula Settings -> Zoom Trigger -> Click esto hará que cada vez que haga click sobre cualquier fórmula, la verá en tamaño grande]

Métricas Propias de Cada Equipo

Éstas dos primeras métricas reflejan Story Points. Debido a que un Story Point es una apreciación de complejidad relativa que los miembros del equipo perciben de los User Stories, es imposible usar estas métricas para comparar el rendimiento de un equipo con otro. Éstas métricas reflejan rendimiento en el contexto del producto que se está desarrollando y el equipo que lo está desarrollando.

Escenario

Con el fin de entender las métricas, crearemos un escenario que engloba los casos contemplados en lo que vamos a medir.

User Story	Estimación Original	Costo Real	Delta
U.S. #1	3	2	1
U.S. #2	1	2	1
U.S. #3	5	8	3
U.S. #4	2	5	3
U.S. #5	8	7	1
U.S. #6	13	12	1	User Story Tomado del Product Backlog durante el Sprint

El User Story #6 no formó parte del Compromiso Original hecho por el equipo durante la reunión de Sprint Planning. El equipo terminó el Compromiso antes de finalizar el Sprint y pudo tomar el siguiente User Story de mayor prioridad del Product Backlog, en este caso el User Story #6.

Velocidad

Yo, como	Product Owner que está tratando de crear una fidedigna hoja de ruta (roadmap) para futuras entregas de software (releases)
necesito	una métrica confiable sobre la cual basar mis supuestos acerca de la tasa de progreso del equipo
de forma que	yo, con mi liderazgo, pueda hacer análisis de ventajas contra desventajas para hacer compromisos bien informados basado en la realidad de las capacidades de la empresa.
Fórmula:	$\sum \text{Estimados Originales de todos los User Stories Aprobados en el Sprint}$

Valor en nuestro escenario: 19.
De esta forma:
$\text{Fecha de Entrega} = \text{Hoy} + \left(\frac{\sum_{k=1}^n \text{Story Points}_k }{\text{Velocidad}} \right) \left( \text{Dias por Sprint} \right)$
donde
$n= \text{User Stories en el Product Backlog}$

Capacidad de Trabajo

Yo, como	Scrum Master que trata guiar a un equipo hacia la Hyper-Productividad
necesito	una forma de medir cuánto trabajo hizo en un Sprint, sea que el trabajo se aceptara en el Sprint Planning o no
de forma que	pueda cuantificar la entera capacidad del equipo, hacer preguntas inteligentes sobre distracciones y tomar acción para optimizar la converción de Esfuerzo a Valor
Fórmula:	$\sum \text{Todo el trabajo reportado durante el Sprint}$

Valor en nuestro escenario: 36.

Métricas Comparables entre Equipos

El cálculo de las siguientes métricas deja en el camino que los equipos estén usando Story Point y ofrecen la capacidad de medir cómo los equipos de su organización están ejecutando de forma comparativa.

Factor de Enfoque

Yo, como	miembro de las altos puestos de liderazgo que no es un miembro del equipo Scrum
necesito	una forma de medir cuánto de la capacidad de cada equipo resulta en un producto entregable, en una forma de comparación entre equipos
de forma que	pueda activamente ayudar a equipos sub-optimizados, inteligente ubicar personal y premiar a nuestros equipos por su duro trabajo
Fórmula:	$\frac {\text{Velocidad}} {\text{Capacidad de Trabajo}}$

Valor en nuestro escenario: 0.52 -> 52%
Ésta fórmula dice cuánto porcentaje del esfuerzo realizado durante el Sprint correspondió a realizar el valor previsto/presupuestado/percibido representado por la Velocidad planeada. Un número interesante para esta métrica está alrededor del 80% significando que el equipo trabajó más de lo planeado pero no por mucho, lo cual es un buen porcentaje de eficiencia para la operación de un sistema no determinístico (cuando digo no determinístico me refiero a la incertidumbre de requerimientos cambiantes y al proceso de creación de software como tal, no al producto de software creado). Un número bajo en esta métrica puede obtenerse por la combinación de dos motivos: 1) Se tomaron User Stories adicionales del Product Backlog antes que terminara el Sprint 2) Se ha dedicado mucho más esfuerzo que el previsto en entregar las User Stories. Un número muy alto (más del 100%) indica una combinación de 1) Se requirió mucho menos trabajo para entregar el mismo valor 2) No se finalizaron User Stories.

Otro cálculo muy útil de factor de enfoque lo propone Henrik Kinberg en su libro "Scrum and XP from the Trenches" [PDF]. Para el Sprint anterior, se calcula el factor de enfoque usando la suma de días hombre de todos los miembros del equipo que realmente se dedicaron a trabajar en el Sprint Backlog:

$\ \text{Factor de Enfoque} = \frac {\text{Velocidad Real del Sprint}} {\text{Dias Hombre Reales}}$

Una vez calculado nos es útil cuando en la reunión de Sprint Planning queremos estimar la velocidad que podríamos tener en el próximo Sprint dado que 1) algún miembro del equipo estará ausente por algún tiempo por algún motivo, o 2) se une al equipo alguien más.
Fácil:
$\ \text{Velocidad Estimada del Sprint} = \left( \text{Factor de Enfoque} \right) \left( \text{Dias Hombre Disponibles} \right)$

Trabajo Adoptado

Yo, como	Scrum Master que trata de guiar a un equipo hacia Compromisos más fidedignos durante cada reunión de Sprint Planning
necesito	una métrica que claramente muestre si el equipo tiene una tendencia a sub-comprometerse y consistentemente tiene que tomar trabajo del Product Backlog antes del final del Sprint.
de forma que	pueda animar el equipo hacia mayores compromisos durante las reuniones de Sprint Planning sin el riesgo de empujarlos hacia el fracaso.
Fórmula:	$\frac {\sum\text{Estimados Originales del Trabajado Tomado del Product Backlog}} {\text{Compromiso Original}}$

Valor en nuestro escenario: 0.68 -> 68%

Trabajo Encontrado

Yo, como	Scrum Master que trata de ayudar a un equipo a hacer Compromisos más fidedignos y confiables durante cada reunión de Sprint Planning
necesito	una forma clara de medir la probabilidad de trabajo inesperado basado en el estimado original de una User Story.
de forma que	pueda ofrecer consejo al equipo sobre hacer Compromisos alcanzables y proveerles advertencia justa cuando ellos aceptan un User Story que probablemente los sorprenderá
Fórmula:	$\frac {\sum\text{Total de Trabajo Reportado por User Story} - \text{Estimado Original}} {\text{Compromiso Original}}$

Valor en nuestro escenario: 0.31 -> 31%
Un buen Sprint tiene un valor de a lo más un 20% es lo deseado en esta métrica, eso, junto con entregar más de 80% del Compromiso.

Incremento del Valor Meta

Yo, como	Product Owner que está tratando de evaluar la eficacia de las direcciones que he escogido para el producto
necesito	una forma confiable de medir la contribución de valor incrementado del equipo Sprint tras Sprint
de forma que	pueda comparar la tasa del equipo del incremento de la contribución al valor a los cambios en los ingresos que estamos generando y ajustar nuestra dirección si el valor que yo estimé no se concretó
Fórmula:	$\frac {\text{Velocidad Actual del Sprint}} {\text{Velocidad Inicial}}$

Si la velocidad del próximo Sprint 24, el IVM es de 126%. Si para el tercer Sprint la velocidad es de 37, el IVM es de 194%.

Exactitud de Estimación

Yo, como	Product Owner que está interesado en crear hojas de ruta confiable, incluyendo fechas de entrega Optimista, Más Probable y Pesimista para iniciativas más grandes
necesito	una métrica que pueda rastrear el margen de error de los Estimados Originales del Equipo
de forma que	pueda multiplicar sus estimados de buena fe por este factor y crear proyecciones de fechas más realistas.
Fórmula:	$1 -\frac {\text{Estimado Delta}} {\text{Compromiso Total}}$

Donde
$\text{Estimado Delta} = \sum_{k=1}^n \left| Real_k - Estimado_k \right|$ y $n= \text{User Stories implementadas en el Sprint}$
De nuevo, un valor de alrededor de un 80% para esta métrica es lo deseable.
En nuestro escenario:
$1 - \frac {10} {36} = \text{73%}$

Exactitud de Compromiso

Yo, como	Product Owner que está interesado en la exactitud de mis hojas de ruta
necesito	una métrica que me informe del margen de error cuando el equipo se compromete a cierta cantidad de trabajo
de forma que	yo pueda utilizar este margen de error para predecir fechas confiables y saber cuándo es seguro cabildear por un mayor Compromiso en cada reunión de Sprint Planning.
Fórmula:	$\frac {\sum\text{Estimados Originales}} {({\sum\text{Estimados Originales}} + {\sum\text{Trabajo Adoptado}} + {\sum\text{Trabajo Encontrado}})}$

En nuestro escenario:
$\frac {19} {(19 + 13 + 6)} = \text{50%}$

Y de nuevo, una valor alrededor del 80% es el ideal.

No hay comentarios »

El ScrumMaster que su Organización Necesita

Vez tras vez me encuentro con organizaciones convencidas del valor de Scrum como herramienta para el manejo efectivo de incertidumbre (y por lo tanto del riesgo) en los proyectos de software.

Sin embargo, una queja reincidente entre mis colegas en el campo de agile coaching & training es que:

Se contratan Administradores Tradicionales de Proyectos para el puesto de ScrumMaster.
Se contratan ScrumMasters solo porque recibieron un taller o curso de Scrum.

En este artículo hablaré sobre las aptitudes y actitudes que un verdadero ScrumMaster satisface cuando se quiere obtener los verdaderos beneficios de Scrum, a saber: completa satisfacción del cliente y un equipo de desarrollo motivado altamente motivado e innovador.

Lo Mismo con Diferente Maquillaje

Algunas organizaciones quieren los beneficios de Scrum, sin en realidad practicarlo:

Sprints de tres meses: El cliente no ve un incremento del producto durante tres meses. Durante tres meses el cliente y el equipo de desarrollo acumulan supuestos sobre supuestos que generan un desagradable y descepcionante proceso de revisión del incremento. Peleas, gritos, búsqueda de culpables y sentimientos de “yo odio mi trabajo” porque tardamos tres meses para darnos cuenta que habían supuestos equivocados.
El criterio de Done no es incluido en las estimaciones: El costo de implementar una User Story tiende a referirse: “Corre en mi máquina” o más deplorable aún: “Ya compila”. Esto genera desagradable sorpresas en los costos, y muy difícil de justificar y comunicar.
El criterio de Done no incluye Quality Assurance ni Quality Control: Sin prácticas de desarrollo de Quality Assurance el equipo llega al “Code Complete” del User Story A y empiezan a desarrollar el User Story B, en algún momento Quality Control aparece y encuentra defectos en A, pero corregir esos defectos significan atrasos en la entrega de B que se está implementando. Resultado: Un producto con pésima calidad, el cliente no entiende porqué, Desarrollo y Quality Control echándose la culpa mutuamente.
No hay equipo: De repente los desarrolladores son interrumpidos o “robados” para que soporten otros proyectos debido a sobre-compromisos irracionales. Esto causa un desenfoque carísimo pues ninguno de los proyectos se terminan entregando a tiempo.
Working From Home: Los miembros del equipo nunca comparten tiempo estando físicamente cercanos unos a los otros en la oficina. [Nota: No tengo muchas cosas buenas que decir a favor de la política semanal fija del WFH para los miembros de equipos de cinco o más personas en donde la intensa colaboración para crear software es obligatoria para lograr alto rendimiento y armonía, en estos casos el WFH es mucho más destructivo que beneficioso: La desincronización es monstruosa y a tantos niveles que no se arregla con “Me mantengo online en el chat todo el día”, “Cuando me necesites me llamas”, “Mándame un correo”. Es el mismo motivo por el que los equipos de cualquier otra disciplina como en el deporte o teatro no hacen “Rehearsing From Home”,“Training From Home” o “Playing From Home”, ningún equipo se construye “From Home”. Y siendo sinceros, esta política se ha hecho famosa en Costa Rica en su mayor parte porque ciertos empleadores querían algo que ofrecer a sus empleados para que no renunciaran por mejores ofertas salariales].
Standup Meetings convertidas en Status Meetings: Esto genera reuniones diarias más largas que 15 minutos, con contenido irrelevante para la mayoría de los asistentes y por lo tanto reuniones aburridas e inefectivas. Nadie está sincronizando nada: Sofía pensaba que Esteban estaba haciendo X así que con ese supuesto hace Y (en realidad Estaban está haciendo Z). Luis está bloqueado hace tres días en un problema que Mario pudo haberle ayudado a resolver en quince minutos.

Los anteriores son algunos de los intentos de poner una capa de spray sobre las mismas viejas prácticas que consideran que desarrollar software es lo mismo que hacer papas fritas.

El ScrumMaster que su organización necesita ha absorbido por completo el pensamiento Ágil y es un agente empoderado de cambio en su organización, no de promoción del status quo.

El ScrumMaster Nominal

En la oferta laboral de Costa Rica no es nada complicado encontrar personas que ya hayan cursado algunos de nuestros talleres o cursos de Scrum, los cuales hacemos regularmente. Esto sin duda es un cumplido para Prontitud: somos la fuerza a nivel regional detrás de la enseñanza y adopción de Scrum.

El valor de un entrenamiento inicial consiste en dar las bases teóricas para empezar a dar los pasos de la Ágilidad en el mundo real. De ahí que nuestro coaching después del curso sea una guía complementaria para lograr ese objetivo.

[anuncio] Asista a nuestros talleres de Certificación Scrum y considere nuestros servicios de coaching de Scrum en español en su organización.

Sin embargo, existe una relación herramienta-talento: un albañil no puede golpear efectiva y eficazmente sin un martillo, pero alguien que posea un martillo no es necesariamente un albañil.

Ninguna organización que busca llenar el puesto de ScrumMaster puede estar satisfecha con alguien que solo haya cursado un taller de Scrum.

Scrum es un excelente marco de trabajo para lograr beneficios que no se lograrían sin Scrum, pero sin un facilitador de Scrum sabio, este marco de trabajo nunca podrá ser implementado.
La sabiduría a la que me refiero sale a relucir cuando hay que decidir qué sabor de Ágil se ajusta mejor a las complejas circunstancias de la vida real. El ScrumMaster sabio sabrá qué principio o práctica en particular de XP, DSDM, Scrum o Kanban se ajusta a cierta circunstancia retadora.

En todo proyecto de software con resultados sorprendentes se puede observar dos fenómenos diferenciadores:

Sobresalientes habilidades administrativas y persuasivas del líder.
Usar como habilitadores vitales los elementos básicos de los procesos Ágiles.

El ScrumMaster nominal es aquél que lo único que tiene de Scrum es el título. Su organización no necesita ese tipo de ScrumMaster.

El ScrumMaster que su organización necesita es aquél que:

Haya entendido que la naturaleza inherentemente incierta del proceso de caracterización del software requiere un pensamiento y un proceso adaptativo de concretización gradual en lugar de un proceso puramente predictivo.
Es inteligente, su mayor arma es su capacidad de raciocinio, su cerebro.

A este respecto, nunca dejan de ser válidas las palabras de David Ogilvy:

“Si cada uno de nosotros contrata personas más pequeñas que uno, nos convertiremos en una empresa de enanos. Si contratamos personas más grandes, en cambio, seremos una empresa de gigantes. ”

[anuncio] ¿Es usted un ScrumMaster buscando una oportunidad de empleo? Contácteme.

No hay comentarios »

Primeros Pasos en la Adopción de Scrum como Estrategia Organizacional

¿Está mi organización lista para lograr una transformación Scrum? ¿Cómo puedo lograr una transformación Scrum?

El interés sobre el mundo de la Agilidad está creciendo sin duda alguna. He identificado tres tipos o fases de interés en la industria local.

Curiosidad: “Se está hablando mucho sobre Ágil y Scrum, ¿qué será eso?”
Impacto emocional inicial: “Parece que Ágil solucionaría nuestros problemas más importantes, pero no lo termino de entender muy bien.”
Determinación: “¡Quiero que mi organización lo implemente!”

La mayoría de organizaciones están entre las etapas de Curiosidad e Impacto Inicial Emocional. Durante estas etapas iniciales, todavía no hay mucho interés en querer adoptar realmente Scrum.

Para llegar a la etapa de Determinación, he visto que se requieren al menos uno de los siguientes factores:

Requerimiento Explícito de Negocio: Usted es un proveedor de servicios de desarrollo de software y un cliente importante, o potencial, está requiriendo prueba de su adopción de Scrum. Este panorama no es nada raro, y menos raro aún es la recomendación (y hasta exigencia) de inversionistas de capital de riesgo para que las empresas usen Scrum.
Por convencimiento propio: Usted ve en Scrum la herramienta que necesitaba para manejar requerimientos cambiantes, cerrar adecuadamente el abismo entre clientes y desarrolladores de manera que el equipo desarrolle lo que el cliente quiere, lograr mayor compromiso de los miembros de equipo o elevar la calidad de código entregado...

Es claro que pasar de “tengo que implementar Scrum” a “quiero implementar Scrum” es vital para facilitar la adopción. Incidentalmente, he observado un gran problema del “tengo que implementar Scrum” en varios proveedores de servicios de desarrollo de software que usan “Scrum” o “Ágil” como argumento de venta y en realidad no han adoptado Agilidad o ni creen en tales cosas, creando una falsa percepción de lo que realmente significa es Ágil o usar Scrum. [Si quiere saber si un proveedor está usando Scrum y a qué nivel, pregunte por las siguientes métricas durante la primera conversación: cuántos equipos Scrum tiene, por cuánto tiempo cada equipo ha mantenida más o menos la mismas personas usando Scrum, cuál es la velocidad de los equipos en Story Points por Sprint, cuál es la capacidad de carga de los equipos, cuál es la exactitud de las estimaciones y de los compromisos...]

Cuando por convencimiento propio se adopta Scrum, un sin fin de preguntas surgen respecto a la forma y velocidad en que la organización debe o puede adoptarlo.

Durante las últimas conversaciones con nuestros clientes de Prontitud, surge a menudo la pregunta: ¿Cómo convenzo al Gerente General (o a mi superior) de que adoptemos Scrum? Esta pregunta es central en el proceso de transformación hacia Scrum. Si su organización no tiene un campeón en las altas gerencias con poder de decisión y económico que defienda y patrocine la adopción de Scrum, le espera un largo y pedregoso camino cuesta arriba.

Cuando me hacen esta pregunta, propongo tres posibles estrategias:

Que me permitan hablar directamente con el superior y hacerles una presentación sobre Scrum. He estado capacitando y viviendo la experiencia Scrum en la vida real, así que mi trabajo “vendiendo” Scrum por su valor real me sienta bien. Se logran sorprendentes resultados cuando la partes de negocios y altas gerencias tienen un claro panorama de Scrum y sus ventajas.
Realizar una Evaluación de Capacidad de Adopción de Scrum/Agilidad. Es más fácil convencer a las altas gerencias a primero hacer una evaluación antes de comprometerse a realizar una transformación organizacional. Esta evaluación me da la oportunidad de encontrar los dolores más grandes que tiene la organización y analizo la eficacia de Scrum para desaparecerlos. Presentar este tipo de análisis es muy convincente. El análisis lo obtengo a partir de conversaciones con los representantes de negocio y desarrollo en donde consigo respuestas a una gran cantidad de preguntas, algunas de las cuales son: ¿Cuánto apoyo hay desde las altas gerencias? ¿Cuánto entrenamiento se hará disponible a nivel institucional? ¿Habrá entrenamiento para el Product Owner? ¿Hay código fuertemente acoplado? …
Establecer un equipo piloto. Cuando las altas gerencias están con cierto convencimiento acerca el uso de Scrum, intento irme por la ruta de hacer un equipo piloto. Busco un proyecto o equipo que tenga criticidad media (desde el punto de vista del negocio) para entonces llevar a ese equipo a usar Scrum y medir los resultados en términos de incremento de valor entregado en cierto período de tiempo. Una criticidad media es ideal porque es lo suficientemente crítico como para que su eventual éxito usando Scrum sea visible (y por lo tanto sea argumento convincente para escalarlo al resto de la organización), pero no tan crítico de manera que los gerentes digan que es muy peligroso intentar algo nuevo en algo tan crítico. Durante el período piloto, 1) la organización entera está consciente que hay un equipo que está recibiendo capacitación y coaching sobre Scrum con el fin de obtener un incremento de productividad en cierta cantidad de tiempo; 2) el equipo irradia información diariamente a todas las personas en la organización.

La transición a Scrum es un esfuerzo intencional institucional y estratégico con miras a resultados concretos. Es un esfuerzo que no se logra con solo leer unos libros de Scrum y unos blogs, requiere entrenamiento y guía. El conocimiento de los libros y blogs proveen un fundamento invaluable, el entrenamiento y guía provee la experiencia para entender el contexto organizacional para realizar la transición de forma exitosa. La transición requiere de una estrategia.

Tags: adopción, estrategia, scrum

No hay comentarios »

¿Scrum sin Product Onwer? Fracaso seguro

Después del AgileFest, tuve una muy enriquecedora conversación con uno de los asistentes al evento con el que pude expresarle varios puntos sobre el rol del Product Owner, los cuales expresaré en este post.

El inicio de la conversación lo marcaron dos realidades:

La adopción de Scrum es un esfuerzo organizacional intencional: Si no hay un "champion", "sponsor" en los altos mandos, es muy probable que el esfuerzo sea fútil. Si el valor de Scrum no es percibido en el upper-management, se está cuesta arriba. Al ser organizacional, los stakeholders experimentan una forma diferente de hacer las cosas. La adopción es arriba hacia abajo, no al revés. Ahora bien, "de arriba hacia abajo" es la consecuencia, la causa es que alguien del upper-managament compró la idea. Tiene sus ventajas cuando todo empieza como un "grass-roots movement" o de “guerrilla” en las trincheras de ingeniería pues la inquietud llega arriba en algún momento y allí se puede convencer a alguien para que apoye la iniciativa para que entonces baje con respaldo.
Fallar en concretizar el rol del Product Owner causa la mayoría de fracasos en adoptar Scrum. Y cuando digo "fracaso" me refiero que el proyecto no cumplió las expectativas, es decir, el proyecto falló.

Elaboraré un poco sobre el Product Owner, y trataré con mi explicación aclarar porqué no tener un Product Owner te lleva al fracaso (hey por eso hay certificaciones/cursos para llegar a ser un Product Owner, imagínese):
Mike Cohn en su libro Succeeding with Agile: Software Development Using Scrum menciona que el Product Owner tiene dos responsabilidades generales:

Proveer la visión.
Proveer los límites o condiciones, las restricciones.

La primera es generalmente clara, pero lo segunda se aborda muy poco.
Sin embargo la segunda responsabilidad es vital pues describe las realidades dentro de las cuales la visión debe concretizarse.
Los límites o condiciones vienen normalmente en la forma de restricciones:

Lo necesito para Setiembre.
Necesitamos reducir el costo por unidad a la mitad.
Debe correr al doble de la velocidad.
Debe usar solo la mitad de memoria que lo que usa ahora.
Y por supuesto, una intrínseca, hasta obvia: No debe tener pulgas [bugs, defectos, seguiré llamándolos pulgas] según lo especificado.

Esas restricciones las da el Product Owner, pero a su vez son restricciones que fueron puestas sobre él por los stakeholders de una u otra forma.

El Product Owner jamás debe permitir que los usuarios finales reciban un "producto pulguiento". Esa restricción de ser claramente transmitida al equipo desde el día uno. Si en la primera iteración el equipo entrega incrementos [User Stories "completos" según el equipo] pulgosos, el Product Owner no los puede aceptar. Él es responsable por eso. Si hay un problema de habilidades [QA, buenas prácticas, diseño, etc..] en el equipo, eso debe escalarse inmediatamente. Usando Scrum, se detecta ese problema muy temprano si no se ha detectado en el momento de conformar el equipo.

Realmente el Product Owner pasa muy ocupado: Recibiendo requerimientos y coordinando con todos los stakeholders, actualizando el Product Backlog, confirmando que las restricciones se están cumpliendo.

Un buen Product Owner es aquel que complementa sus habilidades con Product Management. Como consejo:en algunos casos es más fácil decirle al upper-management que necesitamos un "Product Manager" en lugar de decir ocupamos un "Product Owner".

Espero ser claro en este punto: El equipo de desarrollo no puede transgredir los limites establecidos por el Product Owner, a menos claro, que esos límites sean absurdos, cínicos, imposibles. El equipo no anda por la libre haciendo lo quiere. El equipo debe complacer completamente las expectativas del Product Owner según las restricciones que él establezca.

Y atención: El Product Owner define el "qué" y las restricciones, el equipo define el "cómo". En el ámbito del "cómo" (de nuevo, según las restricciones) el Product Owner no tiene autoridad. El ScrumMaster ayuda al equipo a encontrar un "cómo" que mejore continuamente y lo lleve a ser hiper-productivo.

Product Management

¿Conviene tener un departamento o equipo de Product Management? La respuesta a eso depende si la institución debe crear varios productos de cierto tamaño los cuales deben obedecer a una estrategia institucional que se revise cada cierto tiempo.
Ser un Product Manager es una de las profesiones más difíciles pero importantes. Por eso es difícil encontrar alguien que quiera aceptar un puesto así. Debe construir un producto tomando como entradas:

La estrategia de negocio: "Durante este año iremos en esta dirección".
Las opiniones y requerimientos de los stakeholders, que a veces son varios: Muchos managers queriendo meter la cuchara.
La retroalimentación continua de los usuarios finales.
Las tendencias de mercado. Coordinar constantemente el departamento de ventas y el de mercadeo.
Requerimientos para cumplir con las leyes estatales y regulaciones institucionales internas.
Criterio técnico del equipo de desarrollo.

El éxito de un equipo de Scrum estriba dos factores:

Product Managenement: Una buena definición del Producto y evolución del mismo.
Project Management: Un ciclo de desarrollo de software iterativo incremental basado en la retroalimentación constante y la auto-regulación de un equipo multifuncional.

No hay comentarios »