Innovación en Escala: Articulando SAFe para la generación de innovación – Parte 2

En la primera parte de esta serie explicaba una forma de organizar varios elementos de SAFe que articulados apropiadamente pueden brindar un enfoque válido para la generación de innovación a nivel empresarial, cobijados por la adopción de una mentalidad de emprendimiento al estilo Lean StartUp.  De esta forma, el post anterior presentaba los siguientes pasos:

  1. Definir un Value Stream enfocado a la Innovación
  2. Asignar presupuesto al Value Stream de Innovación
  3. Crear Iniciativas de innovación como Épicas
  4. Presentar y  refinar la Épica

A este punto, ya se cuenta con una Épica analizada y refinada en función de las perspectivas de Deseabilidad / People (¿ésta iniciativa resuelve alguna necesidad de alguien?)Viabilidad / Business (¿es ésta iniciativa rentable para el negocio? ¿están dispuestos a pagar por esta solución?) y Factibilidad / Technology (¿es posible construirla con la tecnología existente? ¿debemos crear tecnología para consolidar esta idea?).

Roles SAFe y DT

Épica vista desde las perspectivas del Design Thinking

Como resultado de este análisis, contamos con una primera versión de su Modelo de Negocio (deseablemente en un Lienzo) y un Caso Ligero de Negocio propuesto por SAFe, que le añade a la Épica mayor perspectiva de negocio y es muy útil para el Portafolio. Puede ser algo como lo siguiente:

Ejemplo de un modelo de Negocio

Ejemplo de un Modelo de Negocio

Es importante resaltar que estos elementos representan el diseño del “primer experimento” a ejecutar; de tal forma, todos los elementos del lienzo son sólo hipótesis y el modelo de negocio completo estará en evolución a medida que vayamos recolectando aprendizaje validado, a través del feedback de nuestros Early-Adopters, descubriendo sus problemas y necesidades.

Evolución del Modelo de negocio

Evolución del Modelo de Negocio

Una vez que nuestra épica ha sido aprobada por el Program-Portfolio Management Team  y asignada al Agile Release Train dentro del Value Stream, lo siguiente que SAFe sugiere en su dinámica a nivel de Programa es trabajar en la Visión, el Roadmap del Producto y en el Backlog de Features, a través de varios roles propuestos en este nivel:

Dinámica Nivel de Programa

Visión, Roadmap y Program Backlog en SAFe

Pues NO!, no lo haga así. Sí bien esta dinámica sirve bastante bien para la creación productos en otro tipo de Value Streams donde las condiciones de entrega y cumplimiento son diferentes, desde mi punto de vista ésta perspectiva no refleja una visión de emprendimiento y generación de innovación. No puede establecer un roadmap y backlog de Features para crear una solución a una necesidad y a un usuario que todavía no conoce; hay que experimentar, hay que aprender.

Entonces, en lugar de la Visión enfóquese en descubrir patrones, problemas, necesidades y aprendizaje validado; puede plasmarlos en un Problem Statement que puede cambiar con el aprendizaje obtenido. En lugar de un Roadmap, no pierda de vista su Modelo de Negocio y su evolución; y  en lugar de un Backlog de Features cree varias Hipótesis de Cliente, del problema y de la solución o producto.

Plan-based Mindset vs Lean StartUp Mindset

Pensamiento basado en Planificación vs. Pensamiento Emprendedor (Lean StartUp)

Realice un “Taller de Empatía” (Empathy Workshop)

Para lograr dirigirse a los elementos de la derecha en el gráfico anterior, es necesario “empatizar”. En este taller el equipo emprendendor (en el que ahora se convierte el equipo de Programa de SAFe: Epic Owner, Product Manager, System Architect, Product Owners, Teams y los demás) se reúnen para profundizar sobre varios de los elementos del modelo del negocio y darle rostro a los Clientes y Usuarios, generar hipótesis de problema y solución más enfocadas, y bosquejar capacidades e interacción. En otras palabras, aplicar los pasos del Design Thinking.

Design Thinking es un proceso de innovación enfocado en personas que se nutre de herramientas de diseño para integrar las necesidades de los usuarios, las posibilidades de las tecnología y los requisitos para el éxito de un negocio.” – Tim Brown, Presidente y CEO de IDEO

La dinámica de este taller me emociona. En los talleres de Design Thinking que he facilitado he visto una integración poderosa de la capacidad creativa y de ideación de los participantes, pensamiento enfocado a personas y uso de técnicas del UX que generan una energía genial y entregables fantásticos. Hay muchas herramientas y técnicas que se pueden aplicar el proceso de DT, sin embargo me permito sugerir el siguiente toolkit al que se le puede añadir o quitar elementos. Aplicando este toolkit he realizado talleres en aproximadamente 2 horas con excelentes resultados (pero tómese su tiempo):

Design Thinking Toolkit

Toolkit ligero para un taller de Design Thinking por Johnny Ordóñez

En esta presentación puede profundizar sobre cada paso y las herramientas propuestas dentro de este, así como también algunas fotos de los equipos y su trabajo.

Reemplace sus Features por Hipótesis

En el primer post de esta serie hablaba de llamar Agile Innovation Lab en lugar de ART a los equipos dentro del Value Stream de Innovación; esto es porque me gusta imaginarlo como lugar donde se están corriendo experimentos para probar hipótesis a través del método científico:

Método Científico en Lean StartUp por Alex Cowan

Una hipótesis es una explicación propuesta para explicar un fenómeno. Es un supuesto sujeto a experimentación.  Cuando junto con su equipo, crearon su Modelo de Negocio, definieron algunas hipótesis que responden a varias de estas preguntas:

  • ¿Quién es tu Usuario y quién tu Cliente?
  • ¿Qué problemas tienen?
  • ¿Cómo tu producto encaja en su vida personal o laboral?
  • ¿Cómo y cuándo usarán tu producto?
  • ¿Quién pagará por tu producto?

Considere a éstas Hipótesis al nivel del modelo de negocio. A continuación se pueden establecer hipótesis a nivel de “capacidades” deseables de producto o solución; es decir, construir el producto correcto para la necesidad correcta. Josh Seiden propone aplicar el enfoque de experimentación al desarrollo de software creando así algo denominado Hypothesis-driven Development. Las hipótesis son mejores que los requerimientos en el contexto del emprendimiento donde existe gran incertidumbre. Los requerimientos o features son mejores en contextos donde los estándares son bien conocidos, existe mayor conocimiento del cliente/mercado y de cierta forma el dominio del problema es “estable”. Por esta razón, no significa que la dinámica propuesta por SAFe: Visión -> Roadmap -> Features está mal, simplemente no la creo apropiada para equipos en un Value Stream de Emprendimiento e innovación.

“Necesitamos cuestionar el concepto de tener requisitos fijos para un producto o servicio. Los requisitos son valiosos cuando los equipos ejecutan una bien conocida o entendida fase de una iniciativa, y pueden aprovechar las prácticas bien conocidas para lograr el resultado. Sin embargo, cuando se está en una fase exploratoria, compleja e incierta se necesita hipótesis.” – Barry O’Reilly, Co-autor de Lean Enterprise: How High Performance Organization Innovation At Scale.

Siguiendo la plantilla de Josh Seiden, una hipótesis luce así:

Ejemplo de Hipótesis

Ejemplo de Hipótesis usando la Plantilla de Josh Seiden

Priorice las Hipótesis

Una de las confusiones comunes de los emprendedores a los que he tenido la oportunidad de hacer mentoring, es aquella de diferenciar ¿quién es el Usuario y quién el Cliente?. En ocasiones son los mismos, en otras no. Cliente es quién está dispuesto a pagar por tu producto o servicio en busca de resolver una necesidad real que posee él o ella mismo o un grupo. Usuario es quien estará interactuando directamente con el producto o servicio, quien tiene el problema. Una forma de priorizar las hipótesis es usar la siguiente matriz:

Priorización de Hipótesis

Matriz de Priorización de Hipótesis

Comience por ordenar desde la sección roja hacia la turquesa. Otra forma de hacerlo es la propuesta por Josh Seiden que enfoca el probar los supuestos más riesgosos primero, aquellos de las cuáles no tenemos información y que pueden tumbar el emprendimiento en caso de ser falsas:

Priorización por Josh Seiden

Matriz de priorización de supuestos por Josh Seiden

Ambos enfoques son totalmente válidos y pueden ser usados en función de la madurez de su modelo de negocio, si posee mucha incertidumbre sobre sus hipótesis de Cliente y de Problema, quizás el segundo sea mejor. Si su modelo ha madurado y ha logrado comprobar efectivamente el Cliente, el usuario, el problema y se dispone a probar la solución, posiblemente el primero sea mejor opción.

Desgloce su Hipótesis en Historias de Usuario

A este punto varios agilistas me han preguntado: ¿y dónde están las historias? Tranquilos, vienen a continuación. A pesar de que esto no es parte del enfoque de Hypothesis-driven Development, cuando combina Lean StartUp y Agile Development donde sus equipos usan Scrum por ejemplo, es necesario establecer alternativas sobre cómo comprobar las hipótesis que sacaremos al mercado. Las historias de usuario tienen como objetivo comprobar el supuesto de la hipótesis a través de capacidades más pequeñas que se implementarán en el producto. Si bien es cierto, las historias también pueden ser expresadas en formato de hipótesis en su nivel de granularidad; mi consejo es hacer una correlación y dejar las hipótesis  un poco más “grandes” y que los equipos puedan descomponerla en elementos más familiares como historias de usuario.

Historia de Usuario

Ejemplo de Historia de Usuario

En un equipo Scrum, el responsable de hacer esto es el Product Owner; si bien este rol puede existir, es preferible que todo el equipo emprendedor trabaje destilando alternativas de producto para probar las hipótesis. En algunos casos, no necesariamente significará crear software.

La matriz podría verse así:

Hipótesis e historias

Hipótesis e historias

No es necesario llenar todas las hipótesis con historias. Es mejor enfocarse en definir historias para aquellas de las hipótesis con mayor prioridad que se desee probar en el siguiente Producto Mínimo Viable o MVP. Crear historias no es suficiente, es necesario priorizarlas también. Hay muchos métodos de priorización de historias de usuario, para este contexto sugiero utilizar el Método de Análisis de Kano porque se enfoca en lograr aquella “calidad subjetiva” que va más allá del cumplimiento de features, me gusta la búsqueda de elementos “deleitadores”, sorprendentes, “no esperados” que son más cercanos a definir una mejor experiencia de usuario, vital para los productos de emprendimiento. No quiere decir que las demás no sean útiles, pero tengo una predilección personal por Kano.

Kano

El Modelo Kano

De esta forma, se podrán agrupar las historias de usuario por Básicas, Lineales y Deleitadoras:

Aplicando Kano a las Historias

Aplicando el Modelo de Kano a las historias

Tentativamente, las franjas desde la roja hacia la turquesa nos indican la prioridad y el orden del backlog. Sin embargo, la linealidad puede ser contraproducente. En algunos equipos Scrum donde hemos usado esta técnica, existe la tendencia de seleccionar primero aquellas historias que son básicas, luego las lineales y por último las deleitadoras; con el objetivo de cumplir las características básicas del producto, aunque al principio no encante.

No me gusta mucho, no debes esperar al final para deleitar al usuario; me gustan más una secuencia que nace de navegar por todas los tipos de historia tratando de entregar en cada MVP un poco de todo, y deleitando también:

Línea curva

Secuencialidad en la toma de Historias

Okay, pienso que puedo cerrar aquí por el momento. En el siguiente post escribiré sobre la definición del MVP y la medición del aprendizaje validado.

Gracias por su feedback.

Johnny

 

Referencias

http://www.alexandercowan.com/creating-a-lean-startup-style-assumption-set/

http://barryoreilly.com/2013/10/21/how-to-implement-hypothesis-driven-development/

https://dzone.com/articles/hypothesis-driven-development

http://swombat.com/2011/1/7/how-to-evaluate-and-implement-startup-ideas-using-hypothesis-driven-development

http://www.hackerchick.com/2012/04/hypothesis-driven-development.html

http://scaledagileframework.com/program-backlog/

Anuncios

Innovación en Escala: Articulando SAFe para la generación de innovación – Parte 1

Hace unas semanas tuve la oportunidad de brindar una clase introductoria a SAFe gracias a la invitación de los amigos de DevAcademy (gracias a Lennon y al equipo, siempre es un gusto). Muchas buenas preguntas de los asistentes y de entre ellas una muy interesante de parte de un gran amigo agilista, Pablo Lischinski, que quedó en mi mente y que me animó a escribir este post. La pregunta fue: “¿Y cómo se maneja la innovación dentro de SAFe?”.

En  ese momento recordé que recientemente la casa de los valores de SAFe fue actualizada incorporando un pilar importante: Innovación.

 

Me permito realizar una traducción del texto en la columna para profundizar:

Pilar 3. Innovación:

  • Los “productores” innovan, los Clientes validan
  • “Sal de la oficina”
  • Proporcionar el tiempo y espacio para la creatividad
  • Aplicar la contabilidad de la innovación
  • Pivotar sin misericordia o culpa

Estos ítems representan la interpretación de SAFe a los principios del método The Lean StartUp. Mi respuesta estuvo enfocada en esta dirección y sobre cómo utilizar los recursos de SAFe para articular la generación de innovación en forma de productos o servicios. Sin embargo, pienso que innovación es algo que va un poco más de la aplicación de un método -y hablando sobre cómo aplicarlo en SAFe- siento que vale la pena ahondar.

Innovación es un mindset

Innovation ProcessPodemos encontrar muchas definiciones de innovación, todas interesantes y muy válidas. En lo relacionado a software, normalmente se conceptualiza como la capacidad de crear productos o servicios disruptivos (o agregar features), capaces de deleitar a los Clientes y abrir los mercados, dando la posibilidad a mejor posicionamiento estratégico e incremento en ventas y mayores ingresos como consecuencia. Esto está muy bien, sin embargo innovar va más allá.

Innovamos en todo. Todo el trabajo que se realiza relacionado al desarrollo de software está basado en innovación y el mismo la fomenta. Innovamos cuando escribimos código para resolver un problema, cuando usamos las herramientas para construir un proceso automatizado, cuando adaptamos y mejoramos el proceso, y en general cuando diseñamos formas para trabajar mejor y generar mayor valor. La innovación ocurre siempre y en muchos niveles, y debe ser concebida como un valor empresarial; como una mentalidad compartida y por ende un elemento clave en la cultura organizacional.

Innovación es algo más que simplemente crear productos innovadores, algo más que un proceso o método; conciba innovación como un mindset.

Articulando la generación de innovación en SAFe

Entrando en materia, deseo resaltar varios elementos en SAFe que articulados apropiadamente pueden brindar un enfoque hacia la generación de innovación a nivel empresarial.

Disclaimer: Esto no es una guía, método o proceso. Simplemente es resaltar elementos dentro de un framework que conceptualmente juntos pueden brindar una dinámica de creación de valor en base a experimentos desde una perspectiva empresarial.

Defina un Value Stream enfocado a la Innovación

Muchas compañías destinan parte de su presupuesto a actividades relacionadas a la innovación. Normalmente en grandes empresas existen las áreas de I+D o Investigación Avanzada. Este presupuesto se destina a dar vida a iniciativas que con una respuesta positiva del mercado pueden generar valor para la organización. Esta dinámica tiene cabida en SAFe y el punto de inicio es el Nivel de Portafolio.

El Nivel de Portafolio de SAFe centraliza la visión estratégica de la organización discutida y plasmada a través de Iniciativas de Negocio y Arquitectura Empresarial denominadas Épicas. La inversión en innovación es una decisión estratégica que busca cumplir una visión corporativa más alta. A este nivel se definen los Value Streams, que son la forma principal usada en SAFe para representar la entrega de valor (un concepto muy Lean).

Imagine que un Value Stream es una tubería por la cual la organización entrega productos y servicios hacia el mercado, y se recibe de regreso Valor para la organización representado por ejemplo: incremento en ventas, posicionamiento, reconocimiento de marca, etc. Más en la práctica, los Values Streams pueden definirse como líneas o frentes de negocio sobres los cuales se diversifica la generación y entrega de valor. Definir un Value Stream es una mezcla de arte y ciencia que implica conocimiento de la compañía y del mercado.

Traditional Value Stream

Representación SAFe de un Value Stream

De esta forma, lo primero en habilitar para la generación de Innovación como estrategia empresarial en SAFe, es contar con un Value Stream relacionado a Innovación, con un nombre que haga relevancia a aquello. Ahora deténgase a pensar por un minuto en lo siguiente: ¿Quiénes son los Clientes de este Value Stream dedicado a la Innovación? ¿nuestra empresa? ¿nuestros Clientes existentes? ¿nuevos Clientes? Son nuestros Early Adopters; aquellos visionarios quienes se atreven a adoptar un producto o tecnología novedosos y están dispuestos a pagar para  solventar una necesidad o problema que poseen. A mi me gustan estos cinco tips sobre cómo identificar sus Early Adopters.

Innovation Value Stream

Value Stream enfocado en Innovación y Emprendimiento

Asigne el Presupuesto al Value Stream de Innovación

Básicamente es la respuesta a ¿cuánto vamos a destinar este año para innovación? Cada Value Stream tiene asignado un presupuesto, y todo el presupuesto de la organización repartido en Value Streams se gestiona dinámicamente en el tiempo, lo que SAFe denomina Lean-Agile Budgeting. Es decir, el presupuesto asignado puede ser revisado y ajustado para dar vida a nuevas iniciativas que según el criterio del Program-Portfolio Management Team pueden ser oportunidades con mayores probabilidades de obtener mayor valor para la empresa en un momento determinado.

El presupuesto asignado sirve para financiar uno o varios Trenes de Entrega Ágil o ARTs (Agile Release Trains). Más que financiar proyectos, SAFe propone el financiamiento de Trenes Ágiles quienes son los responsables de implementar las Épicas. SAFe sugiere que el tamaño de un ART va de entre 50 a 125 personas. Posiblemente en compañías realmente grandes exista grupos de este tamaño dedicados a I+D o relacionados; sin embargo, no toda organización puede hacer esto por lo que el número de personas puede ser menor a 50. En lugar de ART, a mi me gusta concebirlo como un “laboratorio”, algo como un Agile Innovation Lab; en lugar donde se están corriendo experimentos para probar modelos de negocio (no es que quiera inventarme más términos, pero suena bonito 🙂 ).

Iniciativas de innovación como Épicas

Dentro de la compañía en la que trabajo hay personas que constantemente están mirando el mercado, las tendencias en tecnología y lo que está sucediendo relacionado al giro de negocio. Estas personas pueden ser designadas formalmente para aquello (por ejemplo si son Analistas dentro de la organización o Investigadores ) o simplemente cualquier miembro dentro de la compañía. SAFe habilita a que cualquier persona en la empresa pueda convertirse en un Epic Owner y presentar una iniciativa al equipo de Portafolio; yo lo llamo: “Nadar en el estanque de Tiburones.” :). Imagine que Usted es un emprendedor que tiene una gran idea y está buscando financiamiento para lanzar su proyecto, se pone en frente de los inversionistas y comienza a “vender” su idea.

SHARK TANK - Mark Cuban, Daymond John, Barbara Corcoran, Kevin O'Leary, Robert Herjavec and Lori Greiner are

SHARK TANK – Mark Cuban, Daymond John, Barbara Corcoran, Kevin O’Leary, Robert Herjavec and Lori Greiner are “Sharks” on ABC’s “Shark Tank.” (ABC/ADAM TAYLOR)

En esta dinámica, la Épica es presentada y revisada por todo el equipo (de tiburones), se resuelven dudas relacionadas, se conversa sobre los beneficios y el potencial de la iniciativa, para luego ser votada; simplemente levantando la mano de aquellas personas que consideran que se debe invertir en la iniciativa, el voto de confianza. Si su “tiburonez” es bueno (“Tiburonez”: lenguaje que se habla dentro del estanque: valor, dinero, beneficios, margen, etc.) y se decide continuar, se determinará qué Tema Estratégico es apalancado por la Épica y a qué Value Stream pertenece, en este caso, al Value Stream enfocado a Innovación.

Tip: Si va a nadar en el estanque de tiburones, entonces hable buen “tiburonez”: muestre un buen modelo de negocio.

La idea por sí misma no deja de ser sólo eso, una idea. Recuerde que está frente al estanque y no puede llegar únicamente diciendo: “Hagamos esta aplicación móvil, será bueno para la compañía”. Para ayudar a fluir su “tiburonez” trabaje y presente un modelo de negocio convincente, y para esto puede apoyarse en varios “lienzos” para plasmar sus -hasta ahora- hipótesis correspondientes al Cliente (Early Adopters), el Problema, y su solución (en esta presentación, encontrará algunos de los lienzos más populares).

Personalmente me gusta el Javelin Experiment Board, porque su diseño hace que la definición de hipótesis sea más sencilla y concreta (un post-it) y como los demás, habilita una excelente comprensión visual.

Javelin Experiment Board

Trate de que no enfocarse en crear un lienzo o modelo perfecto. Tome en cuenta que todo estará sujeto a validación, incluyendo sus Early Adopters. Trabaje con su equipo para darle forma y sentido de negocio. No dude incorporar su lienzo al Caso de Negocio Ligero propuesto por SAFe para la presentación de Épicas

Todo puede pasar, pero asumamos que incorporando estos elementos y luego de sus sus 15-20 minutos de presentación ha ganado la confianza del estanque y aprobaron su épica. ¡Felicitaciones! Pero el proceso no termina allí, acaba de comenzar.  La Épica debe atravesar un Flujo Kanban donde se refina y está sujeta a las restricciones WIP de la compañía (relacionadas a Presupuesto y Capacidad Organizacional para Ejecución). Así es, normalmente las compañías poseen un presupuesto acotado. Para el siguiente paso del flujo deberá refinar su épica.

Epic Kanban Flow - SAFe

Flujo Kanban de una Épica propuesto por SAFe http://scaledagileframework.com/business-epic-kanban/

Refine su Épica

Luego de su primera victoria al salir vivo del estanque, es momento de brindar mayor detalle a su iniciativa, de refinarla; y esto no lo hace solo. En este punto me gusta mirar a una Épica desde las tres dimensiones tomadas de Discover to Deliver de Ellen Gottesdiener y Mary Gorman : Cliente, Negocio, Tecnología.

 

Customer, Businnes, Technology

Perspectivas de Discover to Deliver de Ellen Gottesdiner y Mary Groman

Es perfectamente coherente. No sólo hay que concebir ideas pensando únicamente en las necesidades potenciales del Cliente, también deben representar un negocio rentable para la compañía y debe poder hacerse con la tecnología existente.

Estas dimensiones se ven mucho más claras desde la perspectiva del Design Thinking y del Human-centered Design, donde las intersecciones de las dimensiones sugieren varios tipos de innovación:

design-thinking-962x1024

Dimensiones del Design Thinking

Nuevamente, enfocarse en:

  • Deseabilidad: ¿Esta iniciativa resuelve alguna necesidad de alguien? ¿Quiénes son? ¿Están dispuestos a pagar? ¿Es una propuesta totalmente nueva en el marcado?
  • Viabilidad: ¿Cuál es el beneficio para la compañía: incremento en ventas, posicionamiento? ¿Cuál es el margen potencial? ¿Podremos sostener su operación en el tiempo? ¿Cuál es el esquema de monetización?
  • Factibilidad: ¿Se puede lograr con la tecnología existente? ¿Cuáles son los desafíos técnicos o tecnológicos que presenta? ¿Poseemos los skills y  las herramientas para hacerlo?  ¿Cuáles son las limitaciones arquitectónicas?

Para cada dimensión puedo sugerir roles SAFe que apoyen en el refinamiento de la Épica desde cada perspectiva:

Roles SAFe y DT

Dimensiones del Design Thinking y Roles SAFe

Por ahora pienso que puedo cerrar aquí. En la segunda parte de este artículo comentaré sobre la visión del producto, el roadpmap y el backlog de Features.

Como siempre, gracias por leer y por su feedback.

Johnny

Referencias

http://scaledagileframework.com/lean/

http://theleanstartup.com/

https://www.rallydev.com/toolkits/enterprise-lean-startup

http://es.slideshare.net/jezhumble/applying-the-lean-startup-model-to-the-enterprise

http://www.infoq.com/news/2013/10/apply-lean-startup-enterprises

http://www.slideshare.net/JohnnyDark/lean-start-up-y-scrum-como-crear-productos-que-los-clientes-quieren-pagar

http://www.amazon.es/Lean-Enterprise-Performance-Organizations-Innovate/dp/1449368425

http://saiframeworkbalancer-762644628.us-east-1.elb.amazonaws.com/epics/

http://www.scaledagileframework.com/value-streams/

http://javiermegias.com/blog/2012/12/early-adopters-clave-nuevo-modelo-de-negocio-curva-adopcion-tecnologia/

http://innokabi.com/early-adopters-5-claves-para-detectar-a-tus-primeros-clientes/

http://www.scaledagileframework.com/budgets/

http://scaledagileframework.com/agile-release-train/

http://www.discovertodeliver.com/

http://designthinking.ideo.com/