Blog&Artículos

6 levels of Agile karma

According to various religions, karma is a transcendent energy (invisible and immeasurable) which is derived from the acts of individuals. Agile also has its own karma which is divided into 6 levels. Each of these offers a different kind of «energy» which is translated into a specific and unique type of feedback loop.

Agility requires the 6 levels implemented and operating effectively to continuously grow into a healthy and unstoppable eco-system.

KarmaFinal

The level zero is what I call Hell or Inferno. In here, the focus of the whole organization is set to push for deliveries at certain dates without seriously considering business value as an evolutionary process. This mentality brings a drop in quality, the creation of a pool «resources» that will make employees slaves of products, bunches of unstable code and products that will not fully satisfy the customer. This will also cause uncertainty about the completion of products by certain dates, thing which will fuel a bigger vicious circle of unintended consequences.

Karma Level 1 implies the adoption of the Agile mindset. Under this energy, people have an internal feedback loop where the customer is placed first and in the centre of the universe. Understanding how to deliver value to them is the primary objective of this kind of energy. This «energy» places also the focus on the effectiveness of a perpetual cadence to  deliver business value and the use of honest and face to face communication. This level of innate feedback occurs in the conscious area of the brain related to decision-making -and is the fastest one-.

Karma level 2 focuses on the use of work in pairs 24/7 (pair programming).This technique has been shown that not only help teams share and retain knowledge within the group but also empowers them to validate and make better design decisions. This  promotes a sense of collaboration on its various tasks and reduces code «paternity», reinforcing individuals to explore different options based on its diverse points of view. This kind of «energy» should be mandatory on times where software complexity has raised exponentially. This circle enables a feedback loop to the team in a matter of seconds.

Karma level 3 focuses on refactoring, writing tests first and Test-Driving-Development (as also as acceptance tests or similar). TDD is a disciplined practice where teams write the evidence that will support a hypothesis before writing the implementation itself. TDD helps create a structure which facilitate changing the application quickly as well as reducing defects and increasing reliability and code quality. Here the feedback loop occurs in a matter of minutes.

Karma level 4 of karma focuses on breaking a pattern typically found in traditional software companies: integration of the components of an application at the very last minute or when the project is almost done. When continuous integration is used, this process is often carried out in a matter of hours. This helps teams lower the risks of integration and eliminate potential periods of stabilization. Using continuous integration activates a  feedback loop which helps analysing  all the code as a whole, thing which occur within tens of minutes.

Karma level 5 becomes in place when the Product Owner is collocated with the team. This helps the group obtain support and questions answered in a maximum of hours. This creates a feedback loop which increases the level of communication related to the product, thing which will decrease the times from days to hours.

Finally, the Karma level 6 keeps the team focused by using a time-box. This allows an  effective flow of information and feedback loop from clients/stakeholders (Stakeholders) in weeks rather than months. This energy will re-affirm the cadence and prepare effectively people to future demands, thing which ultimately strengthen the nature of evolutionary software.

The 6 levels of Karma  must be adopted effectively and in full in companies wishing to move into the Digital IT world and Agility. The fact that one does not exist or is not addressed in full will hinder the company growth towards the creative economy and the steps  towards being a continuous learning organization.

Have in mind that any effect on the lower levels exponentially affects the upper circles. Because the feedback loop times are different inside each circle, the consequences will be seen deferred in time, thing which will increase system complexity and complicatedness. In the event of that happening in a traditional company, people will tend to focus on solving the a problem -resulting from the action in the past- rather than addressing the root/real cause.

This last thing is generally seen in immature companies without continuous improvement. In there, any fault on the inner circles will be addressed by adding new processes or controls to alleviate the system imbalances. The result will be an  increase in complexity and complicatedness and  establish a bigger vicious cycle which will destabilize the other areas.

As you can see, the 6 levels of Karma help teams and companies find a way to self-evaluate and improve themselves. Having in mind the circles in this way will also help understand the effect of the actions and connection between them and the different timings.

In which level of Karma is your team or company currently now?

Enterprise Social Systems explicado…


¿Qué es Enterprise Social Systems (ESS)?

Es una teoría, un conjunto de herramientas y un marco de cambio organizacional que permite acelerar la transformación y modernización de cualquier empresa.
A diferencia de la teorías clásicas que se centra en ver la empresa como interacciones entre máquinas y seres humanos, o la teoría neo-clásica que se centra en variables mecánicas y fisiológicas, ESS se centra en 4 áreas fijas interdependentes (Sistema Social, Mentalidad, Organización formal y creación de Valor) con un fuerte enfoque sobre las redes de valor.
Su principal hipótesis es que el valor de negocio es un elemento clave y que el aumento de la los flujos relevantes de información, el aprendizaje, la forma en la que se hacen visibles los trabajos, la forma en que se gestiona el flujo de trabajo  y la disminución de complejidad tendrán un impacto positivo para construir una empresa exponencial.

¿Cuáles son sus beneficios?
ESS no es intrusivo lo que permite que las personas se sientan confortables utilizándola sin importar la metodología, forma de pensamiento o tipos de estructuras de la empresa.
Esto último apoya que el cambio se viralice y que se puedan fácilmente crear formas de trabajo y planes innovadores que mejoren la organización en tiempo récord.

¿Cuáles son los fundamentos de ESS?
ESS explica la empresa como un sistema complejo de 4 partes interdependientes (Sistema Social, Mentalidad, Organización formal y creación de Valor) donde cada una de ellas cuenta con un conjunto de características específicas que son afectadas por diferentes factores. Comprendiendo cada una de estas es clave para entender la teoría.
El hecho de emplear una visión estándar sobre la organización brinda un mapa consolidado que alinea la forma en que los empleados ven las estructuras de la empresa, sus dependencias y como realizar un cambio.

¿Cuáles son los componentes de ESS?
ESS cuenta con los siguientes 5 componentes:

– Desidad Social Empresarial (Enterprise Social Density)
– Visibilidad Social Empresarial (Enterprise Social Visibility)
– Colaboración Bloqueante Empresarial (Enterprise Blocking Collaboration)
– Patrón de permiso para aprender (Permission to learn Pattern)
– Patrón de Complejidad y complicación (Complexity and complication pattern)

ESS ofrece a su vez 2 marcos de cambio denominados ELSA y DeLTA, que hace posible acelerar un cambio en la empresa.

DELTA change framework es utilizado para acelerar una transformación o cambio cuando los líderes de la empresa no están involucrados con el cambio o la transformación de la organización, mientras que ELSA se emplea cuando estos están totalmente integrados y apoyan la misma.

ESS_Framework_English_Small

Puedes hacer clic aquí para bajar el modelo de Enterprise Social Systems en formato PDF (estará disponible en Español en breve).

¿Dónde aprender más?
Si deseas conocer más sobre ESS, puedes mira primero el webinar sobre Enterprise Social Systems de Scrum Alliance.

progress2

 

¿Quieres saber más sobre cómo acelerar tu transformación de negocio?

ebuhler-exponencial-cover-promo-book.png

Disponible en todo el mundo el 17 de Mayo de 2017 en papel y ebook

 

Gran éxito en el primer Scrum Day Chile

Te reproduzco el artículo publicado por Lookforward Consulting hace algunos días atrás.

August 13 de 2015 Santiago, Chile – más de 140 personas llenaron el salón el 8 de agosto para apoyar el primer Scrum Day Chile organizado por Erich Bühler. Con una colección de variada representación de ponentes internacionales, Scrum Day Chile ofreció cinco presentaciones de pensamiento provocador para los participantes que representaron a las empresas de software chilenas, tanto grandes como pequeñas. Los temas de Scrum Day Chile incluyeron cómo escuchar las señales que envía la organización sobre la salud Agile, cuáles son los cinco factores claves para tener éxito con el inicio de Agile en una nueva organización, la forma de poner en marcha un equipo de Agile en cinco días y nuevas formas para estimar el valor de negocio para apoyar la mejora de priorización.

IMG_0725Carlton Nettleton, Presidente de Look Forward Consulting, presentó su sesión en la escritura de historias de usuario maravillosas utilizando Story Cubes de Rory. Preguntado sobre cómo se recibió su sesión, Carlton dijo, “voy a tener que admitir que estaba un poco nervioso de hablar delante de una multitud tan grande en español, pero ésta no era la primera vez que habla en un idioma extranjero. No debería haber estado preocupado ya que a las personas realmente le gustan los Story Cubes! Donde quiera que voy, la gente se conecta instantáneamente a los Story Cubes y comenza a divertirse”.

Scrum Day Chile es la tercera vez en la que Carlton ha hablado en un evento internacional sobre el tema de la mejora de las historias de usuario con Story Cubes. “Soy un apasionado de volver a conectar a las personas con el verdadero propósito de las historias de usuario – contar historias sobre el software con el cliente. Los Story Cubes son poderosas herramientas para empezar a contar y escribir mejores historias de usuario ahora”, Dijo Carlton cuando se le preguntó acerca de por qué esta sesión ha sido un tema recurrente en su discurso público en el 2015.

La sesión de Carlton en la escritura de historias de usuario maravillosas se ofrecerá de nuevo en Agile San Diego en septiembre de 2015 y en el Scrum Gathering Prague en noviembre de 2015. Para ver la presentación de Scrum Day Chile Day, por favor, siga este enlace de SlideShare.

Gracias por escucharme,

Erich.

Pd: si no leíste mi libro sobre agilidad empresarial para agentes de cambio, conoce más aquí.

Los 6 niveles de Karma Ágil

Según varias religiones, el karma es una energía trascendente (invisible e inmensurable) que se deriva de los actos de las personas. Agile tiene también su karma el cual se divide en 6 niveles. Cada uno de ellos ofrece un tipo de “energía” el que se traduce en un tipo específico y único de retro-alimentación.

La agilidad requiere de los 6 niveles implementados y funcionando de forma efectiva para poder crecer continuamente en un camino sano e imparable.

KarmaFinal

El nivel central es el que yo llamo el Infierno, bajo este tipo de energía el foco de la organización se pone en presionar para lograr la entrega en una fecha o rando de fechas dadas, lo que traerá una bajada de calidad, la creación de un pool de “recursos” que hará que los empleados sean esclavos de negocio, el código sea inestable, los productos no satisfagan totalmente al cliente y los tiempos de entrega sean altos, alimentando así varios círculos viciosos.

El nivel 1 de karma implica el pensamiento y los valores Ágiles. Aquí las personas tienen auto-alimentación interna que comienza por el hecho de comprender la importancia del cliente como el centro del universo, la entrega de valor hacia el mismo como objetivo primordial, la cadencia efectiva a perpetuidad así como la conversación honesta y cara a cara. Este nivel de retro-alimentación innata se produce en las decisiones que toma el individuo.

El nivel 2 de karma se centra en la utilización de trabajo en parejas 24/7. El uso de esta técnica ha mostrado en investigaciones realizadas por allá por 2012 que no solamente ayuda a los equipos a compartir y contener el conocimiento dentro del grupo, sino que también empodera a ellos a validar y tomar mejores decisiones de diseño. Esto a su vez favorece el sentido de colaboración sobre las distintas tareas y disminuye la “paternidad” del código, lo que refuerza a los individuos a explorar diferentes opciones basadas en distintos puntos de vista, cosa necesaria en tiempos donde la complejidad del software se ha vuelto exponencial. Este nivel hace posible una retro-alimentación a los miembros del equipo en cuestión de segundos.

El nivel 3 de karma está basado en refactorización y escribir la prueba primero así como Test-Driving-Development (y pruebas de aceptación u otras similares). TDD es una práctica disciplinada en la que los equipos establecen las pruebas que soportarán una hipótesis antes de escribir su implementación. TDD ayuda a crear una estructura que apoya los cambios inminentes en la aplicación así como la disminución de los defectos e incremento de la confianza y calidad en el código. Aquí la retro-alimentación se produce hacia el equipo en cuestión de minutos.

El nivel 4 de karma se centra en romper un patrón que se encuentra en las empresas de desarrollo de software tradicional: la integración de los componentes de la aplicación únicamente al momento en que la característica está finalmente completa. Cuando se emplea integración continua, este proceso se realiza frecuentemente y en cuestión de horas. Ello ayuda a los equipos a bajar los riesgos de integración y eliminar periodos potenciales de estabilización. Al utilizar integración continua, la retro-alimentación sobre como todo el código trabaja en su totalidad se produce en cuestión de decenas minutos.

El nivel 5 de karma se hace efectivo cuando el propietario del producto está en el mismo sitio que el equipo, lo que ayuda a éste a obtener apoyo y responder preguntas sobre éste en cuestión de horas. Ello aumenta el nivel de retro-alimentación sobre el producto y baja ella de días a horas.

Finalmente, el nivel 6 de karma hace que el equipo se centre en tiempos fijos, lo que permite obtener retro-alimentación efectiva desde el cliente/partes interesadas (Stakeholders) en cuestión de semanas y no meses, re-afirmando así la cadencia y preparando a las personas efectivamente para futuras demandas, lo que finalmente consolidará la evolución natural del software.

Los 6 niveles de Karma deben ser adoptados efectivamente y en su totalidad en las empresas que deseen moverse hacia el mundo digital y la agilidad. El hecho de que una de ellas no exista o no se aborde en su totalidad dificultará el crecimiento de la compañía hacia la economía creativa y organizaciones de aprendizaje.

Cualquier efecto sobre los niveles inferiores afectará de forma exponencial a los superiores. Debido a que los tiempos de retro-alimentación son diferentes por cada círculo, el resultado de éste se verá normalmente en forma diferida, lo que aumentará la complejidad del sistema. Las personas cuando ello pasa se centrarán generalmente en resolver el problema que tienen (derivado de una acción de días o semanas atrás) en vez de analizar y eliminar la causa.

Ello hará que adicionen nuevos procesos para palear la descompensación del sistema, lo que aumentará la complejidad y nivel de complicación, generándose así un círculo vicioso que desestabilizará los demás círculos de Karma.

Como puedes ver, ellos sirven para ofrecer a los equipos y la empresa una forma de auto-evaluación y mejora que le sirva para comprender el efecto de las acciones y la conexión con los varios niveles y su respuesta diferida.

¿En qué nivel de Karma estás tu o tu empresa?

Gracias por escucharme,
Erich.

ScrumDay llega a Chile por un cambio positivo 8.Ago.2015

Finalmente te confirmo que el  8 de Agosto se llevará adelante ScrumDay en Chile. El mismo tendrá como objetivo que las empresas puedan comenzar a conectar con Ágil y Scrum, así como también abrir las puertas hacia el cambio y las personas poder relacionarse con individuos con intereses similares. Se obtendrán también 6 puntos SEU necesarios para mantener la certificación de Profesional Certificado de Scrum.

Deseo que ScrumDay Chile tenga un impacto positivo en la comunidad y para eso, he convenido que se done la totalidad de las  ganancias del evento a un organismo de caridad que trabaja con niños en difícil situación (ver más en ScrumDayChile.cl)

Si estás en Chile, es tu momento de aportar un cambio positivo, baja el documento que está a continuación y envíalo a tus contactos o imprímelo y colócalo en tu empresa.

ScrumDay Brochure (MS Word)

ScrumDay Brochure (PDF)

Gracias por escucharme,
Erich.

Dividir historias de usuario

Hoy será breve; hace mucho tiempo que utilizo un documento para enseñar algunas técnicas sencillas sobre como dividir historias de Usuario y quería compartirlo contigo 🙂  Puedes bajarlo aquí: Cómo dividir una historia de usuario o leerlo abajo.

¿Cómo dividir una historia de usuario? Algunas ideas

  • Las historias brindan siempre valor de negocio y son escritas con lenguaje de negocio y no como características técnicas.
  • Las historias deben ser capaces de poder verificar una hipótesis tan pronto como se haya implementado.
  • Debe existir una forma de medir cuán exitosa ha sido la historia en comparación a que ella no se haya implementado (dinero, clicks, etc).
  • Las historias deberías ser Independentes, Negociables, Valoradas, Estimables, pequeñaS, y Testables (Independiente no es excluyente pero deseable).
  • Asegurarse que se focaliza en un usuario en particular (no genérico)
  • Extraer la historia por su funcionalidad de negocio básica que brinde valor de negocio. Hacer primero que pruebe una hipótesis mínima y luego mejorarla o hacerla más bonita con subsiguientes historias.
Pasos por flujo de trabajo

Como Editor del periódico, deseo publicar artículos al sitio corporativo

…Puedo publicar noticias directamente al sitio corporativo

…Puedo publicar noticias que necesiten ser revisadas.

…Puedo publciar noticias que requieran ser validadas legalmente.

Variaciones por reglas de negocio

 

Como Juan, deseo buscar por vuelos en fechas flexibles

…en pasajeros de clase negocio

…en fechas específicas

…en vuelos directos/indirectos

Esfuerzo

 

Como Pedro, deseo poder pagar con tarjetas de crédito o por transferencia bancaria

…puedo pagar con algunas tarjetas (las más fáciles/difíciles de implementar)

…puedo pagar con todas las tarjetas

…puedo pagar mediante transferencia bancaria

Simple/Complejo

Como Juan, deseo buscar con vuelos entre 2 destinos

…número de paradas

…fechas flexibles

…diferentes compañías y cabinas

Variaciones en datos

Como pasajero local, deseo ver el sitio en mi idioma

…en inglés.

…en Japones.

…en Árabe.

…etc.

Por felicidad

Como Juan, deseo buscar vuelos entre 2 destinos.

…hacer la búsqueda menos eficiente en términos de tiempo primero.

…refinar…

Por investigación

Como Pablo deseo poder comprar un pasaje (**)

…investigar que tan complejo es el proceso de compra

Por criterios de aceptación

Si hay muchos criterios de aceptación…

Seguramente se pueda dividir en 2 historias

Sintáctico

Buscar Y o O en la historia; ellos son marcadores que permiten pensar de potenciales historias

(*)Asume que Juan y pedro son perfiles conocidos.
(**)No se podrá adicionar la historia hasta el Sprint próximo

Gracias por escucharme,
Erich.

El Anti-patrón del foco en la entrega y Scrum

El foco en la entrega de software es una actitud (o anti-patrón) que se ha arrastrado por años y que se consideraba como una o la forma de trabajo eficiente. Al final de un período de tiempo, la empresa entrega un producto y el éxito se mide en la cantidad de características que han podido ser completadas/producidas. De esta forma, las organizaciones basaban muchas de las métricas y alimentaban su eco-sistema/inercia con  un compromiso inicial basado en el número de características a terminar/finalizadas.

Los distintos departamentos a su vez actuaban como contrapartes que verificaban y ejercían como sistemas de control los unos sobre los otros, ya sea mediante la solicitud de informes/reportes o presión social.

Cuando se comienza a emplear Scrum, parece natural hacer la misma cosa, esto es, tratar de finalizar el mayor número de características en cada Sprint.  Y es de aquí donde viene la idea que Scrum o Ágil son formas para entregar más rápido. Es así que las empresas planifican su entrega regular y se encargan de mantener a las personas focalizadas para que acaben con el mayor número de requisitos en las fechas acordadas. Si es posible, se hará economía de personas, tal como tener un Scrum Master que a su vez sea parte del desarrollo o contar con individuos que entren y salgan de los equipos; aquí el objetivo es entregar.

Nuevamente se asocia valor de entrega con éxito ya que primera vista parece ser la forma natural de abordar el ciclo de trabajo de un producto de software. No obstante, existen 3 características recalcables que la agilidad impulsa y que son diferentes a las tradicionales:

  1. Que el enfoque es en el aprendizaje (todos hayan aprendido nuevas y mejores formas de hacer las cosas).
  2. Que se haya esparcido el conocimiento entre los miembros del equipo y su posterior retro-alimentación a la empresa
  3. Que los requisitos dejen de serlo y sean ahora hipótesis a convalidar o invalidar, lo que requerirá conocimiento y maduración continua.

Es así que el objetivo de un Sprint en Scrum es aprender así como también entregar, pero el foco deberá ser siempre en aprender como entregar soluciones de calidad que incrementen la creatividad e innovación de la empresa mediante un entendimiento compartido del problema. Scrum y Ágil no son formas de entregar más rápido, sino para identificar lo que el cliente desea y ayudarlo/ayudarnos a aprender como crear el mínimo mejor que éste necesite.

A mi criterio, el primer paso para una compañía que desea ser exitosa es el hacer visible este anti-patrón, buscar activamente soluciones  en ese camino y detener a cualquier intento del sistema que apunte hacia el modelo de la entrega (sabotaje), lo que obviamente crearía un bucle negativo continuo.

focoenlaEntrega

Si pones el foco en la entrega disminuirías el aprendizaje, lo que traería consigo que las personas fuesen menos creativas incluso terminando el mismo número de características, lo que reduciría la creatividad, la innovación, y haría que la compañía comenzase a ofrecer productos que no fuesende vanguardia, posicionando finalmente a la organización en un espiral descendente. Ello incentivaría nuevamente que la empresa se focalizase aún más en entregar, generando más presión sobre las personas, más horas de trabajo, decremento de visibilidad y valor por el trabajo, etc., lo que repetiría el ciclo (vicioso) una y otra vez.Y todo esto sin que el informe de cosas terminadas lo pudiese detectar.

Una de las cosas que encuentran difícil las organizaciones es romper con el círculo, y para esto se necesita hacer visible el problema y alinear a la organización con los nuevos valores (llamados de Economía Creativa).

PresentaciónScrumDay

Es allí donde Coaches y Espónsores ágiles deben conjuntar los esfuerzos constantemente para que ninguno de los nuevos elementos del sistema se vean afectados (deleitar al cliente, priorización por el mismo, gerentes como facilitadores, etc), ya que basta que un elemento falte o se debilite para que la inercia nuevamente ponga el foco en la entrega.

Es común a su vez que las propias personas se centren exclusivamente en la entrega por temas históricos (modelos mentales) o porque siempre se les ha dicho que hacer, y es en estos casos donde el Scrum Master juega un papel fundamental para romper con el patrón mediante el desafío de las creencias del equipo.

Finalmente, como se puede ver en la primera figura, tan solo el cambio de los elementos a positivo transforma la cadena en un círculo virtuoso, el que apoyará y ayudará a la empresa a posicionarse correctamente, así como también reducirá el desperdicio, apoyará a comprender el coste real del retraso (cost of delay) y reafirmará la cadencia y visibilidad en Scrum, cosa central de este marco de trabajo y la Agilidad.

Recuerda también la ley de Pareto, que indica que el avión solamente el 20% de las características serán las que provean mayor valor al usuario. Es entonces que tratar de identificar ese 20% ayudará a tener más capacidad al equipo para innovación y nuevas características, y permitirá a los usuarios y partes interesadas centrarse en lo que realmente importa.

¿En dónde estás tú y tu compañía en este momento?

Recuerda que puedes aprender más en mi libro Lidera el cambio exponencial.

Gracias por escucharme,
Erich.

Deja de subcontratar y céntrate en la causa y no en el problema

Muchas de las empresas que me topo día a día subcontratan personal para el desarrollo de software. Básicamente, encuentro 3 motivos por el que lo hacen:

1. Quieren ahorrar costes
2. Tienen un proyecto corto y no desean contratar personal adicional y/o fijo
3. No hay personas suficientes en el país o región.

Comencemos por el principio; el desarrollo de software es una actividad creativa que prueba hipótesis con software (antiguamente llamados requerimientos), pero no es una actividad industrial manufacturera. Cada vez que se desea implementar algo, no se sabrá si ello es cierto hasta que no se ponga en manos del usuario final un producto funcionando, lo que generará un ciclo de retro-alimentación hacia el equipo y la empresa.

 

Una vez que esto pasa, algo interesante ocurre… se comienza a incrementar la base de conocimiento grupal: las personas aprenden y descubren nuevas formas de hacer y resolver las cosas y constantemente las mejoran como parte de su actividad del día a día.

Por el otro lado, existe una característica principal que reside en que la mayor parte del tiempo los desarrolladores de software invierten su tiempo en pensar como resolver un problema y no en codificar, como muchos creen. El desarrollo de software es entonces una actividad actividad social, cuanto mayor sea la conexión o interacción efectiva y honesta entre personas (hablen y se comuniquen activamente), mayor será la efectividad y velocidad para  madurar las ideas.

A este indicador se le llama densidad social e indica que tan efectiva es la comunicación entre individuos de una organización. Cuanto más alto sea este indicador, mejor estará posicionada la organización para competir y mayor será su agilidad. El hecho de intercambiar efectivamente ideas y puntos de vista entre las personas aumentará notablemente el conocimiento grupal y permitirá tomar decisiones de forma efectiva. Imaginemos entonces al conocimiento grupal como una burbuja que flota sobre los equipos y empresa y crece con el tiempo.

Éste último a mi parecer es el mayor activo que tiene una empresa, incluso más que el el software en sí.

El aumento del conocimiento grupal hace que las soluciones y crecimiento de la empresa se pueda plasmar como  software o cualquier otra actividad no relacionada de forma sostenible. Debido a ello, éste último puede y se transforma constantemente en alternativas que podrían o no ser  un producto computacional.

1. Quiero ahorrar costes

Si quieres ahorrar costes deberías pensar que una vez que subcontratas bajas la densidad social, por lo que tu producto será mucho más caro de implementar. A su vez, el conocimiento grupal que tanto te costó crear no se generará con la misma frecuenta ya que los bucles de retro-alimentación entre el proveedor y tu empresa serán menos frecuentes, ya sea porque las personas están alejadas o no se sienten ni sentirán nunca parte de tu organización. A su vez, el día que tu proveedor cambie los miembros del equipo o los rote, se habrá destruído parte o la totalidad del conocimiento grupal por el que has pagado.

2. Es un proyecto corto por lo que no deseo contratar personal adicional y/o fijo

¿Quieres mantener a tu cliente fiel? Deberías centrarte en mantener el conocimiento grupal y densidad social alta para poder ofrecer nuevas soluciones y trabajar la confianza de éste con el fin de que te vea como su aliado. En la mayor parte de los casos, no existe tal cosa como un producto que comienza y termina, todo es un beta eterno que crece cuando tu cliente trepa el mercado, y es allí donde tu estás como su ayudante inseparable.

3. No hay personas suficientes en el país o región.

Seguro que si google o apple publica un aviso en el periódico habrá una lista larga de candidatos que desearán trabajar para ellos. Quizá el foco debería ser en lograr hacer tu empresa más atractiva, apoyando a las personas para que aprendan más de lo que a ellos le parece importante, incrementar la confianza y un sueldo acorde.

Son muy raros los casos donde es buena idea sub-contratar personal y en la mayor parte de los casos, es lo que se denomina optimización local, esto es, querer mejorar algo simplemente viendo una parte del problema.

El sub-contratar a su vez agrega complicaciones y complejidad adicional en las interacciones, y como normalmente los individuos o equipos subcontratados vendrán con la cultura de la empresa proveedora pero no la tuya, nunca terminarán de encajar dentro de las creencias y valores de tu compañía.

A mi parecer, subcontratar no es una idea maravillosa sino que una forma que ataca el problema sin resolver la causa, generando asi una maraña de nuevos inconvenientes. Todavía estás a tiempo de convencerme de lo contrario 🙂

Gracias por escucharme,
Erich

ScrumDay Valencia dona 770 euros a caridad

Debo decir que fue duro para mi organizar el evento, pero creo que ha dejado una semilla en el mercado Valenciano que continuará rodando por los próximos tiempos. Está claro que ágil implica un cambio de paradigma con repercusiones políticas, sociales y económicas  y que Valencia no puede quedarse atrás.

Pero… ¿Porqué ScrumDay Valencia?

Hay dos cambios importantes que deben asumir las empresas, el primero es que tienen deleitar siempre a sus clientes y para ello asumir que cada «requierimiento» no es más que una hipótesis que tendrá que ser comprobada lo antes posible con estos. Para lograrlo, las compañías tienen ineludiblemente que reducir los ciclos de producción, lo que implica necesariamente la eliminación de todo aquello que no brinde valor al cliente, tener equipos estables y auto-organizados y transparencia a todos los niveles.

El segundo punto es que el desarrollo de software pasa a ser una actividad social en vez de un simple proceso de producción en masa (de software). Esto implica que las leyes de la sociología, dinámica de grupos e inter-relaciones y sistemas son ahora más importante que el proceso de fabricación en sí. De hecho, los modelos de producción del siglo pasado dejan de ser válidos y traen consigo más dolores de cabeza que soluciones.

“El desarrollo de software pasa a ser una actividad social en vez de un simple proceso de producción de software.” E. Bühler.

La densidad social (o número de conexiones efectivas e informales entre personas) tiene repercusión total sobre el éxito de la compañía. Las empresas donde sus empleados utilizan medios de comunicación poco eficientes (email, relaciones de comunicación indirecta con alto peso político, etc.) o lo que es igual, baja densidad social, están predestinadas a desaparecer en el mediano plazo.

Es así que el mercado necesita un cambio profundo y urgente y es primordial que las personas se acerquen al menos una vez al año a un espacio con el fin de conocer las diferentes alternativas. Esto se logra solamente con profesionales experimentados que puedan brindar información relevante y actualizada sobre el pensamiento Ágil. Mi agradecimiento a Matthieu Tournemire, Vanesa Tejada y Raúl Herránz por las fantásticas dinámicas realizadas durante ScrumDay.

Donación70

Finalmente, creo en la responsabilidad social y el impacto positivo a la comunidad, por lo que se ha donado todo lo recaudad (770 euros) a Casa de la Caridad, una organización que trabaja con adultos y niños que viven en Valencia por debajo del límite de la pobreza.

Gracias por escucharme,
Erich.

Resultados de la 9na. encuesta del estado de agilidad

Hace unos días VersionOne hizo público los resultados del informe anual del estado de agilidad en las empresas. El estudio que comenzó en Septiembre de 2014 e incluyó casi 4.000 empresas de diversas áreas, abarcó 65% de compañías en USA, 21% en Europa y 14% en el resto del mundo.

0714_state-of-agile

Si bien las empresas aseguran utilizar Ágil y Scrum, se debe tener en cuenta que el entendimiento de lo que esto incluye puede variar de una a otra.

Scrum sigue siendo el marco de trabajo más empleado con 56%, seguido por otros con menos del 10%, y siendo la velocidad (Velocity) de los equipos la forma más común de medir el éxito de los mismos.

En cuanto al escalado de equipos, el método más utilizado es Scrum de Scrums con 69%, seguido por métodos creados internamente (25%).

Finalmente, la herramienta más utilizada para gestionar proyectos ágiles ha sido Excel.

¿En que crees que puede cambiar la forma en la que tu trabajas hoy en día éste informe?

pdf

 

Gracias por escucharme,
Erich.