lunes, enero 30, 2017

La Ilusión del Control o ¿Cómo Hago para Controlar un Proyecto Ágil?






Hola a todos

Dentro de las muchas ocasiones en las que comparto con clientes, equipos, product owners, scrum masters o personas que van a comenzar a trabajar en Agile una pregunta recurrente es:

¿Cómo hago para que el proyecto no se salga de control?


Vamos por partes entonces:

¿Qué se quiere decir con la pregunta?

La Rae define control como (Ver definición - clic aquí):


y cuando un cliente o gerente, lider funcional, product owner, o gerente de proyecto pregunta esto se refiere típicamente a esto:

¿Cómo hago para que el proyecto no cueste más, no se demore más, se construya realmente lo que se requiere o no se quede eternamente consumiendo recursos(1)?

Poniendo este tema en blanco y negro, comencemos.

No es que exista mucho control con los proyectos en cascada 

En el informe del caos los proyectos en cascada no salen muy bien librados versus los ágiles, los cuales muestran un resultado más satisfactorio en cuanto tiempo y costo.(https://www.infoq.com/articles/standish-chaos-2015 )



Dado esto:
  • La probabilidad de cumplir estas expectativas es más alta en Ágil que en Cascada, ahora respecto a que el proyecto se vaya a desbordar el problema existe en cualquiera de los dos enfoques, el problema radica en el mecanismo para estar informados si vamos a lograr o no la meta propuesta y reaccionar a tiempo.
  • Los proyectos en cascada cuando se salen de control - de tiempo o costo- (el alcance lo tienen garantizado, tal vez se construya lo que NO se necesita - como ocurre en muchos casos - pero esta garantizado el "qué") o costarán más o nos demoraremos más (ambas son dinero para alguien), el punto clave es que tan diestro es el proveedor para gestionar los cambios:
    • si el proveedor es experimentado o tiene un buen gerente de proyectos el sobrecosto lo asume el cliente, sino 
    • el sobrecosto lo asume el proveedor, caso más común.
  • En cascada (y muchos lo hemos vivido) el proyecto y el cronograma va bien hasta la parte de análisis (como diría un conocido mío: "el papel aguanta todo", todo se complica cuando comienzan las fases de desarrollo, la fase de pruebas con informes de avance que del 90% luego a las tres semanas 90.3% , a las 4 semanas 90.38% y el proyecto se demora un 90% del tiempo cerrando el 10% faltante del alcance (fruto de la procrastinación o postergación del proceso en cascada) y si logramos entregar el proyecto terminamos entregando el producto tardíamente a nuestros clientes o al mercado, tal vez cuando ya no lo necesitan o cuando las condiciones iniciales que dieron origen al proyecto cambiaron.
La verdad, a lo anterior yo no llamaría control


Cómo se "controlaría" un proyecto en ágil

Ahora respecto a la comprobación, inspección, fiscalización, intervención. del cual habla la RAE, se tienen varias soluciones:

1. La Transparencia

En ágile nos enfocamos en valernos de radiadores de información que nos permitan tomar decisiones informadas y todos conocer como está el proyecto y producto en cualquier momento:

  • Burndown chart del Sprint
  • Burndown o burn up release (clic aquí)
  • Flujo Acumulativo
  • Velocidad
  • entre otros

2. La brújula de la agilidad es la simplicidad

Comencemos recordando el décimo principio del manifiesto ágil:

la simplicidad o el arte de maximizar la cantidad de trabajo no realizado es esencial

Decifrando este juego de palabras podemos parafrasearlo diciendo

Nuestra mayor prioridad es NO generar ni software ni trabajo de desperdicio (o hacer algo que terminará siendo inutil)


3. En Scrum existen tres roles que te pueden ayudar a tener "control" de tu proyecto / producto, en cuanto tiempo, costo y alcance.

Product Owner (PO)
En primer lugar el PO es quien esta encargado dentro de sus funciones de dos aspectos claves:

  • ROI (Return On Investment): Preocupado por salir a producción con la menor cantidad de software posible que solucione el problema de negocio
  • DECIR NO (5): El PO al negociar con los stakeholders (interesados) les debe decir para ciertas funcionalidades:
    • eso no se puede hacer aún, 
    • necesitamos generar valor con lo mínimo posible
    • eso va para otra versión o release
    • eso aun no tiene prioridad
    • entre otras.
Es decir la misión del PO es mantener el Backlog de cada release lo mas pequeño posible de forma que se genere valor con la menor cantidad de software.

Scrum Master (SM)
El otro rol es el Scrum Master, este es el coach del PO y estará atento a que quien esta ejecutando este rol lo haga bien y este preocupado sanamente por mantener un product backlog refinado y priorizado.

El Equipo Desarrollador (Development team, o equipo solucionador)
Y por si fuera poco, es una buena practica que cada Relase tenga un objetivo (3)(4), por lo tanto cuando el PO este "corrompiendo el alcance" - como dicen el el mundo PMBoK - por añadir lo que no es clave para el proyecto, tanto SM como Equipo Desarrollador se lo harán ver.

Adicionalmente existe el Review
Cada sprint (ciclo de trabajo entre 2 y 4 semanas) el equipo Scrum - PO, SM y Equipo Desarrollador -  más los Stakeholders del proyecto se reúnen a ver el demo del sprint -a ver software funcionando cumpliendo la definición de terminado- , ha realizar inspección y adaptación sobre el producto y a decidir como seguir avanzando sobre el mismo, de manera que no hay sorpresas y el progreso o no progreso es evidente para todos.

Y si es que lo anterior no funciona
Ahora si ves que el proyecto no lo va a lograr..
  1. Desde las primeras dos semanas tuviste software funcionando 
  2. Suspende el proyecto y fin de la historia.

Cerrando

Los proyectos y productos que son construidos con el enfoque ágil pueden darnos suficiente información sobre su estado y nos permitirán tomar decisiones informadas sobre el éxito y fracaso de los mismos,  depende de nosotros emplearlos o no. En cascada si decides interrumpir el proyecto es probable que no tengas al final ni siquiera software funcionando pues depende mucho de la fase en que se interrumpa o finalice abruptamente el proyecto

Hasta acá esta pequeña reflexión, espero sea útil.

Bienvenido el feedback y sus comentarios

Saludos ágiles

Jorge Abad

Referencias, Comentarios, Notas y Aclaraciones

  1. Entendiendo recursos como dinero y tiempo invertido por las personas o empresas
  2. http://agilemanifesto.org/iso/es/principles.html
  3. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum?-  http://www.lecciones-aprendidas.info/2016/04/la-zona-del-valor-de-negocio-una.html 
  4. Go Product Map -  http://www.romanpichler.com/tools/product-roadmap/
  5. Este post está altamente relacionado con este: El valioso "NO" del Product Owner



lunes, enero 23, 2017

Algunas Frases para Product Owners

















































jueves, enero 05, 2017

Mi punto de vista: ¿Bimodal un punto medio entre la agilidad y la predictibilidad?


En la actualidad la Banca, los Seguros (y hace algún tiempo el Transporte, La Hotelería) entre otras industrias están sufriendo grandes cambios debido a la fuerte disrupción digital (1), la velocidad a la que está avanzando la tecnología, la economía, las comunicaciones es tal, que "estos negocios cambian o se convertirán en otro caso de estudio" (ver tweet).

Como medio de apalancamiento las organizaciones han decido abrazar la agilidad como herramienta para enfrentar el cambio, pues en sus fundamentos y pilares están los factores de éxito de los negocios que están cambiando las reglas de juego. Por lo tanto, no se adopta la agilidad como una evolución natural hacia la generación de valor en periodos cortos con equipos multifuncionales y felices (cosa impensable y que no estaba en el core de sus intereses), sino que se llega a ella como salida hacia la supervivencia, razón por la cual muchas organizaciones quieren comprar la agilidad por kilos, sin comprender que se requieren esfuerzos para transformar la cultura para lograr ser exitoso en este enfoque.

Debido a esto - es mi observación -  es común ver como organizaciones al hablarles de Agile, preguntan más sobre bimodal,
"Bimodal is the practice of managing two separate but coherent styles of work: one focused on predictability; the other on exploration. Mode 1 is optimized for areas that are more predictable and well-understood. It focuses on exploiting what is known, while renovating the legacy environment into a state that is fit for a digital world. Mode 2 is exploratory, experimenting to solve new problems and  optimized for areas of uncertainty. These initiatives often begin with a hypothesis that is tested and adapted during a process involving short iterations, potentially adopting a minimum viable product (MVP)  approach. Both modes are essential to create substantial value and drive significant organizational change, and neither is static. Marrying a more predictable evolution of products and technologies (Mode 1) with the new and innovative (Mode 2) is the essence of an enterprise bimodal capability. Both play an essential role in the digital transformation."  http://www.gartner.com/it-glossary/bimodal/

pues no quieren soltar el esquema tradicional y quieren poner un "if o condicional" para determinar cuando adoptar el uno o el otro, pues no entienden los beneficios entre Ser Ágil y Hacer Ágil. (obvio para eso estamos los de este mundo para ayudar a comprender esta diferencia)



¿Por qué entonces trabajar en Agile?

Existen varias razones

  1. La ley de la incertidumbre de los requisitos: “Para un nuevo sistema de software, los requisitos no serán completamente conocidos hasta después de que los usuarios hayan usado el sistema" Watts S. Humphrey” (3)
  2. La incertidumbre inherente en productos y procesos de software "“La incertidumbre es inherente e inevitable en los procesos y productos del desarrollo de software”(3)
  3. La cantidad de software de desperdicio que se construye en cascada (4)
  4. La inestabilidad de los requisitos y su volatilidad convirtiéndolos casi en material radioactivo que se degrada con el tiempo. Actualmente el tiempo promedio de vida de un requisito está en 6 meses- o tal vez o menos -.(5)
  5. La velocidad de cambio en el mundo de los negocios (1)
  6. La posibilidad de ver el producto funcionando en dos semanas o menos y poder redireccionar y repriorizar hacia el problema que quiere resolver el producto de software que vamos a construir.



Para complementar comparto algunos links a post comparativos:

  • Por qué los Equipos Scrum son más “rápidos” que los tradicionales. Un enfoque desde Lean Software Development (clic aquí)
  • Waterfall vs Agile (clic aquí)
  • Gráficas Ágil vs Tradicional (clic aquí)
  • El Lego y la plasticidad del software (clic aquí)


En que proyectos se recomienda cascada

Gráfica de Henrik Kniberg
Sugiero se cumplan ciertas premisas
  • El cliente sabe exactamente que es lo que quiere
  • Los desarrolladores son conocedores del negocio y de la tecnología
  • No haya incertidumbre, se sabe exactamente lo que se quiere
  • El tiempo transcurrido desde que el proyecto comienza el tramite para su aprobación y la finalización de su desarrollo es inferior a seis meses, de forma que se evite la corrupción de requisitos por el tiempo de levantamiento o identificación de la necesidad superior a seis meses(5)
  • Yo sugiero proyectos de máximo tres meses cuyos requisitos no tengan más de 3 meses de haber sido levantados.

Además recordemos que:



Concluyendo


Dado lo anterior, la inestabilidad de requisitos, el entorno cambiante, la incertidumbre reinante, y la sugerencia de realizar proyectos en cascada para periodos menores a tres meses, observo que:
  • El enfoque bimodal es más una herramienta de transición entre modelo tradicional o cascada al modelo ágil, que un "if-condicional" para clasificar diferentes tipos de proyectos, pues por un tiempo, ambos modelos convivirán- ágil y cascada- (6), y llegará el momento en que la organización concluya por sus propios medios si es conveniente que sigan ambos o desaparezca uno de los dos.
  • El modelo bimodal no es sostenible en el tiempo, pues la evolución los sistemas existentes requerirá de repriorizaciónes de backlog en los cuales ágil es mucho más eficiente.
  • Para que el modelo bimodal sea exitoso requeire de  procesos ágiles de priorización y aprobación de proyectos, sino cuando se construyan ya sea los proyectos tradicionales o ágiles será tarde para el negocio o el mercado.
  • Es importante hacerse acompañar por quienes tengan experiencia en ágil para no fallar y realizar malas transformaciones y adopciones, y que por ende se lleguen a conclusiones y resultados erróneos que no reportarán todo el beneficio de Agile.
  • Cada organización debe encontrar su ritmo, su cadencia, su mejor forma de transformarse a Agile, que le permita aprender de si misma, de su cambio cultural para realizar procesos de cambio exitosos
Bienvenidos los comentarios y apreciaciones


Saludos Ágiles
Jorge Abad


Notas, Comentarios, Aclaraciones y Referencias

  1. Empresas tradicionales: llegó la hora de desprenderse del pasado o desaparecer. Revista Dinero (clic aquí).
  2. Manifiesto Ágil (clic aquí)
  3. Post: Principios de Incertidumbre de Requisitos, Procesos y Productos de Software (clic aquí)
  4. http://versionone.com/assets/img/files/ChaosManifesto2013.pdf: "Our analysis suggests that 20% of features are used often and 50% of features are hardly ever or never used. The gray area is about 30%, where features and functions get used sometimes or infrequently. The task of requirements gathering, selecting, and implementing is the most difficult in developing custom applications. In summary, there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction. After all, there is never enough time or money to do everything. The natural expectation is for executives and stakeholders to want it all and want it all now. Therefore, reducing scope and not doing 100% of the features and functions is not only a valid strategy, but a prudent one. " 
  5. Post: Radioactividad de los requisitos - La necesidad de un enfoque ágil en la industria del desarrollo de software (clic aquí)
  6. Es mejor realizar una transformación guiada por pilotos y casos de éxito en los cuales la organización encuentre su mejor forma de SER ÁGIL, que una transformación big-bang que trae consigo una gran entropía al sistema y requiere de una gran cantidad de energía (Coaches, Scrum Masters, Agentes de Cambio) para estabilzarlo