Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Visión. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Visión. Mostrar todas las entradas

martes, noviembre 28, 2023

Los artefactos Scrum: un enfoque unificado para el éxito del producto

 

Fuente: https://www.linkedin.com/feed/update/urn:li:activity:7132793258551726080/

He tenido el privilegio de guiar a numerosos equipos y empresas a través de implementaciones exitosas de Scrum. Una de las preguntas más comunes que encuentro es: "¿Cuál es el artefacto principal en Scrum: el Product Backlog, el Sprint Backlog o el Incremento?"

En una encuesta reciente en LinkedIn realizada por Scrum Inc., a manera de trivia, el 74 % de los encuestados, incluyéndome, indicaron que los tres artefactos son igualmente críticos para el éxito de Scrum. Esto se alinea con mi propia experiencia, donde he sido testigo de cómo cada artefacto desempeña un papel distinto pero complementario a la hora de impulsar el desarrollo de productos.

Pero qué pasa con quienes dieron respuestas diversas: el 13% estaba a favor del Product Backlog, el 6% optó por el Sprint Backlog y otro 6% creía que el Incremento era el más crucial. Este último parece tener sentido, después de todo, se trata del objeto final de la iniciativa de producto, ir creándolo en pequeñas partes, pero ni siquiera tuvo una mayoría favorecedora dentro de los artefactos individuales.

La ilusión de la separación: un nombre inapropiado

Si bien cada artefacto posee sus propios méritos disímiles, la verdadera magia de Scrum radica en su interacción sinérgica. El Product Backlog proporciona una visión general, el Sprint Backlog traduce esa visión en tareas procesables y el Increment manifiesta esas tareas en valor tangible.

Es definitivo: la noción de que un artefacto reina sobre los demás es un error. Es como afirmar que los cimientos, las paredes o el techo de una casa son más importantes que los demás. Cada componente juega un papel crucial en la integridad de la estructura. De manera similar, cada artefacto Scrum contribuye al éxito general del proceso de desarrollo del producto.

El Product Backlog: la brújula visionaria

El Product Backlog sirve como base de Scrum y representa la visión en constante evolución del producto. Es una lista ordenada de características, requisitos y mejoras que definen el estado deseado del producto. Continuamente refinado y actualizado, el Product Backlog guía los esfuerzos del equipo, asegurando que estén alineados con la dirección estratégica del producto.

El Sprint Backlog: la hoja de ruta táctica

El Sprint Backlog, derivado del Product Backlog, traduce la visión del producto en tareas procesables para un solo sprint. Es una lista dinámica de historias de usuario, errores, tareas y otros elementos de trabajo que el equipo se compromete a completar durante el sprint. El Sprint Backlog proporciona enfoque y claridad, lo que permite al equipo ofrecer valor tangible al final de cada sprint.

El Incremento: la expresión concreta del progreso

El Incremento, la culminación de cada sprint, representa el producto funcional que está potencialmente disponible para los clientes. Es la manifestación tangible de los esfuerzos del equipo, que muestra las capacidades en evolución del producto y permite que se proporcione retroalimentación temprana para una mejora continua. El Incremento sirve como un faro de progreso, motivando al equipo y validando la dirección del producto.

Adoptando la naturaleza entrelazada de Scrum

El verdadero dominio de Scrum radica en reconocer la interconexión de estos artefactos. No son entidades aisladas sino más bien elementos interdependientes que se entrelazan para formar el tejido del éxito de Scrum. Descuidar un artefacto inevitablemente afecta a los demás, lo que dificulta la capacidad del equipo para entregar valor de manera consistente.

Cuando aceptamos el significado colectivo de los artefactos Scrum, liberamos el verdadero potencial del framework. Normalmente, capacito a los equipos para que naveguen por las complejidades del desarrollo de productos con agilidad, enfoque y mejora continua. Juntos, el Product Backlog, el Sprint Backlog y el Increment forman la piedra angular del éxito de Scrum, lo que permite a los equipos ofrecer productos que deleitan a los clientes e impulsan el crecimiento y la innovación en las empresas.

En mi experiencia, los intentos de aislar un artefacto como el más crucial a menudo conducen a una comprensión incompleta del enfoque holístico de Scrum. Cada artefacto juega un papel indispensable y su integración armoniosa forma la base del éxito de las iniciativas Scrum.

Estos instrumentos no son meras herramientas; son el alma de Scrum, son las expresiones tangibles de una mentalidad ágil. Encarnan los principios de mejora continua, colaboración y adaptabilidad, transformando el proceso de desarrollo de productos en un viaje de experiencias y evolución continuas.

Entonces, la próxima vez que reflexiones sobre la importancia relativa de los artefactos Scrum, recuerda que no son entidades aisladas sino hilos interconectados que tejen el tapiz del éxito de Scrum.

miércoles, julio 18, 2018

Apuntes sobre transformaciones ágiles: las personas, sus miedos y qué hacer al respecto


(Tiempo aproximado de lectura: 7 minutos, 30 segundos)
***********************************************************
Nota:
Esta es la segunda parte de una serie de apuntes sobre transformaciones ágiles. Encuentran la primera parte en:
http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html
***********************************************************

Las personas son lo más importante de una organización y los gerentes deben hacer todo lo que puedan para mantener a las personas activas, creativas y motivadas, o algo así nos dice Jurgen Appelo a propósito de energizar a las personas en sus ya muy conocidas técnicas de Management 3.0. Los agentes de cambio también tenemos esa obligación con las personas: motivarlos, energizarlos, enamorarlos de las nuevas propuestas, de las nuevas formas de hacer las cosas.
Por ejemplo, promover el uso de herramientas simples que se adapten a las personas puede ser una magnífica idea cuando introducimos nuevas formas de trabajar en una organización. Instrumentos cuyo aprendizaje no tome mucho tiempo y cuyo uso sea natural y hasta espontáneo y que no intimide. Los radiadores de información como los tableros de tareas son un buen inicio.
Ahora bien, la revitalización casi nunca viene de arriba (de la alta gerencia). La revitalización comienza en los suburbios de la organización, conducida por líderes de área que crean planes para solucionar problemas concretos. A través del alineamiento de tareas –dirigiendo las responsabilidades de las personas hacia la tarea competitiva central de la empresa– estos líderes enfocan su energía en el trabajo y no en abstracciones como “empoderamiento” o “cultura”.
Revisar el propósito y la visión de la empresa, publicar la declaración de la misión y lanzar programas diseñados para causar un cambio en la organización, no siempre tienen el resultado esperado. ¿Cuál es el papel de la alta gerencia en este proceso? Establecer en qué dirección irá la compañía, sin necesidad de implantar lo que para el resto de la empresa puede verse como soluciones dictatoriales. Después, simplemente tiene que dedicarse a respaldar y divulgar las lecciones aprendidas de las áreas renovadas en toda la compañía.
Por su parte, los equipos son dueños de su propio destino. Los líderes están allí para suministrarles las piezas necesarias y suficientes y las guías apropiadas para el uso de esas piezas: armar el rompecabezas sigue siendo responsabilidad de cada uno de ellos y de sus miembros.
Durante los procesos de transformación te encuentras con dos tipos de personas: las que quieren el proceso para seguirlo, aquellas que no son capaces de hacer nada sin un proceso riguroso, meticuloso, estricto, universal, absoluto, paso a paso, detallado y definitivo. Y las que quieren ese conjunto de reglas rigurosas, estrictas, detalladas, obligatorias, para no seguirlas. En cualquiera de los dos casos, el pensamiento Ágil no les cae bien porque no establece o prescribe ni lo uno ni lo otro.
Algunos enemigos de la innovación son también enemigos del cambio y generan aprensión, estudia y practica cómo lidiar con ellos:
1.  Cultura de culpa
2.  No hay espacios seguros para experimentar
3.  Deseo de complacer a todos
4.  Grandes egos
5.  Dudas
6.  Microgestión del talento
7.  Miedo al fracaso
8.  Demasiado rigor en los procesos
9.  Impaciencia
10.      Abundancia de recursos
11.      HIPPO (Opiniones de las Personas más Altamente Pagadas en la compañía, muchas veces consultores externos que no conocen el ambiente organizacional actual)
12.      Necesidad de KPI medibles inmediatos
En síntesis, lograr una transformación sostenible requiere de compromiso, coordinación y competencia y nada de eso se logra por decreto. Las ordenanzas, por el contrario, producen más temor en las personas y estas se retraen y terminan alejándose del cambio. Algunos de estos consejos te pueden ayudar a lidiar con este fenómeno[1]:
1.  Haz que el compromiso a la transformación se logre mediante el diagnóstico conjunto de problemas. Sé inclusivo, logra la participación de todos en la organización.
2.  Desarrolla una visión compartida de cómo prepararse y organizarse para la competitividad. Las empresas más exitosas actualmente tienen un alto grado de colaboración y de innovación pero no olvidan el mercado.
3.  Promueve el consenso para la nueva visión, la competencia para promulgarla y la cohesión para avanzar. Esto requiere de liderazgo y de apoyo de la alta gerencia. Sin eso estás perdido.
4.  Energiza todas las áreas de la empresa, empezando por las personas que las integran. Eso sí, no presiones ni busques que la alta gerencia presione. Necesitas crear un entorno cooperativo, no uno coercitivo.
5.  Cuando hayas probado el cambio, cuando hayas logrado que la organización deguste lo que viene, institucionaliza la revitalización a través de políticas, sistemas y estructuras formales.
6.  Monitorea el proceso de energización, ajustándolo en respuesta a los problemas que encuentres, a los escenarios actuales. No trates de copiar una receta o un modelo calificado como exitoso en otra organización, el que obtengas el mismo resultado será apenas una feliz coincidencia.
Influenciar el grado de resistencia al cambio es un esfuerzo colectivo. Cada que puedas, une a más personas, a más áreas en la organización y con todos, haz un nuevo esfuerzo para influir en el resto aun no “convencido”, esta vez con más ahínco que antes. Y sin importar a cuántos logres convencer esta vez, prepara de inmediato la siguiente actividad. Esto es constante, hasta que la transformación sea sostenible.
Finalmente, si dejas de preocuparte por el porcentaje de avance, por el número de historias de usuario que vas a recibir, por el tiempo que te va a tomar recibirlas y por quién es el responsable de hacer qué y cuándo, lo que te queda es atender el valor recibido y con qué calidad lo recibes.
Liderar o fomentar el cambio requiere que las personas enfrenten problemas dolorosos y renuncien a los hábitos y creencias que aprecian. ¿Resultado? Algunas de estas personas intentan eliminar el agente visible del cambio: ¡ese eres tú!
No te desanimes por ello. Aprende a manejar tu entorno y tus propias emociones. Por sobre todas las cosas, mantente fiel a tus principios.
Finalmente, muchos no esperan o no están preparados para hacer la inversión necesaria para cambiar. Un jefe seguirá queriendo ser el jefe, no un líder al servicio de nadie (léase Scrum Master). ¡Es la forma cómo los inspires lo que motivará una real y profunda transformación!

Fuentes:
1-  Why Change Programs Don’t Produce Change. By Michael Beer, Russell A. Eisenstat, and Bert Spector.

miércoles, marzo 29, 2017

Guía Supernumeraria para un Dueño de Producto Virtuoso


El Dueño de Producto es un nuevo rol para muchas, en realidad para la gran mayoría de las compañías. Y de estas, un gran conjunto no lo entiende o simplemente no ha tenido las mejores experiencias con sus responsabilidades. En términos generales, el Dueño de Producto es un ilustre olvidado.
Mientras que la promesa de un equipo de TI es diseñar y construir el mejor producto o servicio que el negocio necesita, una solución con Valor, dadas las restricciones de tiempo, presupuesto, tecnología, entre otras, la promesa de un Dueño de Producto es trabajar con el equipo en la priorización y negociación de características del producto, lograr no solo que el equipo de desarrollo aprenda del negocio sino de lo que significa Valor para el negocio.
La proposición de valor del Dueño de Producto también incluye mantener al equipo motivado y contribuir desde su posición a que se cumplan los compromisos con los usuarios o consumidores que él mismo representa. También, mientras la organización confía en la mentalidad Ágil del equipo y del Scrum Master para mantener la alineación con las áreas de TI, delega en el Dueño de Producto la responsabilidad de mejorar los tiempos de salida al mercado a la vez que optimizar el retorno de la inversión.
El Dueño de Producto es precisamente el dueño de la visión del producto, el plan del negocio, las ganancias, el plan de entregas y de un backlog de producto cuidadosamente refinado y priorizado con precisión para que el equipo pueda trabajar sin tropiezos. Mientras el trabajo del equipo es construir correctamente el producto, el Dueño de Producto debe entregar el producto correcto. ¡Es un juego de palabras, pero es verdad!
El Dueño de Producto es o será el encargado de devolver el encanto que muchos usuarios, socios y empleados perdieron en el pasado a raíz de las soluciones de TI disfuncionales que estábamos produciendo. Eran soluciones con muy poco o ningún sentido de la calidad, tardaban años en llegar al mercado y carecían de la innovación necesaria para resolver problemas reales del negocio. Las cosas así, la responsabilidad moral de un Dueño de Producto es una carga pesada que todos en la Organización tenemos obligación de ayudar a soportar mediante el apoyo incondicional a su trabajo.
Scrum en particular y el enfoque Ágil en general proporcionan las herramientas suficientes para que el Dueño de Producto cumpla con sus responsabilidades de manera decidida y franca, para conectar efectivamente los deseos y necesidades de los usuarios y el negocio con el equipo de desarrollo, de forma dinámica y receptiva.
En su libro “Agile Product Management with Scrum”, Roman Pichler describe ampliamente las principales actividades que un Dueño de Producto de talante realiza:
Definir y manejar la Visión del Producto

Una visión efectiva del producto responde o debería responder a las siguientes cuestiones:
  • ¿Quién comprará o usará el producto? ¿Quién es el consumidor o usuario final?
  • ¿Qué necesidades cubrirá el producto? ¿Qué valor agrega el producto al usuario o a la organización?
  • ¿Cuáles son los atributos críticos del producto para que este sea exitoso?
  • ¿Cómo y qué tantas ganancias tendrá la compañía con el producto?
Entre otras no menos importantes. En resumen, la visión debería comunicar la esencia del futuro producto de una manera concisa y describir un objetivo compartido que conduzca la creación del producto pero que sea lo suficientemente amplio como para facilitar la creatividad del equipo que lo desarrollará.
Un aspecto importante a considerar aquí es el conocido como el Mínimo Producto Viable (MVP) o, a veces, el Mínimo Producto Mercadeable. Este es un producto con la mínima funcionalidad que cubra algunas de las necesidades básicas de los usuarios y genere valor a la organización. Un Dueño de Producto hábil sabe que el producto debe estar en funcionamiento muy pronto y que este debe entregarse en pequeños incrementos en cortos lapsos de tiempo. Esto reduce la incertidumbre y aumenta el aprendizaje no solo sobre el producto sino sobre los hábitos de consumo de sus usuarios finales.
Para saber más sobre cómo crear la Visión del Producto, pueden ver este Webinar sobre Inception Ágil que facilité con mi gran amigo Jorge Abad:
Es prácticamente imposible, por no decir menos, establecer una visión del producto apropiada sin tener en cuenta el factor humano. En otras palabras, definir una correcta visión del producto es un acto puramente humano.
Trabajar con el backlog de Producto

Este artefacto hermosamente simple sufre muchas veces de la falta de atención apropiada tanto por parte del Dueño de Producto como del mismo equipo de desarrollo.
Para quienes no están familiarizados con la herramienta, es una lista priorizada de los elementos necesarios para darle vida al producto. Estos elementos incluyen la exploración de las necesidades de los usuarios, pero también puede incluir una descripción de opciones técnicas y de requisitos funcionales y no funcionales, así como el trabajo necesario para poner a punto los distintos ambientes de trabajo.
Uno de los aspectos más importantes que debe estar en el radar del Dueño de Producto es este del Valor de cada uno de los elementos del backlog. El valor es un factor común de priorización de sus elementos. El Dueño de Producto sabe que debe entregar primero los elementos de mayor valor. Al agregar nuevos elementos, el Dueño de Producto no solo revisa o establece el valor de estos nuevos elementos sino que reexamina el valor de los existentes.
También hemos aprendido que un Dueño de Producto experimentado va adelante del equipo en cuanto al conocimiento detallado que tiene de los elementos del producto. Quizás uno o dos sprints más allá del actual y está continuamente practicando refinamiento al producto.
Para profundizar más en estos asuntos pueden leer mis artículos:
Sobre gestión del producto en general, en el que abordo cuáles son los atributos (DEEP) de un buen backlog de producto:
Sobre refinamiento del producto en particular:
Planear las entregas

En su libro Agile Estimating and Planning, el gran Mike Cohn escribió que “Planificar... es una búsqueda de valor”. Otra vez emerge el Valor como factor determinante a la hora de planear las entregas de un producto. También hemos aprendido que este plan de entregas no puede ir encadenado a las aristas de tiempo, costo y alcance de manera fija e inquebrantable. Es posible adherirse a una de ellas, quizás a dos, pero no a las tres en simultáneo.
Otra vez: la meta principal de todo Dueño de Producto es entregar el producto correcto. De allí que la planificación de esta entrega de producto, en pequeñas entregas incrementales es una tarea fundamental de todo Dueño de Producto hábil. Sobre este asunto en particular pueden leer mi artículo:
En donde agrego el atributo de Valor a las ya ampliamente difundidas bases de Ágil y propongo El Nuevo Nuevo Enfoque Iterativo e Incremental y de Valor.
Colaborar con las Reuniones del Sprint

¡Scrum!

Las reuniones son oportunidades de Conversación cara a cara y, en el caso específico de Scrum, son momentos propicios para la inspección y adaptación, pilares fundamentales de la mentalidad Ágil. Y el Dueño de Producto hace parte del equipo Scrum, así que bienvenido su aporte estratégico y táctico al equipo durante estas conversaciones.
Para saber más sobre los distintos eventos en Scrum pueden ir a mi Gazafatonario:

En conclusión, el Dueño de Producto es uno de los ejes fundamentales sobre los cuales avanzan los equipos Scrum como un todo hacia la búsqueda de un objetivo común: la generación de valor a la vez que responder al cambio de manera eficiente. En particular, el Dueño de Producto se constituye en una arista esencial para la correcta gestión ágil del producto pero sobre todo para entregar productos cuyos componentes generen resonancia entre ellos e impacten el modus vivendi de sus consumidores, nosotros la humanidad.

Puedes descargar la presentación complementaria del siguiente enlace:

viernes, abril 17, 2015

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas

#RSGECU2015: Ágil es algo que eres, CMMI es algo que usas
Este viernes 17 de abril, presenté en el Regional Scrum Gathering 2015, en Quito, mi disertación sobre Ágil y enfoques tradicionales. Mi asunto principal es que los métodos ágiles no tienen por qué entrar en conflicto con otros modelos o enfoques de construcción de software, no es la idea de ser ágil o, al menos, no está en el flujo de un proceso de transformación a ágil echar tierra a las prácticas existentes en una organización, como erróneamente pregonan muchos. Los líderes de los procesos actuales pueden y deben trabajar en conjunto con los nuevos líderes para que estos últimos obtengan los beneficios de ambos universos y aprovechar esa sinergia para mejorar dramáticamente el rendimiento del negocio.

Para apoyar este concepto, expliqué que los modelos tipo CMMI, PMI e ISO nos dan una idea de cuales procesos son necesarios para mantener una organización madura y disciplinada, capaz de predecir y mejorar el desempeño de la organización misma y de los proyectos. Entre tanto, las técnicas ágiles proporcionan guías para un manejo eficiente de los proyectos de una manera que permite alta flexibilidad y adaptabilidad. Al mezclar los dos enfoques, la filosofía ágil asegura que los procesos se implementen eficientemente a la vez que aceptan los cambios; y los modelos tradicionales aseguran que se consideren todos los procesos relevantes.

Pero de inmediato fui al centro de mi exposición: una de las grandes diferencias, radicales por demás, entre los métodos tradicionales y los ágiles es que estos últimos son generativos, no prescriptivos. Los procesos necesitan evolucionar según las necesidades, no prescritos con anticipación. Un enfoque prescriptivo genera procesos complejos y complicados, mientras que un enfoque generativo comienza con un conjunto de procesos simples y adiciona otros a medida que se requieren.

La filosofía ágil reconoce que los procesos de software más efectivos no pueden definirse por adelantado; es un proceso continuo. Los métodos tradicionales se enfocan en definir y reforzar procesos y gastan muy poco tiempo en identificar y entregar lo que los usuarios necesitan. Aunque su propósito es mejorar la consistencia y la calidad, esto muchas veces se consigue a expensas de la productividad y la entrega. El enfoque tradicional de procesos tipo CMMI también usa herramientas monolíticas y pesadas que causan construcciones frágiles y traspasos inefectivos entre desarrollo, pruebas, despliegue y operaciones.

Lo que siguió fue enfatizar en lo que significa ser ágil: específicamente, la interiorización y la práctica de los Valores y Principios del Manifiesto Ágil, nada alejado de lo que se está hablando en el  #RSGECU2015.

Hacia el final quise poner mi propio manifiesto, el ‘Ágil es algo que eres…’, se trata de la persona, no de las cosas ni de los procesos. Ya lo he dicho en otras oportunidades, ser ágil significa reemplazar la predictibilidad falsa por la eficiencia.

¿Quieres saber más?

Pueden descargar la nueva versión de la presentación haciendo clic aquí o en esta dirección: http://goo.gl/leJ5N8.


No olviden escribirme con sus inquietudes o sugerencias a lucho.salazar@gmail.com o en el foro del blog.