Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Confianza. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Confianza. Mostrar todas las entradas

miércoles, octubre 12, 2016

Dueño de Producto, usted ha sido invitado a la Retrospectiva


El Dueño de Producto, ¡ese ilustre olvidado!

Me preguntan por interno si este personaje debe asistir a la ceremonia de inspección y adaptación. Es una buena pregunta, teniendo en cuenta que hay quienes recomiendan que no sea así o que la participación del Dueño de Producto es opcional en la Retrospectiva.
No hay ninguna buena razón por la cual el Dueño de Producto no deba estar en la retrospectiva. Desde la misma guía de Scrum ya sus autores sugieren que debería participar:
"La Retrospectiva de Sprint es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y de crear un plan de mejoras que sean abordadas durante el siguiente Sprint".
Y ya sabemos que el Equipo Scrum se compone de Scrum Master + Desarrolladores + Dueño de Producto.
Pero más allá de esto, no concibo cómo, sin la participación del Dueño de Producto en esta reunión, sea posible que el equipo en pleno se inspeccione a sí mismo para luego crear un plan de mejoras que nunca estará completo sin la intervención de este actor. Por ejemplo, ¿cómo mejorar la comunicación con el entorno del negocio? El resto del equipo no podría definir la mejor estrategia para lograrlo en ausencia del Dueño de Producto.
Algunos dirán que se define la estrategia en la reunión y luego se la comunican al Dueño de Producto, eso simplemente extendería la retrospectiva, con el riesgo de que él "tumbe" las acciones a realizar por cualquier motivo válido.

  • ¿Y qué pasa si hay problemas con la salud del backlog? 
  • Problemas con la definición de los criterios de aceptación de las historias de usuario.
  • ¿El equipo conoce cómo los usuarios realmente usan el producto?
  • Problemas con la aceptación del incremento sprint tras sprint.
  • ¿El equipo conoce la visión completa del producto, la estrategia de implementación y cómo lo quieren los usuarios?
  • ¿Y qué ocurre si el Dueño de Producto no está el tiempo suficiente con el equipo para responder sus preguntas y clarificar las características del producto? O para proporcionar retroalimentación efectiva.

En fin, muchas son las razones para que el Dueño de Producto sí esté en la reunión. Estas que mencioné son solo algunas. En breve, el Dueño de Producto es protagonista principal en esta ceremonia.
Ahora bien, se me ocurren algunas malas razones por las cuales no debería asistir. Las mencionaré brevemente y estableceré alguna razón sólida para no tenerlas en cuenta:
Lo aburrimos con minucias técnicas. Una retrospectiva no es para profundizar en los detalles de lo puramente técnico.
El equipo de desarrollo y el Scrum Master son de un proveedor y el Dueño de Producto es del Cliente. Entonces dónde queda la confianza y, por consiguiente, la transparencia. Si estamos pensando así, todavía nos hace falta mucho de la Cultura Ágil y de liderazgo. En cualquier caso, esta práctica reduciría mucho la transparencia, necesaria a todas luces en un entorno ágil.
No tiene tiempo. ¡Este es, precisamente, un tema a abordar con él en la retrospectiva!
Así lo hemos hecho aquí y nos funciona. Esta es interesante. ¿Y qué tal si lo hacemos de la otra forma (qué si asista) y vemos la diferencia? ¿Mejoramos o empeoramos? Seguramente será lo primero.
Esta última es la típica cuestión que se enmarca en el empirismo, es decir, aprendemos de la experiencia, como todo en Scrum. Algo que se resume también en eso de "usar o hacer lo que te funciona". Sin embargo, las razones que expuse al principio y muchas otras precisamente nos han enseñado los beneficios de la presencia del Dueño de Producto en la ceremonia.
Entre otras, pero todas absolutamente son "malas" razones.
En definitiva, el Dueño de Producto debería (sí debe) asistir a las retrospectivas, así que adelante. Si como Scrum Master te sugieren que el Dueño de Producto no debe estar en la reunión, te enfrentas a una sintomatología que te indica que falta algo de la base, los valores y principios ágiles, la forma cómo racionalizamos, el fondo de la cultura ágil, más que del mismo Scrum y otras prácticas. --- ¿Y tú invitas al Dueño de Producto a tus retrospectivas? Déjamelo saber en el foro.


martes, abril 26, 2016

Del triángulo de hierro al triángulo ágil (modificado)


Las empresas en período de transformación organizacional se enfrentan a la dicotomía de seguir paradas sobre el triángulo de hierro en lo que se refiere a planificación y gestión de proyectos de software o moverse a una zona que en principio se les parece más al Triángulo de las Bermudas que al área de confort por donde han transitado durante las últimas décadas.

De lo más valioso que hemos aprendido en el desarrollo de software es que muchas de las prácticas y técnicas usadas desde aquella histórica reunión del Comité Científico de la OTAN en 1968 en la ciudad de Garmisch, Alemania y que diera inicio a la Ingeniería de Software como profesión, fueron tomadas a manera de préstamo de otras áreas de la ingeniería y de otras ciencias aplicadas.

Algunas de esas prácticas influyeron directamente en la forma de realizar estimaciones y de planificar proyectos de software. Específicamente, hemos aprendido que no podemos estimar ni planificar proyectos de software como lo hacen en proyectos de la industria de la construcción… ¡a no ser que vayamos  a usar piezas de Lego® para construir ciudades!


Afortunadamente ya sabemos con certeza que la ingeniería de software tiene su propia personalidad. Se trata de un sello que la hace única y que hace que sus practicantes se distingan del resto de profesionales de la ingeniería y de otros cuerpos de conocimiento. Por ejemplo, en su libro Agile Project Management, Jim Highsmith[1] sugirió que si aplicamos el enfoque Ágil al Triángulo de hierro encontraríamos los siguientes vértices:
  • Valor, para el usuario en términos de un producto que se pueda distribuir y cuyo uso genere beneficios para la organización.
  • Calidad, para entregar continuamente valor al usuario en términos de un producto confiable y adaptativo.
  • Restricciones, los ya tradicionales alcance, tiempo y costo, en donde, si movemos uno, usualmente el primero, se mueven los otros dos.
Como dice el mismo Highsmith [2], las restricciones siguen siendo parámetros importantes de un proyecto pero no constituyen el objetivo del mismo. En cambio, el Valor y la Calidad establecen la meta del proyecto y las restricciones mencionadas se ajustan a medida que el proyecto incrementa el valor para el usuario. En particular, El tiempo podría seguir siendo una restricción fija pero entonces el alcance debería ajustarse para entregar el valor más alto posible dadas las restricciones impuestas.


Como nos gusta lo visual, esta otra versión del triángulo ágil de Highsmith nos llega más:


Más allá de este enfoque de planificación y de gestión de proyectos (ágiles), quienes ya hemos trasegado algunos años por los vericuetos, subido a los riscos y caminado por los valles complejos del desarrollo ágil de software, sabemos que todo momento es una oportunidad de mejorar: de mejorar como personas y como profesionales, de mejorar los procesos y las técnicas, de mejorar la calidad de los productos y de incrementar el valor que estos entregan a nuestros usuarios. ¡Es la mejora continua!

Ahora bien, la mejora continua junto al valor y a la calidad forma otro vértice del triángulo, el del resultado. A los agilistas no nos interesa simplemente crear un producto, por más disruptivo o benéfico que este sea. Nos interesa pensar en lo que viene, en lo que llevará al cliente al próximo nivel de optimización, satisfacción y felicidad.

Pero lo más importante en todo proyecto, en todo proceso de innovación o mejoramiento, en todo plan que tenga como propósito el diseño y la construcción de productos (de software), son las personas: la comunicación cara a cara entre ellas, la motivación de todos los individuos que intervienen en el proyecto, la atención continua a la excelencia técnica, la autogestión del equipo y la confianza que la organización deposite en ellas se constituyen en las bases del éxito de cualquier iniciativa que requiera generar nuevos productos o servicios.

Las cosas así, podríamos entonces encontrarnos con esta nueva versión del triángulo ágil:



Referencias:

[1] Highsmith es uno de los 17 firmantes del Manifiesto Ágil

lunes, febrero 16, 2015

“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

Sobre el cambio a ágil, temores infundados y penas frívolas
“No puedes guiar el viento, pero puedes cambiar la dirección de tus velas”

“Las masas humanas más peligrosas son aquellas en cuyas venas ha sido inyectado el veneno del miedo... del miedo al cambio.”
[Octavio Paz (1914-1998) Poeta y ensayista mexicano]

Todavía me encuentro con muchas personas que creen que ‘saltar al ecosistema ágil’ es como en las películas donde después de un ataque al gobierno, a veces por parte de alienígenas, a veces por parte de un gobierno enemigo, se dan a la búsqueda de los jóvenes y niños ‘genios’ de las universidades para que les resuelvan el misterio o le decodifiquen el mensaje cósmico. Lo bueno de esas historias es que siempre hay alguien que lo logra, a veces solo, a veces en compañía de alguien que para lograrlo viola un sinnúmero de leyes y comete muchos delitos en simultáneo. Otros son más facilistas y quieren usar la máquina del tiempo para ir al momento justo antes de que los modelos y enfoques tradicionales salieran a la luz pública y borrarlos de la historia. ¡Eso ya no es posible! Al menos no con una máquina.

Lo bueno de Ágil es que no tenemos que ser súperdotados para practicarlo ni para ser exitosos. Es más una cuestión de disciplina, de ganas, un deseo inacabable de ser feliz (o de volver a serlo) en el trabajo y de juntarse con las personas adecuadas. También es cuestión de pensar un poco, de entender cuáles son los problemas mayores de las organizaciones y de las personas cuando intentan dar el salto a una nueva forma de ver e interpretar el mundo. Hay dolores superficiales, pero también hay enfermedades crónicas cuyos síntomas no son tan evidentes; para completar el cuadro clínico, hay penas que traspasan lo físico y se quedan en lo puramente espiritual, son difíciles de detectar y mucho más de erradicar, de sanar.

Conocer los miedos no solo de los interesados sino también de los patrocinadores, de quienes toman las decisiones, por ejemplo, es un buen comienzo. He encontrado que muchos de ellos/ellas temen no alcanzar el éxito en el proyecto de transformación y quienes no, imaginan o sospechan que pueden perder su lugar en la organización una vez se dé el cambio, asunto que está bastante alejado de la realidad a no ser que la persona no se adapte al nuevo entorno. En este último caso, tendríamos que preguntarnos si en realidad ya estamos en el punto que queremos.

Quizás entonces el entrenamiento y el soporte no ha sido el adecuado. A veces nos quedamos en las áreas de tecnología, cuando ‘Ágil’ es un asunto de toda la organización. El papel del Scrum Master es fundamental en este aspecto y no nos digamos mentiras (al menos no entre nosotros), los buenos Scrum Masters, los verdaderamente buenos, son difíciles de encontrar: ellas o ellos necesitan tener lo que llamamos comúnmente ‘don de gentes’ y también habilidades en lo ágil y también conocimiento técnico y todo esto junto es muy difícil de encontrar en una sola persona.



Algunas otras dificultades ya son ‘clásicas’: cambiar de un enfoque de ‘comando y control’ tradicional a un enfoque de autoorganización, al mejor estilo Scrum, es una tarea espinosa por no decir algo indecible. Este es un aspecto que impacta a los mandos medios de una compañía, por ejemplo, a la habitual oficina de proyectos o PMO que llaman en algunos entornos. Es precisamente en esta oficina donde comienza el cuestionamiento de lo que puede ser y no es: ¿entonces qué hago con todos los gerentes de proyecto que tengo? He escuchado decir. Encontrar una justificación válida para esto es arduo, imposible dirán algunos. Pero en general, todas las personas tienden a sentir miedo, por aquello de los equipos multifuncionales, donde el poder de la especialización de una persona se pierde. En este mismo orden de ideas, abandonar la falsa seguridad que dan los planes a mediano y, sobre todo, a largo plazo, que nunca han funcionado, en pro de planes a corto plazo, es algo que enciende las alarmas de más personas en la organización de las que quisiéramos contar. Miedo al cambio, natural por demás, es el tema de fondo.

Algunos otros obstáculos que he encontrado:
  • Conseguir que las áreas del negocio y la alta dirección se involucren efectivamente
  • Lograr la confianza y la autonomía que requieren los equipos ágiles y, sobre todo, el equipo de transformación
  • Qué hacer con la jerarquía existente en las organizaciones donde el escalafón de las personas es algo ‘valioso’, es una pregunta que deberíamos responder al iniciar el cambio
  • Crear, preparar y promover un equipo ‘colonizador’ o mejor aún, un equipo ‘conquistador’, punta de lanza, que se atreva a hacer las cosas, a ir más allá de donde nadie en la compañía ha llegado. Este es un asunto vital.
  • Desaprender los hábitos del desarrollo en cascada, del comando y control, del esperar a que me digan qué hacer, del llenar documentos por llenar y todos esos aspectos que aborda el manifiesto ágil en toda su extensión. Sobre este asunto, los invito a leer: ‘Respuesta al cambio sobre seguir al plan: no planearás’, aquí mismo en este Gazafatonario.
  • No intentar cambiar a las personas que no quieren cambiar. La naturaleza humana evade el cambio o se resiste a este cuando alguien intenta cambiarla. Cuando la dejan en paz, cambia por sí misma… ¡si quiere!
  • Finalmente, pero no menos importante, cambiar la cultura de la compañía, en ágil todo es acerca de la cultura. Pero sobre esto pueden leer mi artículo: ‘Cultura ágil: ese oscuro objeto del deseo’, aquí mismo en mi Gazafatonario.
  • Más allá de todo, recordar que ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

Cambia... Hay un gran chance de que el nuevo día sea radiante.



miércoles, julio 16, 2014

Certificar un proveedor como Ágil o de la 'Agile Certified Provider Alliance'

Generalmente ganamos la confianza de aquéllos en quienes ponemos la nuestra.” [Tito Livio]
Certificar un proveedor como Ágil o de la Agile Certified Provider Alliance
Hace algunos días, nuestro amigo y colega Jorge Abad decía en un mensaje a la Comunidad de Ágiles Latinoamérica:
Me hacen esta pregunta desde una empresa del estado que realiza grandes contrataciones de proveedores: ¿Existe una lista de chequeo estándar para validar si una empresa es ágil y usa las prácticas de ingeniería adecuadas para ágil?
Al margen de que sea o no una empresa del estado, la pregunta tiene su truco. En cualquier caso, esta fue mi respuesta a Jorge:

Watts Humphrey, el padre de CMMI, decía que certificarse CMMI 5 significaba que tu siguiente proyecto iba a ser exitoso. Él no decía nada de los demás proyectos. Es natural, la organización recién certificada “respiraba” CMMI, calidad, procesos, productividad y motivación, algunos de los elementos clave para el éxito de los proyectos.

¿Pero y los demás proyectos, los que siguen a continuación de ese?

Igual sucede con Ágil. Aun si el cliente visita al proveedor potencial, este último le puede demostrar a aquel (¡a no ser que sea una visita sorpresa!), que es Ágil.

¿Pero y los demás proyectos? [Acá entre nos, no existe ninguna posibilidad de que una lista de chequeo sirva para probar que un proveedor es ágil. Existen listas como esta de Henrik Kniberg (http://goo.gl/QnQUN), una herramienta para evaluar una implementación de Scrum, tratar de encontrar algo más allá es una utopía.]

Quienes hemos navegado por los vericuetos, a veces inescrutables, de las certificaciones de todo tipo, que nos proclaman como los poseedores del vasto poder del conocimiento y la experiencia, sabemos que eso no es suficiente y que, en muchos casos, eso no garantiza el éxito. Sobre todo, en nuestras economías tercermundistas, con nuestra idiosincrasia, con nuestra forma de ver el universo.

¿Qué vale entonces?

¡La confianza!

Aun una entidad del gobierno, debe dar el salto y modificar su “modus vivendi” (Sí, lo sé, no es fácil –pero igual, aun una entidad del gobierno debe saber que “ser ágil no es solo cosa de sus proveedores”, la organización también debe transformarse), para que pueda ser capaz de hacer pilotos, evaluar los resultados y luego sí, ajustar con el probable proveedor o desecharlo de una vez por todas y para siempre, condenarlo a 100 años de soledad, esa fatídica maldición de los que no tienen una segunda oportunidad sobre la tierra.

Incluso quizás unos cuantos sprints no serán suficientes. Más aun, ¿cómo comprobar al final de varios proyectos si tu proveedor es ágil? ¿Acaso es posible probar que parte del equipo no es ágil (el equipo de desarrollo –del Proveedor) y parte sí (acaso el Dueño de Producto y quizás el Scrum Master –del Cliente)?

Estaba reflexionando con toda esta perorata y mi conclusión es que no es posible, al menos no tiene mucho sentido que este cliente del estado, o cualquier otra empresa privada o de gobierno, evalúe si un proveedor es ágil.

Quizás el proveedor sí es ágil, pero cuando se junte con el cliente deje de serlo.
Quizás no lo es, pero cuando se junte con el cliente aprenda a serlo.
Quizás sí lo es y cuando se junte con el cliente, siga siéndolo.

En fin, las posibilidades son variadas.

¡Estamos de vuelta en la Confianza! Martín Alaimo, dice en su libro “Equipos #MásProductivos”, citando a su vez a Gorerg Simmel, que “La confianza es una hipótesis sobre la conducta futura del otro” y más adelante él mismo dice: “La confianza que inspiro en otros sobre mí, la construyo y la sostengo a través de mis acciones.”

Algunos miembros de la Comunidad le respondieron a Abad que era una cuestión de “feeling”. Yo, por ejemplo, tuve varias novias (2 al menos) antes de quedarme con quien es mi esposa, no era la más bonita pero sí la que más confianza me generó. Y eso, mi estimado Jorge, no se consigue con una lista de chequeo ni con una visita a casa de los padres de la novia. ¿Quién sabe? Quizás mañana me divorcie.