Las historias de usuario son una técniva transversal en los entornos que se basan en los principio ágiles y/o lean. Se trata de una técnica que nos permite definir aquellas necesidades de un usuario y que debemos incorporar a nuestro producto. Se centran en la aportación de valor hacia el usuario y no en qué debemos hacer con largas listas de tareas.
Utilizar correctamete las historias de usuario nos aleja y sustituye aquellos pesados documentos de casos de uso y otros diagramas UML que definen una larga lista de requisitos. El model tradicional de requisitos no situa en un marco de definir todo antes de empezar el proyecto y desear que una vez terminado de desarrollar el usuario quede satisfecho a nivel de funcionalidad y experiencia. La experiencia nos respite una y otra vez que no debemos seguir bajo los patrones tradicionales cuando desarrollamos software.
En este post relacionaremos las ventajas que nos ofrecen utilizar historias de usuario y cuanto nos acercan a los principios destacados del Manifiesto Ágil. Una primera valoración es recordar que puntos los firmantes del manifiesto aseguran haber aprendido a valorar (entre paréntesis cuanto nos acerca a esta idea las historias de usuario):
Un truco que acudo recurrentemente con el paso del tiempo es la lectura del Manifiesto Ágil. Lo utilizo para abrir un espacio de reflexión a través de sus palabras, que sirven de guía espiritual entre la agilidad y las fuerzas de la oscuridad.
Si hace tiempo que no lees el Manifiesto Ágil (y especialmente si eres de aquellos que promueven la agilidad dentro de un entorno, utilizas muchos post-its y nunca has leído, y reflexionado sobre, el Manfiesto por el Desarrollo Ágil de Software) te recomiendo que accedas a él antes de seguir con este post. Son 3 minutos de lectura!
El conocido cofundador de Linkedin y anteriormente miembro del equipo de Paypal, Reid Hoffman, tiene las ideas muy claras acerca cuando es preciso lanzar un nuevo producto al mercado. En concreto tiene muy claro cuando sería demasiado tarde y en este sentido un grave error.
Si no te averguenzas de tu primer producto, es que lo lanzaste muy tarde.
Estamos ante una visión completamente lean y, al ser muy fácil de recordar, tenerla gravada en la mente, especialmente si eres product owner o vives muy de cerca el producto. Dos apreciaciones (una sobre la propuesta de valor y otra sobre el equipo) le sirven para dar forma a la idea y tener una línea clara de camino a seguir en las decisiones importantes.
Sobre la propuesta de valor Reid Hoffman argumenta que no se debe tener una fe ciega, o demasiado ciega, en las hipótesis propias. Es normal tener una tendencia hacia la consideración de que tenemos entre manos un buen producto. Aún así, aún teniendo un buen producto 10 veces mejor que las soluciones de mercado, es indispensable contar con una buena red de distribución. Para ganar la partida el producto debe ser accesible a todos su posibles usuarios.
Acerca del equipo Reid Hoffman nos dice que el mayor propósito de un equipo es entregar rápido y entregar a menudo. Para conseguir este objetivo está convencido que se necesita un equipo rápido y dinámico y sobretodo que aprenda deprisa. Rodearnos de personas con una alta capacidad de aprendizaje va mucho más allá de las capacidades de base técnica nos acercará al objetivo máximo del equipo: entregar rápido y entregar a menudo.
Si te interesa profundizar en las ideas de Reid Hoffman os recomiendo el libro The Start-up of You. Es un libro donde, gracias a su experiencia y trayectora, da un conjunto de consejos y advertencias para emprendedores.
Para considerarnos un entorno ágil debemos alejarnos completamente del decadente modelo de ciclo de vida en cascada. En acción y pensamiento. Una ejecución ordenada, unitaria y dividida en fases con un enfoque a proyecto no tiene lugar en un entorno ágil. La transformación ágil se hace de raíz o no es real ni satisfactoria, solo puro maquillaje.
El ciclo de vida en cascada en un modelo guiado por las fases de requisitos, análisis, diseño, desarrollo pruebas... Cada una de estas fases se realizan, teóricamente porqué no hay errores ni cambios, sólo una vez. Solo se empieza una fase cuando se ha terminado justo la anterior. La realidad nos asegura que los requisitos cambian con el transcurso del tiempo y que el uso del producto genera el mejor feedback para cambios y nuevas funcionalidades.
El enfoque de desarrollo iterativo e incremental de software nos permite cambiar de modelo de ciclo de vida. Este enfoque funciona a la perfección con la técnica de historias de usuario y nos permite alinear la visión de todo el equipo, sean cuales sean sus capacidades o responsabilidades.
El desarrollo iterativo e incremental se centra en que el software debe estar lo antes posible funcionando. Una vez que lo usan los usuarios realizar pequeñas iteraciones que permitan mejorar de forma constante la experiencia de usuario con la aportación de mejoras en el producto o nuevas funcionalidades necesarias con el uso del producto. Con el paso del tiempo el software debe estar siempre funcionando.
Agregar una funcionalidad nueva la entendemos como un desarrollo incremental. Estos tipos de desarrollos normalmente van asociados a un nuevo módulo del producto. Mejorar las funcionalidades existentes forman parte de los desarrollos iterativos. Bajo la idea anterior, entregar pronto y frecuentemente, el equipo dedica mayoritariamente su tiempo a desarrollos iterativos.
En noviembre de 2017 ya escribí un post acerca del ciclo de vida de desarrollo iterativo y como se relaciona con el concepto lean de Mínimo Producto Viable y como nos pueden ayudar frameworks ágiles como scrum.
Las historias de usuario forman parte del grupo de responsabilidades del product owner del equipo. Las historias de usuario se acumulan y priorizan en el product backlog y nos asegura que el equipo tendrá una conversación sobre la misma. Necesitamos considerar una historia de usuario como una promesa de que vamos a tener como equipo una conversación.
A continuación veremos tres casos típicos en los que los equipos caen y no aprovechan así el impulso que proporciona un uso satisfactoria las historias de usuarios.
Las historias de usuario no definen el cómo se debe realizar sino qué necesita el usuario con el uso del producto. Aquí nace el primer problema más habitual: un product backlog lleno de tareas. Las tareas en el backlog nos genera una larga lista de cosas a hacer sin poder identificar el valor que aportan al usuario. Complica la priorización y limita la libertad de pensamiento para realizar soluciones efectivas de forma más rápida.
Un backlog lleno de tareas nos maquilla de ágil un ciclo de vida en cascada.
La ventaja de las historias de usuario frente a las tareas es que las historias de usuario son end to end. Una vez se a terminado una historia de usuario es claro el valor que se ha aportado al cliente.
Entornos que están empezando la transformación ágil suelen caer en el recurso de definir historias épicas. Un product owner que trabaje con historias de usuario demasiado largas o épicas actúa contra el principio ágil de entregar frecuentemente nuevo software funcionando.
El uso de épicas hacen que los equipo vayan más lentos, entreguen más tarde y menos a menduo.
Curiosamente también en noviembre, pero del 2018, confeccioné este perqueño manual con las mejores estrategias para dividir las historias de usuario. Seguir estas recomendaciones nos permite aprovechar los beneficios de escribir buenas historias de usuario, ser más rápidos y aportar más valor al usuario.
Los males típicos de los modelos en cascada y de los problemas anteriormente mencionados nos deja en todos los casos con una deuda técnica con la que (sobre)vivir. La deuda técnica normalmente se va acumulando debido a decisiones que se toman ante retrasos o errores en el software.
La deuda técnica es 100% responsabilidad de los desarrolladores implicados.
De quién será sino? Aceptar esta responsabilidad es el primer paso para actuar sobre la deuda técnica. Cuanto antes empieces, antes mejorará tu vida. La deuda técnica se genera con decisiones que comrpometen la viabilidad del producto a largo plazo. Escuchar sobre una supuesta y deseada V2 (versión 2) o oir voces que defienden rehacerlo todo de cero, es realmente escuchar excusas y falsos razonamientos que permiten que uno se sienta mejora y siga perpetuando los mismos problemas de siempre.
En agosto de 2018 profundicé en la reación entre scrum y la lucha contra la deuda técnica en un post que te recomiendo su lectura. Es precisamente un análisis de las causas de la deuda técnica, una reflexión soble la responsabilidad sobre la deuda técnica y un enfoque de como ayudarse de los frameworks ágiles nos ayudarán a empezaar solucionar.
El propósito de cualquier desarrollador o cualquier equipo creador de productos digitales, sea cual sea la disciplina de cada miembro, es la entrega rápida de nuevas versiones que permitan avanzar en prestaciones con el software siempre funcionando.
Cada entrega debe aportar valor. Debemos entregar pronto y frecuente.
El ciclo de vida iterativo e incremental junto a la técnica de las historias de usuario por parte del product owner promueve el principio del manifiesto ágil de la entrega rápida de nuevas versiones. Trabajar en espacios cortos de tiempo y entregando valor end to end al usuario en cada uno de estos espacios nos permite combatir hasta eliminar las debilidades del modelo cascada.
Debemos aceptar que los requisitos cambian y cambiarán con el paso del tiempo. Esta limitación no nos debe generar frustación como equipo sino que debemos transformarlo en una ventaja competitiva que nos permita ofrecer una mejor experiencia de usuario.
Unir el desarrollo iterativo e incremental, la creación de Mínimos Productos Viables y la creación de valor con historias de usuario nos acerca a poder entregar más pronto y más a menudo. Destacamos estos principios del Manifiesto Ágil para relacionar las ideas comentadas:
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>En el mundo agile es típico oír y decir que el Product Owner es el responsable del valor dentro del equipo. Aportar valor a los usuarios o clientes es nuestra única razón de ser.
El diseño de la propuesta de valor no es un proceso fácil y necesitamos definir y probar múltiples propuestas de valor. Se trata de una búsqueda iterativa con el objetivo de descubrir qué es lo que esperan los clientes de nosotros.
El diseño de la propuesta de valor es un proceso interminable que debemos ajustar constantemente para que sea relevante para nuestros clientes.
Las empresas necesitan encapsular su propuesta de valor bajo un modelo de negocio viable, con el fin de capturar este valor. Las propuestas de valor se basan en un conjunto de productos y servicios que crean valor para los clientes.
Los segmentos de clientes son aquellos grupos de personas u organizaciones a los que cómo empresa aspiramos a llegar, creando valor con una propuesta específica.
Para llegar a estos segmentos de clientes se necesitan describir los canales donde se comunicará y ofrecerá la propuesta de valor a un segmento de clientes. Estos canales hacen referencia a la comunicación, distribución y venta.
Si quieres aprofundizar en el diseño de propuestas de valor o aprender a crear los productos y servicios que tus clientes están esperando te recomiendo la lectura práctica de Diseñando la propuesta de valor de Alexander Osterwalder, Yves Pigneur, Gregory Bernarda y Alan Smith.
El mapa de valor nos sirve para describir de la forma más estructurada y detallada posible las características de la propuesta de valor específica de un segmento de clientes de nuestro modelo de negocio.
En el mapa de valor desglosamos los siguientes puntos:
Entre los errores más comunes en el momento de confeccionar nuestro mapa de valor podemos destacar:
Los frameworks ágiles y las técnicas Lean recomiendan trabajar la propuesta de valor bajo el enfoque del mínimo producto viable. Si quieres conocer los errores más típicos en la definición del mínimo producto viable te recomendamos la elctura de este post.
El perfil del segmento de cliente describe de la manera más estructurada y detallada posible un segmento de clientes específico de nuestro modelo de negocio.
Los errores más comunes para identificar trabajos, frustaciones y alegrías son:
Encontramos el encaje de nuestra propuesta de valor cuando el mapa de valor coincide con el perfil de nuestro segmento de cliente. Cuando nuestros productos y servicios generan aliviadores de frustaciones y creadores de alegrías que coinciden con alguno de los trabajos, frustaciones y alegrías importantes para el cliente.
Podemos detectar muy fácilmente que este encaje se producte, puesto que veremos cómo nuestros clientes se ilusionan al ver nuestra propuesta de valor. Esto ocurre cuando abordamos trabajos importantes, aliviamos frustaciones extremas o creamos alegrías esenciales para ellos.
En nuestra propuesta de valor los clientes representan al juez, jurado y verdugo. Si no conseguimos el encaje, serán despiadados.
Buscar el encaje es un proceso infinito que consistes en diseñar propuestas de valor con productos y servicios que cubren los trabajos, frustaciones y alegrías que realmente importan a nuestro segmento de clientes.
El encaje entre lo que ofrecemos y lo que quieren nuestros clientes es el primer requisito para lograr una propuesta de valor de éxito.
Este proceso tiene tres etapas:
La búsqueda de propuestas de valor que coincidan con los trabajos, frustaciones y alegrías del cliente es un constante ir y venir entre diseñar prototipos y probarlos. Más que secuencial lo debemos ver cómo un proceso repetitivo que nunca termina.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Una organización verdaderamente comprometida en convertir el trabajo colectivo en una realidad de su cultura necesita estar formada por jugadores de equipo.
Los procesos de selección ponen mucho foco en las capacidades y los conocimientos técnicos de los candidatos. Tan es así que muchas veces se pasa por alto de aquellos aspectos de la persona que harán que encaje en la cultura de la empresa.
Patrick Lencioni, en su libro Equipos Ideales, identifica las tres virtudes que definen a un jugador de equipo ideal. En este post describiremos las tres virtudes, sus combinaciones y como identificarlas en una entrevista de trabajo.
Los jugadores de equipo que destacan carecen de un ego desmedido y no les preocupa el status. Algunas de las características principales de las persones humildes en el ámbito profesional son:
Compartir los méritos. Poner al equipo por encima de uno mismo. Definir el éxito como algo colectivo
Existen dos tipos principales de personas que carecen de humildad. Los más evidentes son aquellos abiertamente arrogantes que lo centran todo en ellos. Son las clásicas personas que se mueven por el egoísmo y fomentan la división y las intrigas.
El siguiente tipo es mucho menos peligroso para las dinámicas de equipo. Son aquellas personas que carecen de confianza en sí mismas. Suelen minimizar sus propios talentos y aportaciones. En consecuencia los demás les consideran erróneamente humildes.
Ambos tipos tienen en común la inseguridad en sí mismos. Podemos considerar la humildad como el atributo individual más importante para el trabajo en equipo.
Las personas com hambre siempre están buscando algo más. Más que hacer, más que aprender, más responsabilidades a asumir... La gente con hambre casi nunca debe ser presionada por un jefe porqué es emprendedora y diligente.
Compromiso razonable y sostenible de hacer bien un trabajo y de redoblar los esfuerzos cuando sea necesario.
En el contexto de un equipo la empatía hace referencia únicamente al sentido común al tratar a las personas. Las personas empáticas suelen saber lo que está pasando en una situación grupal y cómo tratar con los demás de una manera eficaz.
Las personas empáticas hacen buenas preguntas, escuchan lo que dicen los otros y no pierden el hilo en las conversaciones.
Hay que tener presente que ser empático no significa necesariamente tener buenas intenciones. La personas empáticas pueden usar sus talentos para fines buenos o malos.
Pensar en estas tres virtudes es bastante obvio y presentadas de forma individual no es nada novedoso. Lo realmente poderoso de la humildad, el hambre y la empatía son la necesaria combinación de los tres.
La ausencia de una de las tres provoca que el trabajo grupal se haga más difícil y a veces imposible.
Quien carece de las tres cualidades tienen pocas posibilidades de ser miembros valiosos para un equipo.
Quien carece de dos de las tres cualidades lo tendrá muy difícil, pero no imposible.
Quien carece de una sola aptitud tiene unas probabilidades más altas de resolver sus problemas y convertirse en jugadores de equipo.
Los jugadores ideales de equipo ponen dosis adecuadas de humildad, hambre y empatía. Tienen un ego reducido en lo que respeta a la necesidad de atención o atribución de méritos por sus aportaciones. Trabajan con energía, pasión y responsabilidad personal asumiendo lo que pueden hacer para el bien del equipo.
Dicen y hacen todo lo correcto para ayudar a sus compañeros a sentirse apreciados, compendidos y tenidos en cuenta, incluso cuando surgen situaciones difíciles en las que se requiere que empleen mano dura aunque les duela.
Aprender a detectar estas virtudes entre los candidatos de un proceso de selección es muy importante para favorecer el trabajo en equipo y evitar problemas o situaciones desagradables. A continuación encontrarás un listado de preguntas que sirven para captar y analizar la esencia de la humildad, el hambre y la empatía.
Con el tiempo he acumulado unos cuantos artículos que reflexionan y aportan nuevas ideas acerca del trabajo en equipo. Como equipo siempre hemos de tener el propósito de mejorar nuestro rendimiento, es decir la calidad entregada y el tiempo requerido.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Hablamos de agilidad a la habilidad de cambiar la posición de un cuerpo de manera eficaz. Típicamente atribuible a una persona que controla de forma total sus partes del cuerpo y puede moverlas con rapidez y soltura.
Los últimos años y décadas el concepto de agilidad se ha transportado hacia los equipos de trabajo y a las organizaciones. Scrum es un frameworks ágil que nos facilita acercarnos a esta habilidad.
El framework nos abre las puertas hacia un mundo lleno de nuevas ideas, intrigante y con muchos desafíos por delante. No existe un único camino, cada equipo debe encontrar el suyo. No demos nada por sentado.
Scrum, de forma moderada, nos permite alejarnos de las estructuras jerárquicas y controladoras, muy presentes a día de hoy en las organizaciones. Se proponen alternativas colaborativas y basadas en los principios de la autogestión.
Ningún cambio auténtico será fruto de la obediencia o la coerción. Nunca vendrá impuesto desde arriba. Siempre nacerá en las bases, al nivel del individuo. Todos somos una parte responsable e implicada para el cambio.
Días atrás un amigo compartía en Facebook un decálogo republicano, encontrado en Can Pinyonaire, en Mollet del Vallés (Cataluña) durante la Segunda República española.
Podemos encontrar el decálogo en el libro República Payesa. Como veremos la agilidad comparte el ideario de este decálogo, de este mundo mejor que muchas corporaciones están aplicando desde sus bases.
Cataluña y otros territorios del Estado español fueron mayoritariamente anarquistas durante este periodo. El decálogo se centra en un comportamiento honorable para el individuo.
Una de las lecturas que más me han divertido durante los últimos años es el libro Por Un Scrum Popular. Se trata de un conjunto de ensayos alrededor de scrum y en contra de su comercialización.
La lectura de este decálogo me han transportado directa a la lectura del capítulo Anarquía ágil. Seguramente la palabra anarquía te produzca cierto rechazo. Es probable que la asocies a cócteles Molotov, espirales de caos, falta de cohesión o violencia extrema.
La agilidad es una forma compasiva de anarquía.
El anarquista compasivo exige que sus semejantes estén siempre en pie de igualdad, estimula las soluciones emergentes, deposita el poder en el individuo y busca evitar la deshumanización y marginación del trabajador.
Tanto el decálogo como la descripción del anarquismo compasivo nos generan muchos paralelismos con la agilidad. Es curioso que la palabra anarquista sea rechazada en el mundo corporativo y cada vez más corporaciones incorporen la agilidad en sus modelos de trabajo.
Vamos a profundizar en la palabra anarquista. Tobias Mayer, en el ensayo mencionado, recoge un buen número de citas que describen la anarquía de un modo que también se puede entender la agilidad.
Si bien la definición más difundida del anarquismo lo describe como un movimiento violento, opuesto a la existencia de un Estado, el anarquismo lo describe en verdad una tradición mucho más sutil y matizada que aquella definida a partir de una simple oposición gubernamental. Los anarquistas se oponen a la idea de que el poder y la dominación son necesarios para la sociedad y en cambio abogan por formas de organización social, política y económica más cooperativas y contrarias a todo tipo de jerarquías. L. Susan Brown
Anarquismo, para mí, significa no solo la negación de la autoridad, no solo una nueva economía, sino una revisión de los principios de la moralidad. Significa el desarrollo del individuo, así como también la afirmación del individuo. Significa responsabilidad por uno mismo y no la veneración del líder. Voltaire de Cleyre
La gente se olvida que la industria no es un fin en si mismo, sino que debería ser solo un medio que permita al hombre asegurar su subsistencia material y lograr que le sean accesibles las bendiciones de una cultura intelectual más elevada.Cuando la industria es todo y el hombre no es nada comienza el terreno del despiadado despotismo económico, cuyo funcionamiento no es menos desastroso que el de cualquier despotismo político. Rudolf Rocker
El anarquismo es una filosofía de libertad. En un corpus de ideas revolucionarias que reconcilia, como no lo hace ningún otro concepto revolucionario, la necesidad de libertad individual con las demandas de la sociedad. Es una filosofía que comienza por el individuo y trabaja de forma ascendente, en vez de comenzar por el Estado y luego descender. La estructura social en una sociedad anarquista se reduciría cuidadosa y conscientemente al mínimo posible y sería meramente funcional, donde hiciera falta organización, se mantendría, pero no habría organización por la organización misma. Esto ayudaría a evitar que las organizaciones se petrifiquen hasta transformarse en instituciones, el núcleo duro de la institución gubernamental. Bill Christopher, Jack Robinson, Philip Sansom y Peter Turner
Es la compasión lo que impide que la anarquía se degenere en caos violento así como también previene que la autonomía individual se convierta en insolencia e indiferencia por los otros. La anarquía impide que nuestra compasión se convierta en una carcaza vacía de cualquier autenticidad - es lo que impide que nuestro amor por los otros se convierta en una mercancía que se nos vuelve a vender o en un ardid para lograr nuestro consentimiento para los dictados de la autoridad. La anarquía compasiva trata de encontrar y apreciar ese alma genuina que existe en los seres humanos, manteniéndola libre de toda autoridad, sumisión, moralismo y roles estáticos. anarchopedia.org
Soy anarquista no porque crea que el anarquismo es el destino final, sino porque no existe tal cosa como el destino final. Rudolf Rocker
La agilidad ofrece al mundo corporativo, a las organizaciones y a los equipos la libertad para explorar fuera del perímetro de aquello que se considera correcto o apropiado. El mundo y las personas estamos cargados de buenas ideas.
Voy a montar un comando organizado armado de ideas cargadas de amor.
Los pioneros y defensores de la agilidad mencionan a menudo la valentía como un valor clave para el cambio auténtico, para la revolución ágil.
Todo cambio nace en la persona, en el comportamiento individual. Hace falta coraje para traspasar más allá de los límites de nuestra seguridad. Necesitamos descubrir y escuchar todas esas buenas ideas consideradas despreciables o peligrosas.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Los equipos necesitamos espacios de reflexión. La reflexión es el proceso que permite pensar detenidamente en algo con la finalidad de sacar conclusiones. En scrum el tiempo se separa en bloques temporales cortos y periódicos, los famosos sprints, de 1-4 semanas que abren un espacio de feedback y reflexión.
La reunión retrospectiva es la materialización del espacio de reflexión colectivo en busca de la mejora continua del proceso de trabajo y de los resultados obtenidos. Normalmente las reuniones retrospectivas buscan el encadenamiento de pequeños cambios incrementales en la forma de trabajo con el fin de evitar incendios en el futuro.
La inspiración de la reunión retrospectiva arranca en el concepto Kaizen (cambio bueno en japonés) del modelo Toyota. Si quieres conocer más acerca de los principios de trabajo del método de Toyota puedes leer este post.
Existe otro concepto menos conocido en la agilidad, el Kaikaku (cambio drástico en japonés). Se trata de la filosofía enfocada a la mejora de la producción mediante cambios radicales en la manera de operar.
Hay quien ve el Kaizen como el Kaikaku que vendrá en el futuro.
La misión de los equipos comprometidos es la búsqueda para acercarse a la perfección de forma continua. La perfección existe, pero es inalcanzable. Hacer scrum nos ayuda, mejor dicho, nos empuja a experimentar cada día. Todo experimento nos permite avanzar en la búsqueda de esta perfección. Que la perefección sea inalcanzable debe ser nuestra motivación para mejorar cada día.
Existen muchas dinámicas para la coordinazión de la reunión retrospectiva. Cada una de las dinámicas pone la linterna en algún objetivo concreto de mejora. Los enfoques más comunes de los equipos en las retrospectivas responden a estos tres objetivos:
Un ejemplo de dinámica de retrospectiva es la descrita en este post.
Al final de cada sprint el equipo debe abrir un espacio de reflexión colectiva que le permita avanzar hacia puntos de mejora. Utilizar siempre las mismas dinámicas y enfoques no favorecen la implicación de todo el equipo y puede favorecer la aparición de las siguientes disfunciones:
La reunión retrospectiva debe ser vista como una apuesta de futuro, como una orientación hacia el largo plazo. Invertir en las personas, la tecnología y el proceso nos acerca a un mayor valor para el clientes. Una organización que aprende es aquella que trabaja para la adaptación permanente a las nuevas situaciones. Puedes leer este post para convertir tu empresa en una organización que aprende.
Centrarse en los problemas solo nos provoca esto, pensar en los problemas. Del pensar continuamente en los problemas que nos rodean y ser un negativista hay poco espacio. El negativismo es el mayor problema de las empresas, y no sólo nos afecta como organización, sino que también nos afecta individualmente.
Algunos estudios se han centrado en determinar los costes directos del negativismo:
El negativismo lo creamos las personas. Una sola persona negativa puede crear un entorno de trabajo desagradable para todos los demás. Las personas no somos inmunes al negativismo y por este motivo nos afecta a la moral, al rendimiento y a la productividad de los equipos.
La lucha contra el negativismo es la creación de un entorno de trabajo (más) positivo. En un entorno positivo el negativismo no tendrá espacio para existir.
Un buen símil son los producto agrícolas ecológicos. Estos productos se concentran en el desarrollo de un ecosistema que favorece que las plantas deseadas nazcan y crezcan fuertes. Este ecosistema, este entorno, se extiende hasta desalojar las malas hierbas, puesto que no tienen espacio donde crecer.
Los tratamientos ecológicos requieren de forma inicial un mayor esfuerzo. Una vez que el entorno se propaga, todo se hace mucho más fácil y económico. Dejas de gastar continuamente en insecticidas y otros productos químicos, puesto que simplemente se debe mantener un medio ambiente saludable.
Si hablamos de ser positivos no pensamos en esbozar una sonrisa falsa o en creer que se puede hacer todo sin ayuda alguna. Ser positivo significa ser optimista y vivir con esperanza. Nuestro éxito no viene determinado por cómo actuamos en los buenos momentos de nuestra vida, sino por como pensamos y respondemos a los retos en los momentos más difíciles.
Las compañías no nacen, se hacen. Lo mismo para los equipos. Sin unos principios clave para un entorno positivo es fácil que las fuerzas del mal tomen peso y contagíen una actitud negativa entre los compañeros. Estas oleadas de negatividad pueden convertirse en un estado permanente si el equipo no está alerta y trabaja para un entorno de trabajo positivo.
Los principios positivos se pueden resumir en seis puntos:
La negatividad nace de la queja, que se instaura en nuestras mentes quejicas y contamina a las personas de nuestro alrededor. Evitar la queja nos ayudará a evitar la negatividad. Sin negatividad no existe el negativismo. Sin negativismo nuestro entorno de trabajo será más agradable.
Existen tres herramientas para no quejarse y enfocar las situaciones que no nos agradan en una visión positiva:
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Analizar continuamente las reacciones de los usuarios o clientes permite iterar y adaptar los productos y servicios a sus necesidades o deseos. La agilidad propone dinámicas y herramientas para ayudar a seguir el camino hacia aportar el máximo valor.
Los frameworks ágiles o Lean recomiendan las historias de usuario para describir estas necesidades o deseos y poder definir qué se necesita.
Como ya sabes, las historias de usuario son frases cortas y esquemáticas (como-quiero-para) que comparten todas ellas una misma forma sintáctica y que van acompañadas de un listado de criterios de validación.
Como X (rol que sea) quiero M (lo que sea) para Y (lo que sea)
Las historias de usuario responden a las preguntas:
Observando las preguntas vemos que sus respuestas se centrán en el QUÉ necesita el usuario y no en el CÓMO se debe proporcionar la solución. Las historias de usuario no pretenden dar una definición completa de los requisitos y las tareas a realizar. Tenemos que verlas como una promesa a tener una conversación de equipo.
Si quieres aprender o recordar los elementos clave de las historias de usuario puedes leer este artículo.
Las historias de usuario son una de las herramientas más recomendadas entre los frameworks ágiles o Lean UX. No se trata de un capricho sino fruto de la voluntad de trabajar en puntos que aporten valor.
Trabajar con historias de usuario nos aportará los siguientes beneficios:
Las historias de usuario permiten definir el mínimo producto viable y las posteriores iteraciones para mejorar o incrementar el producto. Si quieres conocer los 7 errores más comunes en la definición del mínimo producto viable puedes leer este post.
Una situación muy frecuente cuando alguien o un equipo empieza a trabajar con historias de usuario es la dificultad en construir historias lo más pequeñas posible y que aporten valor al usuario.
Ante la costumbre de trabajar con grandes definiciones de requisitos o tan siquiera usar una definición de requisitos es fácil encontrarse en situaciones en las que cuesta dividir las historias de usuario y pensar que es imposible, que su caso es especial y que puede que esta herramienta no le sirva.
A continuación describiremos cuatro estrategias para la división de las historias de usuario bajo distintos puntos de vista.
Una buena estrategia inicial es afrontar la división de las historias de usuario bajo el flujo de trabajo que representa conseguir un objetivo.
Este enfoque requiere detectar los pasos individuales que debe seguir el usuario. Cada uno de estos pasos, si aporta valor, es una historia de usuario.
Esta estrategia nos permite crear la secuencia completa de historias por las que pasará un usuario hasta completar el objetivo final.
Ejemplo: Seleccionar un producto
El error más común al aplicar esta estrategia es esconder historias de usuario, por ausencia o en los criterios de validación.
Para no caer en el error debemos asegurarnos que las historias de usuario o ítems de los criterios de validación enlazan completamente en todo lo escrito anteriormente. De no ser así seguramente estamos escondiendo alguna historia de usuario.
El uso de una aplicación no siempre funciona todo, algunas veces aparecen errores. La estrategia de definir por flujo feliz/infeliz permite definir las historias de usuario cuando todo va bien y cuando las cosas van mal.
Este enfoque nos obliga a definir los pasos que seguirá el usuario cuando todo funciona correctamente y todos los puntos en los que se puede generar un error.
Esta estrategia permite detectar todos los posibles errores en un proceso y a definir la comunicación de los errores al usuario.
Ejemplo: Login
Recomendamos la estrategia de flujo feliz/infeliz a la estrategia anterior, por flujo de trabajo. En el primer caso definimos el flujo feliz y una vez terminado lo completamos con la vista puesta al flujo infeliz.
La estrategia de descomponer por parámetros de entrada tiene como objetivo no esconder grandes funcionalidades entre los criterios de validación.
Un ejemplo típico es en la definición de sistemas de búsquedas de productos y los distintos filtros de configuración de búsqueda y mostrado de resultados. Existe la tentación de describir estos filtros y opciones entre los criterios de validación.
Por desgracia es un clásico encontrarse un criterio de validación que indica que el sistema de búsqueda de productos tendrá accesibles un conjunto de filtros, citar los más obvios y dejar completamente abierta su definición con puntos suspensivos.
Ejemplo: Búsqueda de productos
La estrategia de descomponer por parámetros de entrada nos obliga a definir una historia de usuario para cada uno de los parámetros de entrada. Siguiendo el ejemplo de búsqueda de productos debemos entender que cada uno de los filtros debemos contemplarlo como una historia de usuario independiente.
La estrategia de descomponer por operaciones nos obliga a definir todas las acciones que un usuario puede realizar alrededor de una de las entidades del sistema.
Las operaciones típicas de una entidad son dar de alta, dar de baja, modificar su valor y realizar consultas de lectura (CRUD). Estas operaciones son prácticamente imprescindibles para cualquier apartado de administración.
Recomendamos completar la estrategia de descomponer por operaciones con la estrategia de flujo feliz/infeliz para poder definir la gestión de errores en las acciones de administración.
Ejemplo: Gestión de elementos
La estrategia de descomponer por operaciones nos facilita no dejarnos ninguna operación básica sobre cualquiera de las entidades de nuestro producto.
Un buen truco es aprovechar cada vez que aparece una entidad nueva en el producto utilizar esta estrategia para definir todas las acciones disponibles para los distintos roles de usuario de esa entidad.
Las historias de usuario son una herramienta recomendada para equipos que trabajen siguiendo las recomendaciones de frameworks agile, como scrum, en el desarrollo de productos y aplicaciones.
Las características principales de las historias de usuario son:
Es fácil caer en errores en la definición de las historias de usuario cuando se empieza a usar esta herramienta para la definición de necesidades. Los errores más típicos son escribir historias de usuario demasiado largas o esconder historias dentro de la lista de criterios de validación.
Este post explica cuatro técnicas para escribir buenas historias de usuario. Utilizar las cuatro estrategias debidamente cruzadas a lo largo del proceso nos ayudará a prevenir problemas de definición futuros durante el desarrollo de producto.
Los problemas futuros sin una correcta división y definición de las historias de usuario son:
Si quieres conocer más técnicas para la división de historias de usuario para hacerlas lo más pequeñas posible y aportando el máximo valor puedes leer este artículo de Javier Garzás.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>El trabajo en equipo es un elemento básico para la correcta actividad de una organización. Sin su presencia será imposible obtener un resultados excelentes. Scrum y los frameworks ágiles proponen dinámicas para potenciar y mejorar el trabajo en equipo.
El sentimiento de grupo y la autogestión del trabajo son esenciales para mantener un equipo cohesionado y motivado.
El trabajo en equipo es un concepto que está en manos de cualquier directivo o responsable de departamento pero muy pocos realmente consiguen que sea una realidad. Existen obstáculos naturales y peligrosos que dificultan o imposibilitan el trabajo en equipo.
Patrick Lencioni define cinco disfunciones de los equipos que representan estos obstáculos. Las cinco disfunciones no se deben ver como elementos aislados o intentar corregir de forma independiente. Las disfunciones de un equipo configuran un modelo interrelacionado y pueden convertirse en letales si un equipo falla en cualquiera de los cinco aspectos.
A continuación analizaremos en qué consisten estas cinco disfunciones y las vincularemos a las dinámicas que nos proporcionan los frameworks ágiles. Scrum es una caja de herramientas que permite avanzar hacia un equipo motivado y cohesionado.
La primera disfunción hace referencia al concepto de confianza. Entendemos confianza como la falta de disposición para ser vulnerables en el grupo. Los equipos, así pues las personas que lo forman, deben estar dispuestas a abrirse al equipo para aceptar errores y debilidades.
Siempre que nos encontremos ante personas que no están dispuestas a mostrarse vulnerables ante el grupo será muy difícil construir unos cimientos profundos basados en la confianza.
En scrum existen tres espacios en los que las personas del equipo pueden abrirse al grupo y afrontar los problemas en equipo:
Si quieres leer en más detalle las dinámicas que se generan en cada una de las reuniones que propone scrum puedes hacerlo en este post.
La primera disfunción nos conduce a la segunda, el miedo al conflicto. Si un equipo carece de confianza es incapaz de entregarse a discusiones desenfrenadas y apasionadas de ideas. Los equipos excepcionales son capaces de discutir y avanzar hacia la solución.
Esta disfunción se hace evidente cuando nos encontramos ante reuniones aburridas y con comentarios muy cuidadosos para no herir la sensibilidad de nadie. Estas reuniones, en las que todos hemos estado, no sirven absolutamente de nada.
Un equipo cohesionado no tiene ningún temor a preguntar o expresar la opinión. Alinear las visiones es imprescindible. Todos debemos exponer nuestras ideas, dudas o preocupaciones. Un equipo con confianza no duda en discutir apasionadamente por las ideas.
Scrum nos proporciona tres dinámicas en las que podemos establecer diálogos y discusiones acaloradas acerca de las ideas que afectan a las responsabilidades del equipo.
La siguiente disfunción se centra en el valor de la palabra compromiso. Estamos ante un concepto que se ha utilizado muy frecuentemente de una forma superficial y nos ha hecho perder de vista su verdadero significado. En el contexto de un equipo el compromiso depende de dos cosas: claridad y aceptación.
Los equipos excepcionales adoptan decisiones claras y permanentes y las concretan con la completa aceptación de todas las personas del equipo.
Sin confianza o con temor a discutir fingiremos como equipo estar de acuerdo en las reuniones. Necesitamos despertar conversaciones acaloradas entre los integrantes de un equipo y llegar al consenso. Con consenso habrá compromiso colectivo.
En scrum el sprint es el compromiso que toma el equipo del trabajo que se realizará en el siguiente periodo de tiempo. Planificar sprints viables y cumplir los objetivos es una herramienta que nos fortalece como equipo. Puedes leer más acerca de cómo la definición de sprints ayudará al equipo a conseguir los objetivos.
Sin compromiso y aceptación del equipo desencadenaremos la cuarta disfunción, la evasión de responsabilidades. Estaremos ante equipos que no se compreten con un plan de acción claro.
Esta disfunción es realmente preocupante, puesto que provoca que las personas más centradas y entusiastas con el proyecto y el trabajo en equipo vacilen antes de llamar la atención a alguno de sus compañeros. Cuando no nos atrevemos a cuestionar acciones y conductas que parecen contrapuestas al bien del equipo, tenemos un problema.
Una buena fórmula para detectar esta disfunción y hacerla evidente usando scrum es la revisión de los sprints. Revisar los objetivos marcados en el sprint, observar que no se termina por norma y la constante sobreexplicación de excusas, interrupciones o peticiones de clientes nos permite saber que debemos trabajar para cambiar esta situación.
Llegamos a la última disfunción y más grave. Un equipo que no se responsabiliza no prestará atención a los resultados. No centrarnos en los resultados nos provocará que las personas del grupo sitúen las necesidades individuales (como el ego, la carrera profesional, el reconomiento personal...) o de su departamento por encima de las metas colectivas de la organización.
No prestar atención a los resultados pone en peligro el futuro de la organización.
Existen algunos síntomas claros cuando un equipo que supuestamente "hace scrum" y no presta atención a los resultados:
El éxito de cualquier grupo o organización pasa por la cohesión y el trabajo en equipo. Si se permite que aparezca cualquiera de las cinco disfunciones anteriores la dinámica se deteriorará.
Las listas en positivo nos ayudan a construir el fúturo. El pasado es pasado, no podemos hacer nada. El presente es fugaz y está marcado por el día a día. Sólo podemos mejorar mirando hacia el futuro.
Para imaginarnos un equipo cohesionado podemos hacer la siguiente lista en positivo:
Esta lista, una vez leída, parece muy sencilla. En realidad es sumamente difícil de conseguir. Necesitaremos altos niveles de disciplina y perseverencia. Muy pocos equipos podrán conseguirlo.
Scrum nos ofrece herramientas y técnicas que actúan como guías de comportamiento y crean dinámicas de grupo que favorecen la cohesión y el trabajo en equipo.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Como equipo necesitamos tener la noción del todo antes de conocer el detalle. Necesitamos saber porqué haremos un cosa antes de empezar a hacerla. ¿Qué valor estamos buscando? ¿Qué historia queremos contar?
En scrum se promueve la reflexión colectiva a través de la retrospectiva, una vez finalizado el sprint. Las reuniones retrospectivas necesitan un ambiente positivo y de confianza. No deben quedarse sólo en el análisis de problemas, deben convertirse en un auténtico acelerador del cambio.
En el libro Project Retrospectives, Norm Kerth escribe en 2001 la directiva básica para las reuniones retrospectivas:
"Sin importar lo que sea descubierto, entendemos y creemos que todos hicieron lo mejor que pudieron, dado lo que sabían en ese momento, sus habilidades, los recursos disponibles y la situación en la que se encontraban."
Esta directiva puede considerarse un punto superficial. No sitúa al lector en un estadio preparado para el cambio. Aún así se trata de una directiva muy válida para situaciones en las que las relaciones entre las personas del equipo están realmente erosionadas, con una fuerte tendencia a la recriminación del propio equipo o hacia personas externas.
Las personas que formamos un equipo no podemos reprimir nuestros comentarios, opiniones, críticas, dudas, preocupaciones, diferencias o disputas hasta el final del sprint. Debemos promover una cultura de la reflexión, que no sea solo reservada al espacio de la retrospectiva.
La reflexión hará que las personas del equipo se sientan más cercanas entre sí. Se profundizará en el espíritu tribal, la conciencia de grupo, la lucha por un propósito común. La confianza nos llevará a que no sea necesario llegar al final de un sprint para destapar la caja de Pandora. Con la reflexión constante la retrospectiva se convertirá en una herramienta realmente poderosa.
Tobias Mayer, en su libro Por un scrum popular, notas para la revolución ágil, escribe la siguiente directiva para la retrospectiva:
"Somos seres emocionales y vulnerables, sujetos a un enorme caudal de influencias provenientes de un sinnúmero de orígenes. A veces nos desempeñamos de maneras magníficas y otras tantas arruinamos todo, pero generalmente nos ubicamos en un punto intermedio. Durante este último periodo cada uno hizo lo que hizo y seguramente tuvo sus razones para actuar de esa manera. Aceptemos lo que hay, cómo se dieron las cosas. Y ahora preguntémonos, ¿Qué podemos aprender de nuestras acciones y razonamientos pasados, para así poder guiar del mejor modo posible los que vendrán en el futuro?"
Las dinámicas de trabajo son muy importantes y más en las reuniones. A continuación veremos una dinámica para promover la reflexión en la reunión retrospectiva, sin superar la hora y media. La dinámica planteada está inspirada en este post de Proyectos Ágiles.
El facilitador explica el objetivo de la retrospectiva y enumera los distintos pasos y tiempos que va a tener la reunión.
En este espacio el equipo hará un reconocimiento de las cosas que han salido bien e identificará las cosas que necesita potenciar más. Cada miembro del equipo hace 2 o 3 posts-its y los coloca en la pizarra, agrupados por temas.
Este segundo espacio de la reunión es para identificar los problemas de la forma más objetiva posible de la situación. El facilitador debe repasar los puntos siguientes del sprint acabado de finalizar:
Todas las personas del equipo deben proponer aspectos adicionales a mejorar, con la misma dinámica posts-its anterior. Todos los problemas deben agruparse por afinidad o relación para finalmente poder titular el grupo bajo una problemática común.
El equipo deberá escoger cuales son los problemas que más afectan a los objetivos del proyecto o a la productividad del equipo. Cada miembro del equipo tiene 3 o 5 puntos para distribuir en los distintos grupos de problemas.
El tercer espacio consiste en buscar las causas de los problemas. En los equipos con una baja confianza entre los miembros del mismo se tiende a buscar culpables. Aquí no estamos para buscar culpables. En un equipo todos somos culpables de los errores o problemas ocasionados.
Para buscar el origen de los problemas es muy útil la mecánica de los 5 "por qués" de Toyota. Se trata de iterar cada respuesta a la pregunta anterior para formular la pregunta siguiente. Puedes encontrar la explicación completa en este post.
Una vez analizado el origen del problema escogido por el equipo necesitamos entrar en una lluvia de ideas para proponer soluciones sobre el problema tratado. En la selección de la solución debemos ver la aceptación de la solución por parte del equipo.
No podemos pasar por alto el análisis de costes, esfuerzos, tiempos de impliementación o la satisfacción del cliente para aceptar trabajar en una de las propuestas de solución. El equipo se divide las responsabilidades para la solución y se crean las tareas necesarias en el backlog para entrar en el próximo sprint.
Para finalizar la sesión de reflexión debemos revisar las conclusiones a las que el equipo ha llegado y las decisiones tomadas. En este punto de la sesión de trabajo también debemos analizar si hemos conseguido el objetivo principal, analizar qué ha funcionado bien en la dinámica y qué necesitamos mejorar.
Alimentar la mirada reflexiva nos acercará a la reflexión durante todo el trayecto. Cuando el proceso de reflexión es continuo no esperamos a la retrospectiva a comentar nuestras sensaciones y en este momento la reunión retrospectiva se convierte en una sesión de trabajo entre un equipo muy comprometido y con los objetivos de mejora claros.
Una buena forma de alimentar la reflexión es introducirlas en nuestro proceso de trabajo constante. Introducir la reflexión puede ser complicado por el día a día. La daily es la reunión más indicada para favorecer esta reflexión constante. Podemos incluir las siguientes preguntas:
Podemos crear un nuevo backlog, el backlog de síntomas. Este backlog de síntomas debe funcionar de forma distinta al sprint backlog. Cualquier persona del equipo puede tomar espontáneamente un ítem de este nuevo backlog, analizar las causas detrás del síntoma y proponer soluciones en la próxima reunión retrospectiva.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Existe una particularidad importante en el desarrollo de software: se permite la implantación de un producto no acabado o con errores conocidos. Esto provoca que se pueda poner en producción software inestable.
A esta situación podemos sumarle que en muchas organizaciones centran sus políticas de ahorro en recortes sobre los procesos de pruebas, controles de calidad, creación de documentación, optimización del producto...
Estas decisiones comprometen la viabilidad del proyecto a largo plazo.
Entendemos deuda técnica como el concepto del desarrollo de software que hace referencia a los costes adicionales que se generarán en el futuro por la apuesta por un desarrollo sencillo y apresurado, en lugar de haber buscado el mejor enfoque con un mayor tiempo de dedicación
Si queremos resumirlo de forma fácil: la deuda técnica es todo aquello que no hicimos en algún momento del pasado y que deberíamos haber hecho para trabajar profesionalmente en un software decente y de calidad.
No sólo nos debe importar que el código funcione, también se necesita que sea fácil de leer y de mantener. Todos los desarrolladores hemos experimentado esos momentos "creativos" en los que para salir del pozo terminas con una solución que funciona sin saber muy bien porqué. ¿Cuánto tiempo pasará hasta olvidar que hemos hecho? Más allá de la alegría inicial debemos saber que estaremos añadiendo deuda técnica.
Este es uno de los mayores riesgos que existen en el desarrollo de software. A medida que avanza el tiempo del proyecto el conocimiento sobre el código se va diluyendo. Avanzar cada día será más lento y llegará un día que todo quedará frenado. Puedes leer este post acerca de cómo combatir los riesgos de un proyecto mediante el uso de scrum.
Tobias Mayer y Alan Cyment nos dejan algunas reflexiones interesantes acerca de la deuda técnica en su libro Por un scrum popular, notas para una revolución ágil.
Des de 1992, que se propuso por primera vez el término deuda técnica, conocidos desarrolladores han escrito acerca de este concepto. Una de las explicaciones más conocidas es la matriz de Philipe Kruchten (profesor de ingeniería del software en la Universidad Británica de Columbio en Vancouver) en el whitepaper sobre la Deuda Técnica: De la metafora a la teoría y prática.
En la matriz se muestra como la deuda técnica aporta un valor negativo y es invisible, a diferencia de los bugs o caídas del sistema que aportan un valor negativo de una forma visible.
Steve McConnell (autor de libros de texto de ingeniería del software y una de las tres personas más influyentes de la industria del software junto a Bill Gates y Linus Torvalds) define que existen dos vías principales para generar deuda técnica:
Con la deuda técnica pasa igual que con la deuda con un banco: cuanto más tiempo tardamos en gestionar esa deuda más interés vamos a pagar.
Muchos equipos, a menudo en startups o empresas pequeñas, eligen trabajar más rápido al inicio de un proyecto a costa de generar deuda técnica. Esta decisión es doblemente negativa: por un lado estamos incrementando la deuda técnica en las fases iniciales y estamos generando una falsa sensación de velocidad. Ambas se girarán algún día a la contra.
Esta es una lista de posibles causas de generación de deuda técnica:
Cuando tomamos atajos para salir de la presión del cliente, del gerente, de los usuarios, de unos presupuestos bajos... estamos tomando decisiones que fuerzan al equipo a saltarse partes del proceso de creación de software que, aunque puede parecer que no ayudan a avanzar rápidamente en el desarrollo, ayudan a desarrollar de forma segura durante el paso del tiempo. Estas partes no sólo ayudan a ir más rápidos en el futuro, sino que aseguran una estabilidad y calidad del código.
Por más presión que pueda existir es responsabilidad del equipo (y así se le exigerá) que piense en un buen diseño, que realize las pruebas necesarias, mejore los procesos de entrega continua... Nadie de fuera del equipo defensará esta posición!
El mayor peligro de una deuda es no pagarla. Cuando no se paga la deuda técnica ésta no desaparece y se va acumulando en distintas partes del proyecto. Un equipo puede llevar años acumulando deuda técnica.
Toda esta deuda técnica generada un día explotará. Se habrá terminado el crédito. No sabes cuando será ese día, puede que sea hoy, pero cuando pase el equipo quedará totalmente frenado. Avanzar con los desarrollos será difícil y costoso.
El desarrollo de software lo debemos entender como un proceso incremental e iterativo. Sobre todo iterativo. Si quieres saber más acerca del desarrollo iterativo puedes leer este post.
Cuando se habla de deuda técnica es fácil pensar que los responsables de haberla generado son los integrantes del equipo de desarrollo. Así es. Jerónimo Palacios, conocido Agile Coach:
"La deuda técnica es un reflejo de una falta de madurez en la gestión empresarial."
Cuando elegimos dejar un código malo ahí, sin tocarlo, puesto que ahora está funcionando, estamos generando o perpetuando deuda técnica. No podemos ser tan ilusos de pensar que algún día tendremos el tiempo suficiente para empezar a arreglar todas esas partes del proyecto con deuda técnica y dejarlo completamente sano. Nunca existirá este momento!
Las dinámicas que se generan con el día a día es fácil esconderse bajo este "trajín" para no asumir la responsabilidad. Siempre encontraremos cosas más urgentes antes de empezar un cambio profundo en la organización: el pago de la deuda técnica.
No puedes esperar que alguien, de fuera del mundo del desarrollo, venga a solucionarte este problema, no por no querer ayudar sino por desconocimiento total de la situación. A modo de alerta, evita estas frases y combátelas!
Pronunciar alguna de estas frases es no asumir la responsabilidad. La responsabilidad de cualquier equipo de desarrollo reside en la creación de software que funcione, escale, sea fácil de leer, de mantener o de evolucionar.
En algún momento nos podemos encontrar que empezar a combatir la deuda técnica se ha convertido en una montaña gigante. En esos momentos puede que empieze a cuajar la idea que se debe empezar el proyecto de cero, que lo más apropiado es tirar a la basura lo hecho hasta el momento y volver a empezar.
Empezar desde cero no es aceptable
Proponer empezar desde cero es tener un comportamiento muy poco profesional. Por más que pueda parecer la opción más viable provablemente estaremos en un espejismo y no tendremos en cuenta muchas de las cosas buenas que tiene el producto actual. Iterativo recuerdas?
Cuando existe deuda técnica en un proyecto, sí existe, es prioritario empezarla a pagar. Cuando empezamos a hacer los nuevos planteamiento pueden aparecer la siguientes preguntas:
Scrum propone una buena fórmula para ir pagando esta deuda técnica sin que afecte a los tiempos comprometidos y que asegura que se trabaja en ello a medida que se avanza en el proyecto.
Una buena dinámica para empezar a disminuir la deuda técnica sin que esto afecte el rendimiento del equipo (productividad dentro del sprint) es la siguiente:
Con esta técnica no solo conseguimos pagar deuda sino que también ayudamos a hacerla visible, a asegurar sus pagos con la propia evolución del proyecto y crear una dinámica de trabajo que propicie los refactors, haciendo la calidad del código una cosa importante para todos.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>En las empresas técnicas y de servicios las personas están sentadas en sus mesas utilizando el ordenador, reunidas, andando hablando por teléfono u ocupadas con cualquier tipo de tarea. Resulta difícil comprender el flujo de trabajo a simple vista, a diferencia de las organizaciones que trabajan en la creación de producto físico.
En las empresas de producto físico es fácil dibujar un diagrama de flujo. En las empresas técnicas y de servicios el flujo se organiza alrededor de proyectos. Estos proyectos pueden variar ampliamente de tamaño, complejidad, número de personas involucradas, plazos de entrega...
Cuando queremos trabajar en mejorar la agilidad de los equipos de operaciones o de desarrollo necesitamos determinar el flujo de trabajo. Dadas las dificultades en la observación del flujo, necesitamos empezar por el cliente, definir el valor y dibujar el mapa del proceso que añade valor al cliente.
El caso ideal de cualquier proceso en este tipo de empresas sería que cada uno de los equipos obtuvieran la información que necesitan justo a tiempo por parte de un equipo de apoyo o proveedor. Para la definición del flujo de valor en las organizaciones técnicas y de servicios podemos identificar estas cinco etapas.
Una de las responsabilidades del Scrum Máster en el framework ágil Scrum es la generación de flujo y eliminación de impedimentos. Si quieres saber más acerca de esta responsabilidad del Scrum Máster puedes leer este post.
En este post veremos como crear dinámicas que nos permitan mejorar la productividad de los equipos e impulsar la mejora continua. Para ello usaremos los mapas de flujo de valor, inspirados en el Toyota Production System (Sistema de producción de Toyota, TPS). Buscar ejemplos concretos de aplicación del TPS en organizaciones técnicas y de servicios es una tarea complicada. Así pues, ante esta situación puedes escoger perder el tiempo buscando el ejemplo perdido de aplicación del modelo Toyota o empezarlo a seguir, analizar la situación y plantear soluciones innovadoras.
A palabras de Fujio Cho, consejero delegado de la Toyota Motor Corporation:
"Lo que más valoramos es la implantación real y actuar"
Mike Rother y John Shook, en 1999 y a partir del material de Toyota, adaptaron el modelo Toyota con los mapas de flujo de valor para las empresas técnicas y de servicios. Los mapas de flujo de valor recogen los procesos, flujos de materiales y flujos de información de una determinada familia de producto para ayudar a eliminar el despilfarro en el sistema de trabajo.
Si quieres saber más acerca del Sistema de Producción de Toyota (Toyota Production System, TPS) puedes leer este breve resumen acerca de los 14 principios de gestión del modelo Toyota.
Los mapas de flujo de valor nos sirven para representar la entrega de forma fragmentada entre tiempos con valor añadido y tiempos sin valor añadido.
Intentar realizar un mapa de flujo completo en una empresa de servicios puede resultar un caos y muy difícil de poner a todos los miembros del equipo de acuerdo con el resultado. Para ello la idea es realizar un mapa macro de flujo de valor, de forma en la que cada grupo esté de acuerdo con el despilfarro en los procesos.
Una vez tenemos dibujado el mapa macro actual debemos empezar a crear un mapa macro de la situación futura, eliminando las etapas sin valor añadido en el proceso. Esto nos ayudará a identificar grande oportunidades de reducción de despilfarro en el flujo de valor.
Cuando tenemos el actual y el futuro es el momento de escoger entre 5 y 10 puntos en los que trabajar, seguramente serán los más obvios, con el objetivo de entrar en detalle y eliminar el despilfarro.
El tema más controvertido en la creación del mapa de flujo de valor será la identificación de las etapas del proceso que no aportan valor añadido. Nadie quiere admitir que no está aportando valor.
Para ayudar a generar concenso se proponen estas tres categorías:
Los workshops kaizen son una herramienta excelente para poder trabajar de forma detallada en la eliminación del despilfarro en los procesos de una empresa técnica o de servicios.
Se trata pues de eventos que duran una semana, en los que los participantes analizan el proceso real, desarrollan una visión lean del proceso y, lo más importante, empiezan su implantación.
Entre los participantes del workshop debe figurar el responsable del proceso que se quiere mejorar, que será la persona que liderará el workshop, y todas aquellas personas que efectuan realmente el trabajo en el proceso.
Para un workshop kaizen separamos estas 3 fases:
Para facilitar el flujo del workshop y usar de modo eficaz el tiempo de los participantes hay que hacer cinco cosas esenciales en la preparación del workshop:
La dinámica que se seguirá en el workshop kaizen es la siguiente:
Todo lo que se proponga en el workshop no se podrá aplicar durante la propia semana del workshop kaizen. Es por este motivo que saltamos a la tercera fase, una vez se ha terminado el workshop. En este caso el equipo participante se seguirá reuniendo una vez a la semana para:
Mediante los workshops kaizen podemos mejorar los procesos que permiten a una organización de servicios añadir valor al cliente que le contrata. Eliminar el despilfarro, los tiempos de espera o hacer llegar la información justo a tiempo son puntos clave para la mejora de las operaciones.
En el punto que podemos encontrar más fricciones es en la categoriazación de las etapas del proceso. Aceptar que no se añade valor al proceso no sólo es difícil sino que se pueden hacer muchas apreciaciones, por ejemplo
¿Podemos considerar que el departamento de contabilidad no añade valor?
Si respondemos que sí, que el departamento de contabilidad no aporta valor, no estaremos considerando que los clientes de la organización también están comprando los servicios de contabilidad.
No estaremos teniendo presente que el departamento de contabilidad y sus servicios son fundamentales e imprescindibles para cualquier empresa. Si una empresa abandona el negocio debido a una mala contabilidad, por onvio que sea, no podrá dar servicio a ningún cliente.
¿Qué es el valor añadido?
Dependerá de como definamos al cliente y el mapa de flujo de valor que dibujemos. Para terminar, un pequeño extracto de Orson Scott, escritor de ciencia ficción y fantasía, en Pertince Alvin: Los relatos de Alvin Maker, Libro Tres, acerca de la organización de las personas inspirándose en la coordinación de los átomos.
"Un hombre hizo su parte, y el otro la suya, y ninguno tuvo que hacer comprobaciones para estar seguro de que ambas partes se habían hecho. Como la danza de átomos que Alvin había imaginado en su mente. Nunca antes se había dado cuenta, pero las personas también podían ser como esos átomos. La mayoría del tiempo, las personas estaban desorganizadas, nadie conocía quién era el otro, nadie permanecía lo suficiente como para confiar en el otro o que confiaran en él, justo como Alvin imaginó que los átomos podían haber sido antes de que Dios les enseñase quiénes eran y les diese el trabajo que hacer... Parecía un milagro, la facilidad con que conocían el movimiento que haría el otro antes de que hubiese empezado. Alvin casi soltó una carcajada de alegría viendo una cosa así, sabiendo que era posible, soñando en lo que podía significar -miles de personas conociéndose tan bien unas a otras, moviéndose para adaptarse entre sí, trabajando juntas-. ¿Quién podría interponerse en el camino de esas personas?"
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Se acercan las fiestas navideñas y el nuevo año. Ante unos días de regalos y para algunos de nuevos propósitos puede que entre tus inquietudes esté aprender más sobre agile. Para ello en este post recomendaremos 3 libros del mundillo que hacen mucho más hincapié a las personas que a los frameworks ágiles en concreto.
Hace unos meses, coincidiendo con las fechas del día del libro publicamos este post de recomendación de tres libros también vinculados al mundo agile.
Autores: Tobias Mayer, Alan Cyment
En este libro se comentan las ideas que hacen que Scrum pueda tener éxito en las organizaciones. Tiene un formato de capítulos muy cortos, en forma de posts. Estamos ante un libro mucho más centrado en las personas, los problemas del día a día y en la generación de nuevas dinámicas que en la aplicación estricta del framework.
Por un Scrum Popular es un libro fácil de leer que ayuda a comprender que el éxito de Scrum va ligado a entender a las personas más allá del proceso.
Por último, recomendar la lectura de este libro a todos aquellos que utilizan Scrum y, porqué no, también a los que no pero que trabajan en el desarrollo de software.
Manuel Martín comenta en las puntuaciones de Amazon:
Leer este libro debería ser obligatorio para todos aquellos que lidian con Scrum en su empresa. Quizás no es un libro ideal para aquellos que comienzan pero sí para los que ya han batallado en las trincheras. Tanto los artículos de Tobias como las anotaciones de Alan son soberbias y te hacen sentir que no estás solo :)
Autor: Jeffrey K. Liker
El Modelo Toyota ha servido de inspiración en distintos puntos de Scrum, cómo por ejemplo en la figura del Product Owner con los ingenieros jefes de la compañía nipona. Este es un libro ideal para entender y profundizar sobre cómo los principios de gestión del Sistema de Producción de Toyota (Toyota Production System, TPS) nos pueden ayudar en una empresa técnica o de servicios.
Estamos ante un libro recomendado no sólo a las personas que trabajan en el mundo del desarrollo de software, sino para cualquiera que trabaje en equipo. Es de lectura fácil, con ejemplos y diálogos para entender mejor la situación.
Si eres el Product Owner en un equipo que trabaja en Scrum es una lectura casi imprescindible para mejorar en el desempeño de tus tareas. En este caso quote en Amazon que me ha parecido más apropiado es de un usuario que se hace llamar... FreakUser.
No esperéis un libro de técnicas o muy teórico sobre TPS o Lean. El autor cuenta sus experiencias en más de 20 años visitando centros y entrevistando empleados de Toyota. Se centra más en la filosofía de empresa que hace que el TPS funcione de verdad en toda la organización, no en la mejora de un proceso productivo concreto. Es realmente ameno e interesante, se lee con muchísima facilidad incluso para los que desconocemos el tema o no trabajamos directamente en procesos de manufactura (yo soy ingeniero I+D).
Si quieres saber más acerca del Modelo Toyota y cómo aplicarlo para la mejora continua en Scrum puedes leer este post.
Autor: Patrick Lencioni
Estamos ante un libro fundamental para ver el funcionamiento de las dinámicas de equipo. Se describe como los activos pueden convertirse a su vez en amenazas. No ponder foco en buscar una solución directa a un problema y aprender a buscar soluciones para generar un cambio a largo plazo es uno de los ejes principales del libro.
Encontraremos la descripción de los cinco problemas que impiden, incluso al equipo más brillante, funcionar.
Scrum Másters y Product Owners en Scrum y cualquier persona que ocupe un cargo relacionado con la gestión de equipos debería leerlo.
Antonio Martínez escribe en las opiniones de Amazon:
En un formato de historia, el autor nos presenta las 5 disfunciones de un equipo, con contexto, de forma realista y con dinámicas claras. Después de la historia entra en la parte más académica con un formato de disfunción, diagnóstico y dinámicas de grupo para solucionarla. Sin duda un libro revelador y que releeré varias veces.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Querido lector, si estás en este post seguramente conoces qué son las historias de usuario. Como ya sabes y a modo deresumen, las historias de usuario son una excelente herramienta para representar las necesidades del usuario y centrando el punto de mira en la aportación de valor.
Tradicionalmente los requisitos se plasmaban en grandes documentos con diagramas y fichas de casos de uso y otros modelos de la ingeniería del software. Los requisitos se percibían como un contrato cerrado sin tener presente los rápidos cambios que nos ofrece cada día el entorno.
¿Verdad que te suena eso de los cambios de requisitos?
Como apunta el Manifesto ágil, los requisitos cambiarán, incluso en las etapas más avanzadas del desarrollo. Normalmente los equipos de desarrollo reaccionan mal ante estos cambios y esto es un error. Como equipo nuestro propósito es aportar el máximo valor al cliente o usuario y todo su feedback en el uso del software debe ser bienvenido para la mejora del mismo.
Durante los últimos años he escrito bastantes artículos alrededor de las historias de usuario y como las podemos aprovechar para centrar el esfuerzo de un equipo de desarrollo y maximizar así el rendimiento. Todos estos textos han sido creados a partir de mi experiencia personal en la empresa privada y, en la mayoría de los casos, hemos obtenido unos resultados excelentes.
Te invito a leer estos posts para entender mejor las historias de usuario y como aplicarlas:
En este post te ofrecemos una visión general de las historias de usuario, explicando detenidamente sus tres elementos principales: la tarjeta, la conversación y la confirmación. Para el primer y tercer elemento también te damos, al final de la introducción, el acceso de forma totalmente gratuita a nuestra plantilla para crear historias de usuario.
Una historia de usuario es una representación de un requisito escrito en una o dos frases utilizando el lenguaje común del usuario. (Wikipedia)
Las historias de usuario son transversales a cualquier frameworks ágil que podáis estar usando, ya sea scrum, extreme programming (XP) o incluso kanban.
Una definición para cada elemento de las historias de usuario sería la siguiente:
Puedes descargarte aquí la la plantilla para definir historias de usuario (aquí si prefieres en Keynote).
Para que puedas utilizar bien la plantilla que acabas de descargar vamos a explicar brevente el formato de las historias de usuario y como aplicarlo. Cuando trabajamos con la visión del producto debemos llevar sólo las gafas del usuario y oblidarnos de los puntos técnicos, del equipo o las prioridades. Nunca debemos escribir historias de usuario que presenten descripciones técnicas.
El objetivo de las historias de usuario es describir qué necesita el usuario y cual es su beneficio sin importarle el cómo será la solución.
Las historias de usuario serán siempre en lenguaje común. Las historias de usuario deberán ser independientes entre ellas. Para que nos entendamos, una historia de usuario no tiene en cuenta el estado actual o futuro del producto, solo expresa una necesidad del usuario durante el uso del producto.
El estándard de las historias de usuario es una frase redactada que responde a las siguientes preguntas:
El resultado de la frase redactada tiene la siguiente sintaxis:
Como [rol] quiero [algo] para poder [beneficio].
Por ejemplo, en un eCommerce podríamos contar con las siguientes historias de usuario:
Una frase no es suficiente para describir una funcionalidad! Cierto, pero las historias de usuario no son solo una frase!
Las historias de usuario nos deben generar conversaciones profundas acerca de la funcionalidad. La conversación nos llevará a unos criterios de aceptación, en los que el equipo se alineará para acordar en qué consiste aquella funcionalidad y como se realizará.
Como estarás pensando, las historias de usuario son una herramienta muy interesante para fomentar la comunicación dentro del equipo. Las historias de usuario permiten que el product owner involucra a todos los miembros en la definición del producto.
Querido lector, si realmente quiere profundizar en las historias de usuario te recomiendo la lectura del libro de Mike Cohn, Historias de usuario aplicadas. Se trata de una buena introducción a las historias de usuario con el objetivo de identificar qué convierte una historia de usuario buena o mala.
Si eres product owner o trabajas con historias de usuario debes reforzar continuamente la idea de qué una simple frase escrita con una sintaxis determinada no significa que todos comprendan el auténtico valor.
Necesitamos entender que una historia de usuario es una promesa.
Cada una de las historias de usuario nos permite abrir un diálogo entre todos los miembros del equipo. La verdadera fuerza de las historias de usuario es el poder de las personas conversando y pensando por conseguir un objetivo superior.
Serán las conversaciones las que nos permitirán:
Querido lector, si trabajas con historias de usuario y no estás utilizando la conversación con estos objetivos estás dejando pasar la mayor oportunidad que te ofrece la herramienta. Recuerda que las historias de usuario nos ayudan a concentrar a todo el equipo en aportar el máximo valor posible en cada iteración.
Las conversaciones que promueven las historias de usuario tienen como objetivo principal la consecución de acuerdos sobre los distintos puntos hablados. Estos acuerdos, que quedarán reflejados en los criterios de aceptación, nos permitirán validar que una historia de usuario está terminada.
Los criterios de aceptación nos evitan la aparición de discrepancias futuras sobre la necesidad descrita en la historia de usuario. Como product owner o scrum máster debes promover que en la conversación participen todos los puntos de vista implicados (desarrollo, producto, operaciones, marketing, clientes, usuarios...
Cuantos más puntos de vista participen mayor será el entendimiento de la necesidad. A mayor entendimiento mayor facilidad en acordar qué significa realmente una historia de usuario. Querido lector, es en este momento cuando descubrirás la auténtica fuerza de las historias de usuario.
Seguro que no te descubro nada si afirmo que la comunicación es uno de los grandes problemas de las organizaciones. Una mala comunicación empieza a generar errores y la suma de ellos genera grandes bolsas de ineficiencias en las empresas. Esto también ocurre en los equipos de desarrollo ágil.
Cuantas veces no has vivido una discusión entre un desarrollador (o has sido tú el desarrollador) y un cliente interno de la empresa (tester, product owner, key account, marketing...) acerca de qué significaba un requerimiento una vez ya está programado o en producción?
Seguro que tu respuesta es que unas cuantas ocasiones. Seguidamente deberías pensar en el desperdecio de tiempo y esfuerzo que acabas de vivir y como harás que nunca más vuelvas a tener esta sensación.
Para tu suerte querido lector estás leyendo un articulo que te ofrece las herramientas y conocimientos para empezar a solucionar está situación y aprovechar la fuerza que las historias de usuario te ofrecen, la comunicación implicada en el valor para el usuario.
Si quieres saber más acerca de cómo las historias de usuario nos ayudan a motivar al equipo puedes leer este post, en el que se plantea que a los humanos nos gustan las historias y no las tareas.
El resultado que debes obtener de la conversación son unos criterios de aceptación claros y específicos que todo el equipo comprenda exactamente de la misma forma. Los criterios de aceptación nos permitirán evaluar en el futuro si la implementación que se está desarrollando olas pruebas que se realicen está terminada.
De algún modo podemos afirmar que lo que hacemos es detallar la historia de usuario para:
Como escribe Jerónimo Palacios, los criterios de aceptación cumplen principalmente la función de clarificar el contexto el que ocurre la historia de usuario y facilitar la identificación de que una historia de usuario está realmente terminada.
Querido lector, en mi opinión el formato de las criterios de validación debe ser aquél en el que el equipo se sienta comfortable. En todos los equipos en los que he participado han sido frases muy simples y concisas en las que todos entendíamos exactamente lo mismo.
Aún así, los estándares marcan que los criterios de validación también tienen su sintaxis definida. Si no estás acostumbrado a trabajar con historias de usuario empieza utilizando esta sintaxis:
Escenario [número] - [Título del escenario (opcional)]: En caso que [contexto] y adicionalmente [contexto], cuando [evento], el sistema [resultado / comportamiento esperado].
Un error frecuente cuando empiezas a trabajar con historias de usuario es construir historias demasiado largas. La conversación y consecución de los criterios de validación nos ayudarán a detectar los casos en los que necesitamos dividir una historia de usuario.
Si has llegado hasta aquí y has leído atentamente acabas de aprender una herramienta que puede ser clave para potenciar la participación dentro del equipo y en la toma de decisiones sobre el trabajo a realizar.
Has aprendido a valorar que un equipo auto-organizado y con la capacidad de decidir sobre la evolución del producto avanzará más rápido y en la dirección deseado por parte de los clientes, negocio o ,los más importantes, los propios usuarios
Con esto aprendido solo que grabes en tu mente que las historias de usuario son una herramienta para mejorar la comunicación entre las personas involucradas. Si no generas conversaciones sobre las historias de usuario tienes un grave problema.
Querido lector, deja de quejarte diciendo que las historias de usuario no son lo bastante completas o concretas o que en producto escriben malas historias de usuario. En lugar de la queja, usa la conversación. Es el punto de partida para generar acuerdos.
Ante una historia de usuario levántate, junta a los involucrados, empieza una conversación y generad acuerdos.
Recuerda siempre que todos deben participar en la definición de las historias de usuario. Cuando digo todos es todos: product owner, developers, clientes, usuarios, marketing, operaciones...
Cuanto mayor sea el número de personas involucradas en el acuerdo más fácil será trabajar en la dirección correcta, que se traducirá en aportar el valor deseado y esperado a nuestro producto.
Menos es más.
Las historias de usuario nos permiten definir las funcionalidades de una forma concreta, pequeña, fácil de mantener y sin grandes documentaciones. Si la comunicación es un problema, la documentación excesiva también lo es. Las historias de usuario deben contener sólo la información imprescindible.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>El desarrollo iterativo (o incremental) es el proceso de desarrollo de software que consiste en la división del trabajo en pequeñas etapas repetitivas. Estos bloques temporales, bajo la metodología Scrum, se denominan sprints. En el desarrollo iterativo es una buena práctica que estos bloques temporales sean regulares, en Scrum es obligatorio, los sprints siempre duran lo mismo.
En el desarrollo iterativo al final de cada etapa se entrega una funcionalidad completa. Para plantear la evolución del producto es muy recomendable crear el Mínimo Producto Viable (Minimum Viable Product, MVP) y evolucionar con el feedback y necesidades del cliente. Bajo estos paradigmas el uso de Scrum como metodología de trabajo encajan a la perfección.
Definimos Mínimo Producto Viable como el producto con suficientes características para satisfacer a los clientes iniciales y proporcionar retroalimentación para el desarrollo futuro (Wikipedia).
El MVP debemos entenderlo como una herramienta para aprender mientras desarrollamos y entregamos el producto. Nos sirve para comprobar nuestras suposiciones o hipótesis. Gracias a la iteración continua evolucionamos el producto y reducimos el tiempo para la validación de las nuevas ideas.
A medida que avanzamos con el producto, ir creando las nuevas funcionalidades bajo el mismo patrón de trabajo nos permite validar donde merece la pena invertir. Una vez se conoce se pueden dedicar todos los esfuerzos en trabajar sobre las mejores soluciones para nuestro negocio. Si te interesa como aprender junto al Mínimo Producto Viable en este post.
Cuanto antes se entregue al cliente, antes nos dirán si estamos trabajando en lo que necesitan.
Ken Schwaber y Jeff Sutherland, en su libro Software en 30 días, se centran en demostrar y describir como sacar una ventaja competitiva a la entrega de software funcionando en un período de 30 días.
La motivación del desarrollo iterativo se fundamenta, principalmente, bajo estas dos premisas:
El desarrollo iterativo nos permite sacar una ventaja competitiva gracias a lo que se ha aprendido a lo largo de todo el desarrollo anterior. Este aprendizaje no debe quedarse sólo en el mundo de desarrollo, debe extenderse hacia toda la empresa.
En Scrum la figura del Product Owner es quien tiene la responsabilidad de definir las siguientes iteraciones. El Product Owner debe tener un conocimiento profundo del mercado, del producto y de las capacidades el equipo. Es el encargado de recoger el feedback del cliente o de los usuarios y aplicarlo en las próximas iteraciones.
En cada una de las iteraciones el equipo debe buscar la fórmula de aportar el máximo valor posible al cliente o a los usuarios. Es ya conocido que la palabra mínimo no se refiere a mal hecho o mal terminado, que no se trata de la ley del mínimo esfuerzo.
Mínimo se refiere a la mínima solución que permita satisfacer una necesidad. El MVP inicial se presenta a los early adopters del software en desarrollo. En esta línea Steve Blank, emprendedor en serie y profesor de Silicon Valley, comenta sobre la creación del MVP:
Estás vendiendo la visión y entregando el conjunto mínimo de características a visionarios, no a todo el mundo.
En la definición del MVP inicial y su futura evolución en las distintas iteraciones es necesario unir la usabilidad con el proceso de desarrollo, pero no es suficiente asignar técnicas de usabilidad durante las actividades de desarrollo.
Entre las técnicas de usabilidad que necesitaremos aplicar las hay que no se pueden aplicar en cualquier momento del desarrollo del producto. En alguno casos es necesario trabajarlas en el momento que se identifican las necesidades, cuando definimos cómo será el producto en el que trabajar. Para ello el desarrollo iterativo se divide en dos grandes fases: inicialización e iteración.
La etapa de inicialización es la inicial del proyecto y consiste en crear una primera versión del sistema, el MVP inicial. El objetivo principal de esta etapa es crear un producto con el que el usuario pueda interactuar y empezar así a retroalimentar el proceso de creación.
En este momento se define el primer MVP y se marcan las líneas generales de la solución. De este modo se puede ofrecer de una forma simple para que pueda ser comprendida, implementada y usada por el equipo y el cliente.
En esta definición el desarrollo iterativo incorpora una lista de control de proyecto. Esta lista consiste en generar un historial de todas las tareas que se deben realizar. En Scrum esta lista de tareas se llama Product Backlog y no contiene tareas sino historias de usuario.
En Scrum el Product Owner es quien define las historias de usuario y tiene la responsabilidad (y el poder) de ordenar el product backlog. Estos reordenamientos constantes permiten adaptar el desarrollo a las necesidades del cliente o usuario. Estos cambios se definen gracias al feedback directo y/o a las analíticas de uso del software.
Bajo esta visión los calendarios concretos a mucho tiempo vista (dos o tres meses) no permiten adaptar el desarrollo al feedback y podría generar malestar al cliente o decepción a los usuarios al no trabajar en línea con sus necesidades.
Para saber más acerca del backlog vista como una poderosa herramienta de priorización y generación de valor en Scrum pudes leer este post.
La etapa de iteración consiste en el rediseño e implementación de cada una de las tareas de la lista de control, o historias de usuario del product backlog en Scrum.
El principio de Pareto aplicado al software consiste en que el 80% del valor del producto reside en el 20% de las funcionalidades. Plantear el desarrollo como un proceso de iteración constante nos permite centrar todos los esfuerzos en las necesidades que realmente importan a nuestros usuarios.
No debemos preocuparnos porqué el product backlog se vaya llenando. Debemos tener asumido que habrá muchas historias de usuario que nunca deberemos construir, que nunca serán una prioridad o que cambiarán su planteamiento. Debemos trabajar siempre sobre el 20% de funcionalidades que aportan valor al software e ir adaptando la evolución del producto.
Es importante destacar las historias de usuario. Si lo reducimos mucho: a los humanos no nos gustan las tareas, estamos hechos para las historias. Scrum apuesta por el uso de historias de usuario que sirvan para identificar quien necesita una cosa y para qué.
Si quieres conocer más acerca de cómo las historias de usuario pueden servirte para mejorar la productividad, motivación y calidad en el trabajo del equipo puedes leer este post.
Nadie de nosotros ha nacido ágil ni nunca seremos suficientemente ágiles. Los recursos siempre serán limitados y siempre podremos mejorar el flujo, la comunicación, un proceso, eliminar un despilfarro...
En el camino hacia la agilidad nos encontraremos problemas y situaciones a resolver o mejorar. En el desarrollo iterativo (y dicen o incremental) el problema principal es olvidar la palabra iterativo.
Si estamos trabajando en un producto y nos centramos sólo en incremental y nos olvidamos de iterativo tenemos un problema. Si quieres leer más acerca de las diferencias entre iterativo e incremental te recomiendo este post de Javier Garzás en el que puedes leer qué pasa cuando olvidamos el iterativo.
A modo resumen:
El desarrollo iterativo consiste en planificar el proyecto en un formato de bloques temporales. En Scrum estos bloques son siempre iguales y se denominan sprints. En cada una de las iteraciones es necesario entregar una funcionalidad completa sobre el producto final.
Un buen planteamiento en la fase de iteración es pensar en el MVP de una nueva funcionalidad o de una mejora sobre una existente. Para ello es una buena práctica plantearlo como mini proyectos sobre el producto actual. De este modo podemos iterar sobre él y aumentar el valor percibido.
Cada iteración y entrega nos sirve para aprender.
El cliente y los usuarios nos aportan un conocimiento gracias a su feedback directo o datos estadísticos sobre el uso del software. El feedback recogido nos permite reordenar y priorizar el product backlog y así poder destinar siempre los esfuerzos en aquellos puntos que realmente son importantes para nuestro producto.
Puedes leer este post de proyectosagiles.org acerca del desarrollo iterativo, en el que se pone principal foco en los beneficios, restricciones y recomendaciones en su aplicación.
Ante mentalidades poco próximas al manifiesto ágil es difícil aplicar el desarrollo iterativo. Constantemente se necesitará un calendario completo de todo lo que se realizará, poniendo émfasis a la palabra incremental y no a la iterativa. Si tenemos un calendario completo con todas las nuevas funcionalidades a desarrollar no dejamos espacio a la mejora de las existentes ni a la aportación de nuevas ideas o necesidades al cliente o usuario.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Aprender. Aprender de los errores. Un tópico y una verdad profunda. Un error es una oportunidad para aprender. Una organización no debe buscar culpar a las personas, en la resolución de problemas se deben aplicar acciones correctivas, verificar su correcto resultado y compartir el conocimiento a todas las líneas.
La clave está en entender el término aprender. Una organización debe tener la capacidad de aprender cada día, proponer soluciones en base al conocimiento y pruebas de distintas alternativas y comunicar la solución mediante la inclusión de la misma en los procesos de la compañía. En una organización que aprende las personas que la forman amplían de forma continua la capacidad de crear los resultados que realmente quieren. Las personas que desarrollan la capacidad de aprender a aprender alimentan patrones de pensamiento nuevos y expansivos. Una organización que aprende tiene una aspiración colectiva libre y busca continuamente cómo aprender juntos.
Una organización que aprende sólo es posible con una mirada de largo plazo. La gran mayoría de las empresas se orientan a programas que sólo pueden proporcionar unos resultados financieros a corto plazo. En Toyota opinan:
La cultura Toyota apuesta por orientarse al largo plazo, invirtiendo en sistemas de personas, tecnología y procesos que colaboran para conseguir un valor elevado para el cliente.
Cuando dicen "sistemas" no se refieren a los sistemas de información. Se está haciendo referencia a los sistemas de trabajo y procedimientos adecuados para llevar a cabo una tarea con la mínima cantidad de tiempo y esfuerzo (y máxima calidad). La convicción consiste en un enfoque al proceso donde la mejora continua hará alcanzar el resultado financiero deseado.
El Modelo Toyota hace referencia a la organización que aprende en su principio 14: "Conviértase en una organización que aprende mediante la reflexión constante (hansei) y la mejora continua (kaizen)". ¿Sabes cómo puede ayudarte el modelo Toyota en la mejora continua usando metodologías ágiles?
Para afrontar la resolución de problemas, el primer paso es encontrar la raíz del problema. Para encontrar la raíz del problema es muy importante desplazarse al lugar de los hechos para analizar de forma profunda y en primera persona que está pasando. La misión en la resolución de problemas es poder proponer una contramedida que asegura que el problema no pueda volver a suceder. Para ello primero es necesario la observación para poder empezar a buscar el origen real del problema.
Si quieres saber mas acerca cómo trabajar el análisis de la situación para entenderla bien y poder aplicar contramedidas puedes leer acerca de Genchi genbutsu para entender la situación real en el lugar de los hechos.
Una vez se ha hecho este análisis de la situación es necesario buscar la raíz del problema. En Toyota explican, irónicamente, que tienen un sofisticado sistema para encontrar el origen del problema: preguntar 5 veces "por qué".
En los programas de formación acerca del Modelo Toyota para explicar esta poderosa herramienta (ahora sin ironía) utilizan de ejemplo el caso real en el que se encontraron cuando implantaron un nuevo sistema de correo electrónico, a priori, mejor técnicamente, con más capacidad... La realidad fue que cuando se implantó los usuarios no paraban de quejarse del nuevo sistema.
La secuencia de preguntas y respuestas es la siguiente:
Una vez identificada la raíz del problema (la alta dirección no ha dedicado esfuerzon en crear la cultura de trabajo esperada) se puede empezar a trabajar en distintas alternativas para escoger la mejor contramedida. En este caso la contramedida seleccionada fue incluir formación y mucho seguimiento de la alta dirección para crear una cultura que apoye el empleo de buenos procesos internos que sigan los principios del Modelo Toyota.
¿Que aprendizaje debemos obtener de este ejemplo? Es imprescindible preguntarse de forma continuada "por qué" hasta encontrar la raíz del problema. Sea cual sea. Una vez identificado se pueden tomar contramedidas contra el nivel más profundo de las causas, que sea posible, para evitar la recurrencia del problema.
Si la resolución de problemas termina con la comunicación de la solución y su inclusión en los procesos relacionados para evitar que se pueda volver a reproducir el mismo problema parece bastante lógico tener un procedimiento para la resolución de problemas. En el TPS hay estandarizado un proceso de 7 pasos para la resolución práctica de problemas. El objetivo del proceso es solucionar el problema aplicando contramedidas sobre la raíz del problema y no sobre las causas directas.
El proceso que se describe es el siguiente:
Sólo conseguiremos ser una organización que aprende si el proceso termina con la estandarización de la contramedida. Sin una correcta comunicación la transmisión del conocimiento adquirido en la resolución de problema no podremos asegurar que se distribuya por todos los equipos de la organización ni que no volverá a suceder.
Si no se estandariza el proceso mejorado, el aprendizaje realizado cae en un agujero negro, perdido, olvidado y no queda disponible para mejoras posteriores.
Si quieres saber más acerca de las prácticas de Toyota para la resolución de problemas puedes leer este post.
El trabajo en equipo nunca sustituye a la responsabilidad individual. La responsabilidad individual no consiste en ser entendida en formato de quejas o castigos. Nuestra responsabilidad como individuos son el aprendizaje y crecimiento. El término japonés hansei, utilizado también en la cultura Toyota, es importantísimo para el trabajo para aprender a aprender.
La traducción literal de hansei es reflexión. En Japón consideran que los occidentales no comprendemos este concepto de una forma global. Ante este problema de concepto, cuando Toyota explica este concepto a directivos en Estados Unidos o Europa lo introduce así:
Sin hansei (reflexión) es imposible tener kaizen (mejora continua). En el hansei japonés cuando uno hace algo mal hecho, al principio debe sentirse realmente, realmente triste. Luego, debe plantear cómo en el futuro resolverá el problema y debe creer, sinceramente, que no volverá a cometer este tipo de error. Hansei es un modo de pensar, una actitud. Hansei y kaizen van de la mano.
El ciclo de aprendizaje lo podemos expresar como: Planificar - Hacer - Controlar - Actuar. En la imagen anterior relacionamos el ciclo de aprendizaje con la creación de flujo, aflorar los problemas, crear contramedidas y evaluar los resultados. Este proceso debe aplicarse a todos los niveles de la empresa, desde los grupos de proyecto a la globalidad de la organización. Puedes leer este post acerca de cómo el Scrum Máster crea flujo y ayuda en la superación de impedimentos.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>La toma de decisiones es un proceso crítico para cualquier organización. Las decisiones marcan el futuro y evolución de la compañía. La forma cómo se tomen estas desiciones influenciará su ejecución y éxito.
En la cultura Toyota es importante tomar las desiciones por consenso. De hecho de todas las formas en las que se toman decisiones ésta es la favorita para Toyota. Analizar concienzudamente todas las opciones es una buena práctica del Modelo Toyota aplicables a las metodologías ágiles o Scrum.
Necesitamos estudiar detalladamente todas las alternativas posibles con el objetivo de eliminar posibles resistencias y/o problemas en la ejecución. Previo a la toma de decisión final debemos haber comprendido profundamente la situación y analizado todas las posibles acciones y alternativas.
En Toyota el cómo uno llega a la decisión es tan importante como la calidad de la decisión.
El Sistema de Producción de Toyota (Toyota Production System, TPS) cuenta con 14 principios de gestión muy aplicables a la mejora continua en Scrum. Puedes leer este breve resumen del Modelo Toyota.
En la toma de desiciones se distinguen los siguientes elementos principales:
Si asumimos que tan importante es cómo se llega a una decisión como la calidad de la misma, en Toyota se apuesta que la toma de decisiones se hará mediante el consenso dentro del equipo. En este proceso de generación del consenso también participan los proveedores externos.
Tomar las decisiones por consenso responde al principio número 12 del Modelo Toyota. Se trata de Nemawashi, un concepto muy importante no sólo para la cultura Toyota sino para entender el mundo empresarial japonés. La traducción literal sería "revolver las raíces", que vendría a decir: cavar alrededor de las raíces del árbol para hacer el transplante.
Actualmente este concepto se usa para nombrar el proceso mediante el cual se toman las decisiones que implican cambios en la empresa. Este proceso consiste en consultar de forma previa a los implicados antes de proponer un cambio en la empresa. Este proceso busca siempre el consenso y la armonía.
Nemawashi permite eliminar las discrepancias y llegar a un acuerdo con el que todos están contentos.
En Toyota se apuesta por una toma de decisiones por consenso. Se realiza lentamente y considerando concienzudamente todas las opciones. El objetivo es poder implementarlas muy rápidamente y de forma segura.
La forma en la que se genera este consenso es que el personal más junior trabaja en el desarrollo de una propuesta y la hace circular de forma amplia por todo el equipo. El objetivo es generar lograr un consenso entre los más sénior y responsables de equipos para que termine siendo aprobada por la dirección.
El proceso de generar un consenso por todas las partes del equipo puede parecer que será lento, complicado. Para que este proceso no sea doloroso y se fluya de una forma muy ágil la comunicación es un elemento clave. Se necesitan vehículos de comunicación muy eficientes, que permitan entender la propuesta para poder ofrecer su visión y opinión. Para ello debe comunicarse los antecedentes, situación actual y la solución que se plantea.
En muchas empresas se usan informes largos, con muchas descripciones técnicas, jerga de negocio y muchas tablas con datos o gráficas. No hay una forma más difícil y que consume más tiempo que descifrar uno de esos informes para comprender una idea compleja.En Toyota se apuesta por utilizar una sola hoja de papel A3 y a una sola cara. En este documento se debe plasmar toda la información necesaria para tomar una decisión compleja. Este procedimiento es uno de los aspectos diferenciales de Toyota en la transmisión de la información.
El documento en formato A3 actúa como una herramienta de ayuda y soporte visual.
Estos documentos A3 describen al completo una propuesta. Cuentan con la información necesaria para comprender la situación, la planificación, ejecución y control. El documento contaría con esas partes:
A continuación tienes un documento ejemplo en el que se expone la propuesta de implementación de la tarjeta de compra.
Aún entender que un documento A3 es mucho más fácil de digerir que un amplio informe, seguro que estás pensando que el proceso de llegar a un consenso te traerá reuniones muy largas, duras y con momentos bastante inútiles. Para poder generar un consenso es necesario tener un formato de reuniones muy eficientes y que nos ayuden en la resolución de problemas.
Prerequisitos necesarios para una reunión eficaz:
El análisis de la situación en primera persona y en el lugar de los hechos, junto a un completo aprendizaje para obtener un conocimiento profundo sobre la propuesta que se está debatiendo facilita la toma de decisiones, puesto que todas las visiones están analizadas y existe un consenso.
Necesitamos lograr un conocimiento profundo antes de planificar o implementar nada.
Es crítico poder descubrir todos los hechos que, de no haberse considerado, pueden conducir a una gran cantidad de problemas. En consecuencia nos desviaríamos del camino correcto. Mientras que ante unas normas establecidas en la planificación la ejecución tiende a ser impecable.
Para generar el consenso es necesario invitar a las sesiones de trabajo a todos los afectados para que ayuden y formen parte de la decisión. Cualquier resistencia se debe solucionar antes de empezar a implementar. Si empezamos la implementación, el coste resultante de resolver una resistencia es muchas veces mayor que el coste de resolverlo en la fase de planificación.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>La resolución de problemas, la mejora continua y el aprendizaje colectivo son conceptos que van muy de la mano. La resolución de problemas nos aporta soluciones para la mejora continua y cuando una solución es aceptada, necesitamos estandarizarla y comunicarla a toda la organización. Se trata pues de la transmisión del conocimiento entre las personas y los departamentos.
En Toyota está muy arraigada la idea de desplazarse al lugar de los hechos y observar la situación por uno mismo para poder comprenderla. Se trata del concepto "Genchi genbutsu", que traducido de forma literal, genchi significa "la ubicación real" y genbutsu "los materiales o productos reales". En concreto se trata del principio número 12 del Modelo Toyota. Se trata pues de una apuesta de ir a confirmar los hechos por uno mismo y a responsabilizarse de la información que se da a otras personas.
Si quieres leer un breve resumen de los 14 principios del Sistema de Producción de Toyota (Toyota Production System, TPS) puedes leer este post acerca de cómo aplicar el Modelo Toyota para la mejora continua en Scrum.
Lo que uno ve en primera persona podría no verlo en informes escritos, tablas con números y gráficas.
Genchi genbutsu trata de cómo afrontar la resolución de problemas. Apuesta por un conocimiento profundo de la situación ganado gracias a la observación en primera persona y en el lugar de los hechos. El Modelo Toyota destina 3 principios para la resolución de problemas. Puedes leer esta post para ver cómo aplicar estos principios sobre la resolución de problemas en la metodología Scrum.
Taiichi Ohno (ver fotografía del post), máximo responsable de las implantaciones del Sistema de Producción de Toyota, tenía una práctica habitual muy curiosa. Se desplazaba a la factoría, dibujaba un círculo en el suelo y se quedaba en él observando la situación. Taiichi Ohno era ingeniero de procesos y fue uno de los máximos impulsores del genchi genbutsu.
Esta práctica a derivado a que se conozca cómo el círculo de Ohno, una técnica para la observación y la resolución de problemas de la cultura Toyota.
Existen muchas anécdotas acerca de los aprendizajes en el uso del círculo de Ohno. Estas anécdotas nos ayudan a comprender la importancia de desplazarse al lugar de los hechos y observar la situación por uno mismo.
Teruyuki Minoura, presidente de Toyota Motor Manufacturing en Norte América, aprendió el Sistema de Producción de Toyota del mismo maestro, Taiichi Ohno. En una entrevista de Jeffrey K. Liker, Minoura explica su experiencia de aprendizaje mediante el círculo de Ohno.
- Minoura: El señor Ohno quería que dibujáramos un círculo en el suelo de la fábrica y luego nos decía: "Quédate ahí de pie y observa el proceso y piensa por ti mismo", y no nos daba ningún indicio de lo que teníamos que observar. Esta es la esencia real del TPS.
- Liker: ¿Cuánto tiempo permanecían en el círculo?
- Minoura: ¡Ocho horas!
- Liker: ¿Ocho horas?
- Minoura: Por la mañana venía el señor Ohno y pedía que estuviese en el círculo hasta la comida y después venía el señor Ohno para comprobar y preguntaba qué es lo que había visto. Y yo naturalmente le contestaba (reflexiona), le contestaba: "Hay tantos problemas en el proceso..." Pero el señor Ohno no escuchaba. Sólo estaba mirando.
- Liker: ¿Qué pasaba al final del día?
- Minoura: Era cerca de la hora de cenar. Vino a verme. No me dio tiempo a darle ningún informe. Sencilla y delicadamente me dijo: "Vete a casa".
¿Qué enseño Ohno a Minoura exactamente? La fuerza de la observación profunda. Minora aprendió a pensar él solo en lo que estaba viendo. Aprendió a tener una visión crítica, que le permitía analizar la situación y buscar mejoras. El círculo de Ohno ayuda a pensar por uno mismo sobre lo que se está viendo.
Cuestionar - Analizar - Evaluar
Toyota promueve y espera el pensamiento creativo y considera la innovación como una obligación. En ambos casos es obligatorio que este pensamiento creativo o cualquier innovación se apoyen en un conocimiento profundo de todos los aspectos de la situación real. Genchi genbutsu no solo se usa para la resolución de problemas, sino para cualquier trabajo que requiera un conocimiento profundo de la situación. Sí, hablamos de procesos, tecnología, materiales, maquinaria, equipo...
Este conocimiento profundo acerca de la situación se considera uno de los aspectos diferenciales de la cultura Toyota. No se puede dar nada por supuesto, es obligatorio conocer en profundidad el tema del que se está hablando. La observación desde el lugar de los hechos permite conseguir más fácilmente este conocimiento puesto que se hace de primera mano.
El Presidente del Toyota Technical Center, Tadashi Tamashina, redactó estos 10 principios de gestión:
Los principios 3 y 4 hacen referencia a genchi genbutsu. El quinto principio tiene un enfoque al cómo comunicar y transmitir la información y conocimiento a otra personas o equipos. El conocimiento debe fluir entre todos aquellos que se puedan beneficiar de ello.
Genchi genbutsu apuesta por desplazarse al lugar de los hechos y entender la situación por uno mismo. La observación crítica y el conocimiento profundo de la situación ayudan en la resolución de problemas y la toma de decisiones.
Lee este post si estás interesado en los procesos de toma de decisiones dentro la cultura de Toyota.
Cuando hablamos con nuestros clientes o usuario debemos mostrarnos con un conomiento profundo sobre nuestro producto. Si no lo conocemos con exactitud ¿cómo podremos ofrecer la seguridad suficiente a nuestro cliente? Y cuando ocurra un problema, que puede pasar, ¿cómo daremos la seguridad al cliente que no volverá a ocurrir y de que se tomarán las correcciones necesarias?
El vicepresidente del Toyota Technical Center, David Bacter, cuenta que, en sus funciones de evaluación de proveedores, tuvo que gestionar unos problemas con un fabricante de componentes de Estados Unidos. Para calmar la situación ante el problema generado, el vicepresidente de la unidad de negocio que servía a Toyota se presentó al Toyota Technical Center, para dar confianza y hablar de cómo iban a solucionar el problema. Él intentaba explicar de una forma tranquilizadora...
- Lo siento profundamente. No se preocupen. Pondré personalmente atención. Vamos a resolver el problema. No tiene justificación...
Ante tal explicación, los responsables de Toyota empezaron a preguntar cual era el problema y cuales eran los planes que se adoptarían para su resolución. A estas preguntas el vicepresidente del proveedor respondió:
- Oh, todavía no lo sé y no suelo entrar en este tipo de detalles. Pero no se preocupen! Llegaremos al fondo del problema y lo resolveremos. Se lo prometo!
Esta respuesta no fue aceptada. ¿Podían los responsables quedarse tranquilos con esta explicación? En Toyota es totalmente inadmisible acudir a una reunión de tal gravedad con tan poca información y trabajo hecho. ¿Cómo se puede dar explicaciones con seguridad si ni tan solo se ha visto el problema por uno mismo?
La respuesta que obtuvo por parte de los responsables de Toyota fue que fuera tan amable de regresar a su sitio de trabajo, observar el problema por si mismo y no volver hasta poder dar explicaciones de cual es el problema y qué contramedidas se ejecutarán para que no vuelva a ocurrir.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Scrum y las metodologías ágiles apuestan de forma clara por la mejora continua. En el camino hacia la agilidad se necesita eliminarlos impedimentos que nos vamos encontrando. Conseguir crear flujos de trabajo dinámicos nos sirve para una mejor transmisión de la información. La mejora continua es indispensable para el buen funcionamiento de un equipo o de una organización.
El aprendizaje colectivo dentro de la organización se impulsa mediante la resolución continua de problemas. Cuando se utiliza la metodología Scrum, el Scrum Máster es la persona encargada de facilitarla. El Scrum Máster también se denomina agente del cambio por este motivo. Entre sus responsabilidades destacan el facilitar la eliminación de los impedimentos y crear las dinámicas necesarias en las reuniones retrospectivas. Necesitamos sacar a la luz los problemas del equipo.
Sólo cuando un problema se hace visible podemos empezar a trabajar para solucionarlo.
Para poder tomar decisiones correctas debemos tener visibilidad del día a día. Cualquier equipo tiene la obligación de analizar los problemas y proponer soluciones. Para analizar un problema no podemos hacerlo de forma superficial, sino que debemos encontrar el verdadero origen, la raíz del problema. Para ello es indispensable:
La reunión retrospectiva es la dinámica que propone Scrum para potenciar la mejora continua dentro del equipo. En algunos casos empezar a crear esta dinámica puede ser complicado. Descubre como crear una dinámica para la mejora continua con reuniones retrospectivas muy productivas.
Sakashi Toyoda, fundador de Toyota Industries y miembro del Sistema de Producción de Toyota (Toyota Production System, TPS), desarrolló el concepto de los 5 "por qués". Se trata de una técnica que consiste en preguntar 5 veces el "por qué" de un problema en el momento en que aparece. De esta forma se consigue llegar a su origen y se puede plantear una solución que impida que vuelva a ocurrir.
Se trata de una técnica de preguntas iterativas. Cada respuesta a la pregunta anterior forma parte de la pregunta siguiente. El número 5 se estima como el número de iteraciones que típicamente se requieren para conseguir conocer la raíz del problema.
No todos los problemas cuentan con un sólo origen. Es lógico que cuando apliquemos la técnica de los 5 "por qués" estemos en este caso. Para descubrir todas las causas que generan un problema necesitamos iterar entre todas las respuestas que se puedan dar a una pregunta. Y así sucesivamente. Imaginemos gráficamente la secuencia de preguntas y respuestas, si iteramos sobre una única respuesta estamos dibujando una línea, mientras que si iteramos sobre distintas respuestas hacemos un árbol.
En la técnica de los 5 "por qués" no se impone cuantas líneas deben ser exploradas. Estamos ante un método que, aunque se aplique de forma muy cuidadosa, sus resultados siempre dependen del conocimiento, la persistencia y la motivación de las personas involucradas. Si quieres saber cómo motivar a tu equipo puedes leer este post acerca la motivación de equipos en Toyota o este otro sobre cómo motivar a un equipo gracias a la metodología Scrum.
Un ejemplo clásico de los 5 porqués es el siguiente:
Este método está pensando para ser usado por equipos expertos. Es una herramienta muy poderosa para encontrar las causas reales de los problemas. Aún así esta técnica cuenta con algunas limitaciones que debemos tener presente en su uso:
En la metodología Scrum se apuesta por una dinámica de reuniones con objetivos muy concretos para maximizar la productividad del equipo. Si quieres conocer cómo hacer reuniones más productivas gracias a Scrum puedes leer este post. La técnica de los 5 "por qués" nos puede ser muy útil en la reunión retrospectiva, dónde debemos seleccionar un problema a solucionar en la siguiente iteración.
Los impedimentos son inherentes al desarrollo de cualquier producto o implementación de un proyecto. Los impedimentos irán apareciendo y será la obligación del equipo eliminarlos y superarlos con éxito. Un impedimento puede ser provocado por una mala dirección, definición o planificación del proyecto. Así mismo también existen impedimentos que son imponderables, pueden suceder en cualquier momento. El equipo tiene la responsabilidad de estar atento en su trabajo y detectar cuanto antes cualquier impedimento que se pueda encontrar.
Aquí no se buscan culpables, se buscan soluciones.
Algunos de los impedimentos típicos que cualquier equipo se puede encontrar son:
No todos los problemas son causados por terceros. El equipo también puede estar generándose impedimentos de una forma involuntaria. Por ejemplo cuando nos encontramos ante una mala implantación de la metodología Scrum generaremos algunos impedimentos que deberemos afrontar. Algunas veces nos encontraremos ante problemas arraigados en la cultura del equipo, superar estos problemas endémicos se convertirá en una de las grandes bazas para la implantación de la metodología.
Podemos destacar estos impedimentos debidos a una pobre implantación de Scrum:
Si detectamos un impedimento el Scrum Máster debe facilitar que se afronte de inmediato. Cuanto más tardemos en tratar este impedimento más fácil será que se convierta en un problema. El Scrum Máster es la persona encargada de dar luz a los impedimentos y a ayudar a generar un flujo de trabajo ágil. Lee este post para entender como el Scrum Máster actúa de agente del cambio.
La resolución continua de los problemas impulsa el aprendizaje organizativo. Es indispensable identificar sus causas y evitar que vuelvan a pasar. Recuerdas lo de que "el hombre es el único animal que tropieza dos veces en una misma piedra?".
Analizar - Reflexionar - Comunicar
Ésta es la apuesta de Toyota. Bajo esta secuencia de acciones se considera la mejora continua. Cuando se encuentra una solución a un problema y se da por valida, es necesario entrar en un proceso de estandarización sobre esa solución. Con un estándard documentado conseguimos que el conocimiento fluya por toda la organización. Se trata de garantizar que este problema no vuelva a ocurrir.
El Sistema de Producción de Toyota está formado por 14 principios. Puedes leer este post resumen del Modelo Toyota para entender como pueden ayudarte sus principios en la mejora continua usando la metodología Scrum. Los tres últimos principios hacen referencia a la resolución de problemas. A continuación veremos una breve introducción de cada uno de estos tres principios para entender cómo nos puede ayudar la cultura de Toyota en nuestro trabajo en equipo.
Cuando nos encontramos delante de un problema es importante pensar y hablar en base a unos datos e informaciones verificadas, comprovadas y contrastadas. Para ello es importante ir al lugar de los hechos y comfirmar la información por uno mismo. Debemos sacar ventaja de la sabiduría y experiencia de otros para enviar, recoger o debatir la información. Para aprofundizar en este principio puedes leer este post acerca genchi genbutsu.
Ir y comfirmar los hechos por uno mismo es tan importante como responsabilizarse de la infromación que se da a otros.
Este principio se puede explicar con una comparación. Todos sabemos que las comparaciones son odiosas, pero nos puede servir para entender que significa tomar decisiones lentamente e implementarlar muy rápido.
Si suponemos un proyecto tipo de un año, la mayoría de las empresas americanas o europeas tardarán unos tres meses en la planificación. A continuación empezará su implementación. A partir de este momento se irán encontrando problemas y dedicarán el resto del año a desarrollar el proyecto y a solucionar los problemas que vayan saliendo.
Ante el mismo proyecto, Toyota invertirá de nueve a diez meses en la planificación. A continuación implementará la solución a pequeña escala, como si de un piloto se tratara. Antes de final de año estará totalmente implementado y prácticamente sin ningún problema pendiente.
Con esta introducción puede parecer que este principio puede chocar con algunos principios ágiles. Puedes leer este post para entender la paradoja entre el principio 13 del método Toyota y las metodologías ágiles.
Uno de los mejores cumplidos que podríamos realizar a una empresa de hoy en día es que sea una verdadera organización que aprende. Una organización que aprende es una organización que aprende a aprender. No se trata sólo de adoptar y desarrollar nuevos negocios, habilidades o técnicas. Una organización que aprende implanta un segundo nivel de aprendizaje para aprender nuevas habilidades, conocimientos o capacidades.
A palabras de Peter Senge, en su libro "La quinta disciplina" (1990), define a una organización que aprende como un lugar:
"... donde las personas amplían contínuamente su capacidad para crear los resultados que de verdad quieren, donde se alimentan patrones de pensamiento nuevos y expansivos, donde la aspiración colectiva es libre y donde se está contínuamente aprendiendo cómo aprender juntos."
Debemos tratar los problemas como una oportunidad para aprender. En lugar de culpar a las personas, las organizaciones deben tomar decisiones correctivas y distribuir el conocimiento sobre todas sus experiencias. Puedes leer este post acerca de cómo convertirse en una organización que aprende.
Un problema debe ser abordado cuanto antes posible. Scrum nos ofrece las herramientas para hacer aflorar los problemas. Si no tratamos un problema de inmediato, tardaremos más tiempo en el futuro en arreglarlo. Nos podemos encontrar que a veces esperamos demasiado en declarar una emergencia. Si nos encotramos en esta situación el principipal perjudicado es el propio equipo, puesto que deberá afrontar su resolución con un margen inferior de tiempo.
El Scrum Máster tiene entre sus objetivos impedir que el equipo tenga que destinar demasiado tiempo en la resolución de problemas. Él se responsabiliza de hacer visibles los problemas y de crear las dinámicas para buscar su solución. Dos de las reuniones que propone Scrum nos ayudan de forma directa en la resolución de problemas.
La daily es una herramienta perfecta para detectar los impedimentos con los que se está encontrando el equipo. El Scrum Máster no puede permitir que un impedimento se convierta en un problema. La reunión retrospectiva nos permite identificar el obstáculo más grande con el que se ha encontrado el equipo durante el sprint acabado de terminar. Para poder trabajar en la eliminación de tal impedimento se necesita conocer su origen y así impedir que vuelva a ocurrir.
Conocer la raíz del problema nos permite tomar mejores decisiones.
Si un impedimento persiste en el tiempo empezará a generar ciertas dinámicas negativas dentro del equipo. De algún modo, aunque sea inconscientemente, existirá una conciencia colectiva de tal impedimento. Se trata de una situación verdaremente mala, que afectará negativamente a la productividad del equipo. Cuando un impedimento se enquista, se convierte en un problema. Cuando un problema perdura en el tiempo, puede que sea necesario romper la dinámica anterior. Para generar una nueva dinámica debemos conocer la raíz del problema y proponerla en base a este conocimiento.
Cuando queremos cambiar una dinámica o solucionar un problema debemos decidir lentamente. No sólo lentamente sino por concenso. Debemos debatir abiertamente todas las opciones posibles y buscar cuales se pueden adaptar mejor a las necesidades y cultura de la organización. El proceso de implementación debe ser rápido y seguro.
La estandarización es la mejor comunicación de la solución de un problema. Si crear los procesos correctos obtendrás los resultados correctos. Cuando apliques una solución válida debe formar parte de la estandarización de procesos de la organización. De este modo se consigue transmitir la información a todo el colectivo.
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>Si te interesa conocer cómo Toyota logra motivar a sus equipos de trabajo es probable que estés lidiando con algún equipo de personas para conseguir que aumente el rendimiento y el valor aportado al cliente o usuario final.
Como sabes, entre los beneficios que promueve la agilidad en el desarrollo se incluye la felicidad y motivación del equipo. Un equipo implicado en el propósito de la organización siempre ofrece unos mejores resultados. Frameworks como scrum te ayudarán positivamente en la creación de dinámicas que mejores el estado de las personas y su rendimiento.
Seguro que has vivido situaciones de motivación extrema, de no poder parar de trabajar y pensar en lo que estás metido, y momentos de desilusión en los que tu implicación y rendimiento ha bajado considerablemente.
Una persona está más motivada en su lugar de trabajo si tiene la capacidad de usar su creatividad en la resolución de problemas y la autonomía en la auto-organización del trabajo a realizar.
Tras muchos años liderando equipos de desarrollo ágil enfocados a producto propio he aprendido de muchas y diversas experiencias. Algunas de ellas, me han permitido reflexionar y experimentar en la empresa propia como reaccionan los equipos a distintos estímulos o dinámicas de grupo.
En esta lista de artículos he recogido buena parte de las reflexiones de estas experiencias personales con el fin de ayudarte a mejorar la felicidad de las personas del equipo y favorecer un entorno de trabajo ágil:
La autonomia en la organización del trabajo a realizar es clave para mejorar la felicidad y rendimiento del equipo. Frameworks ágiles como scrum favorecen esta auto-gestión del trabajo.
Scrum divide el tiempo en unidades de trabajo (sprints) donde el equipo trabaja con total autonomía para conseguir los resultados propuestos. Los objetivos de un sprint son el compromiso que el equipo ha alcanzado para el siguiente ciclo de trabajo. El propósito del equipo será entregar nuevo software funcionando al final del sprint.
¿Quién puede saber mejor cómo realizar un trabajo que el equipo que lo realizamos habitualmente?
Nadie. Este es un razonamiento de peso para decidir que será el equipo quien decida cómo afrontar un nuevo objetivo. En este artículo profundizo en cómo afecta la autonomía en la motivación de los equipos y como promoverla usando scrum.
Como ya sabes querido lector, el framework ágil scrum ha utilizado el Sistema de Producción de Toyota (TPS) como inspiración.
El modelo de Toyota se centra en los pilares en:
Todos los pilares afectan directamente a la felicidad de las personas y los equipos.
Si es la primera vez que lees sobre el Sistema de Producción de Toyota te recomiendo que antes de seguir leas este artículo en la que encontrarás un resumen de los principios de Toyota y como nos pueden ayudar en el desempeño de nuestros equipos ágiles.
Quizás llevas un tiempo leyendo artículos en los que se menciona Toyota, Kaizen, Lean o otros términos japoneses para describir algun concepto ágil. Si es así, puede que te ocurra como a mi y que necesites comprender mejor como funciona Toyota.
Si estás en esta situación, quieres mejorar la motivación, el rendimiento y la calidad en las entregas de tu equipo te recomiendo que leas el libro Las claves del éxito de Toyota.
En Toyota tienen clarísimo, mucho más de lo que te puedes imaginar, que las personas que realizan las tareas que aportan valor añadido son aquellas que están más familiarizadas con el trabajo real.
Quienes más conocen el trabajo real son también aquellos que mejor conocen los problemas que afectan al día a día del trabajo. Son también aquellos que ante un problema podrán apuntar una solución y que usando su creatividad pueden mejorar el proceso para mejorar la calidad y eliminar posibles desperdicios.
Así pues, como seguramente te estás imaginando querido lector, Toyota se orienta a ofrecer valor añadido a sus clientes. Es por este motivo que el Sistema de Producción de Toyota (TPS) situa en los más alto de la jerarquía aquellas personas que realizan aquellos trabajos que aportan valor añadido.
A continuación te muestro un pequeño esquema con el que guiar la explicación de la organización interna de Toyota.
En la zona más alta de la jerarquía se encuentran los integrantes del equipo. Aquellos que trabajan para aportar valor al cliente final de forma directa.
Bajo el equipo se encuentran los líderes de equipo. La característica principal de los líderes de equipo es que no cuentan con la potestad de tomar decisiones disciplinarias. La responsabilidad de los líderes de equipo es apoyar y ofrecer ayuda a los componentes del equipo. A continuación encontramos los líderes de grupo encargados de liderar (con las mismas potestades que los líderes de equipo) y coordinar los distintos grupos de trabajo.
Seguro que has oído muchísimas veces términos como gestión de abajo a arriba, jerarquía horizontal, organizaciones líquidas... Es más que provable que en muchos casos (por suerte siempre vamos encontrando excepciones) sean solo palabras y el modelo siga siendo jerárquico y tradicional.
Pocas empresas se toman tan en serio la autonomía de los empleados como en Toyota.
Los ingenieros seniors (dominan una área técnica específica) desempeñan el rol de apoyar y desarrollar a los ingenieros juniors en su especialidad. Los ingenieros seniors actúan como líderes de grupo.
Toyota aprovecha esta organización para desarrollar y hacer crecer a las personas dentro de la organización. Este sistema básico de organización de equipos y personas no sólo se utiliza en los departamentos técnicos, sino que aplica a cualquier lugar de Toyota.
¿Has sentido alguna vez soledad ante algún problema?
La cultura de Toyota se enfoca a no dejar a nadie tirado mientras realiza su trabajo. Una buena prueba de ello es, en las plantas de fabricación y montaje cuentan con el botón "andom". Cuando un integrante del equipo pulsa este botón, el líder del equipo acude rápidamente para proporcionar ayuda y solucionar el problema.
Este mecanismo permite también definir cual es la filosofía y estilo de los mentores de Toyota:
Dar tareas exigentes, dejar a la persona luchar y esperar a que tire el botón andom para pedir ayuda.
Este pequeño truco puede serte de mucha ayuda si actúas como scrum máster o eres parte implicada e importante en la resolución de problemas y el desempeño del equipo.
Los miembros de equipo tienen como objetivo principal ejecutar el trabajo de acuerdo con el stándard actual. Para ello deben mantener las 5S en su área de trabajo (que traducido del japonés son: clasifiación, orden, limpieza, estandarización y disciplina).
También son los responsables de ejecutar las rutinas de mantenimiento básico y es una obligación la búsqueda de oportunidades de mejora para las operaciones que realizan. Así pues los miembros de equipo participan muy activamente en las actividades de grupo para la mejora continua.
El líder de equipo es el encargado del arranque inicial del proceso y su control y tiene como objetivos cumplir con las metas de producción y asegurar el abastecimiento de piezas y materiales.
El líder de equipo debe estar muy disponible para el equipo y una de sus principales funciones es acudir a la ayuda del algún miembro del equipo ante la activación de la llamada andom (botón para activar la llamada de ayuda). En este post puedes ver cómo nivelar la carga de trabajo de un equipo siguiendo el mismo Modelo Toyota.
El líder de equipo se ocupa de la validación de los checkeos rutinarios de calidad, cubrir el absentismo, dar formación al equipo, actuando como mentor, y asegurar que se sigue el trabajo estándard. Del mismo modo es la persona que facilita las actividades dentro del grupo pequeño y impulsa las actividades para la mejora continua en los proyectos en curso.
Haciendo el paralelismo en los roles de Scrum, puedes leer en este artículo como el Scrum Máster genera el flujo y elimina los impedimentos.
El líder de grupo es el encargado de realizar un mayor número de tareas de gestión, esta es la lista principal del conjunto de responsabilidades de este rol:
Haciendo el paralelismo en los roles de Scrum, puedes leer en este artículo las características principales de un buen Product Owner.
Si has llegado hasta aquí seguro que en el pasado ya has leído en más de una ocasión acerca de la motivación de las personas o de los equipos de trabajo. Seguro que has tropezado con distintas visiones y siempre te preguntas
¿Tendrán razón? ¿Lo deberíamos aplicar?
Como ya sabes en el contexto de las teorías de la motivación existen dos grandes corrientes:
En Toyota no sólo aplican estas dos, sino que utilizan hasta 5 teorias principales acerca de la motivación de las personas. He construído para ti una pequeña tabla resumen en la que se describe el contexto, la teoría, el concepto y el enfoque que ofrece Toyota en sus principios.
Tipo |
Teoría |
Concepto |
Enfoque de Toyota |
Interna |
Jerarquía de las necesidades de Maslow |
Satisfacer las necesidades de nivel inferior y subir a los empleados por la jerarquía hasta su autorealización. |
La seguridad del trabajo, un buen sueldo y unas condiciones de trabajo seguras satisfacen las necesidades de nivel inferior. La cultura de la mejora continua apoya el crecimiento hasta la autorealización. |
Teoría del enriquecimiento del trabajo de Herzberg |
Eliminar los elmentos de insatisfacción (factores higiénicos) y diseñar el trabajo para crear satisfactores positivos (motivadores)
|
Las 5S, los programas de ergonomía, de gestión visual y las políticas de recursos humanos tratan los factores higiénicos. La mejora continua, la rotación de puestos de trabajo y su retroalimentación incorporada apoyan los factores motivadores. |
|
Externa
|
Dirección científica de Taylor |
Seleccionar científicamente, diseñar trabajos estandarizados, formar y premiar con dinero el rendimiento relativo a un estándard. |
Se siguen todos los principios científicos pero de forma grupal en lugar de individual y basados en la implicación del empleado. |
Modificación del comportamiento |
Refuerce el comportamiento en el sitio cuando se produzca de modo natural. |
El flujo continuo y el andom crean plazos de entrega cortos para una rápida retroalimentación. Hay líderes constantemente en producción proporcionando refuerzo. |
|
Fijación de metas |
Fijar metas, específicas, medibles, posibles y exigentes y medir el progreso. |
Fija metas que cumplen estos criterios mediante el hashin kanri (despliegue de políticas). Medidas continuamente relativas a los objetivos |
En las cadenas de montaje de Toyota la asistencia de los empleado es crítica. Para ello Toyota ha creado el concepto de Club de Asistencia Perfecta, ni un sólo día de ausencia o llegar tarde. Este concepto de asistencia perfecta recompensa el absentismo cero (siempre hablamos de ausencias sin justificar).
La recompensa consiste en que todos los trabajadores que forman parte del Club de Asistencia Perfecta son invitados una vez al año a un gran banquete, en un centro de convenciones. En el escenario se encuantran 12 coches totalmente nuevos. Estos coches se sortearan durante el evento entre todos los invitados. Los ganadores se llevaran el coche con las tasas y gastos pagados.
Querido lector, estás empezando la última sección del artículo y es el momento de trasladarte tres datos sobre Toyota que te sorprenderán:
Toyota es un claro ejemplo de una organización que invierte en las personas. Por este motivo consigue empleados comprometidos con su trabajo. El comopromiso lo demuestran a diario con su puntualidad o la mejora contante de las operaciones que realizan.
Ya lo intuyes, la mejora continua es imprescindible para cualquier equipo o empresa. Para ello es importante involucrar a las personas con actividades de grupo que refuercen la confianza y la motivación...
Que te tengo que contar sobre esto que no sepas, con unas actividades de grupo no será suficiente!
¿Cómo consigue Toyota que sus empleados trabajen con esmero para hacer perfectamente su trabajo y se esfuercen para mejorar día a día?
Crear un sistema que desarrolle personas y equipos excepcionales que sigan la filosofía de la empresa y empiezan por examinar el sistema dinámico de su organción.
Acabas de leer el principio número 10 del Sistema de Producción de Toyota. Aplicando este principio conseguirás mejorar la motivación de tu equipo. Como estás pensando ahora mismo, la filosofía de empresa no se crea de forma rápida. Construir una cultura requiere cierto tiempo y necesita aplicar de forma continuada un enfoque consistente y que se rija por unos principios también consistente.
De alguna forma la cultura de empresa nos recuerda la teoría de Maslow, que dice que las personas necesitamos tener un grado de seguridad y sentir que formamos parte de un colectivo superior (equipo).
A continuación te dejo una lista de ideas que pueden ayudarte a mejorar la motivación del equipo:
Formar personas y equipos excepcionales nace de aplicar el respeto por el sistema humano.
Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>En el camino hacia la agilidad es necesario que el despliegue a producción de una actualización del software se produzca de una forma fácil y rápida. Nos referimos a la entrega continua. Definimos entrega continua como la disciplina de desarrollo de software que tiene como objetivo conseguir un despliegue a producción rápido, frecuente y reproducible.
Usando patrones, técnicas y buenas prácticas conseguimos que la construcción del software se realice de tal forma que en cualquier momento se pueda actualizar la versión de producción (deploy). Gracias a la aplicación de la entrega continua reduciremos los riesgos y la incertidumbre del éxito de cualquier subida a producción.
La entrega continua evita que la puesta en producción de una nueva funcionalidad sea un proceso largo y en el que puedan ir apareciendo sorpresas, más o menos agradables. Los que ya llevamos un tiempo en esto, recordamos los tiempos en los que lanzar una actualización requería la ejecución manual de unos procesos, en el mejor de los casos bastantes mecánicos.
Estos momentos, muchas veces bautizados como los momentos de deploy, eran muy tensos. El equipo, sobretodo algunas personas en concreto (las involucradas en la actualización y en los procesos a ejecutar), estaba altamente concentrado hasta comprobar que todo funcionaba correctamente. O no. Luego venían las prisas para resolverlo.
Ante estas situaciones, los equipos, como señal de autodefensa, intentaban minimizar las subidas a producción, puesto que se podían convertir en situaciones traumáticas con posibles errores humanos.
Una prioridad en la entrega continua es que el software pueda ser desplegado a producción en cualquier momento y mientras se está desarrollando una nueva funcionalidad. La entrega continua nos permite hacer un deploy en el momento deseado, gracias a la ejecución de un proceso directo, repetible y rápido.
El Mínimo Producto Viable, en el desarrollo de un producto, es un producto con las características suficientes para satisfacer a los clientes iniciales y conseguir su feedback para la evolución futura. Descubre los 7 errores más comunes en la definición del Mínimo Producto Viable.
El Mínimo Producto Viable, en Scrum, se trabaja de forma iterativa, dividiendo el tiempo en sprints. El Product Owner es el encargado de priorizar las historias de usuario con las que se trabajará en los siguientes sprints. Al terminar todo sprint se obtiene un incremento en el producto.
Es muy importante que al final de cada sprint el producto sea usable. En cada una de las iteraciones de nuestro producto, bajo la construcción de Mínimos Productos Viables, aporta un incremento en sus funcionalidades y en su valor. En ningún momento nos podemos permitir el lujo de dejar el producto sin funcionar.
El Mínimo Producto Viable nos aporta el conocimiento sobre nuestros usuarios y clientes que nos determina como irá evolucionando nuestro producto. La entrega continua nos permite dedicarnos a la evolución del producto y no a cómo actualizar la versión de producción.
Scrum no va de procesos para desplegar a producción nuevos desarrollos y la entrega continua casi sólo habla de esto.
La entrega continua se resume en poder hacer un deploy a producción en el momento deseado, de forma automática y sin ningún proceso manual. Scrum consiste en dividir el trabajo en sprints, en los que al final de cada uno se entrega una nueva funcionalidad o alguna evolución en el software.
La construcción del software bajo el concepto de Mínimos Productos Viables y sprints nos llevan al desarrollo iterativo o incremental. La entrega continua entiende cada una de las iteraciones en el producto como un miniproyecto.
Las iteraciones, en Scrum sprints, repiten un proceso de trabajo muy similar. Cada una de las iteraciones tiene como objetivo proporcionar un resultado completo sobre el producto final con el que se trabaja. Los beneficios del desarrollo incremental son:
Por experiencia os puedo asegurar que no hay nada más desmotivador que ser el encargado de ejecutar los procesos manuales para subir a producción los cambios desarrollados. Esto ya hace mucho tiempo que son historia! (y sino tienes un problema!)
El equipo que construye el producto debe estar totalmente centrado en la evolución del mismo, para ello necesita que sus entregas, una vez validadas, se vayan publicando a producción de una forma transparente. Puedes leer más sobre el cómo trabajar el Mínimo Producto Viable EN ESTE POST.
Estos últimos años el mundo agile ha introducido en nuestro vocabulario una gran cantidad de palabras nuevas, como si de marketing estuviéramos hablando! Se ha ido bautizando todo y a veces son pequeños matices las diferencias entre una y la otra.
La entrega continua es imprescindible para poder trabajar ágil e iterativamente sobre el Mínimo Producto Viable. Los equipos van actualizando la versión de producción muy frecuentemente, también en función del número de desarrolladores. Bajo el objetivo de actualizar la aplicación de forma incremental, no podemos permitirnos el lujo de perder el tiempo constantemente actualizando de forma manual la versión de producción.
Definimos una integración como la compilación y ejecución de pruebas sobre todo el proyecto. La integración continua es un modelo de desarrollo de software que consiste en hacer integraciones automáticas de un proyecto muy a menudo. Las integraciones nos permiten detectar fallos en etapas muy iniciales.
Los principales objetivos de la integración continua son:
La integración continua la situamos en la fase de construcción del software, en el desarrollo vaya. El desarrollo está en manos de personas y estas deben cambiar ciertos comportamientos para poder seguir las pautas de la integración continua.
Años atrás los desarrolladores de un equipo trabajan de forma aislada entre ellos. Lo hacían durante largos periodos de tiempo. A medida que se avanzaban en los distintos desarrollos, empezaban a aparecer espacios compartidos y se empezaba a escuchar en la oficina que la combinación de cambios (merge) sería muy dura.
La integración continua permite que los desarrolladores se actualizen las modificaciones realizadas de forma constante durante su desarrollo. Con esta actualización constante se elimina de forma drástica que los deploys sean procesos largos y complicados.
La integración continua y las metodologías ágiles, como Scrum, han provocado que los equipos de desarrollo hayan pasado a trabajar de una forma mucho más colaborativa. Si trabajas usando la metodología Scrum y no trabajáis en equipo, tenéis un problema como equipo! En este post se explica como mejorar la motivación de un equipo con Scrum.
Resumiendo, la integración continua nos permite la actualización y ejecución de pruebas automáticas de forma fácil y evita así largos procesos de combinación (merge). La entrega continua amplía la integración continua al implementar todos los cambios en el entorno de producción.
La entrega continua nos permite trabajar en el Mínimo Producto Viable y ponerlo en producción de forma rápida, segura y fácil. Así mismo nos permite acelerar el flujo de trabajo y motivar al equipo para implementar cambios o mejoras sin tener miedo a desplegarlo a producción o a romper alguna otra parte de la aplicación.
La entrega continua nos elimina esta incertidumbre de la puesta en producción de una nueva release y nos da un mayor control sobre todo el proceso. De este modo perdemos el miedo a subir a producción cambios y permite trabajar de una forma mucho más iterativa.
Podemos destacar los siguientes beneficios de la entrega continua:
Si estás interesado en mejorar el flujo dentro del equipo puedes LEER ESTE POST en el que se trata como el Scrum Máster debe trabajar para crear flujo y eliminar los impedimentos.
Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>La eliminación de las tareas y tratar sólo con historias puede ser uno de los puntos más complicados en la aplicación de las metodologías ágiles. Definir las historias de usuario es una buena práctica en Scrum. Deshacerse de las tareas clásicas es complicado, necesitamos cambiar la forma en la que describimos el trabajo a realizar.
Primero vamos a dejar claro el concepto de historia de usuario.
Definimos historia de usuario como la menor unidad de trabajo, que se expresa como un beneficio para los usuarios. Habitualmente las escribimos utilizando la siguiente sintaxis:
Como [personaje], quiero [conseguir algo] para [producir un beneficio]
En las metodologías ágiles, y también en Scrum, las historias de usuario nos sirven para definir las características y funcionalidades de nuestra aplicación. En las metodologías ágiles las historias de usuario nos dan sentido al trabajo que se hace. Crear buenas historias de usuario nos ayuda a que todos los implicados puedan tomar las decisiones correctas durante la ejecución del trabajo.
Si te interesa entender cómo las historias de usuario te pueden ayudar en la definición de un proyecto o en la creación de su mínimo producto viable puedes leer este artículo, en el que comparamos los casos de uso tradicionales con las historias de usuario.
Cuando nos ponemos a elaborar la lista de lo que tenemos que hacer nos resulta muy tentador limitarnos a escribir una lista de ítems, muchas veces muy poco definidos y muy genéricos. Cuando esta lista cae en manos de un equipo que no se siente implicado en la confección de la lista de su trabajo ni conoce los objetivos, tampoco se sentirá implicado en la toma de decisiones durante el trabajo.
Las historias de usuario en Scrum nos sirven para generar motivación al equipo sobre el trabajo a realizar. Seguro que a todos nos puede resultar familiar una situación en la qué nos han asignado una tarea y no entendemos el porqué. Cuando te encuentras en esta situación, realizas el trabajo pero desconoces el motivo. Realizar tares sin saber el porqué genera estas dos reacciones:
Podemos afirmar que tenemos un problema de mala comunicación y de desinformación. Se trata de una situación en la qué cómo equipo no estamos recibiendo, o no nos están proporcionando, la información suficiente para realizar el trabajo correctamente.
Como seres humanos tenemos la capacidad de comprender personajes, deseos y motivaciones. En cambio, nos es mucho más complicado intentar abstraer partes sueltas de una línea argumental y tratarlas de ligar fuera de contexto. Es mejor conocer el motivo por el que se hace el trabajo que tener que descubrirlo enlazando tareas disconexas.
Para conseguir que todo el equipo esté alineado en el trabajo que se debe realizar y que conoce los motivos por los que se hace, necesitamos convertir las tareas en historias. Las historias tienen un personaje que necesita alguna cosa para un beneficio. Comprendiendo los tres elementos sabemos porqué realizamos un trabajo.
Cuando empezamos a considerar una tarea lo primero en lo que tenemos que pensar es en el personaje o el rol de la persona. Para centrarnos en el personaje lo mejor es responder a las siguientes preguntas:
El siguiente punto a comprender es el qué. Bajo la óptica tradicional de generar listas de tareas, este es el punto en el que se concentra el trabajo de la mayoría de la gente. Aquí empiezan y acaban su trabajo en la elaboración de la lista de tareas a realizar. En realidad este punto sería solo la mitad del trabajo.
Finalmente debemos pensar cual es la motivación de ese trabajo. En cierto modo, esto es la clave de todo. Sin saber esto no podemos construir la solución. Para ello recomendamos responder a estas preguntas:
A modo de ejemplo vamos a ver como estas tres partes de una historia de usuario nos modifica el resultado o solución al problema.
Primero, nos vamos a imaginar una historia de usuario que acaba de la siguiente manera:
... quiero un coche para poder ir a trabajar.
Si nos imaginamos ahora quien es el personaje de esta historia, podríamos imaginar estos dos inicios:
Nos encontramos que según el personaje con el qué escribimos la historia de usuario podemos hacer interpretaciones distintas de lo que podría ser el vehículo ideal para esa persona. Con este ejemplo de historia de usuario podemos entender todas sus motivaciones. Si conseguimos esto el equipo podrá dar la mejor respuesta y ofrecer la mejor solución.
Las historias de usuario en agile no nos sirven para generar más documentación. Normalmente se debe evitar escribir mucho, si escribimos demasiado no será una historia de usuario. ¿Cómo podemos escribir buenas historias de usuario en Scrum?
A menudo me he encontrado con historias de usuario que son una epopeya. Llamamos epopeya o historia épica a las historias demasiado largas como para poder ser estimadas. Puedes leer acerca el dimensionamiento relativo para estimar la cantidad de trabajo sobre una historia de usuario mediante el uso de Poker Plan en este post. Para poder explicar esta situación lo haremos con esta historia de usuario de ejemplo.
Ahora nos imaginamos que formamos parte del equipo de Amazon y definimos la siguiente historia de usuario:
Como cliente, quiero la tienda de libros más grande del mundo para poder comprar cualquier libro que quiera en el momento que quiera.
Esta historia de usuario cumple con sus características básicas:
Aún así estamos delante una historia de usuario que como equipo no podemos hacer demasiado con ella. Necesitamos desglosarla. Necesitamos dividir la historia de usuario. La historia de usuario es la unidad mínima en la que se define el trabajo a realizar. ¿Cómo podemos dividir las historias de usuario?
Para poder dividir la historia de usuario necesitamos pensar en los distintos personajes implicados en la aplicación que deseamos construir. Si estamos pensando en redactar las historias de usuario de una página web orientada a vender libros, podríamos escribir las siguientes:
Estas tres historias de usuario el equipo las entiende y entiende sus motivaciones. Para empezar a trabajar en la solución debemos abrir un debate en cómo llevarlas a cabo. A partir de este momento el equipo ya puede empezar a trabajar en cómo será la solución.
Estamos ante historias de usuario suficientemente específicas cómo para poder empezar a actuar. Aún así estas historias de usuario no prescriben la forma en la que van a hacerse las cosas. En las metodologías ágiles, también en Scrum, el equipo es autónomo para decidir cómo realizar el trabajo.
El equipo decide cómo conseguirá hacer el trabajo. Qué se debe hacer lo decide el valor de negocio.
En Scrum las historias de usuario las escribe el Product Owner. Si te interesa conocer las responsabilidades del Prodcuct Owner más allá de definir las historias de usuario en el desarrollo ágil puedes leer este artículo.
Estamos en un mundo en qué necesitamos personas con roles y profesiones distintas para poder sacar adelante un proyecto. En las metodologías ágiles el trabajo se hace en equipo así pues debemos crear equipos multidisciplinares, que sean capaces de realizar todo el trabajo, de inicio a fin.
No podemos concebir en una organización ágil que hablemos del equipo de diseño, el equipo de desarrollo, el equipo de sistemas...
No sólo es importante contar con un equipo con profesionales de distintos orígenes, también es imprescindible que el equipo esté implicado con el trabajo a realizar. Si no se consigue pronto nos encontraremos en el problema comentado al inicio del post.
En un equipo agile, diseñadores y desarrolladores trabajan en el mismo equipo. No sólo están en el mismo equipo sino que están implicados y trabajan juntos. En Scrum cuando tenemos una historia de usuario empieza el trabajo colaborativo para encontrar la mejor solución.
En este momento nos encontramos ante la oportunidad perfecta para entender todos los puntos de vista, los problemas derivados o las interpretaciones que se pueden hacer acerca de las necesidades o motivaciones de la historia de usuario. Si sabemos que un desarrollador siempre piensa en preguntas del estilo ¿Qué haremos cuando suceda esto? Es mejor tenerlo en cuenta desde el primer momento que no que aparezca en fases más avanzadas de la solución.
Un equipo con perfiles profesionales distintos y que trabaja de forma conjunta y en equipo nos da la ventaja de cambiar los marcos de la discusión. Seguro que te has encontrado en reuniones donde integrantes de los departamentos de marketing, diseño y desarrollo están cerrados en su posición de "yo tengo razón y tu no".
Trabajar juntos a partir de la historia de usuario nos genera un sistema en el que conseguimos que cada uno del equipo trabaje, y piense ideas, para solucionar el problema.
Este trabajo conjunto nos hace llegar a acuerdos básicos de equipo de cómo se realizará el trabajo. Este acuerdo deja todo el equipo alineado en los motivos por los que se realiza un trabajo. Cada miembro del equipo, en la parte que le toca, busca las mejores aportaciones para ayudar a encontrar el camino hacia la mejor solución.
Somos humanos. A los humanos nos gustan las historias. No nos gustan las tareas. Nos gusta todavía menos hacer trabajo sin conocer el motivo. Y, a parte de no gustarnos, nos desmotiva no sentirnos implicados en el planteamiento de la solución.
Para poder empezar a trabajar y a priorizar qué trabajo debemos hacer necesitamos redactar las historias de usuario. En Scrum todas las historias de usuario se almacenan en el backlog. Si quieres saber cómo puedes priorizar las historias de usuario puedes seguir con este post.
Es imprescindible pensar primero en quién va a ser el que reciba el valor de algo. En segundo lugar qué es lo que debemos realizar. En tercer lugar porqué necesita este trabajo.
Tenemos que hacer historias de usuario en las que ponerse a trabajar. No es un buen enfoque plantear tareas a despachar.
Si quieres aprofundizar en el desarrollo ágil te puede ser interesante leer estos artículos:
Te ha gustado el post? No olvides en suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
]]>