lunes, marzo 30, 2020

De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg


At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.
There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.
The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.
So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.
An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.
Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.





Traducción



En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.


domingo, marzo 29, 2020

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.
  • Vista 1 - Descubrimiento (Discovery):
    • En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
      • expertos del negocio
      • arquitectos de software y arquitectos empresariales
      • Expertos en UX / UI
      • clientes
      • posibles suarios
      • expertos en Seguridad y Riesgos
      • expertos en Procesos
      • gerentes de Producto (Product Managers) 
      • otros PO e interesados claves
    • Para definir:
      • el producto,
      • la visión del producto
      • la lista ordenada del producto (Product Backlog)
      • el producto minimo viable (Minimum Viable Product - MVP) 
      • las versiones, 
      • los prototípos,
      • los indicadores,
      • los esquemas de ROI
      • las hipótesis, etc.
    • Para esto se vale de:
      • visitas a clientes y usuarios
      • conocer donde va a ser usado el producto (gemba walks)
      • investigaciones de mercado
      • análisis de la compentencia (benchmarks)
      • estrategias de construcción del producto
      • dependencia de otros productos o soluciones, etc.
  • Vista 2 - Desarrollo (Development): 
    • En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
  • Vista 3 - Producción (Production): 
    • En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.
De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:
  • Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • problemas de rendimiento y funcionamiento
      • estadisticas de desempeño
      • problemas de seguridad
      • deuda técnica identificada y que debe ser priorizada
  • Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
    • El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
      • funcionalidades innecesarias
      • funcionalidades a adicionar
      • estrategias de implementación
      • deuda técnica identificada a ser priorizada
      • incidentes y bugs a ser priorizados
      • retos técnicos
      • estimaciones
      • nuevas dependencias técnicas
      • nuevas dependencias funcionales con otros productos o equipos de trabajo
  • Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • valor o ROI generado vs. el esperado
      • datos que se obtienen de la validación de hipótesis
    • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • estadisticas de desempeño
      • problemas de seguridad identificados
      • problemas de experiencia de usuario identificados
      • deuda técnica identificada y que debe ser priorizada
      • estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
  2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
  3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.


domingo, marzo 22, 2020

Reflexión; Un líder no es una víctima



Un líder no es una víctima, es alguien que desde su contexto busca y crea un entorno mejor para quienes lidera y para él/ella.

lunes, marzo 16, 2020

Algunas ideas sobre cultura



La cultura de una organización se conoce por la forma en que trata a sus proveedores.




Los valores y los principios son el mantra que se debe repetir a todo nivel dentro de la organización.




Cuando los procesos no están legislando sobre un determinado aspecto, los principios y valores lo harán.




Los líderes deben reforzar constantemente el conocimiento, difusión, y uso de los valores y principios de la organización.



Las organizaciones que maltratan, discriminan, o segregan a sus proveedores poseen culturas tóxicas.




Para elevar el estándar cultural de una organización el líder debe empoderar a los demás para exigir el cumplimiento de los principios y valores.




La cultura dentro de una organización o grupo de trabajo es la promovida y exhibida por los líderes.




La mejor forma de liderar una cultura es hacerlo con el ejemplo.




El líder debe incentivar y promover todo comportamiento que vaya en pro de la cultura, principios y valores de la organizaición.




El líder debe desestimular todo comportamiento que vaya en contra de la cultura, principios y valores de la organización.




Los procesos reales, es decir, como realmente la organización interactúa para generar valor, son el fiel reflejo de la cultura, principios y valores que tiene la organización, sin importar si estos han sido o no declarados, o si fueron o no documentados de forma correcta o incorrecta.

La forma como interactuamos gobierna sobre lo que esta escrito o declarado. .




"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"(2)




"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"(2)





Los líderes promueven la cultura dentro de una organización, ya sea de forma consciente o inconsciente.
Corolario 1: Las personas a cargo del líder generalmente copiarán los comportamientos del líder independientemente de lo que diga o hace, pues imitar su comportamiento los "llevará a ser como él/ella y a tener su mismo poder", similar como los hijos copian a sus padres (consciente o incosncientemente).






Referencias

  1. Las referencias de este post se basan en muchas experiencias, lecturas y conversaciones, no es mi intención no dar crédito, es más el compartir comportamientos observados para que todos hagamos uso de ellos. Si alguien conoce la cita explícita, no dude en compartirmela, con gusto actualizaré el artículo.
  2. Antipatrón: Solo liderar la primera línea y no gestionar la red - http://www.lecciones-aprendidas.info/2019/08/antipatron-solo-liderar-la-primera-linea-y-no-gestionar-la-red.html