El consejo del presidente de Telefónica que nunca deberías seguir

Hace unos días atrás el presidente de Telefónica César Alierta realizaba un par de aseveraciones importantes durante una presentación, las que me han quedado dando vueltas por el fin de semana. Pienso utilizarlas como ejemplo para explicarte dos modelos de organización diferentes.

Alierta indicó que el ritmo de crecimiento de los ingresos de Telefónica se podría duplicar en los próximos años gracias a la digitalización de la economía y a la monetización de los datos. Esto último se concretaría (entre otros) mediante la limitación de la banda ancha a 500GB de datos, con el fin de que una vez alcanzado el tope, el cliente tuviese que pagar por el exceso. Esta idea ya la utiliza Telefónica en Argentina y Chile, y se estudia su implementación también en Brasil.

La decisión es mayoritariamente debida a que algunas de las infraestructuras no soportan bien el tráfico, lo que se podría enmendar de ésta forma y ayudar al pago de dividendo en efectivo de como mínimo 0,75 euros por acción garantizado para los próximos cinco o diez años a los accionistas. Añadió que la compañía está comprometida con la actual política de alto dividendo (0,75 euros al año en efectivo)

¿Pero qué tiene esto de particular?

Déjame hacer un poco de historia para que pueda exponerte mi punto. Éste modelo de compañía al servicio de sus accionistas y como principal motor de las decisiones estratégicas se lo denomina Economía Tradicional. Aquí, los planes son lineales en el tiempo y normalmente el cliente está ausente de las grandes decisiones de la empresa, aunque es el motor de sus ganancias. Lo importante es la previsibilidad a coste de una menor agilidad o adaptación, lo que repercute en una menor innovación y creación de disrupciones, pero ello se puede compensar parcialmente con enormes inversiones para lograr cierta innovación.

Figura1EmpresaCentro

Una característica para reconocer éste tipo de organizaciones es que cuentan con jerarquías rígidas donde normalmente la firma se sitúa como centro del universo, o lo que se denomina empresa geocéntrica. Aquí el cliente gira en la periferia alrededor de una compañía estable con planes a los próximos años y donde los clientes serán casi un hecho.

La meta principal es hacer más dinero para los accionistas y la pegunta central ronda en torno a “¿Cómo puedo hacer que los clientes me dejen más dinero?”. Ello se logra mediante 4 pilares adicionales:

Figura3ModeloTradicional.png

¿Crees que el patrón es similar al objetivo de Telefónica? Los roles en este tipo de empresa tienen la particularidad de estar basados en el control férreo sobre las tareas e individuos, coordinación mediante burocracia, reglas, planes e informes, y normalmente la eficiencia se lleva adelante mediante la reducción de costes. Finalmente, las comunicaciones fluyen de arriba hacia abajo dentro de canales formales y bien definidos, con densidad social baja (lee más sobre densidad social aquí).

Con el advenimiento de la agilidad y Scrum, el ecosistema comenzó plantearse de forma más horizontal, donde los equipos se sitúan en contacto directo con el cliente y la moneda de cambio de la organización es el valor generado hacia éste. Aquí la empresa ofrece el deleitar al cliente como núcleo, lo que da como resultado que sea involucrado en las decisiones como parte de ciclos de retro-alimentación cortos. Se mueve entonces hacia el modelo heliocéntrico similar a la revolución de Copérnico, dejando de ser la organización el centro del universo.

Figura2ClienteCentro

En vez de preguntar “¿Cómo puedo hacer que los clientes me dejen más dinero?”, se pasa a  “¿Cuáles son las necesidades de los clientes no satisfechos que puedo resolver cuanto antes?”

Con ésta nueva pregunta, el modelo cambia rotundamente ya que ahora a la cabeza de la pirámide ya no está el hacer más dinero para los inversionistas, lo cual puede parecer extraño a primera vista. Tomando el ejemplo de Telefónica, ¿Sería la decisión corecta bajo esta forma de pensamiento el poner una restricción al anchos de banda para generar más ganacia?

Ello genera una cadena de preguntas y respuestas diferentes que dan como resultado 5 nuevos pilares:

Figura4ModeloCreativo.png

Ahora el pilar principal es en deleitar al cliente en vez de generar dinero, lo que acarreará un cambio en la estructura de roles de la organización de jefes controladores pasando a ser ahora facilitadores/habilitadores, de burocracia a Ágil/Scrum/Lean, de valor a valores (transparencia, mejora continua y sustentabilidad) y de comunicaciones de arriba hacia abajo a conversaciones horizontales. Esto se llama “Economía Creativa”, lo que deriva en un paradigma diferente que crea un círculo virtuoso positivo donde se genera como resultante secundario más dinero aunque éste no sea parte de la fórmula.
Es un sistema de organización diferente, pero se deberá tener en cuenta que la falta de alguno de los elementos de las cajas superiores derivará en una empresa incapaz de lograr el objetivo de deleitar al cliente.

“Maximizar el valor para el accionista es la cosa más tonta del mundo”
Jack Welch ex-CEO de General Electric

“La idea de maximizar el dinero de los inversionistas lo cual es omnipresente en el mercado está totalmente equivocado”
Marc Benioff, CEO de Salesforce

La Economía creativa es el paradigma necesario en las empresas del nuevo siglo para obtener una alta flexibilidad a los cambios y adaptación a las turbulencias del mercado, productividad, generación de innovación y altos dividendos, y en lo que está basada la Agilidad.

Cualquier empresa que no transforme su modelo y siga tomando sus decisiones en base a paradigmas tradicionales, tendrá dificultades para competir, un alto nivel de desperdicio en sus procesos y ofrecerá productos menos atractivos.

Por lo que antes de seguir ideas o un consejo, piensa como quieres que tu organización piense y se mueva en los próximos años,

Gracias por escucharme,
Erich.

Recuerda que puedes seguirme en Twitter @erichbuhler con mis pensamientos diarios sobre Scrum, disrupciones, Agilidad y organizaciones progresivas o en Linkedin.

Porqué comprender la teoría de integración ayuda a tus productos Ágiles a ser exitosos

Ya hace más de una década que se escribió el manifiesto ágil y aún más desde que se comenzó a utilizar Scrum. Es momento de que te olvides del marco de trabajo tal cual lo concibes, y te explicaré porqué.

He visitado muchas empresas en los últimos años obsesionadas con crear más y más equipos Scrum. En las organizaciones con mayor flujo de información cruzada entre sus empleados (densidad social), con 4 o 5 personas alcanza para conformar un nuevo equipo, pero en donde existen o existieron silos, se requieren al menos 9 individuos por grupo para poder contar con las habilidades para crear un software específico. Es así que desde la concepción tradicional de Scrum, el foco se traduce en apoyar y buscar diferentes roles que sean capaces de llevar adelante el desarrollo de un producto, lo que lo focaliza en resolver un problema normalente orientado a lo que la herramienta puede hacer por el cliente.

Pero esto ha cambiado y mucho en los últimos años. Comencemos por entender la situación actual de los mercados, lo cual te permitirá comprender qué es lo que puedes hacer y hacia dónde deberías dirigirte o poner el esfuerzo de tu organización.

En los mercados tradicionales para los cuales se desarrolla un software, la cadena de comercialización se clasifica en 3 grupos:

  • o bien la compañía produce (o crea) un producto tangible o intangible
  • o se es un distribuidor
  • o se es un consumidor/usuario final

En muchos casos el resultado puede ser mixto, pero es siempre uno de estos el factor predominante.
La forma en la cual se hace dinero más fácilmente es mediante la retención del monopolio de alguna de las partes, por ejemplo, ser el proveedor o distribuidor único o integrar 2 de éstas áreas en una empresa. En éste último caso produces el bien y su vez lo distribuyes.

Ambas opciones se han empleado por años y son las que permiten en definitiva hacer  más fácilmente dinero ya que controlas al mercado.

Un ejemplo de la integración de dos áreas puede ser una revista, donde la creación del contenido (producto) y la distribución la hace la misma compañía. Otro ejemplo es una empresa de viajes aéreos, donde los aparatos, la atención de ventas y gestión de los aviones lo realiza la misma empresa (ejemplo Ryanair).

Draw1Spanish.png

Esto es lo que llamamos integración: quien crea/produce el servicio o elemento y quien realiza la gestión y distribución se integra bajo un mismo bloque para así controlar gran parte del mercado.
Aquí el foco normalmente del desarrollo de software radica en equipos que puedan potenciar productos que hagan posible unificar los servicios del proveedor y distribuidor bajo una misma solución.

Si el proveedor y distribuidor no son la misma empresa, la forma más efectiva es mediante el logro de la exclusividad, lo que asegurará una alianza estratégica.
Bajo éste mundo, se considera que si tienes un buen producto para ofrecer (zapattos, seguros, etc.), los clientes vendrán solos. Es por ello que la experiencia de usuario pasa a un segundo plano ya que aquí lo crucial es contar con un distribuidor estratégico, un producto y un software que pueda integrar ambas partes.

A medida que la internet y los teléfonos inteligentes se hicieron disponibles a escala masiva y precios asequibles, se generó la primera disrupción en los mercados, cambiando la estructura, las reglas y la forma de ver y crear software.

Lo digital permitió que toda compañía se transformase en una empresa de software y que pudiese  distribuir de forma gratuita. Una aerolíneas o una compañía de trenes ya no tenía que enviar físicamente los boletos, ya que ahora era posible integrar el proveedor y distribuidor bajo la misma herramienta Web y que se ofreciese de ojos a los clientes de forma unificada/integrada la totalidad de la solución. Esto permitía bajar los costes de las transacciones a casi cero, lo que potenciaba el escalar fácilmente el software  a cientos de usuarios en tiempo record. A esto es lo que llamamos agregación, y es parte de la teoría de Ben Thompson.

Draw2InternetEraSpanish.png

Esta primera disrupción cambió fundamentalmente la concepción de cómo las empresas competían entre sí. Un distribuidor ya no lo hacía basado en la relación exclusiva de productos que podía ofrecer a un conjunto de clientes sino que se centraba en que tan bien su software podía integrar la producción y ventas con sus usuarios.
Es aquí que comienza a cobrar vida un factor nuevo y desconocido para los equipos Scrum: La experiencia de Usuario.

Aquel que pudiese unificar el proveedor y su distribución con una buena  experiencia de cara al usuario ganaría más clientes, lo que haría posible que más gente emplease el producto, brindando así mayor retro-alimentación para los equipos de desarrollo (Scrum), cosa que permitiría mejorar el software más rápidamente (círculo vicioso positivo). Esto a su vez ayudaría a los Propietarios de Producto (Product Owner) a centrarse con mayor facilidad en aquellas funcionalidades deseables por el mercado.

Aparece aquí una segunda disrupción que fue originalmente descrita por la llamada Ley de la conservación de las ganancias/utilidades atractivas. Esta indica que cuando se tiene una disrupción, el titular que dominaba el mercado anteriormente (por ejemplo una casa de venta de tickets) ya no lo haría y sus ganancias caerían, pero ellas no se perderían sino que se transferirían a otra parte de la cadena, seguramente adyacente.

Déjame ponerte un ejemplo para que quede claro; antes de Internet, para conseguir huéspedes  los hoteles ofrecían habitaciones bajo una marca que el cliente reconocía y tenía confianza. Recuerdo que la primera vez que viajé a Seattle me alojé en la cadena Hilton, ya que confiaba en que el servicio de esa marca era de calidad, requisito necesario si nunca estuviste en una ciudad.

Draw3HotelesBeforeInternetSpanish

En ese tiempo, las cadenas de hoteles tenían integrada la propiedad que ofrecía las habitaciones con la confianza de la experiencia del usuario, y se dejaba en manos de terceros (modularizaba/tercerizaba) los mecanismos de reservas, los cuales se hacían generalmente a través de una agencia de viajes.
Al madurar la Internet, aparecieron nuevos jugadores en el mercado. Pongamos el caso del sitio Web AirBnB que permite a cualquier persona alquilar una habitación o propiedad. En éste caso, el mercado comenzó a funcionar de forma diferente.

Draw4HotelesAfterInternetSpanish

La Internet transformó la confianza en digital mediante una excelente experiencia de usuario y la posibilidad de emplear la reputación donde huéspedes podían votar sobre su estancia con un determinado anfitrión. De ésta forma, la confianza pasó a ser un bien digital y la propiedad modularizado/tercerizado.

Ahora al modularizarse la confianza (ya no pertenece al titular del monopolio) y ser digitalintegrarse con el sistema de reservas (sitio Web), se consigue que no sea necesario que la propiedad esté localizada en un mismo lugar, cualquier apartamento o habitación del mundo podría ser un candidato.  Lo que antes era un monopolio de una marca ligado a la confianza, ahora se transformó en digital, lo cual hizo que la marca ya no fuese lo importante sino que el centro se transformase en la experiencia que tenía el usuario desde su reserva hasta el fin de su estadía.

Pensemos ahora en una empresa de taxis, antes ella monopolizaba los coches y el despacho de los mismos y se tercerizaba en varios casos la reserva y el sistema de pagos (tarjetas de crédito).

DrawUberBeforeInternetSpanish

Ahora con Uber, Lyft, Cabify, etc. la confianza nuevamente se ha digitalizado mediante la posibilidad a los pasajeros de valorar conductores y a estos últimos al pasajero. A su vez, los coches se han tercerizado/modularizado (puede ser cualquier coche que funcione) y el sistema de despacho y pago está integrado en la plataforma Web.

DrawUberAfterInternetSpanish

En todos los casos se ha digitalizado la confianza, lo que hace que las ganancias se muevan a estas nuevas compañías y generen pérdidas en los «dueños/titulares» originales del mercado.

Esto es lo que la Ley de la conservación de las ganancias atractivas predice: cuando una disrupción aparece en el mercado, el dinero que pierde quien tenía un pseudo-monopolio se transferirá a otro eslabón adyacente de la cadena.

En un futuro podríamos ver entrar en el mercado a otros actores en la industria de trenes, bancos, líneas aéreas, etc. donde el digitalizar la confianza permita que lo importante sea la experiencia de usuario de principio a fin sin tener en cuenta quien realice el transporte.

Existe quizás una pequeña excepción a la digitalización de la confianza y es que el servicio sea excelente y precio muy razonable. Por ejemplo, en España el servicio de taxímetros es excelente, los coches son nuevos y están siempre limpios, personas amables y precio razonable. Aquí seguramente el impacto de la digitalización de la confianza tenga mucho menor impacto sobre su modularización, o su impacto sea debido a la digitalización de las empresas o servicios aledaños. Pero… conozco pocas empresas donde sus clientes estén muy satisfechos y consideren los precios del servicio más que razonables.

Es así que el centro de la creación del software en sí ya no radica en las tareas computacionales para resolver un problema específico y puntual sino en satisfacer al cliente de inicio a fin, y si la compañía desea sobrevivir, deberá poner el foco y llamar ahora a los equipos Scrum/Kanban o cualquier otro marco de trabajo Ágil como Equipos de Experiencia de Usuario, siendo el entendimiento de ésta última disciplina el nuevo centro del universo de la organización, y los cambios consecuentes en las estructuras de los equipos y la organización pasos urgentes de llevar adelante.

Si te gustó el artículo, ¿porqué no lees más sobre mi libro para consultores en cambio de empresa Lidera el Cambio Exponencial?

Gracias por escucharme,
Erich

¿Qué tipos de Coach Ágiles puedes encontrar en el mercado y en qué se diferencian?

Ésta es una pregunta muy frecuente en organizaciones nuevas con Agile, ¿Hay un solo tipo de Coach Ágil?

Déjame ponerte un ejemplo antes de darte la respuesta, si eres un jugador de fútbol, te preocuparás por tu rendimiento, estrategias de juego, habilidades con el equipo y personales, etc.

¿Es ésta la única perspectiva?

No, puedes ayudar al equipo en sí y pensar en sus divisiones inferiores, resto del club, su visión, mejorar la relación con los auspiciantes, proveedores y todas aquellas cosas que están en la periferia de éste.

Lo mismo sucede con Coach Ágiles. Existen actividades relacionadas con los equipos y la forma en la que se desarrolla el software, su calidad, la facilitación entre los grupos, los rituales de Scrum y la enseñanza de las técnicas para que ellos puedan ser exitosos.
Existen otras tareas que están relacionadas con las actividades más periféricas, por ejemplo, coaching de gerentes, la interacción de equipos con el resto de la empresa, el crecimiento de la organización hacia la agilidad, el cambio de los sistemas de compensación y evaluación, modificaciones en los contratos con terceros, la forma de presentar los servicios y todas aquellas áreas relacionadas con la transformación en sí. Aquí los equipos es tan solo un pequeño trozo de la tarta.

Es por ello que la industria normalmente se decanta por 4 tipos de Coach:

  • Scrum Master (facilitador de equipo)
  • Technical Coach (trabajo técnico con equipos)
  • Agile Team Coach (trabajo con varios equipos incluido Scrum Masters)
  • Agile Enterprise Coach (o Transformational Agent) (trabajo especializado en transformación organizacional)

En general, un coach empresarial (Enterprise Coach) requiere más experiencia sobre transformaciones de gran escala y sus dinámicas, y si bien puede hacer las tareas de un Coach de equipos (Team Coach), muy comúnmente un Team Coach carece de conocimiento para efectuar la transformación de toda una organización. Muchas veces él (Team Coach) es la progresión de la carrera de Scrum Master. Éste último es el peldaño inicial, pero no por ello, deja de ser difícil y requiere conocimientos de muchas áreas.
Por su parte, los Coach técnicos se especializan en tareas relacionadas con la construcción de software, herramientas, testing, programación, etc

¿Puedes ver la diferencia?

Lo que no deberías es tratar de tener la navaja suiza, donde una persona cubra todo el espectro (Scrum Master que es un coach organizacional o cualquiera otra combinación). Ello no solamente disminuye el foco (¡que es un valor de Scrum y Agile!) sino que aumenta la posibilidad de conflicto de prioridades. ¿Qué pasaría si un coach de equipos tuviese que hacer una tarea organizacional y otra de equipo, ambas de igual prioridad? Lógicamente una de ellas tendría que ponerse en espera, lo que provocaría un bloqueo temporal. ¡Y ello es justamente lo que estamos tratando de evitar!

Obviamente nada es blanco o negro, pero el seguir ciertas recomendaciones ayuda a crear un ambiente seguro y que la empresa sea más ágil, eficiente y un mejor lugar para trabajar.

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

Gracias por escucharme,

Erich.

¿Porqué las empresas ágiles están plagadas de incompetentes?

Hace mucho tiempo atrás leí un libro del año 1969 de Laurence J. Peter llamado El principio de Peter. Allí se explicaba que las personas que realizan bien su trabajo eran promocionadas a puestos de mayor responsabilidad, a tal punto que llegaban a un puesto en el que no podrían formular ni siquiera los objetivos de su trabajo, y alcanzarían allí su máximo nivel de incompetencia. Esto tiene lógica, ya que al vernos con habilidades, siempre surgirá la idea de ascender al empleado.

De acuerdo a éste, el trabajo sería siempre realizado por aquellos  empleados que no habrían alcanzado todavía su nivel de incompetencia.

incompetencia

A ello lo denominó el principio de Peter y es un clásico de la literatura para los postulantes a recursos humanos.

He vivido por muchos años “transformaciones” ágiles de empresas de todo tipo, donde en la gran mayoría de los casos se suele dar el primer paso como resultado de algún director con visión verdadera… el reclutar equipos de personas que conozcan y hayan utilizado Scrum para incorporarlos a la compañia y así comenzar el camino hacia la agilidad.

Es allí que empieza la búsqueda frenética o selección de personal externo, rastrillaje interno, agrupación con socios de negocio que tengan los «recursos», o cualquier otra actividad que permita obtener los tan ansiados nuevos empleados competentes a nivel de Scrum. Cuanta más experiencia, más será la satisfacción de quienes impulsan el “experimento” y la idea de solidez sobre el futuro éxito de la iniciativa. En la mayor parte de los casos que he visto, se obtiene uno o dos grupos pequeños de personas con conocimiento de Scrum, los cuales liderarán el camino.

Miremos ahora al resto de la organización y cargos superiores ¿Tienen ellos en general competencias a nivel de Ágil y Scrum? Normalmente no. Es aquí donde se encuentra la primer paradoja: los nuevos equipos competentes serán gestionados por individuos incompetentes a nivel de Ágil, Scrum o Lean.

Se cumplirá aquí uno de los postulados de Peter: el trabajo será realizado por aquellos empleados que no tienen nivel de incompetencia.

Los equipos pronto comenzarán a producir cada intervalos regulares de tiempo un producto de software, creando un alto número de tareas adicionales derivadas debido a su alta cadencia,  que deberán ser realizadas por aquellas personas sin competencias sobre Scrum o agilidad. Ello generará una acumulación de peso muerto de tareas en el nivel ejecutivo, compuesto de personas y candidatos potenciales a ser incompetentes debido a la presión ejercida por las nuevas tareas a realizar y la falta de experiencia que ayude a estos a conocer hacia donde ir.

Otra de las paradojas será que la competencia de los empleados en los equipos Scrum no será determinada o evaluada por extraños, sino que por sus jefes directos en la jerarquía. Si el superior contase con grandes conocimientos sobre Agilidad/Scrum/Lean, éste podría valorar a sus subordinados sobre como reducir el desperdicio en los procesos, innovación, brindar más valor de negocio, mejorar el código o realizar una mejor integración continua tanto para el software como para los procesos. Pero si su jefe es incompetente a nivel de Scrum (lo más probable), él evaluará a sus empleados de acuerdo a los valores de la empresa y las formas en las que se han hecho siempre las cosas “allí”. Ello dará como resultado que se considere competente aquel que tenga un comportamiento que siga las reglas, rituales y conserven el status-quo de la empresa, cosa nada deseable si se quiere crear una organización progresiva y adaptable, con ciclos cortos de productos hacia los mercados y que generen innovación.

En tales casos, la consistencia interna, el status-quo, la estandarización de procesos y la obsesión por medir equipos serán más apreciadas que el valor entregado al cliente, la mejora continua a todos los niveles de la jerarquía o el seguimiento de los valores y principios ágiles.

dilbert3

Es por ello que en estos escenarios donde se comienza una ruta hacia la agilidad solamente por la inclusión de equipos Scrum (o islas de felicidad), se obtendrá como resultado varios círculos de personas competentes con alto conocimiento de Ágil/Scrum y una gran mayoría de incompetentes y recuerda… parte de los últimos estarán a cargo de ¡Gestionar el proceso de Ágil y Scrum!

Una buena idea es preguntar siempre a la persona ¿Eres competente en Ágil/Scrum? Ello podrá ayudar a orientar conversaciones cruciales sobre lo que se espera que pase y las habilidades deseadas.

He vivido también compañías donde los equipos Scrum son incompetentes. Allí normalmente la auto-organización se transforma en anarquía, el código para ya  mismo en producción es más importante que las pruebas y la calidad, hay roles que se fusionan y otros que aparecen, y la visión empresarial es débil o no existe, dejándose en manos de los equipos la responsabilidad de forjar un camino incierto a la deriva.

La solución a no tener un alto número de incompetentes en una futura empresa Ágil parece ser fácil de entender pero son muy pocas las organizaciones las que lo practican: dotar de competencias duras y blandas sobre Scrum, Lean y Ágil a aquellas personas que rodearán a los equipos o los evaluarán y abrir las puertas para que se vayan de la compañía los que no estén interesados en apoyar proactivamente la iniciativa o forma de pensar… y todo esto meses antes de comenzar a transitar el camino hacia la agilidad.

De lo contrario, tendrás un alto número de incompetentes dirigiendo, apoyando y ayudando a personas competentes, lo que aumentará la resistencia, rozamiento y no ayudará a consolidar el éxito de tu empresa.

Gracias por escucharme,
Erich.

Recuerda que puedes seguirme en Twitter @erichbuhler con mis pensamientos diarios sobre Scrum, disrupciones, Agilidad y organizaciones progresivas.

Cómo hacer un buen refinamiento en Scrum

Llevar adelante un excelente refinamiento en Scrum es parte de la clave para que la empresa pueda ser exitosa. Sin ello, la compañía derrochará un montón de dinero y hará que sus productos lleguen más tarde, perderá segmento de mercado, alargará los tiempos de desarrollo e impactará sobre la moral de sus equipos.

El refinamiento es una sesión clave en Scrum donde se clarifican ideas para que los miembros de la compañia o integrantes del equipo puedan tener una base consistente sobre un problema que está experimentado un cliente o una hipótesis que se tiene y se desea resolver o comprobar.
Existen 3 tipos de refinamiento:

  1. Aquellos que se realizan durante la incepción de un proyecto o en etapas tempranas para refinar los conceptos iniciales del producto
  2. Los que se realizan dentro del Sprint cada intervalos regulares o lo que llamo refinamientos periódicos del problema (qué)
  3. Los refinamientos esporádicos o refinamientos de la solución (cómo)

En éste artículo te explicaré los 2 últimos puntos, dejando la primera para algún momento, ya que pertenece más al comienzo de una iniciativa ágil en sí.

Existen varios escenarios que me he cruzado en distintas empresas, la primera es que no se realicen refinamientos, se deje para el último día o se haga dentro del Sprint Planning (Planeamiento del Sprint) como parte del mismo.
En general, ello es la consecuencia de que los equipos aduzcan no tener tiempo para poder hacer la sesión, se les quite su foco sobre las tareas diarias o no existan historias o problemas concretos a resolver hasta el día anterior a un Sprint Planning.

La situación anterior se da en empresas con Product Owners (Propietarios de Producto) con menos experiencia, organizaciones con poco conocimiento de agilidad donde se tienen mundos mixtos (un área Scrum y el resto de la empresa tradicional) o donde los equipos tienen presión interna o externa para llegar a una fecha de entrega.

En muchas ocasiones incluso los mismos miembros del equipo ejercen entre sí una presión social exacerbada para cumplir con la fecha estipulada, mientras que en otros casos es el propio Product Owner o la organización de donde provienen las señales. Lo importante aquí es identificar donde se origina cada una de ellas, ya que la aproximación será diferente en cada caso.

 

Refinamientos periódicos del problema

La sesión se realiza cada un intervalo regular de tiempo donde se analiza el problema/hipótesis presentada desde el punto de vista del QUÉ. ¿Qué es lo que el cliente quiere, qué problema se está tratando de resolver y cuando se considera resuelto?

Ten en cuenta que no hablamos durante ésta sesión sobre CÓMO se concretará a nivel técnico, ya que ello se dejará para el último minuto responsable, que es normalmente en la sesión Sprint Planning.

Una pregunta recurrente es cada cuanto hay que efectuar los refinamientos y cuál es su estructura.

Te pondré aquí varios ejemplos basados en mi experiencia:

  • Si Product Owner, equipo o empresa es nueva con agilidad y Scrum, 3 sesiones de 45 minutos máximo por semana de Sprint es una buena opción.

 

  • Si es un Product Owner y equipo experimentado que ha trabajado en conjunto con Scrum y sobre el mismo producto por un período de tiempo razonable y cuenta con excelencia técnica (integración continua, estándares de código, TDD, ATTD, excelente comunicación intra y inter equipos, etc.), se puede pensar en 2 sesiones a la semana de 30 minutos.

Es importante que tengas en cuenta que si bien los refinamientos son el momento donde se junta todo el equipo para centrarse en el qué de un problema, Product Owner deberá seguir refinando la pila (Backlog) de historias de Usuario durante el resto de su día y tiempo. De hecho, y para que sea eficiente, Product Owner requiere una dedicación mínima de 80% al equipo y producto. Al fin y al cabo, el éxito dependerá de la dedicación y  calidad de los refinamientos.

Esto último es normalmente difícil de negociar en organizaciones donde la mayor parte de la gestión se hace de forma tradicional o las personas están más preocupadas en subir la escalera corporativa que servir al equipo/producto.

Digamos que tenemos ya reservada la sala (¡Y sí! la mayor parte de empresas tienen problemas de espacio y disponibilidad de salas al comenzar con Scrum) y todo el equipo Scrum está dispuesto a reunirse esos días.

¿Qué debería pasar en la primera sesión?
Mi primera recomendación es que el equipo defina anteriormente sus reglas de etiqueta, esto es, que cosas serán aceptadas o no durante la sesión y ponerlas visible durante la reunión (ej. No teléfonos celulares o computadores a no ser emergencia familiar, todo el equipo junto, estar en hora, etc.)

Es recomendable también trabajar en un borrador de la definición de listo (Definition of Ready).Este es el acuerdo entre todas las partes a seguir a la hora de que  Product Owner y equipo de desarrolladores puedan considerar una historia de usuario lista para ser movida de refinamiento a candidata de ser comenzada en un Sprint.
Nadie quiere ni es saludable que aparezca sin previo aviso debajo de una manga una historia de usuario un minuto antes de comenzar un Sprint Planning. Ello bajaría la moral del equipo, destruiría la confianza y traería un número indeseable de efectos negativos en el corto y mediano plazo.

Aquí tienes un ejemplo de varios elementos de una definición de listo (DOR), pero pueden haber muchos otros:

  • La historia de usuario está bien definida
  • El criterio de aceptación se entiende y se comparte por todos
  • Las dependencias de alto nivel se conocen así como los riesgos
  • El equipo tiene una idea a alto nivel sobre la experiencia de usuario actual y deseable
  • La historia tiene un tamaño asignado
  • El equipo se siente  confortable que realmente lo que se está tratando de resolver es un problema para el cliente
  • Se han pasado por al menos 2 refinamientos de la historia antes de un Sprint Planning
  • (Opcional) Que la historia tenga un valor asignado de puntos de negocio (Cuánto vale la historia para la empresa y porqué)

Acuérdate de mantenerlo sencillo de no más de 5 o 6 puntos y empuja para que se mejore y simpliifique cada intervalos regulares de tiempo.

¿Qué debería pasar en el resto de sesiones?

En las sesiones posteriores Product Owner deberá presentar las historias de usuarios o sus ideas sobre qué es lo que se quiere solucionar, que le duele al usuario y como se lo haría más feliz. En mi experiencia, es siempre una buena aproximación que éste lleve todas las historias de usuario en fichas de papel y las pegue en la pared de forma visible. El hecho de utilizar una herramienta computacional (ej. Jira, Trello, version One, etc.) ocasiona un detenimiento para las interacciones sociales entre los miembros del equipo y otras personas invitadas a la sesión. Una tarjeta se puede rayar, mover, subrayar, romper, dibujar, y tiene un tamaño máximo donde escribir lo cual fuerza a mantener la “esencia” o simplicidad de lo que se desea resolver.

El Scrum Master es esencial aquí ya que deberá trabajar algunas horas o días antes para facilitar la sesión y que Product Owner tenga todo lo necesario en la sala así como las instrucciones sobre que se espera que brinde a la reunión.

Es importante que se ponga un tiempo fijo por historia (ej. 10 o 15 minutos) y el equipo se mueva a la próxima al finalizar el lapso estipulado. Ello asegura una cadencia y que no se entre en un agujero negro donde el equipo se centre durante toda la sesión en discutir una única historia.

Aquí nuevamente Scrum Master debería cronometrar el tiempo y observar si todos los integrantes participan por igual. Es muy común que alguno de los miembros haya sido Líder técnico antes de comenzar con Scrum y participe e influencie mucho más. En estos casos, recomiendo emplear el mapa de interacciones para balancear los diálogos y decisiones.

FotoRefinamiento

Recapitulando, no se habla de cosas técnicas, se focaliza en el problema a solucionar o hipótesis y la travesía de ese usuario concreto para conocer si se está presentando el problema/hipótesis adecuada y se está plasmando ella en una historia de usuario.

Se deberá analizar en a intervalos regulares si la historia cumple con la definición de listo (DOR) y de no ser así, ver que pasos serían necesarios para acercarse a ella.

Durante el proceso es recomendable también asignar un tamaño a la historia, para ello, con equipos nuevos es saludable el emplear la triangulación.

Este sistema es sencillo y se basa en elegir una de historia de referencia que sea clara para todo el equipo y no demasiado grande o pequeña y asignar números (puntos de historia) o tamaños de ropa (S, M, L, XS) basado en cuan más grande son las otras en comparación con esta.

En equipos con más experiencia quizás el dar tamaño no sea necesario, pero recuerda que es buena idea el comunicar al resto de la empresa que algo que se hará es muy grande o más bien pequeño.

Es también una buena opción que cada historia contenga puntos de negocio (Business Value Points), esto es, un  valor relativo de cuánto se piensa que vale para la compañía el no tener dicha historia disponible y que pasaria si se tuviese.

TAMAÑO: 8               Valor de negocio: 400

Cómo cliente de AutoParking deseo poder pagar por mi estacionamiento sin necesidad de tener que bajarme del coche

Criterio de aceptación:
– Que cubra al menos el 90% de los usuarios
– Que no lleve más de 1 minuto
– Que la persona pueda conocer el tiempo restante

Recuerda que aquí no se habla de cómo se hará técnicamente, sino que el foco estará exclusivamente en tratar de determinar la validez del problema o de la hipótesis, lo que se desea resolver, sus dependencias de alto nivel y riesgos.

Las dependencias se pueden documentar en cada tarjeta o incluso si ocurre entre dos o más de ellas, emplear un hilo para amarrarlas, flechas o cualquier otra técnica que deje clara la misma.

Algunos ejemplos de dependencias de alto nivel:

  • Personas a quien contactar para verificar la historia
  • Conocimiento de negocio a obtener
  • Información a verificar
  • Otras historias
  • Conocimiento de la aplicación
  • Trabajo de otros equipos que éste depende

Es normal que los equipos de software comiencen a tratar de resolver el problema (Cómo), por ejemplo, ver si se utilizará JavaScript, un servidor, el teléfono móvil, etc. pero es importante que comprendan que ello se abordará más adelante.
Scrum Master deberá estar atento para mantener el foco de la sesión para así asegurar que la solución técnica pueda estar abierta hasta el último momento responsable (cuando se comienza el Sprint). De lo contrario se estará congelando algo que podría ser obsoleto.
Abordar la solución técnica aquí trae muy posiblemente la pérdida de foco y el apadrinamiento de la solución, lo que conlleva a una menor flexibilidad. Esto se da cuando un sub-grupo brinda una solución y se siente orgulloso de haberla propuesto, lo que hace que sea más reacio a cambiarla posteriormente.

Muchas empresas a su vez crean el término Historia Técnica para poder hablar de trabajos técnicos/no funcionales durante los refinamientos. Éste término no existe, se debe llamar tarea técnica y no es tampoco aquí el momento de hacerlo. El objetivo de un refinamiento es alinear al equipo con el problema/hipótesis y conocer si éste es en realidad la raíz del asunto, ver las dependencias y establecer el clima para que se enfoque hacia la solución y conversaciones adecuadas.

Durante la sesión se van leyendo una a una las historias de usuario y se espera que el equipo sea honesto con respecto a si entiende la misma, está bien redactada, se siente confortable con el alcance, etc. Incluso se podrían invitar especialistas de negocio para realizarle preguntas o personas que brinden información relevante.

Si el equipo es nuevo, un coach o una persona con concimiento de redacción de historias de usuario podría ser necesaria en éste punto.

Existe también otro tipo de elemento que son comunes durante un refinamiento y son los llamados Spike (o picos). Ellos son tareas de investigación donde el resultado será información o conocimiento para poder tomar una o más decisiones, pero no se deben confundir con implementaciones técnicas que se consoliden como parte del producto.

“Conocer el número de personas que sería afectado si X no está”

“Saber si es posible usar JQuery con la aplicación de parking”

Ellas son también parte del refinamiento y es recomendable que cuenten con un criterio de aceptación. Recuerda que durante el Sprint, los Spike deberán tener un tiempo máximo de 4 a 6 horas.

Una vez finalizada la sesión, Producto Owner tomará notas y se volverá a repetir el proceso en la siguiente sesión. Se puede también obtener retro-alimentación de los asistentes en intervalor regulares para la mejora continua.
Recuerda que  todo el equipo es el dueño de la sesión de refinamiento y no algunos roles en particular.

 

Refinamientos esporádicos de la solución

Muchos equipos se preguntan cuando se hablará de la parte técnica, y ello conlleva a que exista mucho nerviosismo en ocasiones dentro del equipo de desarrollo. En principio, durante el planeamiento del Sprint o Sprint Planning, pero ello no es del todo cierto ni recomendado.

Es aquí donde los refinamientos esporádicos de la solución ocurren; ellos son esenciales y se debe tener un espacio y hábito para que se materialice.

La idea es que los miembros del equipo de forma casual/informal comiencen a conversar en su día a día sobre posibles soluciones, problemas e inconvenientes. Este es lo que llamo pláticas cruciales, lo que dista mucho de ser un planeamiento estructurado.

Pedro: Juan, ¿viste la historia X? Creo que JavaScript es una buena alternativa porque si lo usamos en la aplicación móvil de parking no habrían todos estos problemas…
Juan: Es cierto, pero no lo hemos utilizado nunca. Ahora que me acuerdo, Alfonso lo usó antes y tiene mucha pero mucha experiencia, hoy a la tarde podemos hablar con él, y si es así el tamaño de la historia bajaría y sería más fácil de hacerlo.
Pedro: ¡Excelenta! Hagámoslo y luego hablamos con el equipo.

Este tipo de refinamientos del “como” deberían existir día a día, lo que se traduce en conversaciones que hacen posible sintonizar y conectar a los miembros con una idea o hipótesis y sus posibles soluciones, así como también restricciones de conocimiento o tecnologías u otros riesgos. Esto también se puede traducir en charlas con otras áreas de la empresa, áreas de arquitectura, etc.

El equipo puede posteriormente brindar sus resultados durante el refinamiento programado siempre y cuando se traslade a posibles riesgos en vez de las soluciones técnicas en sí.

Cuando no se da lugar para éste tipo de refinamientos esporádicos, el equipo intentará hablar de la parte técnica durante el refinamiento programado o bien en la sesión de Sprint Planning, lo que hará que se convierta en interminable.

Finalmente, si más de un equipo trabaja sobre el mismo producto (Escalabilidad), alguno de los refinamientos programados deberían ser en conjunto o al menos contar con miembros de ambos equipos. Recuerda que ésto último no debería practicarse con equipos nuevos; empieza pequeño y luego crece.

Y recuerda, si necesitas conocer más sobre como potenciar equipos Scrum y Ágil dentro de tu empresa, o sobre mi último Libro sobre Agilidad empresarial (Leading Exponential Change), visita mi sitio Web.

Gracias por escucharme y suerte con tu próximo refinamiento,
Erich.

365 días, 365 ideas, disrupciones y experiencias sobre agilidad, Lean & Scrum

Hace ya varios meses que he comenzado con el desafío de compartir cada día 1 idea, disrupción o experiencia sobre Scrum, Lean, Agilidad y organizaciones de vanguardia entre otros.

Pensamiento

Puedes seguirme en en twitter @erichbuhler o Linkedin y recibir todos los días del año a las 12 del mediodía horario de Madrid, una micro-experiencia que te permitirá expandir tus horizontes, los de tu empresa y equipo.

Gracias por escucharme,
Erich.

Libro gratuito sobre trabajo en pares en equipos Scrum

El trabajo en pares sigue siendo un tema tabú en muchas organizaciones. Quiero dejarte el siguiente libro electrónico que te mostrará el resultado de alrededor de 70 investigaciones que se han llevado adelante en los últimos 20 años, sus efectos, beneficios y creencias.

TapaTrabajoEnParejas

Haz clic aquí para bajarlo

También puedes conocer sobre mi nuevo libro:

Haz clic aquí para saber más sobre el libro

Gracias por escucharme,
Erich.

La devaluación de la confianza… yo confío, tú confías, nadie confía

La confianza es el valor más buscado por las personas dentro y fuera de una organización pero el menos consistente. Puede ser un fenómeno disruptivo que cree innovación, equipos imparables y una empresa grandiosa, o derrumbarse en el aire en cuestión de horas como una casa de naipes.

A muchos les gustaría que existiese una fórmula lineal, pero no la hay; las promesas grandes pueden tener un impacto menor y aquellas pequeñas establecer puentes duraderos.

La confianza puede hacerte vulnerable y mostrarte como eres, construir ser tu reputación pero también ponerte en aprietos si no sabes decir “NO”.

La confianza puede es injusta… cuando un líder hace una promesa, quienes lo rodeen comenzarán a apilar ésta como parte de su reputación, pero  será tan delicada que cualquier cosa la corroerá

No puedes medir la confianza pero sí apreciar sus efectos, no puedes predecirla pero sí ayudar a que ello ocurra expresándote como un buen líder y empleando canales de confianza en cualquier decisión que desees comunicar.

La confianza es un principio devaluado, pocas empresas lo tienen como parte de sus valores aunque sean tradicionales, y si lo incluyen, no saben como gestionarlo.

Se necesita más que la integridad personal para construir una organización de personas que conformen un círculo virtuoso en donde ellas confíen y sean confiables.

Hay que construir habilidades, asegurarse que los altos cargos pongan especial atención en ello y se adquiera un conjunto de procesos inteligentes que la apoyen en todo momento.

La confianza dentro de una organización es mucho más complicada y frágil que entre la empresa y  cliente. Con el cliente es posible controlar en gran medida el flujo de comunicación, pero en la organización, habrá siempre un tsunami de bombardeos todos los días con mensajes de todo tipo, a menudo contradictorios.

Cuando se comienza el camino hacia la agilidad (a veces llamada transformación), las personas experimentarán objetivos diferentes, procesos distintos, la forma de interactuar cambiará, se volverá más social y ello hará que todo se tambalee por la constante fluctuación entre lo estable y el caos.

Si los empleados confían en los demás y particularmente en sus líderes, entonces serán capaces de trabajar y perfeccionarse aún bajo desacuerdo o estrés, lo harán más duro, estarán en la empresa por más tiempo, contribuirán honestamente con ideas innovadoras, se sentirán más seguros y mejorarán de forma continua. Cuando ello no exista y los lideres no prediquen con el ejemplo, todo ello se desvanecerá, la motivación bajará y los rumores serán parte de la moneda de intercambio del día a día.

En mi opinión, cualquiera debería preguntar en voz alta en los momentos donde se comunique algo que se sienta difuso… ¿Crees que lo que dices incrementará nuestra confianza? ¿Cómo podemos trabajar desde ya para que ello ocurra?

Quizá la palabra frágil la inventó alguien con la intención de explicar de que se trata la confianza cuando de una organización se habla.

Gracias por escucharme,
Erich.