Como hacer amigos e influir las personas de tu equipo y empresa

Este año lo terminaré y empezaré en Nueva Zelanda, y una cosa que me ha sorprendido es lo agradable que son las personas por estas latitudes, así como sus paisajes increíbles. El año anterior fue Chile, donde gané algunos kilos debido al sensacional arte culinario y diversidad de opciones, así como también me hice de varios amigos.
Diferentes países, diferentes empresas, distintas culturas, pero los problemas parecen siempre conocidos y hasta similares.

Hace algunas semanas atrás tuve la ocasión de ayudar a varios equipos que tenían como objetivo crear un proceso o flujo común y compartido. Lo necesitaban para poner en el mercado un producto cada intervalos regulares. Esto requería a varias áreas de la empresa el estar coordinadas (marketing, software, plan comercial, etc.).

Un inconveniente cuando ello ocurre es que, en general, cada grupo tiene aproximaciones diferentes sobre como abordar un problema, formas de interactuar, distintas capacidades y hasta atajos e historias diferentes.

Es entonces que naturalmente surge la idea de emplear algunas de las herramientas visuales, como ser tableros físicos con las tareas comunes (o incluso Kanban), para así comenzar a crear un flujo común.

No obstante, la trampa reside en que un gran numero de personas se focaliza solamente en hacer visible los procesos y luego mejorarlos, aunque en realidad, existan 3 áreas  que deban ser tomadas en cuenta si lo que se quiere es realmente realizar un cambio perdurable y que las personas esten contentas:

  1. Remover los obstáculos obvios antes de hacer nada
  2. Eliminar o sustituir  los procesos innecesarios o mejorarlos
  3. Mejorar o cambiar las interacciones entre los miembros de los equipos (parte humana)

En general, toda mejora debe cubrir estas 3 áreas, y las etapas deberían realizarse  (sobre todo si no son equipos nuevos) en momentos diferentes y con objetivos claros.

Es por ello que me he centrado en dibujar los pasos para dejar explícitas las formas evolutivas que a mi criterio tienen mayor efectividad si se desea hacer un cambio duradero.

img_0088

(puedes bajar aquí el diagrama en alta definición)

Y recuerda que si quires que algo mejore, deben ser las personas que hacen el trabajo las que se adueñen del proceso, de lo contratio, terminarás empujando algo no sustentable.

Dime que piensas y si te es de utilidad…
Gracias por escucharme,
Erich

¡Afuera los que utilizan comando y control!

Parece que está de moda el culpar a las viéjas técnicas de gestión de personas y proyectos  (“comando y control”) de casi todo lo malo que ocurre en una organización. Todo miembro de una empresa ágil se horroriza de jefes, compañeros de trabajo, líderes o cualquier otro empleado que trate de dirijir y conducir con autoridad, y realice un seguimiento de todas las tarea con el fin de poder asegurar su resultado. Es la moda, ahora todo tiene que ser descentralizado, ágil, visual y corto. Ya no eres nadie si no tomas notas con dibujitos, tienes una reunión breve de coordinación a la mañana, eres un facilitador, te auto-organizas o empleas tantos post-it como puedas.

Pero déjame decirte algo, suelo invertir mucho tiempo conversando con quienes hacen de del comando y control su jornada cotidiana, y salvo raras excepciones, todos ellos tienen muy buenas intenciones y realmente desean lo mejor para la organización y la empresa.
Quizás debamos dejar de culpar al comando y control y centrarnos en comprender los motivos que hacen que esa persona actúe de esa forma, ser curiosos sobre su historia personal, sus ideas, sus metas y sus motivaciones. Sólo luego de ello podremos preguntarle ¿Y cómo es un día ideal para ti? y así transformar las conversaciones en una plática inclusiva y duradera.

Gracias por escucharme,
Erich.

Teoría de organización explicada

Hoy he publicado un  nuevo artículo en Scrum Alliance  sobre teoría de organización. Mi motivación principal ha sido que es un punto ciego para muchos profesionales que trabajan hoy en día en la transformación y apoyo a empresas.

El comprender el funcionamiento y sus diferentes etapas, ayuda a conocer las distintas técnicas a emplear, así como qué debería hacerse y cuales cosas son menos recomendables en cada situación, así como una clarificación sobre periodos de convergencia, co-alineación y transformación, muchos de ellos confusos para muchos profesionales.

Lo he plasmado en un cuento basado en anécdotas personales, con el fin de que pueda ser accesible por diferentes personas y roles de una empresa.

picture1

Ésta es la versión en inglés y estaré publicándolo en español en unos dias.

https://www.scrumalliance.org/community/articles/2016/october/the-theory-of-organization-explained

Gracias por escucharme,
Erich

Build unstoppable Scrum teams with the DOD GAME

Scrum teams need to focus on continuous improvement; this includes the following 3 main areas:

1. Software Quality (reducing code complexity, time to detect a bug, technical debt, etc.)

2. Way in which members communicate and information flows within and outside the team

3. Way in which obstacles are removed

These three points plus size and order of the requirements can directly impact the user experience and final cost of your software product. While I will focus on the first area only, you would be able to find more about the the second and third one in here.

When an organisation starts using Scrum, they often have concerns about the initial Acceptance Criteria list to be added into the new Definition of Done. Some companies choose to use an existing and comprehensive DOD list, while others select a basic list and allow the team to improve it, and the remaining ones prefer to create a DOD from scratch. Every alternative has advantages and disadvantages, and each case should be carefully analysed to chose the right option.

dodgamepicture

Whatever the desired option is, the organisation should understand that an Acceptance Criteria list is a proprietary set of rules and, therefore, local knowledge that must be learned and improved over time. That is why, in my experience, it is always advisable to start with a small DOD and, once the team is able to master it, allow them to make improvements.

A process which is run on regular basis to upgrade the DOD is highly desirable; that will assist the team to gain certain cadence and evolve the list over time.

Keep in mind that there will be no continuous improvement if the team in charge of building the software product does not control their own Definition of Done. That will cause a drop in quality, increase in complexity, technical debt and cost per requirements as well as frustration of its members. As a result of the company taking this shortcut, the Scrum Team will be unable to evolve their processes and the DOD will become larger.

Automating as much as possible and taking solid steps towards learning is essential as it allows people to spend more time at focusing on improving the other two areas.

I know by experience that many organisations have no idea how to help their Scrum teams to improve their Definitions Of Done without invading their spaces or pushing items into their lists. They also feel that they don´t have an efficient and consistent framework to support members in taking the right amount of time to learn and think of the coming acceptance criteria items.

The DOD game is a consistent solution which offers a powerful tool to allow teams to improve their DOD’s on regular basis, give visibility to the rest of the company about progress and help the organisation to understand more about software quality.

Instructions and details of the DOD game can be downloaded here

Have fun and send me your feedback!

Thanks for listening,
Erich.

Creando equipos de Scrum imparables con el juego de DOD

Los equipos Scrum necesitan centrar su mejora continua en las siguientes 3 áreas:

  1. Calidad del software producido (disminucion de complejidad de código, tiempo en detectar un error, deuda técnica, etc.)
  2. Forma en la que se comunican los integrantes y fluye la información dentro y fuera del equipo
  3. Vía en que los obstáculos son removidos

Estos tres pilares, sumados al tamaño y orden de los requerimientos, afecta directamente el coste final del producto de software y la experiencia de usuario. Si bien me centraré en el primer punto, podrás encontrar más sobre el segundo y tercero aquí.

Cuando una organización comienza a utilizar Scrum, suelen plantearse dudas referentes a que pruebas de aceptación compondrán la definición de hecho (Definition of Done) de un nuevo equipo. Algunas empresas eligen que se utilice una DOD ya existente que sea completa a nivel de criterios de aceptación, otras que se emplee una lista básica y que posteriormente se vaya perfeccionando, y los restantes que se comience desde cero y se deje al nuevo equipo que elabore su lista de criterios de aceptación inicial.
Cada alternativa tiene ventajas y desventajas, y deberá analizarse cautelosamente cada caso para conocer que opción elegir.

dodgamepicture

Cualquiera sea la opción seleccionada, la organización deberá comprender que los criterios de aceptación pertenecen a reglas puntuales de la compañía y, por lo tanto, es conocimiento específico que tendrá que ser aprendido y mejorado con el pasar del tiempo. Es por ello que en mi experiencia, siempre es recomendable empezar con un conjunto reducido de criterios de aceptación, y una vez que los mismos son entendidos por todos los miembros con facilidad, ir adicionando o eliminando elementos a la lista cada intervalos razonables.

Se necesita entonces que el proceso de evolución de la lista DOD pueda realizarse entre períodos de tiempo regulares y que el equipo pueda adueñarse del proceso.
Si no existe una revisión continua de la DOD por los equipos que producen software, la calidad del producto bajará, lo que aumentará la complejidad, deuda técnica y coste de los requisitos, así como la frustración de sus miembros. A su vez, si es la empresa quien se encarga de empujar este proceso, los equipos no podrán evolucionar, lo que producirá con el tiempo un aumento de la lista.

Automatizar lo mayor posible y dar pasos solidos es imprescindible ya que permitirá al equipo disponer de más tiempo para centrarse en mejorar los demás pilares.

Es por ello que la incógnita se centra en como ayudar a los equipos Scrum a mejorar su Definition Of Done de forma no invasiva y a su vez brindar un marco de trabajo consistente y tiempo adecuado para que sus miembros puedan comprender y mejorar la lista de criterios de aceptación.

El juego de la DOD es entonces una solución que ofrece una herramienta poderosa, que ha sido probado con un elevado número de equipos Scrum, y que permite a estos ponerse objetivos regulares de mejora continua, así como ofrecer visibilidad al resto de la empresa sobre el avance y comprensión sobre la calidad del software.

Las instrucciones y detalles del juego pueden ser bajadas aquí
¡Que los disfrutes y envíanos tu retro-alimentación!

Si necesitas conocer más sobre como potenciar equipos Scrum, visita nuestro sitio Web.

Gracias por escucharme,
Erich.

Something to learn from the Ford Taurus story

Many companies base their decisions on the cost of delay, ROI or value delivered on a fixed date. But you must be careful because the strategy and the numbers are only part of the equation.

I want to share with you a brief story about the Ford Taurus car, which is part of a study from Aaron Shensar from the Stevens Institute in “Strategic Project Leadership – Toward a strategic approach to project management”

FordTaurus

«The first generation of Ford Taurus turned out to be the best-selling car in America in the late 1980s. Conceived in the early 1980’s and introduced in 1985, it used a unique standard for project management and product development. It took full advantage of cross-functional teams and concurrent engineering practices; established close ties with vendors and subcontractors, and was characterized by a strategic spirit of focusing on customer needs and strong synergy with the business. The result was a remarkable business success, and customers simply loved the car. Yet, when the project was completed, the project manager was fired. The reason was that project completion was late by three months.

In contrast, the second generation of Ford Taurus was developed in the early 1990s and completed in 1996. With increased competition and the remarkable success of Japanese imports, Ford had hoped to reestablish Taurus, once again, as the best-selling car in America. But the new project manager learned the lesson of his predecessor: He considered project schedule as the most important criteria, and made sticking to schedule the ultimate goal, while sacrificing other issues. Vendor relationships, team spirit, and product integration were just few of the things that had suffered. The second generation of Taurus turned out to be a disappointing business experience. Although the project was completed on time, it did not recapture the position of the best-selling car in America and Ford was not able to repeat its outstanding success of the first Taurus (Walton, 1997).»

If you want to know more about the way to boost your Scrum and Agility teams within your company, please visit our website.

Thanks for listening,
Erich

Algo que aprender de la historia de Ford Taurus

Muchas compañías basan sus decisiones en el costo de la demora, ROI o valor a entregar en una fecha fija. Pero debes tener cuidado ya que la estrategia y los números son solamente una parte  de la ecuación.

Quiero compartir contigo una breve historia sobre el coche Ford Taurus, el que es parte del estudio de Aaron Shensar del Instituto Stevens  «Liderazgo de Proyectos Estratégicos – Hacia un enfoque estratégico para la gestión de proyectos»

FordTaurus

«La primera generación del Ford Taurus resultó ser el coche más vendido en Estados Unidos a finales de los ’80. Concebido en los comienzos de 1980 e introducido en 1985, utilizó un estándar único para la gestión de proyectos y desarrollo de producto. Tomó el máximo provecho de los equipos multi-funcionales y prácticas de ingeniería concurrentes; estableció vínculos estrechos con los proveedores y subcontratistas, y se caracterizó por un espíritu estratégico de centrarse en las necesidades del cliente y una fuerte sinergia con el negocio. El resultado fue un éxito comercial notable; los clientes simplemente amaban el coche. Sin embargo, cuando se completó el proyecto, el director del proyecto fue despedido. La razón fue debida a que el proyecto fue finalizado tres meses mas tarde de lo inicialmente estipulado.

Por el contrario, la segunda generación del Ford Taurus fue desarrollado en la década de los ’90 y se terminó en 1996. Con el aumento de la competencia y el éxito notable de las importaciones japonesas, Ford tenía la esperanza de restablecer Taurus, una vez más, como el coche más vendido en Estados Unidos. Pero el nuevo jefe de proyecto aprendió la lección de su predecesor: Se consideraría el cronograma del proyecto como el criterio más importante, y se apegaría ferreamente a ese objetivo final, aunque hubiese que sacrificar otras cuestiones relacionadas con los proveedores o el espíritu de equipo y la integración del producto, entre otras. La segunda generación del Taurus resultó ser una experiencia de negocio decepcionante. Aunque el proyecto se completó a tiempo, no recuperó la posición del coche más vendido en Estados Unidos y Ford no pudo repetir su excelente éxito de la primera camada de Taurus (Walton, 1997).»

Si necesitas conocer más sobre como potenciar equipos Scrum y Agilidad dentro de tu empresa, visita nuestro sitio Web.

Gracias por escucharme,
Erich.

Tu organización como nunca la viste antes

(Este es un pequeño extracto de mi Charla en Agile Gathering India)

¿Qué es la cultura de la organización? Unos días atrás me preguntaba el CEO de una empresa.
¿Es la cultura lo que hacen las áreas mayoritarias de la empresa? ¿Aquello que indican los jefes? ¿Lo que propone el CEO? La respuesta es bastante más apasionante que ello.

Todos hemos pasado por momentos donde queremos resolver un problema en una compañía y aplicamos la mejor energía, táctica, estrategia, práctica e idea innovadora, para descubrir más temprano que tarde que no funciona. Y no hablo de algo que no sea efectivo sino que en definitiva trae el efecto contrario al esperado. Sin importar tu rol en la organización, existen normalmente 4 o 5 cosas que culpamos cuando ello ocurre como esperado: la falta de apoyo institucional, la cultura de la empresa, el tipo de estructura de la organización, las formas de alicientes económicos de los empleados o el marco de trabajo.

Algún tiempo atrás, me propuse introducir las técnicas de trabajo en pareja (pairing) en toda la organización (incluyendo jefes, CEO, gerentes, desarrolladores, PO´s, HR, etc.), tomando como unidad mínima de trabajo el par. El resultado fue que las personas no solamente no desearon llevar adelante éste modelo conociendo sus ventajas, sino que tomaron el camino opuesto de aumentar los silos en la empresa y trabajar de forma más solitaria.
Me imagino que te vendrán cientos de casos similares a tu mente, donde un cambio deseable, con buena intención y coherencia de modelo económico, tuvo el efecto contrario.

La mayor parte de libros, conferencias u otros eventos empresariales tratan a la organización como un bloque monolítico, o en algunos casos, hacen solamente referencia a la relación entre cultura y estructura jerárquica o un marco de trabajo en particular.

Desde mi punto de vista, este modelo mental no es suficiente para explicar las distintas causas y efectos, su alcance y la forma de medirlo.

Las 4 capas organizacionales
La organización tiene claramente 4 capas conceptuales diferentes, donde cada una de ellas cumple un objetivo y rol concreto. Ciertas acciones de envergadura que un Agile Coach, Consultor, Scrum Master, Gerente o CEO desean impulsar dentro de una empresa, tienen origen y ejercen una actividad inicial en un área conceptual específica, que se rige por ciertas reglas y un tipo muy particular de causa-efecto.

Antes de realizar cualquier cambio (práctica, técnica, modificación en la estructura, etc.), es recomendable enmarcar inicialmente ella dentro de uno de los 4 contextos específicos, lo que llevará a entender cual es la manivela que se estará moviendo y así poder cuantificar el impacto del modelo apropiado.

El modelo organizacional de 4 capas se compone de:
– Modelo Social
– Forma de pensamiento
– Organización formal
– Creación de valor

Cada uno contiene reglas especificas, por ejemplo, bajo el modelo social las reglas de la sociología se aplican, mientras que en creación de valor aquellas relacionadas con los marcos de trabajo que transforman el esfuerzo en valor para el cliente.

La idea del modelo organizacional de cuatro capas permite a las personas identificar qué es lo que se está afectando, sus reglas y como medir el éxito.

Circle4

(c) Erich Buhler 2015

Al observar el mapa, podrás comprender que hay muchas tareas que antes planificabas como que afectaban a la empresa como un todo, pero ahora podrás analizar claramente las reglas que rigen la causa y efecto. Empecemos por el comienzo.

1. Modelo Social

La capa central de la organización reside en el modelo Social. Éste implica la forma en que las personas se comunican o interactúan dentro de la organización. Aquí todas las reglas y observaciones de la sociología son aplicables.

Piensa de la empresa como un país independiente, no importa si se encuentra al lado de otro, éste tendrá sus tradiciones, otros factores culturales y formas de comunicación específicas, las que podrán ser totalmente distintas a las de su vecino.

Circle1El modelo social también implica la forma en que las personas socialmente llevan adelante las tareas, hacen visible los procesos  y la transparencia que se desea brindar. Aquí es donde reside los patrones de comportamiento, tales como las formas aceptadas de actuación que se deberán tener en cuenta (por ejemplo, que está aceptado en la organización hacer cuando se trabaja bajo presión), qué se considera correcto o incorrecto, que formas de comunicación se creen efectivas entre las personas y como, etc.
En una organización que trabajé hace años, era aceptado y positivo el concurrir los fines de semana o llamar a otro empleado, sin importar la hora, si se requería de algo «urgente». En otra empresa, esto estaba socialmente mal visto.
El hecho de afrontar al CEO y ser honesto sobre los problemas del día a día o el no trabajar horas extras puede ser considerado una ofensa o algo plenamente aceptable.
El empleo masivo del email y empujar reuniones en agendas de otras personas puede estar bien visto, mientras que la comunicación cara a cara algo considerado normal o inmoral.

Existen 4 cosas que principalmente afectan el Modelo Social:

– Cómo las personas se comunican dentro de la empresa
– La forma en que los procesos u otras acciones se hacen visibles dentro de la organización
– Patrones culturales establecidos (Qué cosas están bien o mal)

Hay a su vez un conjunto de factores que impactan directamente al modelo social, tales como las formas aceptadas de trabajo, número de personas, fluctuación entre costo beneficio, etc.
Por ejemplo, es muy común que los empleados expresen que se comunicaban mejor y con mayor transparencia cuando la organización era más pequeña o cuando las cosas económicamente iban mejor.

Estos son los que mayormente impactan al modelo social:

– Creencias culturales (qué está bien o mal)
– Formas o prácticas de trabajo aceptadas como buenas
– Número de personas o escalado
– Fluctuaciones en el modelo económico (a mejor o peor)

He visto el proceso de fusión de compañías, y aparte del tema cultural cuando se produce entre empresas de distintos países, el acto final implica un impacto sobre el modelo social (forma en que se comunican las personas, creencias, etc).

Existe a su vez una característica particular a entender sobre el modelo social que radica que el Sentido de Urgencia tiene un efecto magnificador sobre cualquier cosa que se haga aquí.

El sentido de urgencia es un acto deliberado que se considerado de vital importancia y que genera presión sobre las personas de una organización para realizar una tarea dentro de un marco de tiempo normalmente establecido. El puede darse como resultado en cambios en el mercado o imposición interna de la organización.

¿Cuantas veces nos hemos afrontado a departamentos que no se comunican entre sí y que comienzan a colaborar cuando tienen que llevar adelante una tarea con fecha fija, o personas que al conocer los resultados económicos adversos de la organización empiezan a colaborar, hablar o dar transparencia del proceso para así sacar adelante en conjunto tareas antes que finalice el ciclo fiscal?.

Es entonces que el sentido de urgencia es un factor fundamental para obtener cambios en el modelo social. Normalmente, si el sentido de urgencia se realiza cada intervalos pequeños y regulares, entonces se estará amplificando la eficacia y efecto a largo plazo de los cambios.

¿Cómo es posible medir el modelo social? Mediante observación directa se pueden obtener algunas pistas, pero es necesario hacerlo mediante el flujo de información relevante dentro de la organización, la efectividad de las comunicaciones, la visibilidad y transparencia, la forma en que colaboran las personas, los bloqueos en el flujo, etc.

2. Capa de forma de pensamiento

La capa que rodea al modelo social se denomina Forma de Pensamiento (Mindset) y representa los cimientos, creencias e ideas abstractas que tiene la empresa sobre la realidad y ellos mismo. Ellas pueden ser evolutivas, para el caso de una empresa que ha ido creciendo en el tiempo, aprendidas, como ser el caso de formas de pensamiento conocidas (Lean, Agile, etc.) o heredadas. Esta última se da en casos de fusiones donde se hayan adquirido parte de los valores. Incluso una empresa que utilice Waterfall o técnicas no definidas, tendrá su propia forma de pensamiento, aunque ella no esté escrita, por lo que puede ser implícita o explícita.

Circle2.pngPor ejemplo, una consultora en la que trabajé en el Reino Unido, si bien la forma de pensamiento de la empresa no estaba en papel, ella era conocida por todos los empleados.

El tratar de introducir los valores Ágiles o Lean afectará particularmente ésta capa, pero no sus prácticas, las que residen en la capa de Valor, la cual te mostraré en breve.

Lógicamente, la forma de pensamiento se puede ver afectada en el tiempo por el aumento del número de empleados, fusiones, tener socios de negocio dentro de la misma empresa que tengan otras formas de pensamiento, etc.

La medición aquí se lleva adelante mediante el alineamiento con el tipo de pensamiento esperado (ej. Lean, Agile, etc) o cualquier otro valor que tenga la empresa.

Muchas empresas utilizan ciertas preguntas con valor de 1 a 5, donde se evalúa que tan cercana está la empresa a aceptar los cambios tardíos, cuanto se cree que el cliente sea lo primero, etc.

3. Capa de organización Formal

La tercera capa es lo que se denomina Organisación formal. Hace unos años atrás se solicitó a un elevado número de gerentes que dibujasen su organización; la totalidad dibujó un organigrama con los diferentes departamentos y estructuras.

Circle3.png

Ellos no podrían estar más acertados en lo que parte de la capa de organización formal representa. Aquí reside la estructura jerárquica y artefactos de control de información que aseguran la coherencia entre la empresa, sus estructuras y la realidad.

Un punto importante a tener en cuenta es que aquí es donde se organiza la información proveniente de las capas anteriores o superiores, empleando estructuras metódicas y artefactos de control. El objetivo no reside en crear valor para los clientes sino que en proteger la estructura de la empresa y que ella no cambie muy rápidamente, y hacer funcionar de la forma más eficiente posible aquellos artefactos que controlen, ordenen o midan la información.

Cualquier cambio en la estructura de jerarquías o formas de control afectará directamente ésta capa. Para medir el éxito aquí deberás recurrir a los reportes o informes de alineamiento con la estructura de la organización y la realidad, y todos aquellos que ayuden a organizar y controlar la información.

4. Capa de creación de valor

Finalmente, la última capa es donde se crea el valor para los clientes y los procesos que apoyan ésta tarea. Ellos están orientados a cuidar al cliente pero no a mantener la estructura de la empresa. Scrum. Kanban, SAFe o cualquier otro marco de trabajo o metodología (incluso Waterfall) residen aquí.

Circle4

Es importante que veas la dicotomía y tensión natural que existe entre ésta capa y la anterior y sus diferencias.

Principalmente la capa de creación de valor se vé impactada por el tipo de marco de trabajo utilizado, la forma en que las colas y lotes de trabajo son organizados y su tamaño, la definición que tenga la empresa sobre que es valor para el cliente y el número de personas en la empresa o procesos de escalado.

Se debe medir mediante el cumplimiento con el marco de trabajo y prácticas seleccionadas, así como la entrega de valor al cliente.

Ten en cuenta que la mejora continua en cada una de las capas se representa a través de diferentes tipos de acciones, con un alcance claro y definido.

Es entonces que en toda estrategia de transformación Ágil es necesario conocer las reglas que rigen la organización, por lo que el modelo organizacional de 4 capas es una herramienta de suma importancia para explicar a las personas de la compañía su funcionamiento, impacto, relación y contexto.

Gracias por escucharme,
Erich.

How exploring the 8 product dimensions using an exploratory cube can change the way you do Scrum

The exploratory cube and the 8 product dimensions’ game is a powerful tool that makes it possible for Agile Coaches, Scrum Masters, Consultants, Product Owners and anyone related to a product to understand the best way to focus all the efforts towards the delivery of high business value. Although it was initially created for software products, the exploratory cube can be used with any tangible product as most of the modern organisations are digital, which means that their strategies are based on the direct outcome of a piece of software. But before seeing how it works, let me explain to you why the game is needed.

Did it ever happen to you that an Agile team had no idea how to start with a new product, how to slice a high level user story or which options were more valuable for the client?
In my opinion, this is generally due to several factors, among which I normally see the following ones:

  • Team and/or Product Owner are new to the company
  • Unfamiliarity with the product
  • Cognitive bias (they believe that they know more than they actually do or Dunning-Kruger effect)
  • Political issues in the company which makes the Product Owner get some extraordinary pressure from different areas of the organization with conflicting goals but equal priorities
  • The result of a team working only with technical requirements and not knowing how to properly write user stories from a business point of view
  • As a result of just analysing a few dimensions of the problem instead of having a multidimensional conversation

In these cases, results are often very ambiguous, contradictory or huge user stories are created as a result of  unfruitful talks during long refinements’ sessions.

ExploracionHabitual_Inglés

This generally leads to many teams confirming what is needed to be developed in the middle of the Sprint, thing which obviously impacts the morale and jeopardizes the ability to complete the expected features on time (expectations).

You will agree with me that it is vitally important to focus all the energy on being assertively correct, that is, just centre in the conversations’ dimensions that enable the business and those responsible for implementing the solution to be on the same  page. A set of techniques that are structured, creative, generate consensus among all the people involved are needed to make it possible to easily guide the thinking processes towards the aligning of the organization with the highest possible business value outcome.

We usually have different points of views (marketing, customer service, political constraints, etc.) for the same product, thing which also overflows the amount of information brought to the first meetings.

As an example of that, I had a few months ago to work with two Products Owners who led different teams responsible for exactly the same product. Both had different interpretations and priorities for the same features, making it very difficult to coordinate the groups and/or self-organisation and blockades. This  obviously undermined the developers’ confidence and lead to deficiencies in the development life cycle as it added complexity when both Product Owners wanted to expose their ideas about the product.

I will intentionally leave technical issues, size and dependencies, to focus exclusively on the 8 product dimensions, thing which help promote a multidimensional discussion of the Product Backlog.

ExploracionMultidimensional_Inglés

Using the 8 product dimensions allows you to create a consistent product backlog. This will increase productivity and Team’s morale and establish a common ground for talks related to priorities, objectives and consistency.

The 8 dimensions are used during a exploratory session, that is, a meeting involving the Product Owner, Development Team, Stakeholders and Customers to help identify some key areas and possible options. I use the word «options» as for a single problem might be hundreds of different solutions (options), and the product success is strictly related to the ability to choose the ones which will produce the greatest impact to the user, developed in the shortest possible period of time with high quality and fulfills all the definitions of done.

An exploratory sessions follows a particular structure and uses an exploratory cube. They can be run every a few weeks or part of a refinements. The idea behind this is to teach all members about the different areas needed to get a Product Backlog ready to be consumed (*).

(*) According to a research from Scrum Inc., teams which start the Sprint with a ready Product Backlog double their productivity.

Let me put you an example of how it works; the Product Owner brings a high level user story (Epic) to the meeting, such as:

«As a Frequent flyer I want to be recognized as someone special»

This is a good starting point but really high level for a team to be developed. The main reason is that just covers 2 dimensions: The Customer (1st Dimension) and ambiguously the desired Action (dimension 2).

What does it mean to be recognized? What does it entail to be special? This is a usual situation in an early discovery process and where teams get generally lost. We know that a Frequent Flyer wants to be recognized as a special human being, be spoiled and hugged, but many conversations are needed in order to reach a point where everyone feels comfortable about going ahead and developing the solution.

The biggest challenge for most teams is to focus its efforts on building clarity, something concise, and able to choose the option with the highest business value that can be iteratively developed within a Sprint and great user experience.

CUBO

Each of the eight cube dimensions makes it possible for people to focus on the different areas to be dissected. Let’s now take a look at the different areas:

Tabla_ingléss.png

Each one promotes a specific type of conversation during the session and all of them will become part of a Product Backlog ready to be consumed.

There are functional elements (Customer, Data, Actions and Controls) and non-functional ones (Interface, Experience, Environment and Quality), however, they all become part of the same discovery process.

To have an effective session, you need to gather in one place all the relevant stakeholders, customers and Team to analyse in a collaborative way the 8 different dimensions.

embudo_ingles.png

Each element also contains a clear visual sign that can be kept as an information radiator after the meeting and used for further discussions.You should remember that the idea here is not to use this information to write extensive specifications but to enable people create a common understanding and make sure that the essence of each dimension that solves a specific problem is captured.
Those can be then moved into a set of high business value user stories as seen below:

filtro_atras_adelante_inglés

We normally write the Customer, Actions and Controls dimensions at the front of the card using the classic user story syntax, while the other dimensions are placed at the back.

How is the exploratory cube used and how can the session be run?

Click here to download the instructions and cube and begin to establish all the relevant conversations about the product and its possible solutions.

Many thanks to EBG Consulting for its initial approach.

 

Thanks for listening,
Erich.

 

Remember that you can follow me in Spanish on Twitter @erichbuhler or Linkedin in English with my daily thoughts about Scrum, disruptions, Agility and progressive organizations.

Cómo el explorar las 8 dimensiones de un producto empleando un cubo exploratorio puede cambiar la forma que haces Scrum

El juego del cubo exploratorio y las 8 dimensiones de un producto es una herramienta poderosa que hace posible a Coaches Ágiles, Scrum Master, Consultores, Product Owners o cualquier persona relacionado con un producto, el comprender a enfocar los esfuerzos de las personas en la entrega de alto valor al cliente.

Aunque fue inicialmente creado para un producto de software, el cubo exploratorio puede ser usado con tangibles, debido a que la mayoría de las organizaciones hoy en día se caracterizan por ser digitales, esto es, que su estrategia está basada en los resultados directos del software.

Pero antes de conocer como funciona, déjame explicarte porqué éste existe.

¿Te ha pasado con un equipo ágil que no sepa por dónde comenzar el nuevo producto, partir una historia de usuario o no se comprenda bien en que dirección ir?

Esto se debe a varios factores, entre los cuales normalmente veo los siguientes:

  • Equipo y/o Propietario de producto (Product Owner) son nuevos en la empresa
  • Desconocimiento del producto en su totalidad
  • Sesgo cognitivo (el creer que se sabe más de lo que en realidad se conoce o efecto Dunning-Kruger)
  • Temas políticos de la empresa que hacen que el Propietario del producto (Product Owner) tenga presión de varias áreas de la organización con metas contradictorias pero de igual prioridad
  • Debido a que el equipo trabajó siempre con requerimientos técnicos y desconoce como escribir adecuadamente historias de usuario desde el punto de vista de negocio
  • Como resultado de haber analizado unas pocas dimensiones del problema.

En estos casos, el resultado suele ser de historias de usuario muy ambiguas, contradictorias o gigantes, refinamientos super extensos o charlas no fructíferas.

ExploracionHabitual_Español.png

Ello conduce a que muchos equipos terminen confirmando lo que hay que desarrollar durante el un ciclo de trabajo (Sprint), lo que evidentemente impacta la moral y capacidad de concretar las características esperadas (expectativas) por el cliente/empresa.

Estarás de acuerdo que es de vital importancia el focalizar la energía en ser asertivamente correcto, esto es, centrase en aquellas áreas que permitan establecer conversaciones que habiliten al negocio y a los encargados de implementar la solución en ser capaces de analizar diferentes dimensiones del producto. Se necesitan entonces un conjunto de técnicas que sean estructuradas, creativas, que generen consenso entre todas las personas involucradas y que hagan posible de forma fácil  guiar los procesos de pensamiento y alinearlos con lo que la organización entiende por valor de negocio.

Tenemos normalmente diferentes puntos de vista (marketing, atención al cliente, servicios, partes políticamente interesadas etc.) para un mismo producto que desborda inicialmente la cantidad de información lo que hace difícil el ser asertivo.

Como ejemplo, hace unos meses atrás, me tocó trabajar con dos encargados de un mismo producto (Product Owners)  que lideraban equipos diferentes. Ambos contaban con distintas interpretaciones y prioridades de una misma idea de un mismo producto, lo que hacía muy difícil la coordinación entre los grupos y debilitaba plenamente la confianza de los desarrolladores en estos.

Nuevamente, esto conlleva a deficiencias en el ciclo de implementación del producto debido a que adiciona complejidad a la hora de poner en una misma habitación a todas las ideas de las diferentes partes interesadas.

Dejaré inicialmente de lado temas técnicos, de tamaño y dependencias, para focalizarse exclusivamente en las 8 dimensiones del producto, lo que se trasladará en una pila de producto (Product Backlog) que será el resultado de conversaciones multi-dimensionales.

ExploracionMultidimensional_Español.png

Las 8 dimensiones de un producto permite establecer claramente una pila de producto consistente lo que aumenta la productividad y moral de los equipos así como establece un marco común de comunicación con prioridades claras, que establece objetivos concisos y consistencia entre las conversaciones llevadas adelante entre todas las personas involucradas.

Las 8 dimensiones de un producto se emplean en sesiones explorativas, esto es, una reunión que interviene el Product Owner, Equipo de desarrollo, partes interesadas y algunos clientes para así identificar áreas claves y posibles opciones. Hablo aquí de “opciones” ya que para un mismo problema pueden haber cientos de soluciones diferentes (opciones), y el éxito de un producto consistirá en seleccionar las que producirán el mayor impacto para el usuario, se desarrollarán en el menor tiempo posible con mayor calidad, cumpliendo obviamente todas las definiciones de listo.

Las sesiones explorativas siguen una estructura particular y emplean un cubo de exploración. Ellas pueden hacerse cada un lapso de tiempo determinado o como parte de algunos refinamientos. La idea es enseñar a todos los integrantes sobre las distintas dimensiones a considerar con el fin de dejar la pila del producto (Product backlog) en estado listo para ser consumida(*).

(*) De acuerdo a un estudio de ScrumInc, los equipos que comienzan un Sprint con la pila de producto (Product Backlog) lista, duplican su productividad.

Veamos entonces un ejemplo de como funciona. El Propietario de Producto (Product Owner) tiene su primer historia de usuario de alto nivel (Épica):

“Cómo pasajero frecuente deseo poder ser reconocido como alguien especial”

He aquí un buen punto de comienzo, pero de muy alto nivel para que el equipo pueda implementarlo ya que solamente abarca 2 dimensiones: El cliente (dimensión 1) y de forma ambigua la acción deseada (dimensión 2).

¿Qué significa ser reconocido? ¿Qué es ser especial? Este es un caso común de comienzo de proceso de descubrimiento que muchos equipos encuentran difícil. Sabemos que el cliente quiere ser reconocido como especial, ser mimado y arropado, pero se necesitarán varias conversaciones hasta llegar a un punto de convergencia donde todos se sientan confortables de moverse asertivamente hacia buen puerto.

El gran desafío para la mayor parte de los equipos es traducir los esfuerzos en algo claro, conciso, que obtenga el mayor valor para el cliente y pueda ser llevado delante de forma iterativa dentro de un ciclo  Sprint con un resultado que desborde las expectativas.

CUBO

Cada una de las 8 dimensiones del cubo hace posible a las personas involucradas enfocarse en diferentes áreas a ser tratadas, con el fin de ayudar a disectar el problema y dividir éste en resultados más pequeños. Veamos cuales son éstas áreas:

Tabla_español.png

Cada área establece una discusión específica durante la sesión y es la columna vertebral fundamental para una pila de producto (Product Backlog)  lista para ser consumida.
Existen elementos funcionales (Cliente, Data,Acciones y Controles) y no funcionales (Interfase, Experiencia, Entorno y Calidad), no obstante, todos ellos pasan a ser parte de  un proceso de descubrimiento.

Para llevar adelante la sesión es necesario reunir en un mismo sitio a partes interesadas, cliente y equipo para así analizar de forma colaborativa las diferentes secciones. Cada elemento contiene un factor gráfico y visual que permite el uso del radiador visual incluso luego de la sesión.

Tabla_filtro_español
Debes recordar que la idea no se centra en escribir especificaciones extensas sino en crear un entendimiento común y capturar la esencia de las dimensiones de la hipótesis que solucionará al problema, lo que se trasladará en un conjunto de historias de usuario de alto valor para el cliente.

filtro_atras_adelante_español

Normalmente, Cliente, Acciones y Controles se escriben al frente de la tarjeta y son parte de la estructura clásica de una historia de usuario, mientras que el resto de las dimensiones se sitúan en la parte atrás.

¿Cómo se utiliza el cubo exploratorio y cómo se realiza la sesión?

Baja de aquí las instrucciones y el cubo y comienza a establecer conversaciones relevantes sobre el producto y las posibles soluciones.

Mi agradecimiento EBG Consulting por su aproximación inicial.

 

Si deseas acelerar y sustentar el cambio en su empresa, visita Lidera el Cambio Exponencial.

Gracias por escucharme,
Erich.