Se necesita dar un salto cualitativo hacia la “Early  Majority” (Mayoría Precoz que integra la metodología, tecnología o producto), este es el salto mas difícil según argumentas todos los expertos, el salto que confirma el asentamiento de una nueva metodología, tecnología o producto.

Para poder dar este salto no solo se necesita disponer de un framework que funciona, como es Scrum, sino de crear una marca que signifique para la empresas un salto de calidad en sus procesos y resultados.

Para poder dar este salto se necesita llegar al sector del marketing, el cual esta copado principalmente por las agencias de publicidad, que serán al final la que posicionen  una idea o marca y ayuden a conquistar el mercado.

Las agencias de publicidad deben conocer Scrum y los conceptos de las metodología ágiles, con ellos se consigue que puedan transmitir sus valores y cualidades. Las agencias son agentes intermediarios muy necesarios para la expansión de una marca, que los consumidores la adopten y confíen en ella.

Si las metodologías ágiles quieren llegar a dar un paso mas en su penetración en el mercado, deben sobre todo, llegar a sectores que controlan y gestionan las reputaciones de las marcas, gracias a ello el salto a la Mayoría Precoz será posible y menos traumático.

Scrum se encuentra compitiendo en un mercado donde existen muchos intereses privados, donde las empresas privadas que apoyan de las metodologías tradicionales no quieren perder cuota y luchan por ello, es por esto, que para poder seguir creciendo se tiene que apoyar también en una estrategia de comunicación que le permita seguir afianzado su marca en el sector.

El dueño de producto debe hacer también el papel de escultor con las ideas del cliente. Normalmente este aparece con un documento o idea con la que quiere abarcar “todo”, “la inmensidad del mercado”, el cliente piensa que cuanto más aspectos cubra mas rendimiento le sacará a su inversión.

Si el cliente hiciera él solo la pila de producto, exagerando, más o menos sería como en la ilustración de arriba. Es aquí donde el dueño de producto debe aplicar todos sus conocimientos y experiencias, no solo en Scrum, si no en la gestión de proyectos.

El primer paso es definir bien el mercado, al igual que hacemos disgregando la ideas de los clientes en historias y tareas, debemos conseguir que nos fragmente el mercado objetivo en segmentos, así construiremos nuestra pila de producto tomando los aspectos más relevantes. Los principios que deben regir esta segmentación son: geográfica, demográfica y sicográfica.

El segundo paso es fijar unos costes reales para el primer lanzamiento, con lo que una vez adelgazada la pila de producto gracias a la segmentación del mercado, se debe hacer un análisis de costes. Fijar un precio objetivo conlleva volver a analizar las historias que son vitales y las que no, para que luego el coste del mismo no influya en los consumidores. En este paso, el product owner debe aconsejar al cliente sobre la circunstancia de que cuantas mas historias vitales tenga el proyecto, mayor coste terminarlo, tanto de inicio, como de nuevas tareas que surjan durante los sprints.

El último paso es poner un valor estratégico de cada historia, no nos referimos al coste, si no al valor añadido que supone para los consumidores cada parte del producto. Conocer cuales son los elementos mas valorados por el usuario será la guía que nos oriente a la hora de priorizar la pila de producto.

Si el dueño de producto trabaja en estos tres aspectos con el cliente, la pila de producto será mucho mas coherente, tanto para el equipo de producción como para todos los interesados en el proyecto. Los productos o servicios tienen un fin comercial o de uso y por lo tanto, tener en cuenta los valores del mercado es una de las acciones que conlleva a definir mejor la pila de producto.

En el planteamiento en cascada se realiza un plan estimando la documentación de seguimiento de un programa y el coste de ejecutarlo. Como resultado se tienen que dar una características y sobre ella se van desarrollando el plan y el resultado.

En la metodologías ágiles el planteamiento es distinto.

Se realiza una estimación sobre las características, lo cual da como resultado una visión, no un plan de ejecución, como ocurre en la planificación en cascada, y luego se trabaja sobre el programa y el coste.

La gran diferencia entre las dos formas es el corazón, lo que se encuentra dentro del triángulo, en la planificación en cascada es el “plan”, en la metodología ágiles es la “Visión”. La otra diferencia  es que en una el coste esta totalmente cerrado, sobre el mismo se ha realizado un programa y se ejecuta, y en la otra como se abrigan los cambios, no hay un coste cerrado.

Que no exista un coste cerrado no significa que sea malo para el proyecto ni perjudicial para terceros, normalmente se tiende a pensar en que va a costar mas de lo que se planificó, pero puede ocurrir lo contrario, que la visión lleve a ejecutarse un producto mas sencillo de hacer y con unos costes menores de los previamente previstos. Los costes se irán definiendo mejor cuanto mas se acerque uno al final del proyecto, es muy difícil en muchas ocasiones saber al 100%  el coste total, y si además, el proyecto se atañe a unas cantidades fijadas, perderá eficiencia y eficacia, dado que estos valores se colocarán por debajo en importancia del cumplimiento de unos costes ya firmados.

Las metodologías ágiles, lo que ponen sobre la mesa es que se trabajaba sobre una estimación de las características que se quieren crear en un producto, con una visión que va enfocando el camino, una visión que crece y se enriquece con el paso del proyecto y que, la mejor definición de la misma puede hacer variar el coste y el programa cuando se reciben los primeros resultados de las entregas parciales del producto.

Para responder a esta pegunta hay que realizar un análisis de la situación actual de cada empresa, para ello se deben de tener en cuenta los requisitos y la tecnología que se está empelando.

En la gráfica podemos ver que si disponemos de una tecnología conocida y unos requisitos específicos , el problema a solucionar es bastante sencillo, por lo que cualquier sistema es válido para sacar el trabajo adelante. En el caso contrario ocurre lo mismo, cualquier trabajo sobre una tecnología desconocida y unos requisitos muy vagos, lo único que consigue es una anarquía que no puede solucionar ninguna metodología de trabajo, ni las ágiles, ni ninguna otras.

Integrar una metodología ágil en una organización o empresa, debe de tener como objetivo principal gestionar proyectos que estén dentro de la zona compleja.

Si la mayoría de los proyectos de una empresa se encuentran en la zona azul, es cuando se recomienda a los gestores de la misma el uso de metodologías ágiles. Esta recomendación viene avalada por que es justamente donde se puede sacar el máximo beneficio de Scrum y de sus procedimientos.

El framework Scrum está preparado y es efectivo para manejarse en las situaciones complejas, e incluso las que rocen la anarquía. En las otras zonas se comporta igual que cualquier otra metodología.

Volvemos a hablar de ScrumManager, y esta vez para recomendar sus podcats, dado que son unas lecciones muy interesantes. En cada uno se van tratando diversos temas, siempre relacionados con Metodologías Ágiles y Scrum.

Lo podcats son un coloquio entre personas invitadas debatiendo sobre el tema principal. El nivel de los participantes es muy alto, entre ellos: Agustín Villena, David Alfaro,etc.

Recomendamos esta página, por que cada vez es mas completa, puedes realizar cursos, acceder a mucha información y escuchar podcast.Los podcast te permiten poder escucharlo en cualquier momento y circunstancia, lo que nos permite aprovechar cualquier momento de viaje o de espera para seguir formándonos en Scrum y las Metodologías Ágiles.

Hoy hemos podido leer en el blog Tobias Meyer que Scrum es peligroso.

Es peligroso por que Scrum, al contrario que otros planteamientos, no te ofrece un a hoja de ruta perfecta que te de la sensación de que todo esta controlado, se tienen que olvidar de disponer de una lista de tareas que den directrices para que las cosas funcionen sin problemas.

Es peligroso Scrum por que no te ofrece el proceso perfecto, dado que no existe el cliente ni el proyecto perfecto.

Es peligroso Scrum por que la creación y dirección del proyecto se deposita sobre un equipo, del cual emana todo el conocimiento y capacidad para producir el resultado óptimo.

Es peligroso por que no existe un mapa que marque la ruta de forma específica, por lo que no solo no sabemos que resultado va obtener el grupo autogestionado, si no que además no conocemos a donde lleva el camino, aunque tenemos indicios de donde esta la meta.

Es peligroso por que los jefes o gerentes tendrán que depositar su confianza en otras personas para obtener un resultado óptimo.

En definitiva, es peligroso por que requiere un cambio de mentalidad y de actuaciones, lo que conlleva a todos los implicados a cambiar su forma de vida y de pensamiento dentro de la empresa.

No quiere correr estos riesgos no introduzca Scrum en su empresa u organización. No se acerque a este Framework, podría electrocutarse.

Existe una corriente de criticas a la agilidad fundamentada sobre la pérdida del conocimiento generado en los procesos. Basan sus críticas en la velocidad de los sprints y el constante movimiento de post-it del tablón de un sitio a otro, lo que hace que no se genera apenas documentación y no se puede transmitir de un equipo a otro.

Esta crítica tiene fundamento y es uno de los puntos donde las metodologías ágiles deben mejorar. Para ello los equipos deben tener claro que los conocimientos adquiridos deben ser documentados para poder transmitirlos mejor, pensando en que no se deben repetir errores y que las decisiones futuras puedan ser tomadas con suficiente información sobre experiencia pasadas.

Conociendo esta necesidad de documentación del conocimiento para poder transmitirlo, no hay que caer tampoco en la trampa de usar procesos pesados de gestión, más valen pocas líneas explicando algo que un documento muy completo que ninguna persona se va a leer, también en este aspecto hay que ser ágiles, recoger una excesiva documentación al final produce el efecto contrario.

Existen diferentes métodos sencillos para ir recogiendo el conocimiento y poder transmitirlo:

1. Asignar tareas dentro del sprint que supongan escribir lo aprendido en el mismo.
2. Emplear una wiki donde recoger los comentarios de cada proyecto
3. Escribir un acta en las retrospectivas donde se recojan estos aspectos. Seguimos con la informalidad de celebrar esta reunión fuera de las oficinas, pero se nombra un encargado de anotar los detalles de la reunión y que luego los refleje en un documento.

Hay que acompañar a todos los procesos de Scrum con otros de gestión del conocimiento. Esto se refleja en que se va creando una capa de evolución continua del conocimiento que envuelven a todos los procesos. Esta capa esta presente en todo momento y debe ser plasmada en documentos mediante herramientas que no mermen la agilidad.

Uno de los grandes problemas de todas las empresas es el de querer tener empleados motivados de forma continua. La obsesión con la que se tratan estos temas por parte de los directivos o gerentes, hace que lleguen a probar métodos distintos constantemente.

En el chiste de Forges que abre este artículo se representa uno de los grandes males de todas las organizaciones, existen muchos puestos ejecutivos y de gestión en la cadena de producción, pero por desgracia, recae sobre el último escalafón la responsabilidad de la productividad.

Para poder mejorar esta productividad se suele caer en el error de querer motivar al empleado con ofertas como si fuera el consumidor de un establecimiento de alimentación, pagas de horas extras, regalos por objetivos, viajes anuales, cheques de restaurantes, etc.

Este planteamiento solo tiene una repercusión directa cuando el trabajo que realiza la persona es automático, sin ningún tipo de creatividad, dado que no dispone de ningún otro estímulo posible. Un empleado que esté ocho horas vigilando un proceso de una máquina o controlando que en una cinta transportadora el material este en perfecto estado, no tiene ni un solo segundo para ser creativo, aunque si puede aportar ideas para la mejora continúa de procesos, que normalmente se le ocurren descansando en otro lugar.

Pero existen muchos otros tipos de trabajo, donde siempre hay parte de procesos creativos. Se pueden poner por ejemplo muchas pequeñas tareas: redactar una oferta o presentación a un cliente, atender o realizas llamadas, etc. En todos estos trabajos hay una parte mecánica pero otra creativa, dado que por ejemplo una persona que atiende una llamada, tiene que cumplir unos protocolos pero siempre hay incertidumbre sobre la respuesta del su interlocutor y ahí debe ser imaginativa y resolutiva.

En este segundo caso, para mejorar la motivación y la productividad no es óptimo aplicar los métodos antes comentados, el factor principal es tener un ambiente de trabajo excelente y sobre todo, dejar que las personas o equipos tengan autogestión, con ello se consigue que los empleados tengan poder para tomas decisiones, que tengan la capacidad de poder gestionar sus tareas, se consigue que se involucren más en los procesos, que estén más motivados, y como resultado final, aumente la productividad de forma directa.

Scrum ofrece precisamente un marco de trabajo donde se fomentan estos aspectos, por lo que una de las primeras consecuencias que tiene la integración de Scrum en una empresa es el aumento de la productividad.
Scrum además introduce este proceso de una forma natural, sin ser impuesto desde arriba, por lo que las personas se sienten con la capacidad de poder tomar decisiones que mejoren sus condiciones laborales, consiguiendo con ello aumentar su motivación.

Esto no significa que las empresas tengan que renunciar a ciertas prebendas que les ofrecen a sus empleados, pero hay que tener en cuenta que la principal es que el empleado se sienta valorado como persona, que sepa que sus ideas o mejoras son tomadas en cuenta y aplicadas en los procesos.

En resumen, las empresas pueden ofrecer puntualmente algunas recompensas extraordinarias, pero la mejor de todas es que un empleado se sienta involucrado de forma directa en los procesos, que se sienta parte de ellos. Scrum permite que esto sea posible.