Agilistas: Empatía con el Management

2_5

En los procesos de transformación ágil en los que he podido participar, he visto que generalmente las personas en las que se acumula mayor presión generada por proceso -y quizás mayor frustración y “sufrimiento”- son aquellas que pertenecen a la capa media de gestión, el middle-management: gerentes, directores, coordinadores, líderes.

Veamos un par de escenarios. En un proceso de adopción bottom-up, Agile y métodos como Scrum empoderan a los equipos y les invita a desatar todo su talento y autonomía. Toman sus decisiones, definen acuerdos, fomenta el compromiso y el desarrollo de sus habilidades tanto técnicas como de trabajo en equipo. Normalmente, están muy motivados y entusiastas…aunque no se tenga toda la certeza de algunas cosas.

Desde una perspectiva top-down, los beneficios de la Agilidad hacen eco el staff Ejecutivo -Presidentes, Vicepresidentes y altos Directivos. Mejorar el Time-to-Market, incrementar la Calidad, procesos más eficientes, mayor satisfacción de los Clientes, alineamiento y visibilidad, flexibilidad; son cualidades deseables de un negocio saludable en vista de adaptarse, mejorar y crecer. Estos elementos coinciden con las expectativas de negocio y el lenguaje estratégico. Quizás con algo de escepticismo, pero el mensaje es muy bien recibido en este nivel.

De pronto, las personas del nivel medio de gestión se ven en una reunión en la que ya sea, por arriba o por abajo; el mensaje principal es: “Nos vamos hacia Agile!”. Al principio posiblemente no se tenga mucha conciencia de lo que esto significa: “Una metodología más, ¿no?”, pero no pasa mucho tiempo en evidenciarse que la propuesta hace cimbrar los cimientos en la forma de cómo se conciben el trabajo, los proyectos, la gestión; y los propios paradigmas respecto a la ingeniería y dinámicas de equipo; sin hablar de hábitos y de la cultura de la empresa.

Comienza entonces la tensión.

El sufrimiento en la capa intermedia

Enfocándome en los Gerentes de proyecto, al ser responsables por los resultados de la ejecución, sienten la presión de lograr las promesas de negocio sin contar con mucha certeza de cómo hacerlo en la nueva dinámica de trabajo. Y ven poco a poco como muchas de las funciones de las que se encargaban habitualmente se delegan a varios roles encarnados por otras personas (comúnmente): la gestión del alcance, monitorización y métricas, lineamientos de organización de equipos; etc.

Para empezar, en métodos como Scrum no existe de forma explícita el rol de Gerente de Proyectos, lo que hace pensar de que este rol -más no sus funciones-, es innecesario en entornos ágiles. No comparto, pero sí que hay consultores y coaches que así lo manifiestan. Lo mismo sucede con Arquitectos, Directores de Programa, Líderes funcionales, etc. Es claro, Scrum fue creado bajo una visión de trabajo creativo en equipo (no sólo de desarrollo de software), no estaba pensado para enfoques empresariales tradicionales.

Las destrezas y habilidades que hicieron grandes a estos gerentes ya no son requeridas de la forma como la venían desempeñando. La planificación a largo plazo y el levantamiento del detalle temprano no van más, adiós a la negociación del triángulo de acero como lo conocíamos, SRSs, documentos funcionales pesados, análisis y arquitecturas detalladas up-front quedan en el recuerdo. Técnicas, artefactos y métricas comunes (WBS, Gantts, CPI, SPI, etc.) son reemplazadas rápidamente con planes de Release, Burndown charts,  Velocidades, Story Maps, etc. Hay que re-aprender gestión de proyectos de software.

Los consultores y coaches comienzan a cuestionar su lenguaje, hábitos y estilos de liderazgo, “Ya no digas recursos, son personas” (comparto plenamente), algo tan arraigado en la cultura de gestión . Ya no se puede pedir al equipo que se queden hasta más tarde porque vamos atrasados, ahora el equipo decide, etc., etc.

La organización y el mismo Gerente comienzan a preguntarse sobre la relevancia del rol tal como se conocía, y definitivamente debe existir una transformación que tiene implicaciones a nivel funcional y por supuesto a nivel humano. Comienza entonces un estrés más profundo a nivel personal.

Empatía con el Management

¿Podría existir un milagro tan grande para nosotros, que el de mirar a través de los ojos de otros por un instante?

– Henry David Thoreau

Existe un cierto antagonismo entre una gran parte de agilistas y los roles de gestión. También me pasó. Recuerdo mis días de Scrum Developer y de Scrum Master que junto a los demás compañeros del equipo nos quejábamos de ellos y decíamos que deben desaparecer, “No Managers!”, nos auto-organizamos ya no son necesarios, no aportan valor, son dinosaurios, Holacracy y así por el estilo…todo mientras nos tomábamos una cerveza luego de la retro y andábamos en zandalias por todo el lugar. Sí, era divertido, era joven :)…pero les comento, que esto está alejado del propósito real de la Agilidad que es buscar mayor bienestar de las personas mientras entregan valor a través de su trabajo.

Yo no creo que los Gerentes sean malas personas. En verdad. No creo que digan “son recursos” porque vean a los equipos como baterías que se pueden reemplazar cuando se gasten (al menos los buenos Gerentes no lo ven así). Pienso que este lenguaje, mindset, hábitos y demás son producto de su formación y por supuesto de la organización, del sistema. Pienso que al igual que el resto, ellos quieren que el negocio mejore y que la empresa y los equipos crezcan. Se están enfrentando a una realidad que les desafía a re-aprender muchas cosas, crecer profesionalmente y mejorar personalmente…y es nuestra labor como coaches y agentes de cambio ayudarlos a encontrar su camino.

¿Qué se puede hacer? Aquí algunas sugerencias :

Ayúdelos a encontrar su lugar

Los roles y funciones se vuelven confusos en un proceso de adopción ágil, es un momento de transición. Como mencioné, Scrum no muestra de forma explícita un rol de gerencia, sin embargo hay compañías que mantienen el rol. Si existe, ayúdeles a comprender que el paradigma de gestión cambia profundamente con Agile, de Gerentes a Líderes de Servicio; las personas no se gestionan, el sistema se gestiona; ahora son habilitadores para que los equipos fluyan, preocuparse auténticamente en el bienestar de los equipos, entre otros.

Si este rol desaparece de la organización, ayúdelos a identificarse con los nuevos roles y hágale entender las destrezas y responsabilidades requeridas para ellos. Quizás le guste más el tema de ser Product Owner, o se enfoque más hacia el crecimiento del equipo y se convierta en Scrum Master; o sus equivalentes en escala (Product Manager/Chief Product Owner, Chief Scrum Master, etc.). Si usa otros frameworks, invítelos a revisar los roles y ofrezcan la guía necesaria donde con sus destrezas y mentalidad sean apropiados y se sientan a gusto.

Ayúdelos a prepararse

Haga charlas, hable sobre los valores y principios, métale Management 3.0 por los ojos, envíenles información, artículos, libros, hábleles de las certificaciones (muchos agilistas me matarán aquí por el tema de las certificaciones 🙂 ), motívelos a aprender. Ayude a comprender lo subyacente detrás de los métodos. Explíquele los artefactos y ayúdelos a dibujar tableros para sus actividades, a ellos también les gustaría embarcarse en la onda de pegar papelitos y lo demás, apóyelos.

Involúcrelos

Hágalos partícipes de las iniciativas de cambio durante la transformación ágil. Trabaje junto con ellos en alguna de ellas y luego pídales comprometerse ellos solos, o en equipo de directores, como sea. Conviértalos poco a poco en agentes de cambio y en parte del equipo de transformación. Si logra de a poco cambiar su mentalidad y comportamiento, serán faros y guías para propagar la cultura que se desea en la organización.

Evite el “ellos” vs “nosotros”

Intégrelos al trabajo del equipo, invítenlos a las ceremonias y que perciban la agilidad de la mano de los equipos….por supuesto, hable con los equipos para que tengan apertura necesaria y que sean bien recibidos. Discutan los tableros, argumenten de forma sana y genere la cercanía necesaria para hacerlos sentir “parte de”. Ya basta de “los ágiles” y los “no ágiles”.

Acompáñelos

Hágales coaching. Converse con ellos, haga sesiones One-to-One, lleven una bitácora de coaching, entregue consejos para que mejoren sus destrezas personales y habilidades blandas. Ayúdelos a mejorar como Líderes y como seres humanos.

Pensamientos finales

Como agilistas siempre estamos hablando de empatía: empatía con el usuario, UX, Design Thinking y más. Mi invitación es aplicar esta misma habilidad de “empatizar” -e incluso las mismas herramientas y técnicas que usamos en los equipos- con las personas en la mitad del sánduche (¿por qué no?: haga un Empathy Map, cree Personas). Los procesos de transformación ágil representan un cambio trascendental y muy profundo dentro de las empresas, con impacto a nivel organizacional, cultural y personal. Póngase en los zapatos del management, mire a través de sus ojos, sienta con su corazón. Esta capa es fundamental para el éxito de la transición, para obtener los beneficios esperados y para generar la cultura ágil que queremos ver en todas las organizaciones a las que visitamos.

Como dirían acá en Colombia: ¡Hágale mija! o ¡Hágale mijo! 🙂

Gracias por leer.

Johnny

Thoughts on Agile Acceptance

“It’s the Agile Manifesto we should all be upholding. It’s adapting to change over following a plan which makes us agile, not which framework we choose or even which certifications for frameworks we hold. Let’s not forget our roots! What’s most important are those 4 values and 12 principles of the Agile Manifesto. In fact, the Agile Manifesto is framework agnostic. Basically, Scrum, SAFe, LESS, or whatever isn’t the only way to be Agile. There is no one right way!”

Great post and agree!

i.am.agile

Cara Penyak, an Agile Project Leader on my team, volunteered at the Global Scrum Gathering in Orlando last week and brought me back a new friend, Lee Allison.  Lucky me!  I don’t even need to attend a conference to make new friends.  Anyhow, Lee asked me to review his latest blog post “Agile Acceptance” and I thought what better topic to re-blog than this.
A framework is defined as “a basic structure underlying a system, concept, or text.”  Seems pretty straightforward but, among the agile community, frameworks are super polarizing for whatever reason.  If frameworks represent a “basic structure” then they are surely intended to be adapted.   Who cares which scaling framework you start or end with?  
It’s the Agile Manifesto we should all be upholding.  It’s adapting to change over following a plan which makes us agile, not which framework we choose or even which certifications for…

Ver la entrada original 51 palabras más

3 razones del por qué sin Agile Testing no está siendo Agile

3_stones_on_wood

Con relativa frecuencia -más de la que me gustaría- observo como las compañías y sus equipos adoptan Scrum para el desarrollo de software excluyendo deliberadamente a las personas de pruebas dentro de los equipos. Ellos consideran aún que el “desarrollo” significa únicamente codificación, manteniendo a las personas de testing alejadas del equipo, sin participar en las ceremonias e incluso en ubicaciones distantes físicamente. Cuando les pregunto sobre las pruebas funcionales durante el sprint, normalmente me responden: “Es que hacemos TDD…las pruebas funcionales las hacen al final y nos reportan los bugs en el sistema de tracking de incidencias.”

Lo que se puede observar es que se conserva el paradigma de que las pruebas es algo que viene después, realizado por un grupo de personas que está más allá, que es responsabilidad de alguien más; y no existe nada más alejado de la Agilidad verdadera.

Ahora quiero sintetizar en tres razones la importancia de comprender y asumir la disciplina de Testing y cómo ésta se evidencia en Agile:

1. Muchas de las promesas de Agile provienen del Agile Testing y de la automatización

El desarrollo ágil habla de mejorar el Time to Market, de aumentar la calidad, de incrementar la productividad y predictibilidad, y mejorar la motivación. Pues bien amigos, les aseguro: mucho de estas promesas provienen del ejercicio consciente del Agile Testing dentro de los equipos, más un nivel decente de automatización de pruebas e integración continua; todo esto en camino hacia habilitar Continuous Delivery. Agile no es magia, sigue siendo software que debe ser diseñado, construido y probado; el cambio está en el enfoque colaborativo y de integración en lapsos cortos a través de un equipo que combina sus disciplinas; es lo que marca la diferencia.

Imaginen el escenario donde se codifican historias en un sprint y luego al final le dan a un Tester o equipo de Testing que las prueben. Probablemente se encontrarán errores que serán reportados y corregidos por los equipos durante el sprint que corre. Al final del segundo sprint la persona o equipo de Testing deberá verificar la corrección de los bugs anteriores más la revisión de las historias del nuevo sprint; y no sólo eso; sino hacer una regresión de los flujos de negocio más importantes que involucra también historias del primer sprint. Ahora imaginen este ritmo para el tercer, cuarto, quinto sprint. Es una bola de nieve, y esto es grave. Las personas de Testing estarán con trabajo acumulado que supera su capacidad, la presión hace que reduzca el ámbito de pruebas y que minimice sus casos tomando en cuenta lo que considera más urgente y no lo más importante, la calidad de los casos de prueba disminuye, los managers estarán encima de ellos porque se evidenciará retrasos al no tener historias probadas; la motivación de este equipo estará por lo suelos. ¿Y los developers, pueden ayudar? No, están ocupados haciendo más historias 😦

Okay, esto no es Ágil. Son como cascaditas más pequeñas, nada cambió a excepción a que ahora generamos más código basura en sprints. Recuerdan aquel principio que dice:

“Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.”

– Principios del Desarrollo de Software Ágil, Manifiesto Ágil

2. Las personas de pruebas no son ciudadanos de segunda clase, son profesionales talentosos

Existe una percepción generalizada en la industria de que los testers son un tipo de profesionales de segunda clase, que no son tan importantes o necesarios o geniales como los desarrolladores, tienen salarios menores, hay una proporción mínima de testers en las empresas comparados con los desarrolladores, hay muy pocas capacitaciones -incluso en la Agilidad- y normalmente están en una sala aparte donde su trabajo se reduce a encontrar bugs. Recuerdo alguna vez que estaba con un equipo de gerentes trabajando en la planificación de un proyecto y decían: “Necesitamos aproximadamente unos 50 developers.”, “Okay ¿y los testers?”, “con dos juniors ya tenemos!”. La disciplina en sí mismo está desvalorizada. Agile es contrario a todo esto, no puede seguir pasando. De hecho, cuando en las organizaciones veo este tipo de escenarios, son para mí olores de que su nivel de Agilidad está lejos de ser verdadero a pesar del uso de Scrum o cualquier framework.

Pues bien, la verdad es que sin nuestros amigos testers no podemos tener buen software ni software de valor. El testing de software es para mí una disciplina que requiere talento, preparación continua y un mindset diferente al de los desarrolladores para diseñar estrategias de mejor cobertura funcional y mejorar el diseño mismo del software. Las empresas y los equipos deben darse cuenta de lo trascendental de este rol.

3. Agile Testing es igual a colaboración

El Agile Testing es el pegamento entre las expectativas de negocio y la construcción. El tester es parte del equipo y es un puente de colaboración y comunicación entre el Product Owner, Stakeholders y developers más gente de operaciones, quienes codifican y mantienen los requerimientos para satisfacer esas necesidades.

Por ejemplo, el Tester trabaja junto con el PO y le apoya en:

  • Mejor comprensión de las necesidades
  • La preparación y revisión de historias
  • La definición de Criterios de Aceptación (a partir de los cuales se pueden generar Escenarios de Prueba)
  • Mejor entendimiento del Dominio de Negocio
  • Identificar dependencias entre Historias

El Tester trabaja junto con los Developers y les apoya en:

  • La definición estrategias de prueba para las historias
  • Apoya en la automatización de pruebas funcionales (ATDD)
  • Detecta y notifica bugs
  • Entrega feedback temprano de las historias
  • Sugiere mejoras funcionales y de usabilidad

Por su lado, el Tester trabaja en:

  • Preparación de la estrategia de pruebas del sprint
  • Preparación y mantenimiento del Ambiente de Pruebas
  • Preparación de Casos y Data de Pruebas de las historias del Sprint
  • Validación de “Done” de las Historias
  • Registro y notificación de Bugs
  • Aceptación de la Historia junto con el PO
  • Llevar las métricas de Calidad de Software

El Tester trabaja junto con otros Testers y equipo de operaciones en:

  • Diseñar y preparar la estrategia general de pruebas
  • Colaborar junto con los Stakeholders en las pruebas UAT
  • Identificar los escenarios y flujos de negocio más vitales
  • Difundir el Plan, Casos de Pruebas para Integración
  • Ayuda a conocer la salud del entregable
  • Identifica dependencias
  • Apoya en las pruebas de requerimientos No funcionales
  • Apoya en las pruebas de sistema end-to-end

Como pueden apreciar, son funcionales muy importantes.

Pensamientos finales

Nuevamente, Agile es más que adoptar y adaptar frameworks. Entiendo que existe un frenesí en la industria, pero sin una verdadera comprensión de los valores y principios detrás de las prácticas, sólo son cascarones. El Agile Tester es parte del Scrum y es el mejor amigo de los developers, se comporta como un compañero cuyo objetivo es ayudar a mejorar el software, dar feedback continuo y evitar a aparezcan errores en lugar de ser sólo un filtro para detectarlos, participa activamente en las ceremonias y es parte del éxito del equipo. En mi experiencia, es un rol vital y no puede existir agilidad sin este apoyo.

Gracias por leer y por compartir sus experiencias.

Johnny

¿Cambiar Comportamientos = Cambiar Cultura?

7029d8a64a79f01fdd34f471dfeadbc1

A medida que se avanza en los procesos de transformación hacia Agile en organizaciones de cualquier tamaño o giro de negocio, se hace cada vez más evidente que precisamente el obstáculo más fuerte al que se enfrenta el equipo de transformación y el proceso como tal, no tiene que ver tanto con el entendimiento del método o framework seleccionado, y más bien este posee aproximaciones hacia índoles humana y sistémica; el tema es cultural. Ya lo decían las encuestas: la habilidad de cambiar la cultura organizacional es la barrera más grande en la Adopción Ágil.

“A nivel de iniciativa ágil, los encuestados citaron a la cultura organizacional o una resistencia general al cambio como las barreras más grandes hacia una adopción ágil, seguido de no contar con el conjunto de habilidades correctas.”

– 9th Annual State of Agile Survey, VersionOne

De aquí que el verdadero desafío consiste en trabajar en influenciar -más que “cambiar”- la cultura organizacional vigente del grupo (equipo, área u organización). Por lo tanto, los miembros del equipo de transformación son Agentes de Cambio inherentemente, y es necesario enfocar iniciativas para lograr figurar una nueva cultura donde la Agilidad florezca en múltiples niveles; una cultura de transparencia, confianza, colaboración y preocupación auténtica por las personas. Y esto por cierto, no es nada fácil.

Y entonces te pones a leer, a comprender y aprender cómo hacerlo. Y en este aprendizaje me he encontrado con un pensamiento compartido por algunos excelentes coaches y amigos que dice: Comportamientos = Cultura. Cambiar comportamientos = cambiar Cultura. Suena coherente en verdad, pero tras mi experiencia y profundizando sobre el asunto, comienzan a aparecer mis conflictos. No creo que esto sea tan simple ni que funcione de esta forma, y pretendo explicarlo a continuación.

El comportamiento es sólo el aspecto visible de la Cultura

En varios procesos de adopción en compañías donde he tenido la oportunidad de participar, comienzan aplicando las reglas del método o framework seleccionado para traer agilidad. Algunos me dicen: “Sí, somos ágiles…aplicamos Scrum y todas las ceremonias y roles”. Entonces pienso, “Okay, veamos más de cerca.”  Al principio cada persona del equipo comienza a ejecutar su rol muy proactivamente, se levantan, responden sus preguntas, una buena ejecución y cumplimiento del método; pero se siguen percibiendo rastros del esquema de pensamiento y actitudes anteriores; ciertas disfunciones y algunas muy sutiles de detectar: el reporte al jefe (que ahora es Scrum Master o Product Owner), personas algo tímidas en comentar los problemas, justificaciones por el no cumplimiento del trabajo, mediciones de desempeño ahora de la forma ágil (Velocity u horas) pero con el tinte tradicional, ejecución mecánica de las ceremonias o prácticas sin la verdadera comprensión del beneficio, entre otras “reglas no escritas”.

Uno de los gráficos que uso con frecuencia para explicar qué entendemos como cultura es la siguiente pirámide basada en el enfoque de William Ouichi, -el mayor precursor de la Teoría Z-:

Agile como una Cultura

Es como un iceberg, lo único que vemos -los comportamientos- es sólo la punta; lo de abajo es más interesante. A pesar de la aparente buena ejecución del framework, los cimientos culturales anteriores se mantienen o se modificaron muy poco. Claro, quizás sólo sea el principio, pero no deja de ser una “agilidad cosmética”, poco profunda. Sin embargo, si se aleja y observa el conjunto, podría apreciar un comportamiento homogéneo en función de lo establecido.

Pensando detenidamente, considere que el comportamiento del grupo -algunas de las disfunciones descritas arriba- son el reflejo de la verdadera cultura imperante; es como el aire alrededor; difícil de señalar pero saben que está allí. Significa que la cultura está lejos de cambiar con sólo la ejecución de prácticas o reglas.

El comportamiento es un resultado

Son nuestras creencias, nuestra formación, nuestros modelos mentales, nuestras experiencias, la sociedad…y en sí, nuestro mindset los que dibujan nuestro comportamiento, y no al revés. Pero no es lo único, dentro del contexto organizacional la forma en cómo se llevan las cosas dentro de la organización, la naturaleza de las tareas, los flujos de información, la estructura y procesos influencian la forma en la que actuamos.

High Altitude Leadership

Cambiar Cultura es trabajar sobre el mindset: Incepción u Origen

Estaba en una de las primeras reuniones con el staff ejecutivo de una compañía para inducción sobre Agile y el framework en específico que seleccionamos. Entre los asistentes, unos de los VPs, el más fuerte de carácter y quien veía con mayor escepticismo el tema de Agile. Todos habían leído al respecto, pero el taller era más que necesario para profundizar.

Queríamos explicar el concepto del Costo de la Demora (Cost of Delay) y realizamos uno de aquellos ejercicios lúdicos con todos los presentes en la mesa, ya saben…comenzamos simulando el flujo tradicional y luego lo enfocamos como flujo de valor y tomamos los tiempos, las variaciones y todo lo demás…y este Ejecutivo tuvo un momento ¡A Ha!, se detuvo a explicarlo porque creo que sentía las ganas de exteriorizarlo y dijo algo como: “es increíble la cantidad de desperdicio que estamos generando”. Al siguiente día, reunió a su equipo de Managers y propuso cambios interesantes. Él comprendió que la forma con la que estaba acostumbrado a trabajar estaba lejos de ser eficiente y que su presión -en el buen sentido de sacar las cosas- estaba generando frustración en los equipos, y lo más importante; el impacto que esto tiene en la economía de la organización. Él cambió su comportamiento y argumentos.

“No es lo mismo conocer algo que comprender algo.”

Okay, ¿recuerdan a Leo Dicaprio en la película Inception / Origen? Acá pasó algo similar, la comprensión de la idea, de los principios detrás de la práctica generaron un nuevo comportamiento. No hubiera ocurrido lo mismo si sólo le decíamos al gerente que establezca WIP contraints en su tablero Kanban o que reduzca el tamaño de los lotes (por ejemplo). El cambio se generó de adentro y se externalizó en un nuevo comportamiento. Lo mismo a nivel de proyecto, hacemos una Inception como una actividad de entendimiento compartido, de identificar y comprender la problemática a resolver, de estar todos alineados, de que salgamos con la misma imagen en la mente de todos.

¿Cómo ser como Leo Dicarpio? Utilice herramientas: SAGAs, StoryTelling, experiencias lúdicas, practique con el ejemplo, module su lenguaje, haga inceptions.

Cambiar Cultura es trabajar sobre el sistema: el qué y el cómo

Una parte del cambio se genera a nivel individual, pero es necesario reconocer que mucho de la cultura en una organización se dibuja a partir del sistema de gestión existente. A grandes rasgos el sistema de gestión está formado por el cómo se hacen las cosas y qué cosas hay que realizar. Los procedimientos, las métricas, procesos de evaluaciones y recompensas, planes, organigramas, estructuras y otros, dibujan la cultura organizacional. No es de sorprenderse que cuando una persona llega a una compañía, poco a poco la cultura de la organización dibuja su comportamiento, la cultura se contagia.

organizational-culture-is-like-an-iceberg-e1422608195987

Para tomar un ejemplo, imagine a las personas de mesas de servicios o atención de tickets de una empresa de servicios a internet; si el esquema de medición está basado en cuántos ticktes pueden cerrar, la persona se enfocará en cerrar la mayor cantidad de tickets como medida de buen desempeño de su trabajo, entre más tickets cerrados y con el menor tiempo de vida es mejor; lo que hace perder el foco de que el verdadero servicio es entregar soluciones a los clientes. Me ha pasado centenares de veces con los proveedores de internet en Ecuador, te piden que llames y generes otro ticket para quejarte; y hablan muy rápido porque quieren despacharte rápido para tomar otro ticket. Observe, sólo la forma en la que se mide el “desempeño” de una persona, generará un comportamiento determinado en aquella persona.

“Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. Our idea of the culture of a place or organization is a result of what we experience there. In this way, a company’s culture is a result of its management system.”

– David Mann, Creating a Lean Culture

Si realmente se desea crear una nueva cultura organizacional, es necesario cambiar el sistema de gestión. Por lo tanto el enfoque debe ser sistémico, evitar la optimización de una parte y pensar que lo más importantes es la interacción de las partes y cómo fluye la información a través del mismo.

Cambiar Cultura es duro, ésta se defiende

La cultura organizacional es un memeplex. Una linda y acertada analogía que plantea el gran FlowSensei (Bob Marshall). ¿Qué significa? Cada elemento de la cultura organizacional anteriormente mencionado es un meme (y no me estoy refiriendo a las imágenes con textos alusivos del Facebook). Un meme es una idea que se refuerza a sí misma. De los elementos de la cultura organizacional, la idea del correcto Liderazgo, de los roles y estructura existentes, políticas y demás…están allí porque se consideran respuestas correctas a varios problemas. Por ejemplo, he escuchado cosas como: “colocamos managers porque sino los developers no hacen su trabajo”, “generamos actas porque sabemos que no van a cumplir” y cosas similares. Cada argumento justifica su razón de existencia y se refuerza así mismo, generando nuevos paradigmas.

Organizational Culture is a Memeplex

Un memeplex es un sistema de memes que actúan en coordinación (cultura), y se comporta como un sistema inmune hacia elementos foráneos que pretenden cambiar la estabilidad del sistema. El sistema repele los cambios como una forma natural de defensa.

“La Cultura es el sistema inmune de la organización.” – Michael Watkins

Nuevamente, el enfoque es sistémico. Si el equipo de Agentes de cambio se enfoca en sólo un aspecto o sólo en desarrollo de software, la misma cultura se encargará de desayunarse sus iniciativas de cambio haciendo que todo el proceso se deteriore, minando la confianza de la organización y frustrando al equipo. Es vital trabajar con las capas de liderazgo.

Si la Cultura cambia se reflejará en nuevos comportamientos: de mindset a comportamientos, no al revés

Como los comportamientos son un resultado, a medida que el equipo de cambio trabaje sobre el mindset de las personas y sobre el sistema de gestión de la organización en múltiples niveles, los comportamientos cambiarán como consecuencia. Probablemente, cuando vea a los equipos podrá apreciar adherencia al método y cumplimiento de prácticas, pero si se acerca más apreciará que la dinámica del equipo, su lenguaje y comportamientos actúan en coherencia; incluso los equipos pueden cuestionar una práctica en particular y modificarla, porque comprenden los principios detrás, y esto puede que rompa la homogeneidad, pero está perfectamente bien; ya que todos están enfocados en la entrega de valor. Algunos harán StandUps diarias, y otros StandUps emergentes, algunos usarán, Scrum y otros Kanban; no hay problema siempre y cuando todos estén alineados al propósito del proyecto y la organización. El entendimiento e interiorización de valores y principios dibujan las prácticas y el comportamiento; que consecuentemente dibuja una cultura acorde.

Gracias por leer.

Johnny

Referencias

Evitando la seducción de la herramienta

seduction-2

Durante mi charla en Ágiles 2015 presenté una lámina para ilustrar un par de conceptos interesantes tomados del libro High Altitude Leadership de Chris Warner and Don Schmincke relacionados al cambio organizacional y a los desafíos de los Líderes de Cambio. De entre ocho peligros a los que se enfrentan los líderes en busca de sobrevivir a la escalada de la montaña, quiero enfocarme en este post en el peligro #3: la Seducción de la Herramienta.

La imagen a continuación -que es mi representación del entendimiento de estos conceptos del libro- muestra de forma sencilla los aspectos que afectan al comportamiento organizacional y su influencia en la cultura, básicamente es otra forma de representar la dinámica de la cultura organizacional.

High Altitude Leadership

Conocemos que nuestro sistema de creencias influencia nuestro comportamiento: nuestra conciencia de identidad, el cúmulo de valores y principios inculcados en nuestra infancia, lo aprendido de nuestros padres y la sociedad. Pero no es lo único que afecta el comportamiento. Dentro del contexto organizacional, el “Qué” –representado como la estructura o jerarquía actual, el enfoque de planificación, establecimiento de objetivos, la definición métricas y su objeto de medición– más el “Cómo” que son los procesos, políticas y mecanismos actuales de a través la organización ejecuta– influencian fuertemente y dibujan un comportamiento. Ambos definen la forma de cómo viaja la información y cómo se interpreta.

Lo que se espera es que a través de este comportamiento se generen resultados, y que estos sean cada vez mejores para el bienestar de la organización (y su supervivencia). Entre el comportamiento y los resultados normalmente se usan herramientas que sirven de “habilitantes” (enablers) que brindan soporte durante la ejecución y al posterior cumplimiento de objetivos.

¿Qué es la Seducción de la herramienta?

“Las herramientas ofrecen esperanza, y hacen sentir a las personas que tienen la respuesta correcta. Pero hay problemas cuando los empleados usan las herramientas como muletillas para tener respuestas seguras. Ambos, escaladores muertos y compañías en banca rota fueron encontraron agarrando grandes herramientas.”

– Chris Warner and Don Schmincke, High Altitude Leadership

Es ser seducido por la ilusión de que la herramienta produce resultados en lugar que las personas. Es pensar que la herramienta en sí misma es la solución; es cuando la herramienta nos deslumbra, nos impresiona, nos “enamoramos” de ella. El problema radica en que fácilmente se puede perder la perspectiva y dejar de pensar en el propósito, la problemática y el contexto general. En muchos situaciones, sobre todo en grandes organizaciones, se tiende a pensar que entre más cara o sofisticada o completa parezca ser la herramienta ésta es mejor.

Esto normalmente sucede cuando las últimas herramientas para el cambio organizacional, desarrollo de liderazgo, mejora de procesos, métodos de gestión -y por supuesto, frameworks para la adopción de Agile a nivel empresarial- distraen nuestra atención de los aspectos vitales. En lo relacionado a Enterprise Agile, no se trata de la adopción de un framework específico, sino de lograr la agilidad del Negocio (y un poco más allá).

 

Algunas evidencias de que esto está sucediendo en la organización incluyen:

  • Equipos trabajando para la herramienta en lugar de la herramienta trabajando para los equipos;
  • Contar con mucha información nueva e interesante pero irrelevante;
  • Síndrome del “Consultor de la Semana” (uno más experto que otro en la herramienta);
  • Nuevas ideas pero sin la capacidad de producir resultados;
  • Muchas reuniones inútiles;
  • El cumplimiento de tareas se confunden con resultados.

“En montañismo, la seducción de las herramientas ponen en peligro a los escaladores cada vez que se visten con la mejor ropa y últimos equipos, pero que aplican comportamiento y técnicas equivocadas para el desafío. En su exceso de confianza (o novatada), terminan perdidos durante días en una pendiente devastada por una tormenta, mientras que los escaladores experimentados están en el campamento base tomando cerveza y viendo el clima. Del mismo modo, el peligro de un ‘desfile de expertos’ empaquetando y vendiendo las últimas herramientas pueden distraer a los equipos.”

– Chris Warner and Don Schmincke, High Altitude Leadership

La herramienta adecuada para el problema adecuado

“Un tonto con una herramienta sigue siendo un tonto.”

-Grady Booch

Por supuesto, las herramientas son importantes; pero deben poder usarse inteligentemente y mucho de esto radica en identificar el problema correcto. Imagine que le pido pintar un paisaje en una hoja de tamaño A4; se podría usar lápices o crayones o acuarela y pincel (mi hija es una profesional en esto). Imagine ahora que le pido pintar un paisaje en una pared de 25mX8m, si bien es cierto que podría usar pinceles o todo lo anterior, pero puede ser más efectivo usar una brocha o un rodillo o un soplete, o los tres; y esto no significaría que un rodillo es mejor que un pincel; cada una es útil en el contexto apropiado.

Lo mismo ocurre con los frameworks para escalamiento de Agile (LeSS, DAD, SAFe, Nexus, Scrum, etc.). Cada uno ofrece mecanismos interesantes que son más útiles para ciertos contextos, y muy probablemente pueda usar elementos de más de uno. El punto clave del asunto es identificar cuál es más adecuada para el contexto actual y cómo puede aportar efectivamente al cumplimiento del propósito: Agilidad Empresarial. Scaling Agile no es igual a Enterprise Agile. Enterprise Agile responde a buscar Agilidad en el Negocio, Agilidad Organizacional y Cultura Ágil viva. Por lo que la adopción de frameworks son simplemente formas de apalancar a los equipos en la consecución de este propósito, de lograr pintar la pared.

¿Cómo evitar la Seducción de la Herramienta?

“De la misma forma que la música proviene del músico y no del instrumento; Agilidad proviene de las personas y no de los frameworks.”

-Johnny Ordóñez

Algo que me gusta del libro es que provee “tips de supervivencia” para evitar estos peligros. Para este caso: enfocarse en el comportamiento y en la adaptación; esto es centrarse en la generación de resultados desde una perspectiva de comportamiento. Enfocar el propósito, identificar problemáticas y contextos, la toma de decisiones apropiadas en base a hechos, generación de acciones coherentes.

No importa cuando se invierta en libros, entrenamientos, certificaciones, reuniones, etc.; todo es una pérdida si los equipos no adaptan su mindset, comportamientos y acciones consecuentemente. Si bien, el entrenamiento en las herramientas conlleva a su mejor uso, la clave es no perder de vista que el propósito es escalar la montaña, no sólo saber a hacer nudos. Así como los Líderes de Gran Altitud, los Agile Coaches deben tenerlo presente; sea fuerte y no se deje seducir :).

Gracias por leer.

Johnny

Referencias:

Escalando el Índice de Felicidad

Medir la felicidad es algo complicado. La felicidad es algo abstracto e íntimamente ligado al aspecto personal, es difícil establecer un valor determinístico que permita concluir “qué tan feliz” se siente alguien. La felicidad es una elección consciente más que una respuesta automática. Sin embargo, dentro de las técnicas aplicadas por los equipos ágiles, existen interesantes herramientas para obtener información relacionada al estado anímico de los equipos y su satisfacción en el contexto laboral. En este sentido, el Índice de Felicidad se concibe como una medida organizacional de la percepción de satisfacción y motivación de los equipos ágiles. 

¿Por qué medir la Felicidad?

“El Compromiso de los empleados es un imperativo de negocio; este es el eje fundamental entre la estrategia y los resultados de negocio.”

– Trends in Global Employee Engagement, 2013

1. Agile es acerca de personas

La Agilidad proviene de las personas, no de los frameworks (Scrum, SAFe o cualquiera). La Agilidad vive en los equipos y florece gracias a un entorno de confianza, transparencia y colaboración auténtica. El impacto de la motivación y la satisfacción de los empleados se ha venido estudiando con atención desde hace un tiempo. A continuación algunas cifras al respecto recopiladas por compañías como Gallup y otras:

Cifras sobre la Motivación en el trabajo

Cifras sobre el Impacto de la Felicidad en el Negocio.

La Felicidad es un asunto serio. Preocuparse por la motivación y el bienestar de las personas es un reflejo de la mentalidad ágil, de un nuevo estilo de gestión, de una práctica saludable y recomendable para Líderes de Servicio, Coaches, Managers, área de Talento Humano y otros.

2. Permite medir promesas de Adopción

En un proceso de transformación ágil en el que participé utilizando SAFe como framework referencial, uno de los desafíos al que nos enfrentamos fue el de cómo medir la “Promesa SAFe” expresada en el siguiente gráfico:

Promesa SAFe

Resultados de Negocio de SAFe – SAFe Foundations

SAFe ha podido obtener estos datos de sus varios casos de estudio documentados. Con relación al engagement de los empleados, sus cifras están alrededor del 10% de incremento. Las preguntas fueron: ¿y cómo lo midieron? ¿y cómo lo medimos nosotros?. El Happiness Index resultó una herramienta útil para este contexto. (Para los otros aspectos, espero publicar pronto algo que puede servir; tema de otro post.)

3. Información que permite enfocar acciones de mejora sobre los equipos

Información valiosa que le permite a Scrum Masters, Coaches y Managers; enfocar acciones sobre aquellos equipos que necesitan mayor atención y protección. Sirve para indagar sobre las causas de su estado anímico, conversar, identificar problemas y actuar en busca de mejorar el bienestar de los equipos.

Se me ocurren otras razones, pero quizás estas sean las más importantes.

Mecanismos para medir la Felicidad

He leído de varios; desde el uso de aplicaciones en nube, encuestas de Google Docs y hasta el conteo de pelotas de tenis; todas muy interesantes.

Mecanismos para medir la Felicidad

Algunos mecanismos para medir la Felicidad

Más que las herramientas, siempre me ha gustado que este tipo de actividades sean muy lúdicas  y divertidas; entonces me gustan más herramientas empleadas en Retrospectivas. Dos de las que más me gustaron fueron el Happiness Profit de mi gran amigo Hiroshi Hiromoto y la variación del Happiness Radar de mi otro amigo Paulo Caroli de su libro Fun Retrospectives.

Happines Profit y Happiness Radar

Happines Profit y Happiness Radar – Técnicas para Retrospectivas

Debido a la información relacionada a varios aspectos, el Happiness Radar fue la elección que tomamos junto al equipo de Scrum Masters. Lo personalizamos y aplicamos en cada retrospectiva para los equipos.

Happiness Radar - Evac 2

El Happiness Radar de la Retrospectiva de un Equipo

Equipos

Equipos en Retrospectiva – Happiness Radar

Escalando el Índice de la Felicidad

1. Recopilación de la Información

Nos pusimos a trabajar y ensayamos nuestro primer sprint con la nueva técnica. Luego de la recopilación en la herramienta física, cada Scrum Master la pasaba a un excel que diseñamos para este propósito, un archivo por equipo.

Radar de Felicidad por Equipo

Archivo de Registro del Radar de la Felicidad por Equipo

Cada archivo era subido a un repositorio de donde una macro en Excel leía la información y la consolidaba en un archivo que unificaba la información de todos los equipos. La periodicidad de medición fue de cada sprint (cada dos semanas). Teníamos que establecer un nivel de automatización para que el proceso sea repetible y que no se constituya una tarea que demande demasiado tiempo, volví a programar en macros después de muchos años 🙂

2. La fórmula

El Happiness Radar es un mecanismo de conteo, es decir simplemente cuenta la personas con un estado anímico sobre un aspecto particular. La idea fue obtener un indicador que represente de la mejor forma la sensación de todo el equipo. Entonces, me basé en la fórmula del Net Promoter Score, usada comúnmente para medir la satisfacción de Clientes sobre un servicio o producto.

Fórmula del índice de la Felicidad

Fórmula del Índice de la Felicidad

La escala es un rango de entre -1 a 1, cuyos valores representan: +1: Equipo Feliz, 0: Equipo Neutral, -1: Equipo Triste. Luego se podría profundizar los aspectos y su valoración.

3. Visualización y Publicación

Quería que estaba herramienta fuera vista y discutida a nivel Ejecutivo y compartida por toda la organización, entonces figuraba en mi mente la mejor forma de presentar esta información, que fuera dinámica, muy visual y al estilo de dashboard o Balance Scored Card y en lo posible vía web. Excel no me iba a ayudar mucho por lo que recordé esta fantástica herramienta (con versiones gratuitas) para la elaboración de vistas y análisis de datos: Tableau nos salvó; así que me puse a “monear” (término ecuatoriano que significa explorar algo sin tener la certeza de lo que realmente estás haciendo, hacer monadas).

La herramienta debería contestar varias preguntas:

  • ¿Cuál es el nivel de motivación general de la compañía?
  • ¿Cuál es el equipo más “feliz” o motivado?
  • ¿Cuál es el equipo más triste?
  • ¿Con qué aspecto están más descontentos?
  • ¿Cuál es la tendencia de la felicidad en el tiempo?
  • ¿Qué equipo o equipos necesitan mayor atención?

De esta forma, el diseño de vistas debería responder de forma rápida estas cuestiones. Luego de mucho café y varios tutoriales en línea, logré crear algo como esto:

Puede explorarlo en línea en este link.

4. El proceso resumido

A modo de referencia, el resumen del proceso en la siguiente imagen:

Proceso

Proceso de Consolidación y Publicación del Índice de la Felicidad

Analizando la Información

1. ¿Mayor Felicidad = Mayor productividad?

Al principio la iniciativa de medir la felicidad fue vista como algo muy romántico, muy abstracto. Obviamente no era muy común escuchar de esto y no se había intentando algo similar antes. Si bien es cierto, se tenía en mente como algo que permitía medir la “Promesa SAFe”, el staff Ejecutivo no veía mucho valor…hasta que resaltamos lo que decían los estudios: “Un empleado feliz es más 31% productivo”. Recuerdan las cifras de arriba. Veía como empezaba a brillar una luz en los ojos de algunas personas.

Nuestra hipótesis fue: “A mayor felicidad mayor productividad”. Aunque productividad es un concepto que se presta a discusión, sobre todo hablando de Agilidad (quizás un término del siglo XX como bien lo dijera Ángel Medinilla) el reto ahora es expresar desempeño en términos de agilidad. Como eran equipos Scrum, la respuesta fue muy obvia: “Velocidad” (otro concepto discutible, pero se escapa a este post). Al inicio no me gustaba usar la Velocidad, pensaba en que se prestaría a comparación entre equipos, y más significativamente uno de los motivos fue que no hay homologación entre los puntos o velocidades de los equipos, es decir, cada equipo tiene su propia definición de qué es un punto y sus velocidades no son comparables. Una de las formas de lograr una comparación más homogénea fue utilizar la Velocidad promedio de todos los equipos.

De esta forma, contrastamos Felicidad vs. Velocidad. Recuerdo que moría de ansiedad por ver los datos, en verdad esperaba que se cumpliera la hipótesis. Pero, oh sorpresa!…no fue así. Encontramos que podíamos tener equipos tristes con mayor desempeño, y equipos felices con una entrega inferior. ¿Por qué? Me rompía la cabeza tratando de encontrar explicación. Investigué y me encontré con el trabajo del Dr. Charles Kerns, PhD por el 2008 y que despejó mi mente.

Lo más interesante fue la siguiente matriz:

Felicidad vs Desempeño

Matriz de Felicidad vs Desempeño – Dr. Charles Kerns, PhD

Cada cuadrante corresponde a un grupo que poseen sus propias características y lo más interesante, el autor propone acciones de mejora específicas para ayudar a los equipos en cualquiera de las categorías. Esto fue revelador para mí. Lo discutimos con los Scrum Masters y podíamos enfocar acciones de mejora más claras con los equipos. Compartimos los hallazgos con los managers y los invitamos a generar acciones en conjunto. Estábamos muy felices! La herramienta sirvió en ayudar al crecimiento y bienestar de los equipos. Esto destapó la creatividad de los Scrum Masters, surgieron nuevas técnicas de retrospectivas, más actividades lúdicas, campañas y actividades interesantes para lograr mayor motivación. Gracias equipo! (a Katty, Andrés, José Manuel, Polo, Luis, Ana María, Stephanie y Ximena).

Pensamientos finales

Aprendí mucho de implementar esta herramienta. Espero que este post le brinde la guía y motivación para emprender una iniciativa similar en su compañía, y que por favor me comente cómo le fue. Obviamente, fórmulas, visualización y demás pueden mejorarse; pero más allá de eso, mi mensaje final es que considere el aspecto de la Felicidad como algo importante, y realzar su enfoque hacia cuidar y cultivar le bienestar en sus equipos y su organización.

“Las empresas a menudo se olvidan de la cultura, y en última instancia, sufren por ello porque no se puede entregar un buen servicio con empleados infelices.”

– Tony Hsieh, CEO de Zappos

Gracias por leer.

Referencias

La evolución de SAFe (en imágenes)

Uno de los aspectos de SAFe que más me gustan es su naturaleza evolutiva. A través del feedback de empresas, consultores, comunidades y practicantes en general, el framework ha ido creciendo, adaptándose, mejorando; hasta consolidarse en la versión actual SAFe 4.0 for Lean Software and Systems Engineering.

Esto es bastante bueno, ya que Agile se trata de eso, adaptación continua en base al aprendizaje. Si bien es cierto, SAFe no es la bala de plata para todos los escenarios ni todas las compañías, a mi forma de ver SAFe brinda un robusto conjunto de valores, principios, patrones y prácticas para llevar agilidad a nivel empresarial, más allá del área de TI y del desarrollo de software. Es un gran inicio hacia buscar la Agilidad empresarial, y tal como lo mencionara Henrik Kniberg; SAFe es un framework en modo Shu.

He podido hacer un tracking de la vida de SAFe en el tiempo y encontré versiones de varios Big Pictures desde el 2008 y de la época en la que SAFe todavía no se llamaba SAFe; desde los antiguos posts de Dean Leafingwell hasta la versión actual:

El pase de diapositivas requiere JavaScript.

¿Qué es lo nuevo en SAFe 4.0?

El nuevo Big Picture de SAFe trae -además de un diseño más sobrio a través de un matizado de grises- novedades interesantes para el escalamiento de Agile. A continuación comento las cosas que más me llamaron la atención:

El nivel de Value Stream

level_choice_3-4-768x948

Diferencias entre SAFe 4.0 en 3 niveles y SAFe 4.0 en 4 niveles

Posiblemente lo que más resalta a la vista es la posibilidad de expandir a SAFe de 3 a 4 niveles. Esto tiene una connotación importante, SAFe 4.0 en 3 niveles está diseñado para Value Streams donde el número de personas puede llegar hasta cien; SAFe 4.0 en 4 niveles puede albergar a Value Streams por encima de cien personas y habilita la coordinación entre varios Value Streams de diferente naturaleza, donde no todos están destinados necesariamente a desarrollar software; sino también hardware, firmware, trabajo con proveedores, entre otros.

fig-3

El Nivel de Value Stream – SAFe 4.0

Este nivel es muy interesante, incluye un enfoque hacia pensar en Soluciones (Solution Intent y Solution Context), nuevo roles, un framework económico para la gobernabilidad, un trío interesante (Value Stream Engineer, Solution Architect y Solution Management), Arquitectura Ágil a nivel de Value Stream, entre otros. Este nivel fue heredado y adaptado desde SAFe for LSE.

Realce de los Fundamentos, Valores y Principios

Esta característica me encanta. En la base de la Big Picture y sobre el costado izquierdo, se hace énfasis en los Fundamentos, mindset y principios, y adicionalmente en el esquema de implementación de SAFe propuesto por los autores. El verdadero camino hacia la transformación ágil empresarial viene de la comprensión e interiorización de los valores y principios más que de la ejecución de las prácticas. SAFe es coherente con los principios ágiles y Lean; los principios del Flujo de Desarrollo de Productos de Don Reinertsen (Second Generation Lean Product Development) y patrones exitosos de transformación ágil como Comunidades de Prácticas y Líderes de Cambio (o coalición de Cambio).

figure-1-foundations-layer

Secciones de SAFe 4.0 enfocado a Valores, principios y prácticas

Por lo tanto, hacer un realce sobre estos elementos invita al lector a profundizar sobre las bases de SAFe más allá de lo detallado en el Big Picture; teniendo en cuenta que su comprensión permitirá adaptar el framework a su contexto y obtener los beneficios esperados.

Kanban en el nivel de Equipos

Heredado también de SAFe for LSE. SAFe brinda flexibilidad a los equipos ágiles de seleccionar el método que mejor se adapte a su contexto y a la naturaleza de su trabajo (entrega iterativa o flujo continuo de valor), y esto es correcto, pues no todo tiene que ser Scrum necesariamente. Sin embargo, los equipos Kanban (sobre todo aquellos enfocados en el desarrollo de productos) pueden tener la necesidad de integrarse a la cadencia a nivel de programa; significa que hay consideraciones a tener en cuenta para logrartrabajar en armonía con los equipos que no son Kanban.

fig-5

Nivel de Equipos en SAFe 4.0

Hay varios artículos de los SAFe practitioners acerca de la implementación de Kanban dentro de SAFe que vale la pena revisar. Personalmente, he visto muy interesantes los webinars de Allan Shalloway donde habla sobre SAFe Kanban y LeanBan.

Nuevos tipos de ítems en los backlogs

SAFe propone un nuevo modelo para la gestión de requerimientos, incorporando en los backlogs de los distintos niveles nuevos tipos de ítems. En el nivel de portafolio existe el Enabler Epic, que de la versión 3.0 se lo conocía como Architectural Epic. A nivel de Value Stream existen el Capability y Enabler. A nivel de Programa, Enabler (antes Technical Feature). A continuación un resumen del nuevo modelo:

figure-1-safe-requirements-model

Modelo de Requerimientos de SAFe 4.0

CapEx y OpEx

Esto sí que es interesante. SAFe trae a la mesa la discusión sobre la Capitalización de la inversión que realiza la organización en las iniciativas que buscan lograr los objetivos estratégicos. De esta forma, en la asignación del presupuesto a los Value Streams, SAFe invita al Program-Portfolio Management Team, Epics Owners y Value Stream Managers a pensar en la distribución de los gastos operativos y del propósito de inversión en varios rubros: I+D, software para Venta, software de uso interno, etc. Algo que me ha parecido muy interesante y que deseo ahondar es la discusión sobre la Capitalización de Puntos de Historia de Usuario.

A continuación coloco algunos links donde encontrarán más información junto con mi invitación a revisar más sobre SAFe.

Manténganse ágiles mis amigos. Gracias por leer.

Johnny

Referencias

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/

El Levantamiento de los Movimientos “#No”

NoMovements

No sé si soy yo, pero siento que en Latinoamérica existe un creciente interés acerca de algo que yo denomino, los “movimientos #No”: #NoEstimates, #NoBacklogs, #NoManagers; que ya tienen un rato dentro de la jerga agilista (yo me encontré con ellos hace unos años). En realidad pienso que es esto es bueno porque demuestra mayor exploración y, en términos generales, mejor entendimiento del pensamiento Lean; y quizás de una transición de enfoques de desarrollo iterativos incrementales (como Scrum) hacia otros donde se habla flujo de entrega de valor (como el método Kanban). Buenísimo!

Pero -desde mi punto de vista- hay que tener cuidado en no caer en enfoques puristas que pueden alejarnos de los beneficios que estos movimientos pueden brindarnos. Mi opinión a continuación:

#NoEstimates

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones son inútiles, pero el proceso de estimación es valorable. El proceso de estimación es un proceso de conocimiento compartido, muy valioso para los equipos; no por el valor de estimación obtenido, sino por la discusión alrededor. Si las estimaciones y la dinámica aporta valor para su organización y a sus Clientes, úselos; recuerde también que tiene áreas Comerciales, maneja contratos y departamentos legales; estas cosas siguen existiendo en el mundo real. Si las estimaciones no le aportan valor, deséchelas; pero independientemente, revise su contexto y manténgase enfocado en la entrega de valor: hacia el Cliente y hacia la organización.

#NoBacklogs

“No hay nada derrochador sobre el concepto del backlog. Un backlog en sí mismo no es un desperdicio. Lo que importa es cómo las personas lo usan. Los trabajadores creativos necesitan herramientas para almacenar sus ideas y recordar sus opciones. Sólo de trabajadores de manufactura se debería esperar mantener su inventario bajo y sus máquinas limpias.” – Jurgen Appelo, Backlogs Are Not Waste

No a los backlogs estáticos, esos sí son desperdicio. No a backlogs de cientos de requerimientos que se levantan “up-front” y que cuyo valor se pudre en el tiempo. Si su backlog es un inventario entonces es un despercicio. Pero si su backlog está continuamente cambiando gracias al feedback de sus Clientes o del mercado, adaptándose a las necesidades, mutando continuamente para maximizar la entrega de valor, generando discusión y experimentos; esto es aprendizaje, respuesta al cambio. Sí a estos backlogs. Crear software no es igual al trabajo de manufactura.

#NoManagers

“Cuando la cultura de una organización es mala, no sólo es culpa de los managers. El Management de una organización es responsabilidad de todos. Un mejor management significa “enganchar” a la gente, mejorar el sistema entero e incrementar el valor hacia nuestros Clientes.” – Jurgen Appelo, Management 3.0 Workout

Managers no es igual a Management. El management en una organización -bueno o malo- no es sólo responsabilidad de los managers, es responsabilidad de todos. Es un sistema complejo donde se conjugan principios, comportamientos, reglas “no escritas”, sistemas de recompensas, cultura, diseño organizacional y más. Ver a los managers como la causa de todo mal es sólo ver los árboles, no el bosque; no es sistémico. Sí a la descentralización de decisiones y a la autonomía en los equipos, pero esto no es igual a no tener managers.

Un nuevo movimiento #No

Por favor no interprete que trato de decir que estos movimientos son malos. Lo contrario, mi invitación es a explorarlos, comprenderlos y analizar su aplicabilidad en su contexto; si le aporta valor y le funciona, adelante! Al mismo tiempo, le invito también a no establecerse en una postura purista al respecto; lo que le funcionó a Usted para su contexto, puede que no aplique en otro.

Yo me atrevo a proponer un nuevo movimiento: #NoDogmas. Podemos sentarnos a discutir por horas sobre cuáles enfoques son conceptualmente mejores y cuáles no. En realidad no importa, todos pueden estar equivocados y algunos pueden servir para un contexto determinado; sólo se sabrá cuando se aplique; pero independientemente de todo, siento que encerrarse en enfoques puristas no es recomendable para las organizaciones y equipos en los que tratamos de llevar agilidad. Agilidad sobre debates metodológicos.

Como siempre, gracias por leer.

Johnny

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/