Kanban dentro de Scrum

Hoy revisaremos una parte que aunque no está explicitada la utilización directamente en la guía de Scrum está implementada en la mayoría de los equipos que utilizan Scrum. Se trata del tablero Kanban , también conocido como el sitio donde los agilistas ponen los postit :)

Los tableros Kanban están muy extendidos y aceptado por los equipos Scrum siendo un elemento de transparencia e inspección que se convierte en una herramienta muy potente si sabes hacer uso de ella. Tenéis que tener en cuenta que el Kanban utilizado en Scrum es una versión reducida y adaptada con la intención de que los dos se complementen formando un tándem muy poderoso.  

Recordad que la unión hace la fuerza ( siempre que se tenga un objetivo común o un buen Sprint Goal 😛 )

Os dejo el link a la guía Kanban para Scrum.

Con la intención de engancharos a Kanban (desde la visión de Scrum) te resumo en unas líneas y de manera muy general los beneficios y mas abajo (para los mas cafeteros ) entro de manera mas técnica aportando datos:

Kanban ayuda en todos los eventos de Scrum, aportando motivos de conversaciones en la Daily para tomar consciencia del estado real del sprint. Aporta conocimiento sobre la capacidad de trabajo del equipo en la Planning. Ayuda al Producto Owner en la review quitando incertidumbre y poder estimar el alcance de la próxima entrega de valor. Entrega información para poder motivar al equipo con la mejora o encontrando los “pain points” en la retrospectiva para evolucionar en la mejora continua de todo el equipo Scrum.

Ahora sí, esta parte es mas técnica y la intención es en próximos posts explicaros que son cada una de las partes así como el funcionamiento del tablero.

Kanban en los diferentes eventos de Scrum:

  1. Sprint Planning
    1. Kanban ayuda entregando métricas del Flow de sprints anteriores y así ayuda a todo el equipo Scrum a entender su capacidad de trabajo, siendo este un valor clave para la planificación del siguiente Sprint.  ¿Cuánto valor podemos entregar en un Sprint?, ¿Cuántos PBI (Tareas, Historias de usuarios, casos de uso, etc…) podemos incorporar al Sprint Backlog?
  1. Daily Scrum
    • Es un gran generador de conversaciones sobre el estado real del trabajo involucrando a todos los Developers y haciéndoles reflexionar sobre el camino hacia el Sprint Goal.
  • ¿Cuantos ítems tenemos bloqueados y que podemos hacer para desbloquearlos? 
    • ¿Qué ítems están yendo mas lentos de lo esperado?
    • ¿Cuál es el “work ítem Age” de cada uno de los ítems?
    • ¿Están representados todos los estados en la tabla o es necesario algún nuevo estado que impacta en nuestro trabajo?
    • ¿Tenemos algún cuello de botella? ¿Cual es el impedimento? (WIP)
    • ¿Se cumple el SLE (Service level Expectation) o hay elementos que lo transgreden? ¿Qué se puede hacer para arreglarlo?
    • ¿Nuestro “cycle time” es el proyectado?

  1. Sprint Review
    • Las métricas pueden crear oportunidades de conversación y proveer de información adicional al Product Owner para priorización de Product Backlog así como para estimación de próximas entregas de valor.
  1. Retrospectiva
    • Las métricas aportadas sirven para motivar al equipo revisando la evolución del “average cycle of time” , “average througput” y del WIP del equipo utilizando el “cumulative flow diagram”).
    • Podemos definir mejoras en el tablero para mejorar en el entendimiento del equipo:
      • ¿es necesaria la utilización de “políticas”?
      • ¿Es necesaria la utilización de “Clases de servicio”?
    • Viendo la evolución de las métricas podemos saber si el equipo está en un estado de mejora.

Por hoy me despido y espero haber sido capaz de transmitir un poco de la potencia de Kanban.

Como siempre ¡sed curiosos! Y hasta pronto.

ADKAR – El camino del cambio I

El día de hoy vamos a tratar las necesidades que se producen dentro de una organización cuando se quiere producir un cambio y que pasos se deberían de seguir para poder lógralo con éxito. Para ello os traigo un modelo de gestión de cambio focalizado en las personas que forman las organizaciones, dado que son ellas las lo ejecutan o crean la resistencia en contra. 

Lo primero que nos propone el modelo ADKAR es que el cambio se trata de un proceso complejo y hay que tratarlo como tal (no como si se tratara de un evento), siendo por ello necesario detectar todos los estados por los que debe de atravesar cada persona de la organización. Una vez detectados estos estados es necesario saber qué métricas utilizar y cómo impactar en cada persona en función del estado en que se encuentre para que el cambio se produzca con éxito.

Creo que como introducción esto sería lo básico, ya que no pretendo aburriros entrando a fondo, por lo que paso directamente a explicaros los pasos del modelo.

  1. Awareness (Consciencia)
    • Es muy importante no solo conocer las razones por que la una compañía quiere introducir un cambio, si no que es igual de importante que las personas en las que queremos impactar tengan un conocimiento pleno de las motivaciones y los beneficios que esto les brindará.
    • En este punto la empresa debe de ser plenamente transparente y comunicar al máximo nivel con personas que generen una alta confianza en los impactados. 
    • Es necesario hacerles participes de las finanzas o los datos de relevancia que nos motivan como empresa al cambio y que por norma general ignoran o no tienen acceso. Este punto no es trivial, ya que nos servirá para poder controlar rumores o la difusión de falsas motivaciones. Además, creará un ambiente de pertenencia y de importancia dentro del cambio generado.
  1. Desire (Deseo)
    • En este paso se tiene que abordar el interés que tiene las personas que pertenece a la organización motivándolo para querer y formar parte del cambio. Si las personas no sienten el cambio como una manera de mejora es muy probable que no encaje en el nuevo modelo, pero si muchas personas no desean este cambio es muy probable que estemos ejecutando mal nuestra tarea, por lo cual el cambio puede fracasar.
    •  Es necesario tener en cuenta los factores que pueden crear deseo en cada uno de las personas tales como: Obtención de beneficios, necesidad de formar parte de algo, confianza en un líder que promueve el cambio, comienzo de una situación futura, comprender que el resto de alternativas no aportan valor, comprender el valor que el cambio aporta, etc…
  1. Knowledge (Conocimiento)
    • Es el momento de formar a todos las personas que tienen que realizar los cambios dentro de la empresa. Un punto muy importarte dado que tienen que sentirse capacitadas y seguras de que pueden realizar sus nuevas funciones.
    • Si es posible siempre es positivo tener una persona guía que aconseje y resuelva dudas que muy probablemente surgirán una vez estén realizando las nuevas tareas.
  1. Ability (Habilidad)
    • Cada persona tiene una curva de aprendizaje diferente y esto debe de ser tenido en cuenta dado que las personas no aprenden solo por indicaciones o por recibir una formación, es necesario que interioricen toda la información y llevarla a la práctica.
    • Será importante que no se centre toda la formación en un inicio y después no vuelva a impartirse, esto puede llevar a malas ejecuciones o incluso que existan personas que no sean capaces de realizar el cambio.
  1. Reinforcement (Refuerzo)
    • Este ultimo punto es muy importante y se tiende a olvidar. Es necesario consolidar el cambio y es por ello que debemos de establecer una estrategia de recuerdo y de retroalimentación para poder adaptar el cambio y que este se produzca de manera correcta.

Como antes os comentaba quiero tratar este punto solo como introducción y podemos profundizar en un segundo post, donde también os mostraré la herramienta de control que ADKAR propone y como debe utilizarse. 

¡Cuidaros mucho y nunca dejéis de ser curiosos! 🙂

Scrum vs Kanban

Hola de nuevo, volvemos otro día con una nueva píldora y hoy me voy a meter en un buen lío (yo solito). Voy a hablar de… Scrum vs Kanban a vista de pájaro (of course).

La intención que tengo no es explicar todo sobre ellos, ni mucho menos, pero sí intentaré que entiendas para qué se puede utilizar cada uno, ya que son para cosas muy distintas.


Como siempre ras i curt!


Scrum: 

Visualizamos cómo puede ser el producto y vamos entregando con control de tiempo y de manera iterativa un incremento utilizable (compuesto siempre de los elementos (pbi) del Product Backlog de más valor en ese momento). No estamos buscando entregar el producto final acabado al 100% si no que vamos aportando partes / funcionalidades que aportan valor en base al mercado (controlando PKIs de control) y siempre con el cliente final en el foco, lo cual puede hacer que nuestro producto sea muy diferente a lo proyectado pero que tenga siempre el mayor valor para el usuario final.

Podemos decir que Scrum abraza y acepta la incertidumbre y nos entrega reglas para poder ir despejándola aportando además control sobre cuándo y qué partes del producto van a ser entregadas. También como resumen os escribo los pilares de Scrum (lo que dicen mucho de él) Transparencia, Inspección y Adaptación (siempre desde el empirismo).

Kanban: 

Busca visualizar todos los estados por los que tiene que pasar el valor o producto, para poder visualizar la información de lo que se está realizando en todo momento.

La intención es tener una transparencia total del proceso y poder mejorarlo haciéndolo más fluido (bajar el Lead Time), siendo una herramienta muy buena de detección de “cuellos de botella” y de ajuste de los mismos.  

En este aspecto Kanban busca la mejora en la producción y no la mejora en el producto ya que este está definido de inicio. 

Es una herramienta muy pero que muy versátil y puedes establecer priorización de tareas introduciéndolas en carriles, saber estados de carga de trabajo de personas o de equipos, limitar el número de tareas que hay en un determinado punto del proceso (valores máximos o mínimos y definir reglas que se aplicarán cuando se llegue a estos valores), mezclar varias métricas, etc… Es por ello que Kanban es muy poderoso.


Be smart!

Por regla general y creo yo que de manera muy inteligente, dentro de los equipos de desarrollo de Scrum se utilizan los tableros Kanban durante el Sprint (aunque creo que Kanban es «ese gran desconocido») ya que uniendo estas dos poderosas herramientas obtienes un pack inmejorable de transparencia y mejora continua.

El equipo utilizando Kanban puede controlar de muy buena manera el estado del Sprint Backlog (el trabajo que tienen pendiente de acabar dentro de ese Sprint) además de saber todo lo que hay en proceso para poder controlar las dependencias.

Pues hasta aquí la chapa del día de hoy 🙂 y espero que os sea muy muy útil.

Saludos y ¡hasta muy pronto!

SCRUM – 2020 NEW GUIDE

¡Hola a todos!

Hoy os traigo novedades importantes en SCRUM dado que la nueva guía que salió a la luz en  Noviembre 2020 y que fue modificada por los cocreadores de SCRUM, Ken Schwaber y Jeff Sutherland, ya ha entrado en vigor para todas las nuevas certificaciones, invalidando de esta manera la guía del 2017. 

Os dejo aquí el link de descarga a la nueva guía para que podáis revisarla. (¡no seáis vagos!)

Vamos a ver los cambios más sustanciales que he podido encontrar en una primera lectura (os daré mas información cuando la revise a fondo) y más abajo los cambios que remarcan dentro de la propia guía como importantes (ojo que no son los únicos).

Ya sabéis que, como siempre, para las certificaciones debéis revisar además de la guía los blogs de scrum.org, que aparte de ser muy interesantes, también sé extrae de allí información muy válida que puede aparecer dentro de los exámenes de certificación.

Pues sin entreteneros más, os dejo con lo prometido.

¡Hasta pronto! 🙂

Cambios entre las versiones 2017 y 2020 en una primera revisión:

Introducción de LEAN con la nueva descripción de Scrum: Scrum se basa en el emprimo y en el pensamiento Lean. El emprimo afirma que el conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se observa. El pensamiento ajustado reduce los residuos y se centra en lo esencial.

Nuevos elementos dentro de SCRUM Compromisos: 

Se formalizan de la siguiente manera:
1. Para el trabajo pendiente del producto (Product backlog) es el objetivo del producto (Product Goal).
2. Para el Sprint Backlog es el Sprint Goal.
3. Para el Incremento es la Definición de Hecho.
Estos compromisos existen para reforzar el empirismo y los valores de Scrum para el equipo de Scrum y sus partes interesadas.

Liberación del incremento:

Este puede ser entregado/liberado antes del final del Sprint.

Sprint Planing:

Tiene una guía de trabajo y añade un nuevo topic a la reunión.
1. * ¿Por qué este Sprint es valioso?
2. ¿Qué se puede hacer este Sprint?
3. ¿Cómo se realizará el trabajo elegido?

Sprint Review:

1. Desaparece el guión especificado en la guía 2017

Equipo Scrum: 

1. Muy importante, cambia de entre 3 – 9 personas a 10 personas o menos

Cambios entre las versiones 2017 y 2020 de la Guía Scrum:

Aún menos prescriptivo

Con los años, la Guía Scrum se volvió cada vez más prescriptiva. La versión 2020 pretende que Scrum sea un marco mínimamente válido y suficiente, eliminando o suavizando su lenguaje prescriptivo. Por ejemplo, las preguntas se han eliminado del Daily Scrum, se ha suavizado el idioma relacionado con los atributos del elemento de trabajo pendiente del producto (Product Backlog), se ha suavizado el lenguaje relacionado con los elementos de la Retrospectiva para añadirlo al trabajo pendiente de sprint (Sprint Backlog) y se ha acortado la sección de cancelación de sprint, entre otros.

Un equipo, centrado en un producto

El objetivo era eliminar el concepto de un equipo independiente, lo que ha dado lugar a comportamientos de «proxy» o «nosotros y ellos» entre el propietario del producto (Product Owner) y el equipo de desarrollo. Ahora solo hay un equipo de Scrum centrado en el mismo objetivo, con tres categorías de responsabilidades: Product Owner, Scrum Master y Development Team (Desarrolladores).

Presentación del objetivo del producto

La Guía Scrum 2020 introduce el concepto de Objetivo de Producto, con la finalidad de permitir que el Equipo de Scrum se centre en un objetivo más grande y con más valor. Cada Sprint debe acercar el producto al objetivo de este.

Un espacio para el objetivo de Sprint, la definición de hecho y el objetivo del producto

Las guías anteriores de Scrum describieron el propósito del producto y la definición de hecho, (Definition of Done) sin reconocer realmente su identidad. No eran artefactos, pero estaban asociados con él de alguna manera. Con la inclusión del objetivo del producto, la versión 2020 proporciona más claridad a este respecto. Cada uno de los tres artefactos ahora contiene «compromisos» asociados. Para el trabajo pendiente del producto (Product Backlog), existe el objetivo del producto. El Sprint Backlog tiene como objetivo el Sprint, y el incremento tiene la definición de hecho (ahora sin comillas). Todos ellos existen para proporcionar transparencia y centrarse en el progreso de cada artefacto.

Autogestión en lugar de auto-organización

Las Guías Scrum anteriores se referían a los equipos de desarrollo como autoorganizados, eligiendo quién hizo el trabajo y cómo se hizo. La versión de 2020 presta más atención al equipo de Scrum, y hace hincapié en un equipo autogestionado de Scrum, que selecciona quién, cómo y dónde trabajar.

Tres temas en la planificación del sprint

La Guía Scrum 2020 añade y enfatiza un tercer tema «Por qué» en referencia al Objetivo del Sprint, más allá de los «Qué» y «Cómo» existentes.

Simplificación general del lenguaje para un público más amplio

La Guía Scrum 2020 ha hecho hincapié en la eliminación de frases redundantes y complejas, así como en la supresión de las influencias restantes en el mundo de las TIC (por ejemplo, pruebas, sistemas, diseños, requisitos, etc.). La Guía de Scrum 2020 ahora tiene menos de 13 páginas.

Pista: ¿Has seguido el link musical? 😛

S.C.A.M.P.E.R

Hola a todos de nuevo, hoy regresamos con otra pequeña píldora.

En esta ocasión se trata de una píldora que os puede ayudar en la ideación cuando llegamos a ese estado en el que todo está tapado por una gran niebla y no hay manera de avanzar hacia ninguna dirección.

Es un método que nos ayuda a pensar “out of the box” dándonos una guía para la ideación. Recordad que idear es una metodología y no magia 🙂  

Al lío que quiero que sea cortito:

SCAMPER es el acrónimo de:

Substitute, Combine, Adapt, Modify, Putt in other uses, Eliminate y Reverse.

El método es bastante sencillo de aplicar, ya sea en grupo (preferible) o de manera individual, ya que se trata de ir aplicando al reto definido preguntas sobre los conceptos que nos aporta SCAMPER. 

Es muy importante tener siempre en cuenta la sencilla regla de NO poner limites a los planteamientos y nunca descartarlos de entrada por muy locos que parezcan. 

Recordad que en Desing Thinking primero hay que divergir para luego poder converger.

Os dejo a continuación unas preguntas a modo de ejemplo sobre diferentes temas:

Substitute: ¿Podemos sustituir una parte para reducir costes?, ¿Podemos sustituir el material para que sea más resistente?, ¿Podemos sustituir el método de comunicación con los clientes?, ¿Podemos sustituir la subcontrata? ¿Podemos sustituir el cliente?

Combine: ¿Podemos unificar productos para poder obtener mas valor para el cliente?, ¿Podemos combinar áreas de la empresa para aumentar la productividad?, ¿Podemos combinar equipos para ser mas eficientes?, ¿Puede mi producto integrarse con un tercero para ganar valor?

Adapt: ¿Cómo podemos adaptar el producto a un target concreto?, ¿El proceso actual de venta es el más eficiente o se puede llegar directo al cliente con publicidad?, ¿Qué canales de publicidad hay disponibles?, ¿Debo adaptarme a otro circuito de publicidad?, ¿Cómo puedo adaptar el framework que utiliza X empresa a la mía?, ¿Puedo adaptar mi producto para que cumpla X función? (Sustituya la X por lo que más le guste 😛 )

Modify: ¿Puede mi producto satisfacer otras necesidades?, ¿Puedo modificar mis canales de comunicación internos para que los equipos sean mas transparentes?, ¿Qué parte de mi producto puedo modificar para que tenga un mayor valor?

Putt in other uses: ¿En qué otro contexto mi producto puede aportar valor?

Eliminate: ¿Se pueden eliminar procesos en la creación del producto?, ¿Se pueden eliminar procesos en la gestión interna?, ¿Se puede eliminar una parte del producto sin que este pierda valor?, ¿Se puede eliminar una parte del producto en el que tiene bajo valor, pero alto coste? 

Reverse: ¿El proceso de creación es el correcto? ¿El espacio de los equipos es el correcto o se necesita otra distribución? ¿Nuestro producto está bien ordenado o debemos cambiar como se presenta? ¿Podemos cambiar el flujo de facturación?

Espero que os pueda ayudar y recordad que la práctica hace al maestro… No tengáis prisa ni os frutéis si en un principio os parece complicado.

¡Feliz año a todos y nunca dejéis de ser curiosos!

DISEÑO DE PRODUCTO – 1

Para poder diseñar un producto se deben de tener encuesta muchas consideraciones, en esto creo que estamos todos de acuerdo, pero si intentamos aterrizar y llegar a la parte nuclear del diseño de producto creo que hay tres factores principales (tres grandes épicas) que engloban al resto:

En realidad estas tres preguntas son tres grandes KPI que se tienen que tener muy presentes ya no solo en la ideación del producto, si no en todas y cada una de las iteraciones, nos ayudará a tener una correcta visión y que los incrementos estén orientados hacia el sitio correcto.

Voy a tratar de explicar cada una de ellas y poner algún ejemplo para entender el motivo de la unión de las tres.

¿QUÉ?:

Esta es siempre la primera de las preguntas que todos los planteamos a la hora de idear nuestro producto / servicio.
He detectado una necesidad/problema en el mercado y la quiero resolver/explotar.
En este punto hay que tener muy en cuenta si nuestro producto es deseable y por quién es deseable la solución que aportaremos (siempre tenemos que solucionar, no crear nuevos problemas). Creo que para poder entenderlo de manera correcta, es necesario mencionar a Geoffrey A. Moore.

En su libro CRUZANDO EL ABISMO, que si no lo conocéis deberíais de hacerlo, se relata los diferentes tipo de consumidores y cómo estos entienden los productos que se lanzan al mercado. Un posible resumen es: «Como vender productos disruptivos a consumidores generalistas y no morir en el intento».

Es un pilar básico entender a quién y cual es nuestro target dado que puede que no llegues a cruzar el abismo que separan a los innovadores y los adaptadores tempranos de la mayoría temprana y de allí a la tardía, por lo que el producto no prosperará dado que es en estos dos últimos tipos de consumidores donde realmente está el pastel.
En otras palabras, puede que vendas tu producto de manera imparable en un principio a gente que no le da miedo enfrentarse con un producto nuevo, incluso que les encanta tener que hacerlo y creas que tu producto está totalmente aceptado, maduro y que le gusta a todo el mundo (seguro que no estás revisando los KPI correctos), si llegas a este caso, lo siento pero estás destinado al fracaso.

¿Cómo?:

Llegamos a la segunda pregunta una vez ya tenemos claro que queremos hacer y a quién se lo podemos vender.

1. ¿Es factible poder desarrollarlo?
2. ¿Tendrá la suficiente viabilidad para que sea sostenible en el tiempo?
3. ¿Podemos hacer que realmente funcione?

Está claro que debemos ser ambiciosos cuando comenzamos a crear un producto, pero hay que tener muy claro que es posible y que no es posible crear, no solo si se dispone de la tecnología necesaria, también el talento dentro de nuestro equipo, la capacidad económica y lo mas importante, poder realizar un producto que tenga la calidad deseada y que podamos continuar desarrollando el producto sin perderla.

Debemos recordad que en la sociedad actual es la sociedad de la información y el cliente está empoderado. Su opinión ya no está únicamente en su circulo próximo si no que está reflejada en los puntos de venta finales. Esta información es utilizada por muchos otros posibles compradores / usuarios para poder descartar productos, por lo cual es muy importante que entreguemos lo que decimos que entregamos y con la calidad que estamos vendiendo ya que es el propio cliente el que juzgará si esta es la adecuada o no , si no lo es, aunque tengamos la mejor idea del mundo jamas cruzará el abismo.

Para muestra un botón de lo que NO queremos que pase:

¿Cuando?:

T2M (Time to Market) Para poder ayudaros a entender la magnitud de esta pregunta, abajo podéis encontrar unas cuantas preguntas que surgen de la primera:

1. ¿Está el mercado preparado para asumir el producto?
2. ¿Está el mercado pidiendo este producto?
3. ¿Tengo la capacidad de realizar la entrega de producto que estimo me demandarán?
4. ¿Qué capacidad tengo de aprender y de adaptarme al mercado?

Todos conocemos casos de productos que simplemente llegaron demasiado pronto o demasiado tarde, que estaban en el sitio y su visión sobre su propio producto dejó de tener en cuenta que estaba pasando en el mercado realmente y cayeron hasta desaparecer.

Sobre esto tenemos varios ejemplos:
1. Google Glasses – Llegaron demasiado pronto, pero volverán.
2. Blackberry – Pensaron que los smartPhones serían un fracaso y no pivotaron.
3. LaserDisc HD-DVD – Se encontraron con el streaming.

Ahora que ya sabemos más o menos por dónde comenzar será necesario saber cómo tenemos que relacionas las tres principales épicas para poder sacar un producto que sea competitivo, pero eso lo dejaremos para más adelante.

César.

AGILIDAD VS CASCADA – 1

Seguimos con esta pequeña guía hacia la agilidad y creo que lo siguiente que es necesario conocer, antes de entrar mas a fondo en el manifieste ágil, es que diferencias hay entre crear un producto de manera ágil y crearlo de la manera «tradicional» o en cascada.

Lo primero que tengo que decir es que la manera de crear en casaca no es el lado oscuro (aunque seguro que en algún post lo digo 🙂 ) y no tenemos que cambiar de repente todos hacia la agilidad y utilizarla en todos los proyectos que desarrollemos, ya que no siempre será posible, aunque por otro lado, no siempre hay que quedarse en waterfall ya y pensar que la agilidad «es un invento» ya que está mas que demostrado que funciona.

Venga que si no comienzo esto será larguísimo:

Cascada: Lo que todos conocemos «Quiero tal cosa de esta manera y la quiero para el día tal. Por cierto si te atrasas te tendré que penalizar y tu alma será mía» (la parte en cursiva la puedes cambiar por lo que quieras, pero que sea doloroso 😛 ).

Para poder completar esta tarea desde el inicio debemos de saber todos los requisitos del proyecto antes de comenzar para diseñar el producto final y completo.

Necesitamos, como he dicho antes, tener todos los requerimientos especificados, crear un calendario con unos hitos bien marcados sabiendo todas las dependencias entre ellos, tener un contrato en el que ambas partes estén de acuerdo en todo lo que se tiene que crear y sobre todo cumplir con lo que se ha firmado (aunque veamos que faltan o sobran cosas) y es muy importante cumplir con el contrato para no caer en penalizaciones y en caso que existan problemas poder defendernos. En este caso no estaremos cooperando con el cliente que realiza el encargo.

Es decir, una vez se ha pensado el producto final, este no acepta modificaciones ya que se ha especificado de manera muy clara en un principio y por norma general todas las modificaciones que se tenga que realizar implican un coste extra para el cliente.

Agilidad: Aquí la cosa cambia «Tengo una idea que quiero se convierta en realidad, pero no sé seguro al 100% que es lo que el «Stakeholder» ( usuario final que utilizará el producto, entre otros) querrá que implementemos primero o que le parecerá más interesante.

Vemos que hay un cambio importante por parte del cliente stakeholder (en este caso quien tiene la idea y quiere realizarla), asume que existe una incertidumbre sobre el producto y que no puede predecir en que acabará convirtiéndose, sabiendo que la única manera de descubrirlo es observar a los usuarios finales (otros Stakeholders), saber como ellos tratan el producto, que partes utilizan y como lo hacen. Este es un punto importante ya que aunque los usuarios finales no lo sepan, se les acaba de convertir en una parte muy importante de desarrollo del producto.

Para poder completar la tarea debemos de tener claro cual es la visión y cuales son los requisitos, pero en este caso no para poder diseñar el producto final, si no para poder diseñar un MVP (Minimum viable product) (mas adelante revisaremos metodología para poder alcanzar este MVP) es decir que es lo mínimo que podemos construir para poder lanzar el producto al mercado y recibir feeback de los usuarios finales o stakeholders (en este caso los que utilizarán el producto).

Para poder recibir el feedback es muy importante determinar cuales son los KPI que queremos tener en consideración ya que estos son vitales, ya que son la clave que nos ayuda a despejar incertidumbre sobre el producto y poder predecir con mayor grado de fiabilidad que será valor y que debemos desarrollar en próxima iteración.

Sobre este punto hay que abrir la mente ya que no siempre el único KPI debe ser el retorno de la inversión, puede ser que nos interese la valoración de la experiencia de uso de los stakeholders (en este caso clientes finales), o cuantos de estos stakeholders han modificado sus hábitos gracias a nuestro producto, numero de stakeholders que lo utilizan, si ha mejorado la sensación de calidad de los stakeholders, cuanto pensamos que podemos evolucionar el producto, etc…

Otra de las grandes diferencias que cabe destacar y que es muy diferencial entre agile y waterfall es cuando comienza el retorno de la inversión.

Se puede decir que en waterfall no se recibe retorno hasta la puesta en marcha del producto, ya que hasta ese momento los usuarios no tienen posibilidad de uso dado que el producto no es alcanzable para ellos. también se debe de tener en consideración que una vez lanzado será «doloroso» realizar cambios en el producto en caso que detectemos que los usuarios finales reclamen o no utilicen partes, ya que se ha utilizado el presupuesto para desarrollar un producto finalizado completamente y puede que no acertáramos al 100% en todo lo que pensamos inicialmente.

Diseño VS Experiencia de usuario

Por otro lado en agilidad, se intenta comenzar a tener retorno lo mas temprano posible, por eso se crea el MVP, con la ventaja que podemos ir conduciendo la creación de nuestro producto con cada iteración que realizamos para aumentar el retorno a la vez que potenciamos los puntos que mejor aceptación tienen, creando un producto «a medida» de nuestros consumidores.

Camino hacia la Diana

Pues nada, que como se dice … hasta aquí puedo leer … Seguiremos mas adelante y que creo que si has llegado a leer hasta aquí te mereces un descanso y una buena cerveza 🙂

Saludos y cuidaros todos mucho!!!

MANIFIESTO ÁGIL

A petición de algunos de vosotros os iré lanzando algunas pequeñas píldoras de #agile, Intención: ver si os puedo convencer y convertiros también en belivers ?. (Ya sabéis que me encanta explicar cosas) Para comenzar el famoso MANIFIESTO ÁGIL, que parece poca cosa, pero visto desde una empresa “clasica” puede ser un verdadero dolor de cabeza.

  1. Individuos e interacciones sobre procesos y herramientas
  2. Funcionando sobre documentación extensiva
  3. Colaboración con el cliente sobre negociación contractual
  4. Respuesta ante el cambio sobre seguir un plan

Para entender el manifiesto hay que comprender que todo lo que está situado a la derecha de las frases es importante, pero tiene más valor todo lo situado a la izquierda. Esta manera de ver el manifiesto es para remarcar que “nos gusta que los planes salgan bien” y es por ello que tenemos que enfocarnos en que necesitan las personas, trabajar con personas; Si tenemos que fallar hay que hacerlo rápido y barato para pivotar; Entregar un producto viable en el menor tiempo posible para que este comience a producir valor; Convertirnos en un equipo junto con el cliente (win-win) y que el equipo esté abierto al T2M y las modificaciones.