martes, noviembre 12, 2019

Conferencia: Agile Marketing - Para Hacer Frente a los Cambios

Conferencia "Agile marketing para hacer frente a los cambios"

Todo el mundo busca ser ágil. Ahorrar tiempo, minimizar recursos y duplicar los resultados. Sin embargo, ¿es algo que nace innato o se puede entrenar?


En la mayoría de los casos la agilidad puede trabajarse. Y en marketing en concreto, existe una tendencia que aporta las claves para hacerlo: el Agile Marketing.


Día: miércoles 13 de noviembre de 2019

Hora: 9:30 a 11:00 a.m.

Lugar: auditorio OtroMundo



Algunas frases sobre planificar y los planes

Hola a todos

Las frases son muchas veces puntos de quiebre que nos hacen reflexionar, reafirmar o reformular nuestras creencias, paradigmas o prejuicios.

A continuación les comparto unas frases e ideas sobre planeación, planificación y planes.



“If you fail to plan, you are planning to fail!” Benjamin Franklin

"Si fallas planeando,estan planeando fallar"  Benjamin Franklin


Otras versiones derivadas de la anterior:


"Al no planificar, se esta planeando fallar"

"la gente no planea fracasar, fracasa por no planificar"


También tenemos estas más contundentes



"No battle plan survives contact with the enemy"


"Ningún plan sobrevive al contacto con el enemigo"





 "In preparing for battle I have always found that plans are useless, but planning is indispensable"

“En la preparación para la batalla siempre he encontrado que los planes son inútiles, pero la planificación es indispensable”

Dwigth D. Eisenhower


En marcos ágiles



"Valoramos más respuesta ante el cambio sobre seguir un plan" www.agilemanifesto.org


Y por experiencia propia en marcos ágiles


En marcos ágiles se hace planeación y se revisa el plan frecuentemente debido a que la planeación es adaptativa, muy diferente que en que en gestión tradicional que es más orientada a cumplir el plan que fue trazado desde inicio.


Saludos Ágiles

Jorge Abad

lunes, noviembre 11, 2019

Cómo Promover la Autoorganización Empleando OKR

Imagen tomada de (2)

Hola a todos

Este es uno de esos post que tenía en mi deuda de publicación, pues llevo aproximadamente 2 años trabajando con OKR (1) pero no había sacado el tiempo para compartir sobre este comportamiento que he observado en las empresas, equipos y áreas al implantar esta técnica de alineación organizacional basado en objetivos y resultados.

Los OKR al trabajarlos organizacionalmente desde el CEO e ir propagándolos de forma progresiva sobre todas las áreas, portafolios, porgramas y equipos, no solo un generan una fuerte alineación estratégica, sino que logran que los equipos y áreas estén retados y animados con tener una meta común o diferentes metas que logran que como organización se generen resultados coordinados.

Tomada de (3)


Partiendo de la base de que un equipo es un grupo de personas con un objetivo común, y al este objetivo (OKR) convertirse en el reto trimestral, del cual ellos pueden monitorear y ser responsables de su progreso, genera el compromiso y el marco de decisión para avanzar en la dirección asiganda o propuesta por ellos mismos para área, portafolio, programa o equipo.


Para garantizar esa alineación y autoorganización recomiendo:
  1. Los OKR de cada equipo deben ser públicos
  2. Se debe fomentar el tener gráficas de progreso, tipo burnup o burndown que sean actualizadas cada dos semanas o máximo un mes
  3. El equipo debe ser responsable de actualizar constantemente estas gráficas o delegar en alguien su actualización
  4. El líder coordinador de los diferentes equipos o áreas debe promover la actualización de las gráficas de los OKR y realizar reuniones de mejora continua y remoción de impedimentos con miras a lograr el objetivo
  5. En la medida que los equipos van haciéndose responsables de los OKR pueden autoasignárselos con la colaboración o validación del equipo de management.
  6. Es importante que los equipos o áreas se coordinen con otros de manera que "garanticen" la colaboración coordinada en objetivos comunes o que los relacionen.
Bajo este esquema:

  • Los líderes se liberan de la microgestión y de la operatividad
  • Los equipos y áreas tienen un marco para toma de decisiones, por lo que no están preguntando constantemente si algo debe o no realizarse
  • la organización deja de percibirse tanto como una construcción piramidal y en caos, sino se percibe como un conjunto de áreas y de equipos que colaboran con los demás para lograr grandes resultados
Hasta acá este compartir

Saludos ágiles
Jorge Abad



Notas, Comentarios, Aclaraciones y Referencias

domingo, noviembre 10, 2019

Sobre La Mejora Continua






La Mejora Continua no tiene como propósito ser cumplida por el proceso, esta ahí para hacernos inalcanzables.





Retrasar el realizar una mejora es reducir la probabilidad de supervivencia de la organización




jueves, noviembre 07, 2019

Reflexión: La empatía y Jugar a Ganar

Una Reflexión


De las cosas que más me han servido laboralmente (y hasta en el ámbito personal) en los últimos años, es comprender que TODOS SIEMPRE (es cierto, es una generalización) ESTAMOS JUGANDO A GANAR, incluso tu me lees o estás suscrito a este blog por que consideras que en alguna medida lo que publico te puede ayudar a ganar en tu contexto.

La clave es entender que la DEFINICIÓN DE GANAR de los otros, algunas veces es la misma nuestra, otras veces es no (y eso no es malo, es simplemente otra). Saber alinearse, saber entender o encontrar esa definición del otro, me ha ayudado a ser más simpático y a generar mejores resultados, generar abundancia para todas las partes.


Saludos

Jorge Abad

martes, noviembre 05, 2019

Dos frases sobre Ágil, Valor y Alcance






Ágil es sobre Gestión de Valor, no sobre gestión de alcance.





En Ágil, el alcance es un medio para generar valor



De Colección: El pez rápido se come al pez lento






"En el nuevo mundo, no es el pez grande el que se come al pez pequeño, es el pez rápido el que se come al pez lento" Klaus Schwab



viernes, noviembre 01, 2019

De Colección: ¿Y tus retrospectivas cuándo van a ser de tipo Élite?

Tomado de (1)
Hola a todos

Uno de los informes que más ha tomado fuerza dentro del mundo Ágil y de DevOps es el elaborado por DORA (DevOps Research and Assessment): "Accelerate: State of DevOps", en la versión de 2018 "Accelerate: State of DevOpsStrategies for a New Economy 2018"(1)(clic aquí), en su capítulo "Influencing culture through learning" se encuentra este interesante texto

"We found that learning reviews help contribute to a climate for learning and also impact organizational culture. It is important to note that this is true when teams conduct them to learn from their mistakes and failures and then turn these into opportunities to improve how they work. In particular, teams that leverage findings from retrospectives to implement changes to tooling, processes, or procedures see the strongest impacts.

Our analysis found that elite performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work. When we asked respondents about their most recent retrospective, we see common themes around outages, failures, performance, and deployment."

Traducido

"Descubrimos que las revisiones de aprendizaje ayudan a contribuir a un clima para el aprendizaje y también impactan la cultura organizacional. Es importante tener en cuenta que esto es cierto cuando los equipos los conducen para aprender de sus errores y fracasos y luego los convierten en oportunidades para mejorar su funcionamiento. En particular, los equipos que aprovechan los hallazgos de las retrospectivas para implementar cambios en las herramientas, procesos o procedimientos ven los impactos más
 fuertes.


Nuestro análisis encontró que los Jugadores de Élite tienen 1.5 veces más probabilidades de tener retrospectivas consistentemente y usarlas para mejorar su trabajo. Cuando preguntamos a los encuestados acerca de su retrospectiva más reciente, vemos temas comunes sobre interrupciones, fallas, rendimiento y despliegue."
Luego comparten esta nube de temas que se discuten en los equipos élite en el mundo
Tomado de (1)

El listado de palabras en orden alfabético las encuentras al final del post(3).


Invitación

Una de las recomendaciones e invitaciones que hago a los Scrum Masters, Facilitadores, Líderes Ágiles y Equipos de Desarrollo que tienen cierta madurez haciendo Scrum o cualquier otro marco es:

"tarde o temprano tus retrospectivas tienen que hablar del tema técnico, o ¿vas a seguir perfeccionando la comunicación y el proceso en el sprint 20 y siguientes?, es urgente que veas el elefante en el cuarto si quieres llevar a tu equipo al alto desempeño"
No estoy afirmando que: "no sea necesario mejorar el proceso y el trabajo en equipo", si hay que mejorarlos se hace, pero el tema técnico es un tema obligatorio a tocar en las retrospectivas, y más si deseas alcanzar alto desempeño.

Scrum Master y Equipo evitando hablar del tema técnico

Basado en la sugerencia anterior he escrito y compartido post similares en el pasado:
  • Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo (clic aquí)
  • Presentación: Los puntos ciegos del Scrum Master (clic aquí)
Quedan entonces dos preguntas
  • ¿de qué tema hablaron en la última retrospectiva de tu equipo?
  • ¿y tus retrospectivas cuándo van a ser de tipo Élite?


Hasta acá este compartir.

Bienvenido el feedback

Saludos ágiles
Jorge Abad

Notas, Referencias, Aclaraciones y Comentarios

  1. Accelerate: State of DevOps. Strategies for a New Economy 2018 - https://inthecloud.withgoogle.com/state-of-devops-18/dl-cd.html 
  2. Accelerate: State of DevOps 2019- https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
  3. El listado de palabras de la nube en orden alfabético es el siguiente:
  • able
  • access
  • analysis
  • api
  • app
  • application
  • architecture
  • automated
  • automation
  • availability
  • aws
  • bad
  • behavior
  • breach
  • broken
  • bug
  • bugs
  • build
  • business
  • capacity
  • cases
  • cause
  • caused
  • certificate
  • change
  • changes
  • client
  • cloud
  • cluster
  • code
  • collaboration
  • communication
  • communications
  • config
  • configuration
  • container
  • cpu
  • crash
  • critical
  • customer
  • customers
  • data
  • database
  • deadlines
  • defect
  • defects
  • degradation
  • delivery
  • dependencies
  • deployed
  • deployment
  • deployments
  • design
  • development
  • devops
  • disaster
  • disruption
  • dns
  • documentation
  • done
  • dont
  • downtime
  • due
  • efficiency
  • email
  • environment
  • environments
  • error
  • errors
  • external
  • failed
  • failing
  • failure
  • failures
  • feature
  • features
  • feedback
  • firewall
  • functional
  • functionality
  • gaps
  • hardware
  • high
  • human
  • implementation
  • improve
  • improvement
  • improvements
  • incident
  • incidents
  • incomplete
  • incorrect
  • infrastructure
  • integration
  • issue
  • issues
  • kafka
  • know
  • knowledge
  • lack
  • last
  • learning
  • lessons
  • load
  • loss
  • major
  • management
  • manual
  • many
  • migration
  • mismatch
  • missed
  • missing
  • mistakes
  • monitoring
  • mortems
  • needed
  • network
  • networking
  • new
  • none
  • nothing
  • one
  • operational
  • outage
  • outages
  • party
  • patching
  • performance
  • planning
  • poor
  • post
  • postmortems
  • power
  • problem
  • problems
  • procedures
  • process
  • processes
  • prod
  • product
  • production
  • project
  • projects
  • push
  • quality
  • recovery
  • regression
  • regular
  • related
  • release
  • releases
  • requirements
  • resource
  • retrospective
  • retrospectives
  • review
  • reviews
  • rework
  • root
  • scope
  • security
  • server
  • servers
  • service
  • services
  • slow
  • software
  • sprint
  • sql
  • stability
  • steps
  • storage
  • support
  • system
  • systems
  • tasks
  • team
  • teams
  • technical
  • test
  • testing
  • tests
  • time
  • tool
  • tools
  • unexpected
  • unplanned
  • updates
  • upgrade
  • upgrades
  • use
  • user
  • value
  • vendor
  • version
  • went
  • work
  • working
  • wrong

sábado, octubre 26, 2019

La Cultura Organizacional del Miedo



Una Cultura Organizacional basada en el miedo:
  • No se permite fallar
  • Se inhibe la innovación
  • La mejora continua debe ser predecible y da poco lugar a experimentos
  • No asume riesgos (observación: "El mayor riesgo es no arriesgarse")
  • Es ególatra
  • La iniciativa es vista como insubordinación
  • Se pide permiso para avanzar, incluso para hacer lo correcto
  • Es compatible con la planeación predictiva
  • Es compatible con una mentalidad fija
  • Es compatible con estructuras fuertemente jerárquicas
  • Es compatible con el estilo de liderazgo "Comando y Control"
  • Conduce a la inmovilidad

Una Reflexión sobre Hacer Ágil y Ser Ágil



La brecha entre Hacer Ágil y Ser Ágil nunca será cubierta con entrenamientos, se requiere del cambio en el Mindset de los líderes y de la Cultura de la Organización. 

lunes, octubre 14, 2019

Métricas para Product Owners


Hola a todos

Uno de roles que más cuesta entender dentro del mundo de Scrum y de los marcos ágiles es el de Product Owner (PO), pues su área de dominio se encuentra dentro del mundo del negocio y de la gestión del producto y no específicamente el mundo del desarrollo de software.

Traducido de (1)







Hoy quisiera compartir algunas métricas útiles durante:
  • la construcción del producto y 
  • el uso del producto, 
que ayudarán a la correcta gestión del producto por parte del PO, algunas de interés exclusivo por parte del mismo, otras serán compartidas con el equipo de desarrollo y otras áreas.


Durante la Construcción

Las métricas a continuación son tanto de interés del Product Owner como del Equipo que está construyendo el producto
  • Desarrollo del producto
    • Burndown Chart del Sprint
    • BurnUp Release* (también puede ser útil el Bundown del Release pero sugiero el BurnUp, ustedes sacarán sus conclusiones)
    • Velocidad del Equipo
    • Control del LeadTime
    • Flujo Acumulativo
    • Deuda de Valor o Valor no Liberado (5)*
    • Tiempo promedio entre liberaciones o releases
  • Calidad del Producto
    • Defectos encontrados en desarrollo
    • Defectos encontrados después de cada liberación
    • Defectos postergados para una versión futura
    • Tickets de soporte por día o semana
    • Deuda Técnica
    • Cobertura de pruebas unitarias
    • Cobertura de pruebas funcionales automatizadas

(*)Métricas de gestión exclusiva del PO


Durante el Uso

Estas métricas son de interés del PO, muy posiblemente otros equipos de trabajo en la organización le ayuden a obtener estas métricas, pero siempre será más útil no depender de otras áreas y que esta información haga parte del tablero de control del producto.

  • Uso del Producto
    • Tráfico
    • Tasa de Retención
    • Duración de la sesión
    • Número de acciones del usuario por sesión
    • Proporción de usuarios activos diarios / usuarios activos mensuales 
    • Tráfico (fuentes de tráfico)
    • Porcentaje de rebote (porcentaje de usuarios que encontraron el producto y se fueron)
    • Tasa de Rotación (Clientes perdidos / Clientes totales)
    • Número de sesiones por usuario
    • Usuarios por función o por volúmenes de transacción (semanal, mensual)
  • Desempeño del Producto en el Negocio
    • Satisfacción del cliente (el NPS es una buena opción)
    • Hipótesis validadas/Hipótesis planteadas
    • Valor liberado (interna y externamente)
    • Ingreso mensual
    • ROI mensual
    • Ingreso promedio del usuario (Average revenue per user -ARPU)
    • Customer Lifetime Value (CLTV or LTV)
    • Costo de adquisición del cliente (CAC)

Cerrando

No todas las métricas son necesarias, pero se puede ir creciendo orgánicamente sobre ellas en la medida que el producto y el entorno nos van proporcionando más información.


Hasta acá este compartir

Saludos ágiles
Jorge Abad


Notas, Comentarios, Aclaraciones y Referencias


  1. Creating Success – A Guide to Product Manager KPIs.  https://www.toptal.com/product-managers/product-management/creating-success-a-guide-to-product-manager-kpis
  2. Qué es el Product Owner en el marco de Scrum y cuáles son sus áreas de atención? - http://www.caminoagil.com/2019/08/13/product-onwer-cuatro-areas-atencion/
  3. Five agile metrics you won't hate - https://www.atlassian.com/agile/project-management/metrics
  4. 15 Key Product Management Metrics and KPIs - https://www.altexsoft.com/blog/business/15-key-product-management-metrics-and-kpis/
  5. Scrum: Una herramienta para el PO, ¿cuanto costo he convertido en valor? - DEUDA DE VALOR - http://www.lecciones-aprendidas.info/2013/10/scrum-una-herramienta-para-el-po-cuanto.html

sábado, octubre 12, 2019

Un tip para escribir mejores OKR

Hola a todos

Hace unos días luego de un post de Nadia Zapata (1), Jose Luis Lee exponia un problema común al momento de escribir OKR (2) y que el compartía en su post (3), y es confundir un Key Result (kr) con una tarea, justo en esa misma dirección quisiera poner otro granito de arena, de algo que he compartido en otros escenarios y aporta (desde mi punto de vista) a evitar en e problema

un OKR mal planteado podría ser


Obj2. Investigar y mejorar la satisfacción del cliente (4)

  • kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0
  • kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual
  • kr3. Realizar 50 entrevistas telefónicas con los mejores clientes
  • kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonados
  • kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Podríamos decir, que este problema se podría observar en el kr2, kr3 y kr4, pues se observan que son acciones pero tal como están redactadas no se conectan bien con el objetivo.

Una forma de evitar esto es
ver los kr como criterios de aceptación similar a como lo hacemos con las historias de usuario
De esta manera nos enfocamos en satisfacer el enunciado del objetivo (ver 5 y 6) y no caer en el error de identificar las tareas.

Basado en esta sugerencia el OKR quedaría


Obj2. Investigar y mejorar la satisfacción del cliente (4)

  • kr1. Superar el puntaje neto del promotor (NPS) en más de 8.0
  • kr2. Obtenga 1000 respuestas a la encuesta de satisfacción anual y analizar y obtener cual es el pareto de las causas de insatisfacción
  • kr3. Realizar 50 entrevistas telefónicas con los mejores clientes y obtener cual es el pareto de las causas de insatisfacción
  • kr4. Realizar 15 entrevistas telefónicas con clientes recientemente abandonadosy obtener cual es el pareto de las causas de insatisfacción
  • kr5. Presentar un plan de acción de 10 mejoras para el próximo trimestre.

Nota:

hasta acá este  compartir.


Saludos ágiles
Jorge Abad


Aclaraciones, Notas, Comentarios y Referencias


  1. Diapositivas de Nadia Zapata sobre OKR compartidas en el Ágiles 2019
  2. Para más información de OKR ver http://www.lecciones-aprendidas.info/2019/10/un-ejemplo-de-okr.html
  3. Me equivoqué con mis ejemplos de OKRs - de Jose Luis Lee
  4. tomado de https://okrexamples.co/support-customer_service-okr-examples
  5. http://www.lecciones-aprendidas.info/2013/06/la-magia-de-las-historias-de-usuario.html
  6. Reconozco que este ejemplo es fácil entender por las personas de tecnología que están habituadas a trabajar con las historias de usuario, pero ayuda que al momento de facilitar o explicar el concepto, identificando claramente cuando un kr tiene sabor de tarea y cuando a sí tiene sabor a resultado.
  7. Porque deberíamos intentar implementar OKRs en una Transformación Agile
  8. http://www.lecciones-aprendidas.info/2013/11/como-es-una-historia-de-usuario-un.html

Un ejemplo de OKR

Hola a todos

Existe muy buena literatura y post sobre los OKR (Objectives and Key Results, por sus siglas en inglés).

Si aun no te has aproximado al concepto, es una técnica de alineación organizacional y de equipos desarrollada por Intel y consiste en establecer un objetivo trimestral cualitativo, para determinar si ese objetivo trimestral se cumple o se esta cumpliendo se establecen entre tres y cinco resultados clave que muestren que ese objetivo se esta logrando.

Por ejemplo un OKR, para un Área de Servicio al Cliente, para un trimestre determinado podría ser:

Obj2: Que nuestros usuarios se sientan atendidos como en primera clase
  • kr1- Obtener una mejora del NPS del área en un 40%
  • kr2- Que no quede un correo pendiente por atenderse más de 2 horas hábiles
  • kr3- Reducir las quejas sobre el área en un 90%
Para más detalle sobre los okr sugiero leer:

Saludos ágiles

Jorge Abad

martes, octubre 08, 2019

El Manifiesto Ágil está pensado para todo el Ecosistema Software


Tomada de (1)
Hola a todos

Hace poco luego del Evento del Ágiles 2019  - http://agiles2019.agiles.org/ en Rosario Argentina, espectacular por cierto (felicitaciones a los organizadores, nos hizo falta más evento, más Rosario y más Argentina), reflexionaba sobre que aspectos contemplaba el "Manifiesto por el Desarrollo Ágil de Software", el cual es la base del movimiento ágil y los marcos ágiles que han transformado al mundo.

Luego de este evento surgieron críticas  sobre la cantidad de charlas que fueron técnicas y la cantidad de charlas que no lo fueron (cosa buena la crítica  nos cuestiona y nos hace evaluar otros puntos de vista), yo estuve allí y en efecto vi que se dieron charlas de un sabor y del otro, adicional que ninguna charla se prohíbe y existe total apertura que se hable sobre lo que es importante.

Se habló de todo lo que los asistentes quisieron hablar, adicionando que no todo hace parte de la agenda, hubo muchas conversaciones en las mesas, cenas, almuerzos, grupos de a pie, en fin.

Desde mi punto de vista se cumplió el lema “MUCHAS TRIBUS, UNA MISMA AGILIDAD”


Volvamos al Manifiesto

Pero veamos que dice el manifiesto y que pistas nos da para la comunidad ágil:

Tomado de: https://agilemanifesto.org/iso/es/manifesto.html

Tomado de: agilemanifesto.org/iso/es/principles.html

Tomado de: agilemanifesto.org/iso/es/principles.html


Algunas palabras claves agrupadas del manifiesto, son las siguientes


  • Conceptos claves
    • Desarrollo de software
    • Conversación cara a cara
    • Cambio
    • Ventaja Competitiva
    • Trabajamos juntos
    • Entorno
    • Ritmo constante
    • Excelencia técnica
    • Buen diseño
    • Simplicidad
  • Artefactos
    • Procesos
    • Procesos ágiles
    • Herramientas
    • Software funcionando
    • Documentación (extensiva)
    • Plan
    • Software de valor
    • Negociación contractual
    • Requisitos
    • Proyecto
    • Arquitecturas
    • Diseños
  • Roles
    • Terceros
    • Cliente
    • Responsables de negocio
    • Desarrolladores
    • Equipo de desarrollo
    • Promotores
    • Equipos auto-organizados

De forma similar, según las referencias de como se firmó el manifiesto ágil publicadas por Alistar Cockburn .https://twitter.com/TotherAlistair, (ver imágenes a continuación), se observa que:
  • Los principios 1 al 4, están inclinados a los clientes
  • Los principios 5 al 8, están inclinados a los gerentes
  • Los principios 9 al 12, están inclinados al equipo


Tomado de (2)


Tomado de (3)

Por lo tanto, el manifiesto se encuentra pensado en todo el ecosistema en el cual esta inmerso el desarrollo de software, no excluye a uno o a otros, invita a que trabajemos juntos de forma continua y sostenible y generemos software de valor.

No existe una preferencia, por unos y otros, se requiere de la mejor voluntad de todos los involucrados para generar resultados grandiosos.

Clientes-Gerentes-Desarrolladores nos necesitamos entre sí, y aunque existan aproximaciones Clientes-Desarrollaores, la gran cantidad de productos y proyectos del mundo requieren de gerentes, promotores para garantizar que unos y otros interactuen de forma coordinada.


Cerrando

Bienvenidos los eventos de agilidad, bienvenidas todas las personas y roles del ecosistema software, bienvenida la excelencia técnica, bienvenidos los desarrolladores, promotores, lideres, scrum masters, agile coaches, y hablemos sobre todo lo que nos interesa, duele y queremos mover y promover en el ecosistema


Nos vemos en Uruguay Agiles2020

Saludos Ágiles

Jorge Abad

Aclaraciones, Notas, Comentarios y Referencias


  1. Más fotos e información de referencia en https://siamchamnankit.co.th/history-some-pictures-and-pdfs-of-the-agile-manifesto-meeting-on-2001-a33c40bcc2b
  2. https://www.facebook.com/photo.php?fbid=10156214339079035&set=a.496846469034&type=3&theater
  3. https://www.facebook.com/photo.php?fbid=10156214339084035&set=a.496846469034&type=3&theater

martes, octubre 01, 2019

La frase que compartí en el pasado #Agiles2019

sábado, septiembre 28, 2019

Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales


Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).


Adaptado de (2)
Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de
  • la gestión de riesgos
  • la gestión de problemas o impedimentos


Claro, claro esto se puede gestionar con dos tableros,




o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo




y post-it que indiquen:
  • descripción del problema o impedimento
  • fecha de identificación
  • persona a la que fue asignado
  • días que lleva sin resolverse (pueden ser solo líneas en el post-it)




Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.


Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)



como lo comparto muchas veces


"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"



Adaptado de (2)


Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad




Notas, Comentarios, Aclaraciones y Observaciones

  1. Photo on Visualhunt.com
  2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
  3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
    • tener a alguien asignado para su resolución
    • tener el tiempo de "no resolución"
    • la importancia para el "proyecto"
  4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.

martes, septiembre 24, 2019

Criterios para la Selección y el Éxito del Proyecto Piloto en Scrum

Hola a todos

Con cierta frecuencia comparto tips sobre como elegir el Proyecto Piloto en el mundo ágil, aquí va la lista de tips actualizada.


Se recomienda iniciar con proyectos que cuenten con los ciertos criterios que nos permiten tener un mayor impacto en la organización:

  • Duración estimada de máximo 8 meses
  • Contratación del proveedor bajo esquema ágil - ver más aquí -.
  • Seguimiento bajo métricas ágiles.
    • burndown chart para los sprints
    • velocidad
    • burnup chart para el Release
  • Dedicación una persona experta en el negocio de al menos el 50%, la cual esté empoderada y no denigre de la agilidad.
  • Un Scrum Master o Facilitador experto 
  • Los impedimentos identificados por el Scrum Master o Facilitador serán atendidos y tendrán prioridad
  • Las evaluaciones de desempeño de quienes participan en el proyecto no sean en cascada
  • Las áreas de soporte le den prioridad al proyecto
  • Ejecución por uno o dos equipos ágiles (15 personas máximo en total)
  • Se debe de considerar tecnologías conocidas por los equipos
  • Las personas de los equipos deben: 
    • Contar con los skill técnicos
    • Dedicación al 100%
Tomado de (1)
Si quieres conocer los post asociados a este tópico haz clic aquí - http://www.lecciones-aprendidas.info/search?q=piloto


Aclaraciones, Notas, Comentarios y Referencias

lunes, septiembre 23, 2019

Algunos ANS (Acuerdos de niveles de servicio) y Penalidades sugeridas en el Mundo del Desarrollo Ágil de Software

Hola a todos

En el pasado Ágiles 2019, presente la charla "Tips para una PMO perdida en el Mundo Ágil" - clic aquí -  y uno de los puntos en los cuales hay una constante inquietud por parte de las organizaciones tradicionales es:

¿Cuáles son las ANS (acuerdos de niveles de servicio )(1)  y penalidades aplicarían en un contrato de desarrollo ágil?

Responsabilidades en el Desarrollo Ágil

Para empezar, establezcamos responsabilidades bajo el esquema ágil
  • el cliente es responsable del producto que esta requiriendo, o seá,
    • tener claro el ¿para qué?
    • ¿el Qué? 
    • y que sea el producto correcto
  • el equipo (que puede ser un proveedor externo) es responsable de la calidad técnica y funcional del producto que esta construyendo, es decir:
    •  ¿Cómo esta construido? o
    • ¿Construir el producto de forma correcta?
  • el facilitador, líder, coach, Scrum Master, Agile Coach, que acompaña a cliente y equipo es responsable de la mejora continua de ambos y de lograr la mayor fluencia, es decir, la menor fricción entre cliente, equipo, y el entorno para ser exitosos, es decir:
    • ¿Cómo interactuamos mejor?
    • ¿Cómo podemos dar mejor resultado, y más rápido?

Los ANS Sugeridos y Deseables

Con este contexto, y habiendo clarificado que la responsabilidad del equipo es sobre "como construye el producto" les comparto algunos ANS, que se sugieren y que son deseables para el mundo ágil:


Tomado de (2)

Sugeridas
  • Nivel de cumplimiento de los sprint (historias finalizadas/ historias de usuario acordadas). Valor sugerido>=80% (suponiendo que el marco de desarrollo sea Scrum)
  • Calidad de los entregables (Defectos encontrados en Producción/Pruebas unitarias y de aceptación). Valor sugerido<=10%
  • Efectividad de las pruebas (defectos encontrados en Producción/Cantidad de defectos). Valor sugerido<=10% 
  • Deuda técnica (validación estática de código). Valor a acordar 


DescripciónObjetivoFormula Medición
Unidad
Medición
Valores Aceptación
Peso
Nivel de cumplimiento en los SprintsControlar que las historias de usuario acordadas en cada sprint sean finalizadas por cada uno de los equipos(Historias de Usuario finalizadas por en cada sprint / total de Historias de Usuario comprometidas por en cada sprint) *100
%
sprint 
>= 80%
xx%
Calidad de los entregablesPromover la calidad general del producto

Cantidad de defectos encontrados en producción una vez se instale funcionalidades de un sprint 
(Cantidad de defectos encontrados / Casos de pruebas unitarias + aceptación)*100
%
sprint
<=10%
xx%
Efectividad de las pruebas  Promover la calidad general del producto

Porcentaje de defectos identificados en producción sobre el total de defectos encontrados
(Número de defectos en producción / Total de defectos en fase de pruebas (Incluido unitarias, aceptación Y Producción))*100
%
sprint
<=10%
xx%
Deuda TécnicaPromover la calidad técnica del producto

% de deuda técnica identificada por el validador estático de código
%
sprint
Valor a acordar (depende del producto)
xx%


Deseables (Depende de la madurez en DevOps de la organización contratante y el equipo de desarrollo) 
  • % de cobertura de pruebas unitarias. Valor a acordar 
  • % de cobertura de pruebas funcionales automatizadas. Valor a acordar


DescripciónObjetivoFormula Medición
Unidad
Medición
Valores Aceptación
Peso
Cobertura de pruebas unitariasPromover la calidad técnica del producto del productoCobertura de pruebas unitarias al código en %
%
sprint
>= 80%
xx%
Cobertura de pruebas funcionales automatizadasPromover la calidad técnica y funcional del producto(Total de casos de pruebas funcionales automatizados/ Total de casos de pruebas funcionales) *100
%
sprint
>=70%
xx%


Y las Penalidades

Las dejo a su consideración, realmente no estoy de acuerdo con el DPS (o Desarrollo Punitivo de Software) donde en el esquema de desarrollo tradicional o cascada se activan cantidades y cantidades de penalidades, tantas que como proveedor puedes terminar pagando económicamente al cliente cuando debería ser al contrario. Nadie se mete a hacer desarrollo de software (o a cualquier negocio) para terminar pagándole a su cliente.

Soy mas partidario de lo que comparto en la charla de contratos ágiles(3), tener esquemas de finalización anticipada, y si el cliente o el proveedor no dan la talla (el tema es mutuo), simplemente terminar la relación comercial sin penalidad alguna, con la ventaja que en el mundo ágil y específicamente con Scrum siempre tienes software de valor funcionando cada mes o menos (por lo general cada dos semanas).



Hasta acá este compartir

Saludos Ágiles

Jorge Abad


Aclaraciones, Notas, Comentarios y Referencias

  1. También conocidos como SLA - Service Level Agreement, por sus siglas en inglés.
  2. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 
  3. Hablemos de contratos ágiles - http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html