viernes, octubre 25, 2013

Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR -

Hablamos mucho de deuda técnica dentro de agilismo (cosa sana y buena)

pero que tal hablar de la DEUDA DE VALOR!!!

Veamos..


Dentro de las necesidades de un PO - Product Owner, está el conocer el ROI de su producto (cosa que no es siempre fácil de calcular) y el PO cómo líder estratégico del proyecto  (el cual proporciona la visión y el direccionamiento del producto) debe trabajar en convertir el dinero / tiempo /esfuerzo invertido (el cual llamaré costo) del Team Scrum en un Release usable en producción lo antes posible.

No se trata de salir con un Release del sistema el cual no genere valor (ejemplo, un software repleto de administración de tablas maestras y de CRUDs). Se trata de que mientras el sistema no sea usado para el fin para cual fue creado (plasmado en la visión) y no haya un usuario final dándole clic, todo el esfuerzo de ser ágiles no tiene sentido y bajo este enfoque muy poco sirve:

  • ser equipo Scrum 
  • decir que somos Agile
  • predicar el desarrollo orgánico del software
  • cumplir los criterios DONE!!! de todas las historias de usuario
  • tener cero errores, y deuda técnica en cero
  • etc
El software cobra valor cuando es usado por los usuarios, antes no. (lo he leído, me lo han enseñado y lo he predicado, pero cuesta, a ratos plasmar esto cuesta, por múltiples razones y casuísticas - benditas heridas de guerra - )

En esa misma dirección y con la necesidad de tener herramientas para los PO con los que trabajo, pensé en esta tabla y gráficas, las cuales pongo a su consideración; y si les son útiles para mitigar el riesgo de quedarnos con "la papa caliente" de un software que noes liberado, implicando caer en una de las causas de fracaso de Scrum/Agile, habrán cumplido su misión. (si las usan y les sirven, me cuentan)


A continuación las gráficas y su explicación


Proyecto Ágil que no Genera Valor



Características principales:

  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 0% 
  • probablemente cumple con todo lo que pide el PO
  • pero su comportamiento es igual a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), solo saliendo a producción al final del proyecto y poniendo en riesgo el presupuesto asignado y la reputación del PO.

Riesgos
  • Alta probabilidad de cancelación del proyecto
  • Alta probabilidad de cambio de PO
  • Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (recordemos que Scrum es como las suegras: "Siempre esta señalando tus defectos")

Causas
  • Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se requiere un solo release para el proyecto.
  • Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
  • Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución



  • Coach al PO por parte del SM.
  • Evaluar el Release Plan
  • Proponer en producción algo con valor lo antes posible

----

Proyecto Ágil que Tuvo una Tímida Salida a Producción




Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 13%
  • probablemente cumple con todo lo que pide el PO
  • Se tuvo una salida a producción, pero este afortunado evento no se volvió a repetir.
  • Su comportamiento es muy similar a un proyecto ejecutado bajo el esquema tradicional (Cascada o RUP), y su poco valor generado pone en riesgo la viabilidad del proyecto.

Riesgos
  • Alta probabilidad de cancelación del proyecto
  • Alta probabilidad de cambio de PO
  • Alta probabilidad de cambio del SM - Scrum Master - por no hacerle Coach al PO y guiarlo en los principios ágiles (y el mismo chiste sobre las suegras...)

Causas
  • Un Release Plan en el que existe alta dependencia de todas las funcionalidades según el PO,  Lo más seguro es que se argumente que se salió a producción con lo que se podía pero para cerrar el proyecto requiere el resto resto del producto.
  • Un mal pareto de software vs funcionalidad, o sea,  el  product owner no esta convencido del  80 / 20, en que con el 20% de software es capaz de cumplir con el 80% de necesidades de negocio.
  • Clasificación de funcionalidades como criticas y necesarias cuando estas en realidad no lo son.

Solución
  • Coach al PO,
  • Evaluar el Release Plan
  • Proponer salir a producción con algo lo antes posible
----

Proyecto Ágil que Tiene Salidas a Producción pero aún no Convierte todo su Costo en Valor





Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 50%
  • Se cumple con todo lo que pide el PO
  • Tiene salidas frecuentes a producción pero no logra poner todo el valor en producción.
  • Es un proyecto satisfactorio desde el punto de vista ágil aunque puede mejorar
Riesgos
  • No Aplica.

Causas
  • Existe una buena gestión del PO aunque no se cumple completamente el pareto de software vs funcionalidad.
Solución
  • Evaluar el Release Plan (SM, Equipo y PO) buscando con que elementos se puede salir a producción.
  • Identificar si se esta invirtiendo tiempo en funcionalidades innecesarias.

----

Proyecto Ágil que Tiene Salidas a Producción y Constantemente Convierte su Costo en Valor




Características principales:
  • es un proyecto ágil
  • Porcentaje de costo convertido en valor  (tasa de dinero convertida en valor - valor correspondiente al último sprint) = 88% 
  • Se cumple con todo lo que pide el PO
  • Tiene salidas frecuentes a producción
  • Es un proyecto satisfactorio desde el punto de vista ágil  

Causas
  • Buena gestión del PO
  • Buen acompañamiento del SM y del Equipo

Solución / Recomendación
  • Seguir así y no bajar la guardia.

Quedo atento a su retroalimentación y/o comentarios.




Saludos Ágiles

Jorge Abad


martes, octubre 22, 2013

EVM, CPI, SPI en AGILE / SCRUM

En el mundo Agile / Ágil he notado tres tendencias:
  1. Los que buscan la optimiización, la eficiencia, el ROI, (tipo Jeff Sutterland)
  2. Los que son extremadamente poéticos, que nos les gusta que les hablen de puntos de historia, de horas, de eficiencia, solo de valor como un bien tangible de una manera sobrenatural para el PO (Product Owner)
  3. y los que están /estamos (me incluyo) en la mitad de las corrientes, que creemos que primero están las personas e interacciones que los procesos y herramientas (como lo promulga el manifiesto ágil, - clic aquí), pero que aún así les interesan los índices las métricas para mejorar predictibilidad y lograr equipos más felices y más profesionales.

Este articulo no le gustará a los segundos, los otros dos lo recibirán con agrado. No voy a satanizar ni a exaltar a ninguna de estas tres corrientes, lo que si he comprendido es que cada equipo encuentra las métricas que le ayudan a autogestionarse y a saber si llegan a la meta, a concretar la visión. 

Dentro del  amplio espectro de métricas posibles, y con la necesidad de tener herramientas para medir el avance de parte del PO basados en los lineamientos del PMBOK, hace unos días me encontré con este PDF de Collabnet AgileEVM  clic aquí, donde se explica como calcular el valor del SPI, CPI para proyectos ágiles. A continuación realizaré mi propio ejemplo basado en esta propuesta:


Puntos estimados para el proyecto
250
BAC (budget At Completion)

Presupuesto estimado del proyecto)
 $ 130.000.000 
Puntos totales hasta el momento
60
Porcentaje completado

Puntos totales hasta el momento / Puntos estimados del proyecto

24%
Sprints planeados 
5
Sprints completados hasta el momento
2
Porcentaje pleneado completado

Sprints completados hasta el momento / sprints planeados

40%
 PV (valor planeado)

BAC (2)x Porcentaje planeado completado

$ 52.000.000 
EV (Valor ganado)

BAC x Porcentaje completado

$ 31.200.000 
AC (costo actual del producto)

Total desembolsado, facturado, o pagado por el producto
$ 43.000.000
CPI = EV/AC

índice de desempeño del costo.

Esto se interpreta que por $100 que se invierten solo $72,56 se
convierten en valor para el producto 
72,56%
SPI= EV / PV

índice de desempeño del cronograma.

Esto se interpreta como, que tenemos un atraso del 40% respecto
a lo que deberíamos estar hoy.
60,00%
EAC  (costo estimado final del proyecto - estimate at completion )

Forma de cálculo 1 - supone similar comportamiento del proyecto

EAC = BAC / CPI

$ 179.166.667
EAC  (costo estimado final del proyecto - estimate at completion )

Forma de cálculo 2 - se usa cuando la situación actual
es atípica respecto al futuro, y creemos que la situación se corrige

EAC = AC + BAC – EV

$ 141.800.000
EAC  (costo estimado final del proyecto - estimate at completion )

Forma de calculo 3 - se usa cuando se supone un mal rendimiento
del costo así como la necesidad de establecer una
fecha de conclusión inamovible

EAC = AC + [(BAC – EV) / (CPI acumulativo x SPI acumulativo)].

$ 269.944.444


Es importante tener en cuenta que todas estas son proyecciones que ayudan a saber como esta la salud de la construcción del producto respecto a un plan inicial el cual es una aproximación, una estimación y no un compromiso.

Pero si resulta por ejemplo, que se encuentra valor de negocio en el Sprint 3 (por un costo de $22.000.000) y se decide NO seguir construyendo, crear un Release y salir a producción,  pues se alcanzó el objetivo que se quería con el proyecto, el costo del proyecto es menor ($65.000.000) y  se puede tener un ROI mucho más temprano que bajo el esquema de trabajo tradicional que por lo general solo contempla la finalización del producto cuando se alcanza todo el proyecto con su alcance pactado.

Saludos Ágiles

Jorge Abad

jueves, octubre 17, 2013

Dos post que nos invitan a ser muy buenos desarrolladores y a no menospreciar el arte de escribir líneas de código

Estos dos Post... son de antología

Lo escribieron dos ingenieros que conozco y que son de una alta capacidad técnica, los voy a copiar y pegar acá pues es necesario que esto redunde, que esto cale en la mente de los que se están formando en ciencias de la computación, ingeniería de sistemas, ingeniería informática, afines y tambien cale en quienes las estamos enseñando.

Se que un ciclo de formación profesional no tiene como objetivo un solo fin, pero no tiene presentación que los egresados salgan de carreras de sistemas (y sus afines) y que estos no quieran ver lineas de código "por que ya programaron demasiado en la carrera" como alguna vez lo he oído.

Es una realidad, requerimos buenos y excelentes programadores, pero lo cierto es que muy pocos quieren serlo, o peor quieren dejar de serlo lo antes posible.

------


Muchos caciques y pocos desarrolladores

Por: @GabrielMorrisS - Link: http://gabrielmorrissa.blogspot.com/2013/10/muchos-caciques-y-pocos-desarrolladores.html#!

Hace poco alguien me decía que había evolucionado bastante, que ya no desarrollaba y que dirige proyectos, que es todo un PMP. Casi me pega cuando le mencioné que yo siempre voy a ser un desarrollador, aunque lamentablemente cada vez lo hago menos. 

No me creía cuando le conté que cuando trabajé en unos proyectos en Brasil, el que más ganaba era el tester. Varios se han reído de esa anécdota, pues de inmediato me recuerdan que ese "recurso" debe ser un practicante o un bachiller ávido de conocimiento que ejecute checklists. Falso, el tester no solo hace pruebas, afina y recomienda refactorizaciones, evalúa el comportamiento en ejecución a través de telemetrías, en general tiene cicatrices de guerra, no come cuentos.

En otros escenarios me he enfrentado a discursos acerca del recurso, de fábricas de software, de métricas sofisticadas, de planes tipo bola de cristal, de látigo, como si los desarrolladores de software fueran unos chimpancés que se pueden llevar a alta mar para reducir tributos para que entreguen piezas de software similares a chaquetas o camisas. Que hacemos, el software es arte, lo demás son enfoques comerciales que buscan demostrar teorías de modelos de madurez o medir cuantas veces un "recurso" entra al baño para ser más productivo o contabilizar las líneas de código generadas.

En otros escenarios se muestra a super expertos que se muestran así por certificaciones alcanzadas, expertos de un año de experiencia y 6 meses de manejo de una herramienta. Qué pasará si cambian la herramienta? Si cambian las tácticas, las estrategias, los patrones a aplicar? Será que es mejor tener criterio que un discurso acartonado y poco original? Bien dice el antipatrón de dependencia del vendedor que si su arquitectura son herramientas implicará que no tienes arquitectura.

Otras cosas del hoy, bueno y del ayer es el fastidio a ensuciarse las manos con código miserable. Se buscan más niveles de abstracción olvidándose de niveles subyacentes. Por ejemplo: uso JSF según san X vendedor como MVC, uso como ORM  a hibernate, etc. ¿Qué pasa si ocurre un error en estas APIS? ¿Cómo lo resolvemos? ¿Cómo afinamos las consultas?  ¿Cómo evitamos introspecciones innecesarias? .....otro ejemplo es el uso de flujitos, dibujitos con herramientas que generan código; ¿y si fallan, y si el desempeño no es el esperado?

Hace unos meses un desarrollador tuvo un problema elaborando un servicio Web (mal llamado servicio). La afirmación del personaje era, "no funciona", sin entrar en detalles. El problema consistía en que no seguía un estándar simple de JavaBeans acerca de gets y sets para un bean, Qué pasó? Simple, nos volvimos herramienta dependientes, framework dependientes y nos olvidamos de los fundamentos.

Creemos por ejemplo que un ESB es una herramienta o que un servicio es un servicio Web; simple, los fabricantes necesitan vender y ese es un discurso fácil de mostrar y de aprender por figuras comerciales. Por ejemplo, el ESB es un concepto, una estrategia,  una capa de integración, una guía de arquitectura compuesta de patrones de integración siguiendo un manejo stateless con gestión de recursos orientados a la conectividad, que puede ser implementado a conveniencia y a la medida, no es la super herramienta que centraliza todo el procesamiento de transformaciones o adaptaciones. 

Bueno, y ¿los arquitectos qué? En mi opinión son necesarios. Éstos deben proporcionar decisiones de arquitectura teniendo como base pruebas de concepto PoC, decisiones de diseño de alto nivel HLD que impliquen su desarrollo así como el cumplimiento de restricciones y de los principales aspectos no funcionales. Sin embargo, no creo en arquitecturas de marfil o  BDUF, pues muchas decisiones de diseño detallado se determinan en  el día a día, en el tablero no en modelos que desencadenen generadores de código. Es  necesario un dueño de la arquitectura, un Architect Owner.

Otro punto clave es que conozco muchos casos de empresas de ciudad gótica en donde a las personas de negocio les molesta trabajar con personas de áreas de tecnología. Lo anterior porque ven que no les ofrecen implementaciones que realmente produzcan valor para el negocio, prácticas, sencillas, en tiempos cortos y que den solución a su problemática.

En conclusión, nos preocupamos por el cuidado de la caja, del tiempo, del presupuesto y del alcance, pero no en la generación de valor hacia el cliente quien es finalmente el más interesado en el software, si este le proporciona beneficios. En resumen, es necesario buenos desarrolladores con amplia experiencia, con criterio, que en  muchos casos son conocidos como arquitectos de aplicaciones.

Creo que en países hispano parlantes todos quieren ser abogados, gerentes de proyectos, médicos, pero pocos quieren ser maestros en una actividad específica. De igual manera pasa con los desarrolladores, pues todos quieren ser directores de proyectos o arquitectos en pocos meses.

Espero no herir susceptibilidades ni establecer opiniones fanáticas, es una opinión muy personal: mucho cacique y poco desarrollador.

------------------

Un desarrollador de 20 millones mensuales

Por: Yuji Kiriki


Recibí la llamada de una amiga con la que hace años no hablaba. Con ella trabajamos en un proyecto big bang en el que debíamos automatizar cerca de 30 procesos de negocio hace ya más de 7 años.
Después de ponernos al día, le pregunté el motivo de su llamada. Me dijo que quería saber si ella me podría poner en su hoja de vida como referencia profesional, a lo que respondí afirmativamente. Luego le pregunté si estaba escribiendo software en algún proyecto. Me sorprendió notar un fuerte cambio de tono, casi de indignación e ira; me respondió: “Yo ya no escribo código. Hace mucho que ya no hago eso. Yo ya soy administrativa y estoy Gerenciando proyectos.”
Por otro lado me encontré con un compañero de la universidad. El recién se bajaba de su BMW (no creo que esto indique algo, pero quédense con la connotación esnobista del BMW para efectos de esta entrada). Hablamos, nos reímos y le pregunté a qué se había dedicado. Me respondió con orgullo “nada, usted sabe que a mi me gustaba mucho la parte técnica y era hasta bueno, pero me ofrecieron un cargo Comercial super bien remunerado y ando vendiendo el X producto de esta Y empresa Multinacional Super Reconocida.”.
Esta situación es muy curiosa. En mi trabajo me enfrento a muchísimos proyectos en clientes de varios dominios. A medida que pasa el tiempo me doy cuenta de que las organizaciones esperan más de las plataformas que desarrollamos. Es de esperarse, pues a medida que pasa el tiempo las personas del común van conociendo e interactuando con aplicaciones en línea que cada vez les ofrecen más comodidades, mayores facilidades u optimizaciones en la operación de sus negocios y su vida personal.
Por ejemplo cada vez es más común que nos pidan desarrollos con la disponibilidad de Facebook o con la simpleza y capacidad de respuesta Google. Inclusive nos han pedido colas de trabajo basadas en el comportamiento de Twitter. Es un hecho que los usuarios de las plataformas empresariales ya no son los que otrora se conformaban con lo que se les entregaba y eran completamente ignorantes del potencial de las TI.
Estos mismos usuarios son los que hoy en día se inventan requerimientos funcionales cada vez más interesantes. Y no sólo hablo de la experiencia de usuario, sino de reglas de negocio basadas en la evaluación de miles de eventos; o la detección de fraude en tiempo cercano al real; pueden ser reglas de negocio que se adapten al flujo de transacciones o que se autogeneren dadas ciertas condiciones de negocio. Sobra decir que estos desarrollos representan retos técnicos considerables.
Si el implementador es capaz de entregar este tipo de funcionalidad, el negocio será seguramente capaz de optimizar su costo de operación o de ofrecer servicios más interesantes a sus clientes. Muy seguramente este tipo de funcionalidad le permitirá a la organización diferenciarse frente a su competencia y posicionarse de mejor manera en el mercado. Posiblemente este conjunto de funcionalidades le permita a la organización abrir nuevos mercados o ganar terreno en el actual.
Ahora pregunto: ¿cuánto está dispuesta a pagar la organización por estas funcionalidades? ¿Le importaría que estas funcionalidades de negocio las desarrolle un joven recién graduado, que devenga al mes menos de $2’500.000 y que debe trabajar más de 12 horas al día, incluyendo sábados, para poder cumplir con un cronograma que definió un Gerente de Proyectos PMI y que acortó un VP por política y por mostrar resultados?
No sé en qué momento en Colombia ser desarrollador se volvió un trabajo, al parecer, de segunda clase. No sé en qué momento seguir siendo desarrollador se volvió sinónimo de no haber avanzado profesionalmente. Me sorprende que esto ocurra en el país si en países desarrollados este oficio es de los mejor pagados 1 o es considerado como uno de los mejores trabajos a realizar profesionalmente 2 debido a la autonomía, bienestar y salario que representan.
Es triste, pero no es raro ver las famosas y mal llamadas Fábricas de Software repletas de inexpertos e ignorantes 3 desarrolladores trasnochando de domingo a domingo entregando software hecho de la peor manera por cansancio, siguiendo metodologías rancias (RUP, TSP, PSP, ¿alguien?) y cumpliendo cronogramas políticos. No es raro que me llamen a prestar servicios de consultoría en proyectos donde el Arquitecto no tiene idea de desarrollo de software, pero sí de productos; lo que los lleva a implementar plataformas inviables.
¿Lo más triste de todo? Que estas plataformas supuestamente prestarán servicios a los ciudadanos o en teoría deberían optimizar la operación de una organización para ayudarla a cumplir con sus objetivos estratégicos.
Ah, la estrategia. Estos, podríamos decir, nuevos ricos llamados “Arquitectos Empresariales” que al ser tan “estratégicos” no tienen idea de software ni de tecnología pues saber de eso los ensucia o los avergüenza y terminan comprando productos porque están de moda o porque la competencia también los adquirió. Ríanse los documentos de justificación que se jalan estos personajes.
¿O qué me dicen de algunos Arquitectos que definen Arquitecturas de Solución pero que son incapaces de implementarlas, pues desarrollar software es una labor demasiado operativa y vulgar que debe ser tercerizada en alguna Fábrica de Software en India para que le cobren por hora hombre o punto de función (sólo nombrarlo da ganas de vomitar) y no por valor de negocio entregado?
Es un hecho que las plataformas de software son mecanismos a través de las cuales las organizaciones pueden innovar y pueden apalancar los objetivos estratégicos. Pero si estas plataformas son implementadas por personas sin experiencia o por personas mal valoradas ¿cuáles serán los resultados? ¿Será que esos resultados les alcanzarán a las empresas para lograr la innovación y el apalancamiento de la estrategia que buscan?
Es vital que nuestra industria empiece a entender que construir requerimientos funcionales no es lo mismo que echar cemento y pegar ladrillos (no es peyorativo, sólo quiero dar la connotación de que no es un oficio operativo). Es fundamental que nos saquemos de la cabeza que los desarrolladores son “recursos 4” intercambiables y explotables y que uno es capaz de hacer lo mismo que el otro.
La industria tiene que caer en cuenta que este oficio es profundamente artesanal y que el resultado de un proyecto depende casi en su totalidad de los artesanos que lo construyen. Entre mejor sea el artesano mejor será el producto. Si no me creen que es artesanal, métanse a Github 5 comparen proyectos y saquen sus conclusiones.
Por nuestra parte, como desarrolladores debemos empezar por respetar nuestro oficio estudiando, leyendo, compartiendo y publicando conocimiento. Debemos formarnos en la capacidad de escuchar, de entender y de proponer. Debemos volvernos diestros en entender una idea de negocio y de presentar la mejor alternativa técnica para llevarla a cabo.
Nosotros como desarrolladores somos el puente entre las ideas, las estrategias y su implementación en TI. También debemos esforzarnos por proponer ideas que abran nuevos mercados o que faciliten la penetración de los productos y servicios actuales. Recuerden Software Is Eating The World 6.
Como buenos desarrolladores debemos hacer valorar nuestro trabajo y explicarle a nuestros clientes que no es lo mismo un desarrollador juicioso con experiencia de 2 años que un desarrollador juicioso con 10 años de experiencia.
Imagínense: es como si compararan un experto en preparación de sushi con 2 años de experiencia con un experto en preparación de sushi con 10 años de experiencia. ¿Cuál pieza de sushi será más valorada suponiendo que ambos han invertido el mismo esfuerzo en ser cada día mejores? 7
Pienso que el tiempo nos dará la razón, pues a medida que las organizaciones dependan más de las plataformas de software, más valiosos deberán ser quienes las implementan. No es lo mismo implementar una aplicación que funciona a una que también funciona y que además es fácil de mantener y evolucionar. ¿Creen que la mantenibilidad de una aplicación depende completamente de la Arquitectura de Referencia o de un generador de código basado en modelos? Pues no mi querido Arquitecto PowerPoint. No.
Si los desarrolladores ven que si siguen en este oficio no van a avanzar profesionalmente porque ni la industria ni nuestros clientes los valoran por su experiencia ¿con qué tipo de desarrolladores se implementarán las retantes y poderosas plataformas de software necesarias en el futuro? ¿Con personas que no se han dedicado a ser maestros en su oficio y dirigidas por Arquitectos con asco a programar?
Para cerrar quisiera que me dijeran cómo se imaginan un desarrollador que devenga veinte millones de pesos mensuales. ¿Qué debería estar haciendo? ¿Qué experiencia debe tener? ¿Es demasiado irreal que en Colombia lleguemos a ese nivel?
¡Espero sus opiniones!















sábado, octubre 12, 2013

Una de las claves de Scrum : Fail Fast - Fallar Rápido

Hola a todos...

Cada vez que tengo una retrospectiva con los equipos en los que soy Scrum Master, vivo, comprendo y profundizo más en el concepto del:

Fail Fast

Fallar Rápido


Pues noto que los ciclos cortos de inspección y adaptación, de retroalimentación (Sprints de 2 a 4 semanas), habilitan y potencializan el PHVA - Planear Hacer Verificar y Actuar - (PDCA - Plan Do Check Act - en inglés) y la mejora continua del ciclo de Deming de una manera sorprendente.


Miremos a Scrum [1] desde esta óptica del PHVA:
  • P - Planear = Sprint Planning
  • H - Hacer = Ejecución del Sprint (tiempo que transcurre entre el fin del planning y la review)
  • V - Verificar = Reunión de Review (se identifica si se cumplió o no con lo comprometido, con su respectivo criterio de DONE / HECHO/ REALIZADO)
  • A - Actuar = Retrospectiva, encontrar en cualquiera de los pilares de scrum (Producto, Procesos, Equipo):
    • qué se está haciendo bien, para continuar haciéndolo
    • qué se esta haciendo mal, no tan bien, o se puede mejorar para desecharlo, mejorarlo (kaizen) y/o corregirlo.


Adicionalmente, el hecho de tener que cerrar el ciclo, obliga a parar y presentar el producto en el estado en que se encuentre para el Review, logrando que el Equipo Scrum (Product Owner, Scrum Master y Equipo de desarrollo) aprenda sobre:
  • el cumplimiento de los compromisos adquiridos
  • la transparencia y
  • la efectividad de los cambios y mejoras realizadas (ya sea al Producto, Proceso y/o Equipo) y propuestas en el sprint pasado.


Por lo tanto, tener ciclos de construcción de producto cortos hace que el ejercicio de Scrum lleve al Equipo Scrumfallar rápido y de forma frecuente permitiendo que se encuentre prontamente con las mejoras que impulsarán a todos a tener victorias tempranas y lograr el éxito en el producto que se está construyendo,



El fallar rápido permite al Equipo Scrum a:
  • encontrar los errores pronto
  • aprender de estos errores pronto y no permitir que te acostumbres a ellos
  • realizar un proceso de mejora exploratorio, basado en:
    • encontrar las mejoras a realizar, 
    • proponer las mejoras como hipótesis, 
    • priorizar las mejoras a realizar 
    • construirlas como historias de usuario técnicas, con criterios de aceptación
    • intentar pocas mejoras, en vez de muchas (recomiendo a lo sumo 3, pero obvio existiran particularidades y escenarios en que sean más o menos) 
    • poner estas mejoras como lo primero del sprint backlog [5]
    • ejecutarlas en el próximo sprint,
    • validarlas y adoptarlas o desecharlas
  • comenzar un nuevo ciclo identificando elementos a mantener, nuevas fallas y nuevas mejoras
Nota: Es responsabilidad del Scrum Master ser habilitador de esta mejora continua, aunque es importante aclarar que en un equipo Scrum, la mejora viene de cualquier miembro del equipo (o de los stakeholders), y esta mejora aparecerá tanto en la retrospectiva como en el día a día del sprint.



Este ciclo exitoso de continuo PHVA retroalimentado, es lo que ayuda a que en cada Sprint se identifiquen mejoras simples y sorprendentes de los componentes de Scrum de una manera natural, estimulante e intuitiva, permitiendo la evolución (mejora continua) rápida de Producto, Proceso y/o Equipo.

Recuerdo bien el espíritu de una frase (no recuerdo ni la frase exacta, ni el autor):

Te perdono que falles, lo que no te perdono es que no aprendas


Hasta acá mi reflexión, no quiero ahondar más en el tema, pues pienso que otros lo han hecho mejor que yo. por lo tanto, a continuación copio varios artículos[6], e imágenes que explican mejor este punto de vista.


Saludos ágiles

Jorge Abad.

Referencias

[1] Guía de Scrum - https://www.scrum.org/Scrum-Guides
[2] Mi evolución sobre las retrospectivas en Scrum - http://lecciones-aprendidas.blogspot.com/2013/04/mi-evolucion-sobre-las-retrospectivas.html
[3] Fail often, fail well -http://www.economist.com/node/18557776?story_id=18557776&utm_source=buffer&utm_campaign=Buffer&utm_content=bufferb5099&utm_medium=twitter
[4] Cómo es un día en pixar, según su director dearte -  http://www.enter.co/#!/eventos/campusparty/2013/jay-shuster-narro-en-cpco6-como-es-un-dia-en-pixar-animation-studios/
[5] Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - http://lecciones-aprendidas.blogspot.com/2013/08/seis-6-formas-de-lograr-mayor-velocidad.html
[6] En el link ▼ a continuación  se encuentran las referencias citadas.

lunes, octubre 07, 2013

Management 3.0

Conferencia dictada por Jurgen Apelo en la Universidad Javeriana el 7 de Octubre de 2013.

Una nueva forma de gestión