viernes, 28 de julio de 2017

¿Cómo son las historias de usuario de marketing?

Ejemplos de historias de usuario de marketing
Gracias Jim y Fernando
Fernando, un alumno de los cursos on-line Scrum Manager de mayo de 2017, inició un tema interesante; no siendo técnico y viniendo de marketing preguntaba sobre cómo debería de escribirse una historia de usuario para el caso de un fármaco, un cliente que buscara el desarrollo de una vacuna inexistente para una nueva enfermedad xx en pacientes de rango etario yy a zz de edad.

Profundizando en el tema me topé con el blog sobre Marketing Agile de Jim Ewel que describe de un forma excepcional como son las historias de usuario de marketing.

Como ejemplo de historia de usuario de marketing Jim propone entre otras la siguiente:

"Como madre quiero grabar y compartir vídeos de los niños para poder compartir momentos importantes con los abuelos, tíos y amigos"

Si nos fijamos está escrita con el patrón que recomienda Mike Cohn:

Como [rol del usuario], quiero [objetivo], para poder [beneficio]

con matices algo diferentes:

Como [cliente ideal], quiero [nuestra solución], para [que sus problemas desaparezcan]

En marketing también se utilizan User-Personas para describir de forma ficticia al público objetivo, para poder diseñar sitios web, escribir material de marketing y generar contenido (publicaciones de blog, videos, libros electrónicos, etc.) que satisfagan sus necesidades. La solución nos hace centrar en lo que los clientes quieren lograr, ya sea resolver un problema, aliviar un dolor o aspirar a algo mejor a través de nuestro producto. El "para" trata la pregunta que un buen marketing debe responder: ¿Qué hay en él para mí? (What’s In It For Me? - WIIFM).

Jim Evel nos compara los dos tipos de historias de usuario en la segunda parte del post sobre historias de usuario de marketing:

Historias de usuario de marketing
Bajo nivel
Alto nivel
Número elevado de estas en la pila
Relativamente pocas en la pila
Hemisferio izquierdo del cerebro
Hemisferio derecho del cerebro
Focalizadas en funcionalidades
Focalizadas en resultados

Las historias de usuario de TI son detalladas y tienen una granularidad muy fina, las de marketing son cosas amplias, por tanto la pila de producto de marketing suele ser corta. Lo interesante es en lo que se focalizan, las historias de TI al hablar de funcionalidades están orientadas a la parte racional de las personas, las de marketing a la parte emocional (fijémonos en el ejemplo más arriba de la madre que quiere grabar a sus niños, sus razones son emocionales). Cuando la gente habla de marketing, por ejemplo de anuncios que les han impresionado, hablan de cómo les han hecho sentir, acerca de como cambió su día o cómo les hizo reír histéricamente.

Veamos pues como sería la historia de usuario sobre el fármaco de Fernando:

"Como farmacéutico quiero el desarrollo de una vacuna para prevenir la malaria en pacientes de rango etario de 4 a 13 años de edad para mejorar la calidad de vida de la población afectada"

Historia de usuario terminada - cortesía de Pixabay
Recordemos que las historias de usuario, que van a la pila de producto son "qués", aquello que necesitamos o queremos para resolver un problema, y el desarrollo de la vacuna inexistente sin duda es un "qué". En la pila de sprint se desglosará esta en los "cómos", las tareas o desarrollos a resolver, que en este caso podrían ser: descomponer del target del mercado, patología, composición de la droga preliminar, forma de aplicación de dosis, etc.

Tal como prescribe Scrum debe de haber una definición de hecho (DoD) para considerar la historia como terminada, por ejemplo, "y la vacuna pasará los controles de calidad e irá embotellada y etiquetada". Finalmente se añadirán los criterios de aceptación que van servir para comprobar si la historia cumple con los requisitos, por ejemplo: "realizar la comprobación que la vacuna funciona al xx% en una muestra de zz personas".

Mis agradecimientos a Fernando por haberme impulsado a escribir este post.

sábado, 22 de julio de 2017

¿Cómo preparar a los futuros profesionales para la colaboración y la autoorganización?

Alumna eduScrum Master actualizando el burndown
Una de las áreas donde se está explorando la aplicación de Scrum es la educación. Desde 2011 en Holanda diversas escuelas practican en clase un marco derivado de Scrum, una iniciativa del profesor de química Willy Wijnands, que bautizó con el nombre de eduScrum.

En eduScrum el aprendizaje toma el centro del escenario: aprender de forma más inteligente, mejorar la colaboración y llegar a conocerse mejor a uno mismo, sobre pilares de transparencia, inspección y adaptación y con equipos autoorganizados. Esta forma de trabajar crea una mayor responsabilidad, diversión y energía, construye sobre las motivaciones de autonomía, maestría y el propósito, lo que conduce a mejores resultados y a tiempos de aprendizaje más cortos. Los estudiantes experimentan un fuerte crecimiento personal que refuerza la confianza en sí mismos y en los demás. Con eduScrum prepararmos a nuestros chicos de secundaria para convertirse en los profesionales del siglo XXI, donde lo que importa es la colaboración y no la competitividad:

"eduScrum es un marco para el coaching de estudiantes donde la responsabilidad del proceso de aprendizaje se delega de los profesores a los estudiantes"

El equipo eduScrum está formado por el equipo de estudiantes (4 estudiantes) + el eduScrum Master (estudiante, uno de los 4) + Propietario del Producto (profesor).

El Propietario del Producto es el responsable de la pila de producto, lista priorizada de objetivos de aprendizaje o capítulos del tema a estudiar en forma de historia. A diferencia de Scrum también vela por el proceso, y lo va delegando al eduScrum Master a medida que este coge experiencia.

El eduScrum Master es el responsable de velar por el tablero u "hoja", actualizar el burndown y de asegurarse que su equipo de estudiantes sigan las reglas.

Los alumnos estudian de forma colaborativa en equipo, parten de las historias que el Propietario del Producto ha priorizado en la pila de producto, y al ser propietarios de su propio proceso de aprendizaje crean, estiman con planning poker y se autoasignan las tareas que consideran necesarias. Por ejemplo, son ellos mismos los que definen sus deberes. Si tienen dudas requieren del Propietario del Producto para tratarlas adecuadamente.

Los sprints son de uno a dos meses, en la planificación sprint se forma cada vez un equipo de estudiantes nuevo y se determinan los objetivos aprendizaje. La reunión de a pie se hace antes de clase y en ella los estudiantes dan respuesta a las tres preguntas referidas a los objetivos de aprendizaje. Cuando todas las historias estás hechas según DoD el Propietario del Producto hace un examen, si el equipo no lo pasa, las historias vuelven a la pila de producto.

A modo de mejora continua después de la revisión de sprint se realizan una retrospectiva a nivel del equipo y una reflexión personal a nivel de cada estudiante.
"Hoja" o tablero eduSrum
El tablero u "hoja" de eduScrum tiene dos columnas para el Propietario del Producto, "Historias" donde pone los capítulos del tema y los "Criterios de Aceptación" del temario que los alumnos han de trabajar. Los alumnos crean las tareas que colocan en "Pendiente" y hacen avanzar a través de "Ocupado" a "Hecho".

En el tablero se muestran los criterios de hecho (DoD) y los criterios de divertido (DoF) que son acuerdos entre alumnos y profesor. En otras áreas a tal efecto se muestran el burndown y los impedimentos que van afectando el sprint.
Para quienes quieran profundizar en esta forma de aprendizaje colaborativo les dejo un link para descargar la Guía de eduScrum, "Las reglas del juego" creada por el equipo de eduScrum.

Maria Montessori en la renovación de los métodos pedagógicos de principios del siglo XX

sábado, 15 de julio de 2017

¿Cómo gestionar las acciones resultantes de las retrospectivas?

Scrum Master facilitando una
retrospectiva, gracias Marisa :-)
Una de las responsabilidades del Scrum Master es la de asegurarse que el equipo cierre las retrospectivas con acciones, una por retrospectiva, que sean posibles hacer durante el siguiente sprint. Recordemos que a través de las retrospectivas estamos estableciendo una cultura de mejora continua en la que equipo mejora su forma de trabajar con cada sprint.

Para asegurarnos que el equipo obtenga beneficio de las acciones propuestas, estas deben de gestionarse. Sin esta gestión las acciones de mejora pueden perderse o retrasarse innecesariamente, y el equipo puede perder la confianza en el marco de mejora continua. Suele ser frustrante si retrospectiva tras retrospectiva no hay acciones de mejora que se hayan materializado, en estos casos los equipos hasta dejan de hacer la reunión.

Las acciones resultantes de una retrospectiva deben de ser claras y entendidas por todos los involucrados, equipo de desarrollo y Propietario del Producto, y todos deben de estar de acuerdo en que las acciones son válidas.

Es recomendable que sean pequeñas y potentes, estén escritas con un patrón que incluya el porqué, la razón de esa acción o los problemas que resolverá, así como los beneficios que aportará, y también la persona o las personas que se la llevarán para gestionarla o hacer una exploración para determinar si se produce una mejora para el equipo en el siguiente sprint.

En función de la naturaleza y el tamaño de las acciones podemos llevarlas a diferentes pilas:

Acciones pequeñas al siguiente sprint, pueden incluirse en post-its de otro color el la pila de sprint en el scrum board. Ejemplos de ello pueden ser acciones como:
Acciones grandes a la pila de producto, suelen ser acciones que requieren de un esfuerzo estimable y que por tanto deben de tenerse en cuenta en la planificación de sprint y pueden, o no, entrar en el siguiente sprint. Ejemplos clásicos son:
  • Carencia en la formación técnica o de negocio
  • Preparar un máquina para integración continua
  • Refactorización mayor
Para acciones de mejora que sean acuerdos del equipo llevarlas al tablero de políticas explicitas, usualmente un área específica del scrum board:
Impedimentos que surjan en las retrospectivas se los lleva el Scrum Master, recomiendo tener un tablero específico para éstos:
  • Aligerar documentación de seguimiento (clásico de la PMO)
  • Rendimiento de las VDIs (máquinas virtuales), incrementar su RAM
  • Entorno de test estable y réplica de producción

viernes, 14 de julio de 2017

¿Hay nombres para la disfunciones de los roles de Scrum?

Good Scrum Master
Cortesía de Pixabay
A lo largo de mi experiencia en diferentes compañías, charlas con compañeros coaches ágiles y trainers y recorriendo algunos blogs la web, he recopilado unos pocos términos disfuncionales para el Scrum Master y el Propietario del Producto que me han hecho mucha gracia. En especial el post "The Scrum Master as the Change Leader" de Barry Overeem menciona algunas disfunciones de Scrum Master que me han hecho reír mucho. :-D

Good Scrum Master: el Buen Scrum Master que solo se dedica a ser Scrum Master. Se dedica de forma efectiva a ser el facilitador de todo el proceso, cuida que se cumplan las reglas de Scrum, se responsabiliza de que haya mejora continua, facilita las reuniones, forma y acompaña al equipo de desarrollo y al Propietario del Producto en el aprendizaje del marco, gestiona la resolución de impedimentos, motiva la colaboración desde los valores ágiles y participa e impulsa el cambio cultural de forma gradual en la organización.

Ugly Scrum Master: Un Scrum Master Feo es el que es a la vez miembro del equipo de desarrollo y Scrum Master. Usualmente se habla de disfunción porque el foco de ambos roles es otro, tecnología y coaching son cosas muy distintas, es difícil entrenar bien a un Scrum Master y no debemos menosvalorar la importancia del rol ni los desafíos a los que se enfrenta. La persona que hiciera ambos roles puede entrar en conflicto cuando producto/proyecto y proceso choquen, debiéndose inclinar por uno o por otro. Un desarrollador va a dar prioridad al producto ya que en primera instancia es constructor de producto.

Bad Scrum Master: Un Mal Scrum Master es a la vez Propietario del Producto y Scrum Master; un Scroduct Ownster como lo bautiza Atlassian en su serie de "The wrong way to do Agile". La Scrum Guide prohíbe explicitamente esta combinación, el Propietario del Producto busca el mejor producto posible, el Scrum Master el mejor equipo posible y si combinamos ambos puede convertir a la persona en un jefe de proyecto despótico.

Executive Scrum Master: Un Scrum Master Ejecutivo es un ex jefe de proyecto que aprendió a planificar en cascada y a ejecutar los planes por fases, entiende Scrum pero intenta llenar las supuestas carencias que detecta desde su perspectiva con sus técnicas de planificación. Tiene el foco fuertemente anclado en el cumplimiento de del sprint, en ver como el proceso toma forma y se asienta, y no es consciente de la parte esencial referente a los aspectos humanos, en desarrollar a los miembros del equipo y proporcionarles un entorno en el que aprendan de forma continua.

Scrum Police Officer: El Oficial de Policía Scrum es un Scrum Master que probablemente forme parte de una oficina de proyectos y que sigue rigurosamente las reglas de Scrum o las reglas de la metodología adaptada por la organización. Lo hace con cero empatia por la situación y contexto del equipo, simplemente si este no actúa de acuerdo con las reglas está mal hecho, independientemente de si aplican o aportan al equipo. Las acciones de mejora de las retrospectivas que no "encajan" simplemente son ignoradas con la afirmación que no admite duda: "somos así y eso no va a cambiar, ¡somos profesionales!"

Scrum Mother or Father: Scrum Master maternalista o paternalista que cuida de su equipo como si fuera una madre o un padre. Aplica las normas de autoridad o protección tradicionalmente asignadas a la madre o al padre de familia al ámbito laboral, en este caso al equipo de desarrollo. La consecuencia conlleva una reducción de la libertad y autonomía del equipo, siempre dependerán de este tipo de Scrum Master. A veces un Scrum Master ha de apartarse para que los equipos cometan sus propios errores y aprendan de ello.

Scribe Scrum Master: El Scrum Master Escribano que toma notas de todos las reuniones de Scrum, documenta exhaustivamente las planificaciones de sprint, las reuniones diarias, los refinamientos, las revisiones de sprint y las retrospectivas. Probablemente sus superiores miden su "eficacia" por el número de palabras de sus informes.

Team Boss Scrum Master: El Scrum Master/Jefe de Equipo, o como se suele llamar a si mismo "líder al servicio". Es el jefe, quien ficha y despide, el que decide quien merece un aumento de sueldo y quien no, el que premia y penaliza, el que se encarga de mantener las buenas costumbres en el equipo como por ejemplo hacer dos horas extra al día como buenos profesionales, el que decide quién está más capacitado para cada una de las tareas del sprint...

Secretary Scrum Master: El Scrum Master Secretario que planifica todas las reuniones de Scrum y las agendas en los calendarios de todos los miembros del equipo, Propietario del Producto e interesados... y otros jefecillos, gerentes y hierbas varias. También es responsable de mantener los calendarios de los equipos actualizados con días festivos y vacaciones.

Chairman Scrum Master: El Scrum Master Presidente de la reunión diaria, al que todas las mañanas el equipo proporciona una actualización de la situación actual. Así el Scrum Master obtiene la información necesaria para escribir el informe de situación diaria a sus superiores, informe estratégico para el buenhacer de la compañía. :-P

The Admin Scrum Master: El Scrum Master Administrador, si el equipo necesita un cambio en JIRA, Redmine, CCM, iceScrum o cualquier otra herramienta el Scrum Master es tu amigo, él conoce todos los flujos de trabajo de memoria y haciendo honor a su rol es el experto en herramientas.

Good Product Owner
Cortesía de Pixabay
Good Product Owner: un Buen Propietario del Producto es aquél que toma toda la responsabilidad sobre el producto a la vez que tiene toda la autoridad sobre el mismo. Es alguien con una fuerte conocimiento del mercado, que siente pasión por el producto y es un verdadero líder al servicio que se integra en el equipo, está disponible, lo apoya y asiste a todas las reuniones. Tiene una visión de lo que desea construir, gestiona su propio presupuesto para decidir qué construir y es capaz de transmitir la visión al equipo de desarrollo, al inicio a través de la visión del producto, y a lo largo de los sprints a través de la pila de producto. Un buen Propietario del Producto motiva al equipo con una meta clara y elevada.

Phoenix Product Owner: un Propietario del Producto Fénix es aquél que desaparece al finalizar la planificación de sprint y no reaparece hasta dos semanas después en el inicio de la revisión de sprint. Puede tener una pila de producto bien preparada, con elementos bien trabajados y lo puede estar haciendo de sprint en sprint, su carencia reside en que no está disponible para el equipo durante el sprint y por tanto no resuelve dudas ni da feedback en caliente, minimizando de esta manera las posibilidades del marco de Scrum.

Scribe Product Owner: El Propietario del Producto Escriba suele ser un Business Analyst o un ingeniero de requerimientos de una empresa que está empezando con Scrum y que usualmente todavía no ha desarrollado su cultura ágil. La empresa describe las funciones del rol como alguien que recoge deseos y necesidades de los interesados y los escribe de un lenguaje entendible por el equipo de desarrollo a través de historias de usuario. También se le considera gestor de la pila de producto con mínima o nula autoridad sobre las historias, esta suele residir en una PMO o un SteerCO.

Proxy Product Owner: El Propietario del Producto Proxy es un corre-ve-y-dile que no tiene conocimiento profundo del negocio ni poder de decisión. Algunas compañías distribuyen el rol en dos, un gerente del producto, o product manager, y un "Propietario del Producto" Proxy. El gerente del producto se encarga de los aspectos de comercialización y gestión del producto, posee la visión, se relaciona hacia negocio y por tanto se mantiene en contacto con el mercado. El proxy tiene funciones de gestor de proyecto para con la pila de producto y la de interfasar con el equipo de desarrollo, por tanto se difumina la responsabilidad. La autoridad de este tipo de Propietario del Producto es muy limitada, tiene que pedir aprobación para introducir cambio, para cambiar prioridades, para cambiar la hoja de ruta... con lo se producen retrasos y otros desperdicios como cuellos de botella en la toma de decisiones y una disminución de la productividad y la moral.

Business Representative Product Owner: El Propietario del Producto Representativo de Negocio suele ser un senior o experto de negocio de la empresa que conoce el contexto de negocio, el mercado y a las necesidades y deseos de clientes y usuarios. También puede ser alguien del departamento de IT, un Manager de IT o un arquitecto con un alto conocimiento técnico del producto. Este tipo de Propietario del Producto suele ser responsable de parte del producto y tiene toda autoridad sobre la pila de producto y sobre lo que construye el equipo de desarrollo, pero no tiene un presupuesto propio, los cambios que gestiona en su pila están limitados al presupuesto que la PMO o el SteerCO le han asignado en forma de proyectos a ejecutar u objetivos a cumplir.

Sponsor Product Owner: El Propietario del Producto Espónsor es muy similar al representativo de negocio, la diferencia principal está en que este tiene su propio presupuesto, sobre el que dispone y decide libremente, así como la autoridad sobre sus propios objetivos. Por ejemplo, si el producto tuviera un gran éxito, este tipo de Propietario del Producto podría decidir escalar contratando nuevos equipos para acelerar el desarrollo, de la misma manera que podría desacelerar, siempre con el fin de maximizar el ROI del producto.

Mis agradecimientos a Alexandre y a Marcos que han aportado algunas disfunciones resultantes de sus experiencias :-)

jueves, 13 de julio de 2017

¿SAFe® es un marco empírico en evolución continua?

Realmente lo que me hacía gracia para escribir este post era poner en orden las diferentes versiones del "Big Picture" de SAFe® que he ido encontrando a lo largo de la web.

SAFe es un marco que está en continua evolución, parte de una amplia base de conocimiento como son Lean Thinking, Lean Product Development, Ingeniería de Sistemas, Agilidad, System Thinking y otros, y se va actualizando y refinando constantemente con aquello que su equipo aprende con cada implementación. Cuando me formé con Dean Leffingwell este nos contaba lo agradecido que estaba a cada compañía por el feedback y el aprendizaje que suponía cada una de las implementaciones.

En sus inicios SAFe publicaba actualizaciones frecuentes, actualmente lo hace de forma en entorno anual, veamos la evolución de sus "Big Pictures" :-)

..., 2008, 2009, 2010 - The Agile Enterprise

En años previos a Scaled Agile Dean Leffingwell describe en su post "Enterprise Agility–The Big Picture" como trabajando con los ejecutivos de Symbian Software Ltd. trataba de darles un "Big Picture" de como quedaría la compañía después de adoptar Agile a nivel de la empresa.
Big Picture - The Agile Enterprise - 2008/1Big Picture - The Agile Enterprise - 2008/2
Big Picture - The Agile Enterprise - 2009Big Picture - The Agile Enterprise - 2010

2011 - Scaled Agile Framework 0.X

En la fase de construcción del marco Dean Leffinwell y su equipo completan los textos a nivel de equipo, crean el logotipo y añaden nuevos iconos como el RTE "Release Train Engineer" y de recursos compartidos "Shared". Podemos ver el avance en su post "Scaled Agile Framework Big Picture Update".
Big Picture versión 0.8 - Scaled Agile Framework - 2011Big Picture versión 0.93 - Scaled Agile Framework - 2011
Big Picture versión 0.98 - Scaled Agile Framework - 2011

2011 - Scaled Agile Framework 1.0

En 2011 SAFe presenta la primera versión oficial del interfaz de usuario principal, el "Big Picture", que pone de relieve los roles individuales, equipos, actividades y artefactos necesarios para escalar Agile a nivel de empresa, desde el equipo individual al equipo de equipos.
Big Picture versión 1.0 - Scaled Agile Framework - 2012

2011 - Scaled Agile Framework 2.0

El mismo año de la primera versión SAFe lanza la versión 2.0, una versión mayor en la que refina sensiblemente el nivel de Portfolio.
Big Picture versión 2.0 - Scaled Agile Framework - 2012

2012 - Scaled Agile Framework 2.1

Con esta versión menor se refina la visión y en mayor grado el contenido público de la web.
2012 - Scaled Agile Framework 2.1

2013, agosto - Scaled Agile Framework 2.5

Con esta versión SAFe añade nuevos contenidos sustantivos en todos los niveles: Team, Program y Portfolio. Explicita en el "Big Picture" como los objetivos los identifican los equipos y se agregan a nivel de ART. Estas adiciones están destinadas a acelerar aún más los beneficios empresariales que la aplicación del marco ha estado brindando a los usuarios de todo el mundo.
Big Picture versión 2.5 - Scaled Agile Framework - 2013

2014, agosto - Scaled Agile Framework 3.0

La versión 3.0 no trae cambios estructurales en el marco, el enfoque principal es resultar más fácil de entender y mejorar la representación de cómo funcionan los 3 niveles (Team, Program y Portfolio) y cómo se podrían aplicar a una organización grande, especialmente en el nivel de Portfolio.
Big Picture versión 3.0 - Scaled Agile Framework - 2015

2015, marzo - LSE: SAFe for Lean Systems Engineering

El 10 de marzo SAFe lanza en paralelo SAFe LSE, el primer marco que proporciona los valores, principios, prácticas y constructores organizativos necesarios para construir e implementar sistemas ciberfísicos complejos más rápidamente y con mayor calidad. LSE está diseñado para satisfacer las crecientes necesidades de aquellos que construyen los sistemas más complejos del mundo que contengan elementos aeroespaciales, mecánicos, eléctricos, fluidos, ópticos y otros elementos y que cada vez requieren más software.
SAFe for Continuous Systems Engineering 0.1SAFe for Lean Systems Engineering 0.09
SAFe for Lean Systems Engineering 0.30SAFe for Lean Systems Engineering 0.40
SAFe for Lean Systems Engineering 0.59SAFe for Lean Systems Engineering 0.61
SAFe for Lean Systems Engineering 0.73SAFe for Lean Systems Engineering 0.77

2016, enero - SAFe 4.0 for Lean Software and Systems Engineering

La versión 4.0 incorpora nuevos constructores con un nuevo nivel, llamado "Value Stream", que está diseñado para aquellas compañías que construyen los sistemas más grandes y complejos del mundo. Incluye guía para líderes Lean-Agile, orientación para la formulación de estrategias y la comunicación del Portfolio. Los ARTs alinean a los equipos a una misión común apoyados por arquitectura y UX, e introduce Kanban y flujo a nivel de equipos.
Big Picture expandido versión 4.0 - SAFe 4.0 for Lean Software and Systems Engineering - 2016

2017, junio - SAFe for Lean Enterprises 4.5

Con la versión 4.5 SAFe proporciona una introducción más sencilla al marco a través de sus configuraciones "Full SAFe", "Large Solution SAFe", "Portfolio SAFe" y "Essential SAFe". Introduce temas como "Lean UX", "Continuous Delivery Pipeline" y "Scalable DevOps", la novedad más grande de esta versión. También incluye el "Implementation Roadmap", una descripción más detallada de como introducir SAFe en una compañía.
Big Picture completo versión 4.5 - SAFe for Lean Enterprises - 2017

ACTUALIZACIONES POSTERIORES

2018, noviembre - SAFe for Lean Enterprises 4.6

La versión 4.6 introduce las 5 competencias core de una empresa Lean-Agile, que son Liderazgo Lean-Agile, Agilidad de Equipo y Técnica, DevOps y Releases a demanda, Soluciones de Negocio y Sistemas Lean y Lean Portfolio Management. Como novedad trae SAFe para empresas públicas e incluye DevOps, Ingeniería de software ágil y arquitectura de soluciones y sistemas SAFe en el Implementation Roadmap.
Big Picture completo versión 4.6 - SAFe for Lean Enterprises - 2018

Esta versión se focaliza sobre las 7 competencias
2019, octubre - SAFe for Lean Enterprises 5.0

La novedad principal de esta versión 5.0 trata en focalizarse en un Big Picture con las 7 competencias para evolucionar a Business Agility, un enfoque de valores y principios, y dejar el Big Picture de prácticas y procesos en segundo término.

Los niveles team y programa se unen en uno solo; el essential, presenta dos nuevas competencias básicas basadas en el espíritu de la Agilidad, incluye Business Agility, Design Thinking, se centra del todo en el cliente, agrega un nuevo principio; organizar en torno al valor y ha evolucionado significativamente el nivel de Lean Portfolio Managment.
Big Picture completo versión 5.0 - SAFe for Lean Enterprises - 2019

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.