Muchas personas creen que por negar varias veces al día algo se acaba convirtiendo en una afirmación, en un verda incontestable.

Esta doble negación es en verdad un síntoma de que algo falla,  achacando esta baja productividad al sistema y no a la ineptitud o ineficiencia de el que lo ejecuta.

Si buscamos en Google imágenes la palabra ineficiencia obtenemos este resultado:

Con un vistazo rápido podemos sacar varios conceptos asimilados a la ineficacia: El dinero y gráficos de bajada.

Las personas no se quieren sentir como el demonio de la primera imagen, desde el punto de vista de la empresa y del mercado, una persona ineficaz cuesta dinero y malgasta recursos de la empresa. Cuando se quieren introducir métodos de trabajo como Scrum, que con unas sencillas reglas se puede obtener la productividad y los costes de los proyectos, estas personas reniegan del mismo, buscan toda clase de excusas para así poder esconderse en otros procesos de gestión. Otros procesos que permitan camuflar su ineficacia, su ineptitud y su falta de implicación con los objetivos de la empresa y de sus compañeros. En definitiva, refugiarse en otros procesos que les permitan esconder sus carencias el máximo tiempo posible.

Negar que Scrum aumenta la productividad es algo parecido a negar que el aceite de oliva es bueno para la salud. Existen siempre unos intereses comerciales, empresariales, o de otra índole, que hacen que colectivos apoyen unos sistemas de gestión y desprecien otros, simplemente por intereses personales o pecuniarios. Estos apoyos además sirven para que la persona que realiza la negación se pueda apoyar en sus conclusiones erróneas.

Desde que comenzamos a ayudar a integrar las metodologías ágiles en empresas, siempre nos encontramos con ciertos individuos que realizan esta afirmación negativa, suelen protestar de que la bajada de su rendimiento es por causa de la integración de Scrum, y no por que ellos siempre han sido poco productivos, ineficaces, y desde que está integrad dentro de un equipo de trabajo él es el que menos rinde, no puede seguir el ritmo de sus compañeros, ni realizar las tareas estimadas por consenso.

Desde ese día esta persona se convierte en un enemigo público de las metodologías ágiles, defiende cualquier otra que le ayude a conservar su ineficacia.

Es verdad que Scrum no sirve para todo, no es la herramienta que va a salvar a una empresa de su mala gestión, pero si todo un equipo de trabajo ha decidido integrarlo como sistema de trabajo, es por que el equipo si ha entendido los beneficios, la mejora de la productividad y la eficiencia de los procesos, así como la felicidad de todas las personas que intervienen. Si el equipo ve los beneficios, el improductivo sale a la luz fácilmente.

El truco que se utiliza con los niños cuando le quitan un bolígrafo a un compañero en el colegio: “Será fácil identificar al ladrón, el bolígrafo destiñe así que tendrá las manos rojas”, el que ha cometido el hurto se mira rápidamente las manos, tiene que defender su inocencia. Pues con la integración de Scrum pasa lo mismo, el primero en negar es el primero en autoinculparse, el primero en negar la mejora de productividad.

]]> http://scrum.es/scrum/no-me-gusta-scrum-no-me-hace-ser-mas-productivo/feed/ 0 http://scrum.es/scrum/no-me-gusta-scrum-no-me-hace-ser-mas-productivo/ http://feedproxy.google.com/~r/scrum-es/~3/Spq8_qtlvf4/ http://scrum.es/scrum-es/la-agilidad-una-bandera-a-seguir-por-todos-los-departamentos/#comments Tue, 29 Jun 2010 13:07:23 +0000 Dani http://scrum.es/?p=1238

La agilidad debe ser la bandera que se encuentre en el estandarte de todas las empresas, significa que toda la empresa debe estar unida, que todos los equipos deben trabajar de forma continua junto con el cliente o a un producto que se quiera lanzar.

Esa bandera debe ondear cada día, no solo a principios cuando se integra el sistema de trabajo dentro de una empresa, si no que no tiene sentido que algunos departamentos lo sigan a rajatabla y otros no, lo que no puede suceder es que los clientes, en el caso de que se trabaje para un tercero, reciban mensajes desde los departamentos de ventas o marketing que desconocen los equipos de ejecución, que negocien plazos o requisitos que pongan en riesgo el objetivo.

La bandera de la agilidad debe ondear en la puerta de toda la empresa, para que la vean todos los departamentos y personas, y no solo para ciertos equipos.

El problema surge cuando un departamento tiene unos interese particulares, estos acaban construyendo su propia parcela de poder, buscando su espacio para tomar decisiones y poder controlar una parcela de poder. La bandera de la agilidad debe hacer desaparecer este pensamiento, dado que todos los departamentos trabajan conjuntamente por crear un producto o solucionar un problema a un cliente.

Las empresas que están estructuradas en la suma de estas pequeñas parcelas de poder son mas costosas, invierten mas recursos, y se generan mas gastos.

Existen algunas parcelas de la empresa que siempre se sienten ajenas a cualquier tipo de estructura, como por ejemplo la contabilidad, que como anteriormente hemos comentado, quieren mantener su propia parcela de poder y auto organización, defendiendo que sus tareas no tienen nada que ver con el proceso de creación o de servicio que ofrece la empresa. El error de este planteamiento, es que la bandera de la agilidad, lo que exalta es la comunicación, el diálogo, no tan solo con el posible cliente, si no entre todos los departamentos, y aunque el de contabilidad, por ejemplo, no esta involucrado directamente en la cadena de producción, si afecta a otras decisiones que se pueden tomar, por lo que si estuviera informado informado podría ayudar y asesorar para que el resultado final sea mas óptimo, mejorando con ello la calidad del resultado.

Esta comunicación entre departamentos es esencial, para que la empresa como un equipo conozca que se esta realizando, los objetivos que se quieren conseguir, y que toda sepa por camino andan cada día.

No hemos escrito estos últimos días por que hemos estados trabajando en la ponencia que tenemos que dar en el evento.

A partir de la semana que viene volveremos a nuestra rutina de 1/2 post semanales sobre agilidad y Scrum.

Desde aquí os animo, a los que todavía no lo tengan claro, a acudir a este evento.

Se están dando pasos para ir asentando las metodologías ágiles como un sistema eficiente de creación de software, y durante dos días podremos ver ejemplo de éxitos.

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 listado de ponentes y de las sesiones.

No vamos a engañar a nuestros lectores, no nos hemos leído el estatuto entero por el que se rige la Scrum Alliance. Mas o menos lo que hemos hecho es echar un vistazo y detenernos en algunos puntos concretos.

Aun reconociendo nuestra falta de profesionalidad por no leernos el documento completo y de forma detenida, os ponemos el enlace para que si algún lector tiene interés pueda descargárselo.

Si quieres conocer como se rige la institución que controla las certificaciones de Scrum puede interesarte la lectura.

Esta semana hemos asistido a la universidad para dar una charla de introducción a Scrum.

La mejor manera de dar a conocer las metodologias ágiles es hacer ágil la clase, convertir a tu auditorio en partícipes activos. Los alumnos comentaron que en otras charlas los ponentes venían con un mensaje prefijado y no interactuaban apenas con él.

El planteamiento que se planificó para su primera lección introductoria  fue muy sencillo, una breve explicación sobre el manifiesto ágil, las herramientas y los roles, y luego a jugar con una estimación real entre todo los asistentes empleando Plannigpóker.

Los que mas le gustó fue este último aspecto, sentirse parte de la ponencia, saliendo al estrado a dar explicaciones sobre el por que afirmaban que una historia tenía un coste concreto, distinto del de sus compañeros.

El juego consiste básicamente en crear un proyecto sobre alguna tarea habitual que realicen los alumnos, por ejemplo, limpiar una casa. Se crean las tareas: Barrer el suelo de una habitación, fregar el cuarto de abaño, limpiar el polvo de una estantería,  etc. Los alumnos van creando las historias y luego las estiman. Lo mejor viene cuando tienen que explicar a sus compañeros por que ellos creen que algo cuesta el doble de lo que dicen los demás.

El tiempo en la universidad es escaso, pero con este rápido juego se fomenta el espíritu de colaboración, de trabajo en equipo, en verdad, la lección que aprenden es que es la comunicación es el éxito de los proyectos, mas que las herramientas o las metodologías.

Uno de los grandes errores que cometen muchas empresas al introducir Scrum como metodología de trabajo, es que confunden la sencillez de sus principios, con la complejidad de integrarlos en un grupo de personas.

En Slideshare podemos encontrar muchos cursos de Scrum. Destacamos este que nos permite explicar que es Scrum a un neófito en diez minutos, y son precisamente estos titulares los que le llevan a la confusión antes comentada.

Explicar Scrum es bastante sencillo, sus principios y sus herramientas no tienen una gran complejidad, por lo que en realidad con un curso que dure como mucho un día, cualquier empresa puede empezar a aplicarlo sin necesitar nada más. El coste de adquirir conocimientos sobre Scrum es bastante barato en tiempo.

El error se comete cuando se piensa que por disponer de un grupo de herramientas y de un sistema sencillo, la complejidad de integración es también sencilla. El problema no viene por las herramientas o por los sistemas, vienen por las personas que participan.

Los roles obligan a cada persona que está implicada a tener que asumir su papel sin interferir en el de los demás y a tener que pensar en equipo y no en uno mismo. Cuando se integra Scrum el cambio de mentalidad obliga a que las personas realicen un esfuerzo para adaptarse a él, un esfuerzo que requiere un gran sacrificio al principio, hasta que haya asimilado el cambio a la agilidad.

En conclusión, los titulares que propugnan que agilidad es igual a sencillez son un error y llevan a la confusión, las metodologías ágiles son fáciles de integrar pero igual de difíciles de gestionar al principio, aunque a diferencia de otras metodologías, una vez superada la primera fase de integración, la producción se hace más efectiva y eficiente, dado que la carga de gestión de los procesos es menor.

Los clientes primerizos demandan mucha información sobre los procesos de creación de  los proyectos y sus fases. Demandan sobre todo esta información por que quieren tener controlado tanto el proceso como el coste, sobre todo esto último.  El problema ante el que nos encontramos es más de concepto empresarial que de uso de una u otra metodología.  La agilidad debe ser una opción que toma el cliente por que crea en ella y sus fundamentos y no por que la quiera integrar en un entorno donde de no se quiere hacer ágil y no quiere aprender a delegar funciones y responsabilidades en el equipo de trabajo.

La mejor manera de representar a un cliente una planificación de costes es explicarle que esta se va realizando por bloques, que él mismo se marca unos objetivos parciales, sobre ellos se hace una labor de extraer las historias concretas hasta el último detalle, que son las tareas. Sobre estos detalles se realiza una estimación y se da el coste, así como el tiempo de desarrollo, llamado sprint para cada objetivo. Los equipos que estiman  tareas a corto plazo lo hacen mejor, con un nivel de detalles mas riguroso,  conociendo mejor la complejidad, el coste y el tiempo de desarrollo, dado que cada equipo conoce su velocidad.

Con el cliente se tiene que trabajar en un documentos de objetivos con requisitos generales, estos deben quedar claro, así el cliente tiene la garantía de conocer el orden de cumplimiento de objetivos y que aspectos principales tendrá, pero no se conoce el coste exacto, dado que este se irá fraccionando. Suele ocurrir que el cliente, para conseguir cada objetivo parcial, exige mas esfuerzos de los inicialmente estimados, por eso es mejor realizar para cada objetivo la estimación directa y añadir mientras vayan ocurriendo las tareas extras.

El enfoque de un coste cerrado por adelantado debe ser  cambiado por el de  ”Coste para cumplir unos Objetivos”.  Si un cliente quiere conocer el importe exacto de cada fase, lo mejor es darle una orientación, un rango, cuando mas complicado sea el objetivo mas amplio el rango. Hay que hacerle entender el beneficio de las metodologías ágiles aun teniendo una incertidumbre sobre el coste exacto del proyecto.

La Disección en los inicios del proyecto podría presentarse al cliente de la siguiente manera.

La experiencia del cliente le va llevando a conocer el coste aproximado de un objetivo en relación al número de sprints necesarios para conseguirlo, algo que le sirve de orientación, y con el paso del tiempo lo acaba asumiendo y entendiendo. Cerrar un precio es tan perjudicial para el equipo desarrollo como para el cliente, dado que no puede moldear el encargo cuando va viendo los resultados parciales.

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.