miércoles, noviembre 27, 2019

Ejemplo de reporte de la "PMO Ágil"

Hola a todos

Les comparto un ejemplo de reporte que podría realizar una "PMO Ágil", donde se observan los diferentes aspectos de la gestión del portafolio ágil (ver post anterior).

Recuerde, se puede incluir estos o diferentes campos de acuerdo a su contexto, esta es solo una propuesta que permite ver los aspectos de:
  • Construcción del Producto
  • Calidad del Producto
  • Salud de los Equipos
  • Uso del Producto
  • Desempeño del Producto en el Negocio
dentro del portafolio de productos que se están desarrollando con marcos ágiles.




Reporte General


A continuación cada una de las secciones.
Durante el Desarrollo o Construcción del Producto


Calidad del Portafolio 


Salud de los equipos



Uso del Producto

Desempeño del Producto en el Negocio
Con este tipo de reportes y de transparencia generada (ojala con una frecuencia de dos meses al mes), se podrán tomar acciones y la "PMO Ágil"(1) fungir como ese Scrum Master Organizacional: preocupada por:

  • La generación de valor
  • remover impedimentos organizacionales
  • promover la inspección y adaptación (agilidad) organizacional




Saludos Ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias


  1. En el mundo de 

lunes, noviembre 25, 2019

Métricas Sugeridas para la "PMO Ágil"

Hola a todos

Hace poco compartí un post sobre Métricas para Product Owners (ver aquí), y basado en esa aproximación y considerando que para las PMO que en la actualidad tienen Productos y Proyectos desarrollados de forma ágil, las métricas comunes de CPI (Cost Performance Index) y SPI (Schedule Performance Index), fuera de que es difícil calcularlas, no proporcionan mucho valor en ese contexto, considerando que lo que se busca es la generación de valor y no la construcción del alcance.


Importante: De ahora en adelante cuando se mencione la palabra Portafolio se referirá a una colección de productos que tienen un propósito común dentro de una organización y que están siendo construidos empleando algún marco o metodología ágil



Basado en lo anterior propongo este Modelo de Métricas a seguir en una "PMO" Ágil(2), esta aproximación tiene como pilares:
  • Durante la Construcción
    • Salud de los equipos
    • Desarrollo o Construcción del Portafolio
    • Calidad del Portafolio
  • Durante el Uso
    • Uso del Portafolio
    • Desempeño del Portafolio en el Negocio






Las métricas a considerar dentro de cada uno de estos pilares son:

  • Durante la Construcción
    • Desarrollo o Construcción del Portafolio
      • Frecuencia de despliegues del producto (1) (También puede interpretarse como cantidad de releases en un periodo de tiempo)
      • Lead Time para cambios (1) (También puede interpretarse como Time to Market de cualquier cambio sobre el producto, nuevas versiones, etc)
      • Probabilidad de cumplir el rango de fechas de release 
      • Sprints sin cumplir con velocidad (es decir, inferior al 80% de velocidad del equipo)
      • Velocidad del portafolio (6)
      • Predictibilidad del portafolio (6)
      • Presupuesto invertido (8)
      • Deuda de valor
        • % de costo construido puesto en producción
        • % del valor construido puesto en producción
    • Calidad del Portafolio
      • Tiempo para restaurar el servicio (1)
      • Tasa de cambios fallidas (1)
      • 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
    • Salud de los equipos
      • Lead Time promedio de resolución de impedimentos (8)
      • Mejoras realizadas 
      • Escalamientos sin ser resueltos
      • Experimentos realizados
      • Cantidad de Vacantes (8)
      • Tiempo sin cubrir vacantes (8)
      • Tiempo sin Product Owner
      • Tiempo sin Scrum Master
      • NPS
        • del Product Owner acerca del Equipo 
        • del Equipo hacia el Product Owner
        • del Scrum Master hacia el Equipo
        • del Equipo hacia el Scrum Master
      • NPS del Equipo acerca del trabajo en la organización (es decir, la pregunta a realizar, sería.¿De 1 a 10 que tanto recomendaría trabajar en esta organización?)
  • Durante el Uso
    • Uso del Portafolio
      • 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 Portafolio en el Negocio
      • Validación del Business Case
      • Satisfacción del cliente (el NPS es una buena opción)
      • Hipótesis validadas/Hipótesis planteadas
      • Los OKR del portafolio
      • Valor liberado (interna y externamente)
      • Ingreso mensual
      • ROI mensual del portafolio
      • Ingreso promedio del usuario (Average revenue per user -ARPU)
      • Customer Lifetime Value (CLTV or LTV)
      • Costo de adquisición del cliente (CAC)

Cerrando

Nuevamente la recomendaciones son las mismas que se hizo con el articulo de Métricas para Product Owners(3):
  • no trates de abarcar todo desde el inicio
  • crece orgánicamente el uso de las métricas
  • esta es una propuesta
  • toma lo que te sirva
  • y no olvides la orientación y generación de valor unido con la salud de los equipos de trabajo
Ver acá un -ejemplo aquí-.

Hasta acá este compartir

Saludos Ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Tomado de "2019 -  Accelerate State of DevOps Report"- https://cloud.google.com/devops/state-of-devops/
  2. Quedo debiendo el post de el por qué de cada métrica, pero este MVP, no dudo que genere valor como una primera aproximación
  3. Métricas para Product Owners - http://www.lecciones-aprendidas.info/2019/10/metricas-para-product-owners.html
  4. PMO - Una Propuesta de Responsabilidades y Nuevos Nombres en el Mundo Lean-Agile - http://www.lecciones-aprendidas.info/2019/08/pmo-una-propuesta-de-nombre-y-funciones.html 
  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
  6. Tomado de https://www.scaledagileframework.com/metrics/
  7. Evidence-Based Management Guide -https://www.scrum.org/resources/evidence-based-management-guide
  8. Sugerido por Paola Becerra - (ver su perfil aquí)


jueves, noviembre 21, 2019

Mi notas sobre OKR


Hola a todos

Quisiera aprovechar este post para compartir mis notas sobre OKR, tomadas de el artículo de Dan North - https://dannorth.net/2017/05/01/applying-okrs/





Para más información sugiero consultar mi banco de imágenes en: https://co.pinterest.com/jorge_abad/tips-management-y-management-30/okr-s/

Saludos ágiles

Jorge Abad








martes, noviembre 19, 2019

Frase: El mayor riesgo de todos sería no aceptar ninguno






"The biggest risk of all is not taking one." - Mellody Hubson




"El Mayor riesgo de todos sería no aceptar ningunto" - Mellody Hobson

La Transparencia, el Burndown Físico, el Kanban Fisico y el Efecto Hawthorne - Si me observas me comporto diferente

Tomado de 1


Hola a todos

Quisiera compartirles una conversación que constantemente sostengo con scrum masters, agile coaches, project leaders y diferentes de personas encargadas de equipos ágiles al momento de explicarles los beneficios de la transparencia y del sprint burndown chart físico y el kanban del sprint físico versus las herramientas digitales.

Y por qué no una herramienta

Siempre al abordar la forma de conocer el avance del equipo, hay una preferencia a sugerir Jira, o cualquier otra herramienta para tener registro de la finalización de ítemes de backlog (por lo general historias de usuario) y sus tareas durante un sprint.

Y la verdad eso no le veo lío, una herramienta digital me permite recolectar datos, saber estadísticas, concluir sobre comportamientos o problemas comunes.

Lo que observo es poco útil para facilitar la transparencia, pues siempre necesitaré hacer ingreso a una herramienta para saber el estado (tal vez me tome unos segundos, o alguien me pregunte algo y me distraiga o se me olvide), cosa muy distinta si tengo un burdown físico o un kanban físico al lado del equipo, siempre será facil ver y reconocer el estado sin preguntarle a nadie.


Tomado de 2 - Sugerencia de un Scrum Board 

Adicional que se genera el efecto Hawthorne, que es más efectivo el "RC - léase Erre Ce", es decir, la Respiración en el Cuello (4) o la pregunta frecuente:
"¿y cómo van?"
Pues el burndown y el kanban alcanzan a generar ese nivel de transparencia y compromiso.

Por lo tanto, es importante conocer el propósito de cada herramienta

  • la información digital me proporciona estadísticos 
  • y la información física transparencia 
es importante pues comprender esto y hacerle entender al equipo que no se está duplicando información, ambas tienen propósito distinto.

El Efecto Hawthorne

"El término fue creado en 1955 por Elton Mayo cuando analizaba antiguos experimentos realizados entre los años 1924 y 1932 en Hawthorne Works (una fábrica de la Western Electric a las afueras de Chicago). Los experimentos fueron coordinados por Elton Mayo, con la colaboración de Frist Roethlisberger, la Universidad de Harvard y el ingeniero de la Western Electric, William Dickson. En Hawthorne Works encargaron un estudio para comprobar la posibilidad de aumentar la productividad de sus trabajadores aumentando o disminuyendo las condiciones de iluminación ambiental. La productividad de los trabajadores pareció aumentar en el momento en el que se instauraron los cambios, y no sólo se produjo en los casos en los que los niveles de iluminación eran aumentados, sino también en aquellos casos en los que la iluminación se reducía. Al momento de terminar el estudio, los niveles volvieron a los niveles normales. La explicación sugerida fue que la mejora en la productividad no se debió a los cambios operados sobre los niveles de iluminación, sino al efecto motivador que supuso entre los obreros el saber que estaban siendo objeto de estudio." (2)


Por lo tanto podríamos concluir:
"si me observas me comporto diferente"


Los beneficios de la Gestión Visual

Adicional, contar con la información física nos permite obtener los beneficios de la gestión visual (5)
  • El 90% de la información transmitida al cerebro es visual
  • Las imágenes son procesadas 60.000 veces mas rápido que el texto
  • La gestión visual mejora la habilidad de aprender/comprender por encima del 400%

Cerrando

Bajo todo lo anterior mi recomendación sigue siendo,
"A pesar de que tengas un sistema para registro de avance de tu sprint, genera un burndown chart físico y un kanban de manera de que exista transparencia y todos podamos ayudar y conocer el estado del sprint de manera fácil"

Ventajas
  • No tengo que ingresar login y password
  • Es público
  • Es transparente
  • Implica foco, coraje y compromiso tanto al interior del equipo como hacia la organización
  • Todos sabrán si requerimos o se requiere ayudar
  • Si alguien nos pregunta como va el sprint le señalamos el tablero y seguiremos en lo nuestro (obvio cordialmente)
  • y por último (desde mi punto de vista) es más efectivo que el "Erre Ce"(4)

Sprint Burndown Chart Físico o en Papel

Sugerencias y Advertencias

  • Si tu equipo Scrum desde su creación registró su avance en herramientas digitales, haz el experimento del burndown físico, saca tus conclusiones y compártelas.
  • Esta práctica es muy útil en equipos coubicados, es decir todos en el mismo lugar
  • Si tu equipo es remoto, esta práctica es difícil de implementar, mas no imposible.
  • Una buena página para generar el burndown es - http://www.burndowngenerator.com/



Hasta acá este compartir, bienvenido el feedback

Saludos ágiles
Jorge Abad



Notas, Observaciones, Comentarios y Referencias

  1. Photo on Visualhunt.com
  2. https://agiledigest.com/agile-digest-tutorial-2/preparing-working-scrum-board-sprint-board-n/
  3. https://es.wikipedia.org/wiki/Efecto_Hawthorne
  4. RC - Erre Ce. Acrónimo que simboliza el micromanagement y su preguntas constantes y frecuentes como: ¿y cómo van? ¿les falta mucho? ¿cuánto les falta?, etc.
  5. https://ernestoolivares.es/pensamos-90-en-imagenes/

lunes, noviembre 18, 2019

Frase: Que sucede cuando nuestro trabajo depende del logro de objetivos




"People with targets and jobs dependent upon meeting them will probably meet the targets - even if they have to destroy the enterprise to do it." - W. Edwards Deming



"Las personas con objetivos y trabajos que dependen de cumplir estos objetivos seguramente los alcanzarán, aunque tengan que destruir a la empresa para ello" - W Edwards Deming



sábado, noviembre 16, 2019

Una Conclusión: Cómo me midas me comporto

Hola a todos

Basados en esta frase de Deming (les recomiendo que busquen sus frases)



"Cambia la regla y usted obtendrá otro número." - W. Edwards Deming


Quisiera compartirles dos conclusiones a las que he llegado en este compartir con organizaciones y equipos


Cambia el número y obtendrás un nuevo comportamiento

Cambia la métrica y obtendrás un nuevo comportamiento


o mejor



Cómo me midas me comporto



Tener esto presente me ha ayudado bastante para lograr alinear fuerzas y tener foco de los equipos y organizaciones en la generación de valor.

Hasta acá este corto compartir


Saludos Ágiles




Jorge Abad

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, pleneación, planificación 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,están planeando fallar"  Benjamin Franklin


Otras versiones derivadas de la anterior:


"Al no planificar, se está 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




 "Everybody has a plan until they get punched in the face "

“Todos tienen un plan hasta que son golpeados en la cara”

-Mike Tyson




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