sábado, 27 de agosto de 2016

SCRUM: PO y Valor, nivel 2

¿Cómo medimos el valor trabajando bajo un marco ágil como scrum? y ¿cuán precisos somos midiendo valor? 

En la práctica estas preguntas se resuelven dependiendo del grado de madurez del equipo Scrum y de su PO. Tal vez, el primer nivel considera medir en forma relativa, subjetivo a la perspectiva del PO, sin una transparencia precisa (no se dan argumentos basados en datos ni se conoce el valor que aportan los entregables), priorizando sin técnicas precisas, etc.; y un segundo nivel puede ser como el que paso a contar seguidamente. 

Scrum y el valor

Primero que nada recordemos que, Scrum es una herramienta que puede ayudar a enfocarse a la entrega temprana de valor [1], a re-enfocarse en la rentabilidad de la inversión relacionada al desarrollo de features orientadas al valor aportado [4] y a disminuir el riesgo financiero asociado al valor de pérdida por un mal producto que tarda en salir al mercado y falla [7]. Aunque no es una herramienta que brinde el cómo hacer esto ni cuán precisa debe ser la medida de valor que se tenga en cuenta. Respecto a lo primero, scrum da un “qué” relacionado al valor, el objetivo de scrum es conseguir un MVP en manos de los futuros clientes o usuarios cuán rápido sea posible y obtener sus comentarios [2] o  feedback. Esto se hace para descubrir lo valioso para el cliente o usuario, validar el producto y encaminar el desarrollo en esa dirección, de ser factible el producto. Para ello se propone enfocarse en las features de valor. Ahora, el cómo se valoran las features o cómo se hace el trabajo de priorización de features de valor no es solución brindada por Scrum ni por el Manifiesto Ágil [3] -pues scrum solo da el contexto como marco de trabajo-.

ROI y técnicas de priorización de valor

Para priorizar trabajo por valor se usan técnicas, recomendaciones y prácticas complementarias cuya selección será subjetiva al equipo, organización que las implemente o seniority y skill del PO. Por ejemplo se pueden  recomendar, para buscar el MVP y focalizarse en el valor, algunas técnicas como: ley de Pareto 20/80 para priorizar [7],  priorización por KPI, estimación relativa de valor, técnicas de "cost of delay", priorización urgencia e importancia, medición técnica de satisfacción del usuario, ROI [5] y ROI Scorecard, NPV [5], IRR [5], EVM [8], etc.; y de estas, la más renombrada es el ROI, ya que el PO debe buscar lograr y maximizar un retorno de la inversión. La fórmula de ROI genérica es la siguiente:

Tipos de valor 

En cuanto a cuán precisa debe ser la medida de valor que se tenga en cuenta, también es ajeno al marco Scrum y al Manifiesto. Por un lado, hay que tener en cuenta (a) ¿el valor para quién? ¿para el usuario final o para el cliente negocio?... y por otro lado (b) ¿qué es específicamente el valor? (valor hipotético vs valor real)

¿El valor para quién?

En relación a los primero (a), en Scrum se recomienda definir esto al comienzo y luego nos enfocamos según los objetivos planteados que involucran al beneficiario del valor. Aquí puede ser el usuario final (“valor percibido por el usuario”) o la compañía cliente (“valor del negocio” [1]). Relacionado a esto último es que con scrum nos proponemos responder rápidamente la pregunta: ¿Ganaremos dinero con esto? [7] Aunque siempre se termina validando contra el usuario final en cuanto a “software funcionando”[3] (o producto funcionando) como valioso para el usuario.  Otra pregunta que el PO debe tener siempre en su mente es: "¿Qué es lo más valioso que podemos entregar bajo un costo y tiempo fijo?" (aquí el el costo y tiempo fijo es el equipo y el sprint)

¿Qué es específicamente el valor?

Con respecto a lo segundo (b), hay que partir de que el valor mismo siempre es subjetivo y no existe realmente un valor real concreto y empírico, aunque mientras más nos acerquemos a la realidad del mercado económico, será mejor. Siempre en un justo balance, ya que lo que sí recomienda el Manifiesto es “la adaptación” en vez de seguir un plan minucioso, o sea a no tener toda la información precisa y detallada -la económica por ejemplo- de antemano, desde el comienzo, sino más bien tolerar ciertos grados de incertidumbre -valores hipotético o cercanos al real- en pos de entregar software funcionando que el usuario percibe como valioso. O sea, pretender saber qué valor real en dólares tiene asociado cada entregable es poco válido dentro del agilismo y de scrum; y hasta cierto, punto es utópico. Como versa la frase: "No hay tal cosa como valor absoluto en este mundo. Sólo se puede estimar qué cosa es valiosa para ti" [4] (Charles Dudley Warner, 1829-1900). 

Tips para POs

Particularmente recomiendo, a equipos maduros y principalmente a POs más que juniors, las siguientes prácticas: 
  1. El establecimiento de objetivos comunes entre todos los stakeholders (internas y externas) alineados al negocio [4] (Alineamiento con metas y KPI definidos). 
  2. ROI mediante desarrollo de las features más importantes [4], según MVP y KPI definidos. 
  3. La identificación de las features innecesarias o de bajo perfil para remoción del backlog durante la “priorización continua” [4], usando ley de Pareto 20/80 [7] u otra técnica de priorización. 
  4. Motivar al equipo haciéndoles saber cuánto valor relativo de negocio están entregando por features o historia de usuario [4], se puede usar el Value Point como medida; o midiendo el impacto mediante el KPI propuesto. 
  5. La reducción del riesgo mediante uso de MVP, MMP y release plan [6][7]. 
  6. Medir la satisfacción del cliente para buscar su incremento [4] (NPS, CSAT, etc.). 
  7. Respaldar con datos al “Business Case” u "Opportunity Assessment" y al release plan o Roadmap. 
  8. Medición o estimaciones de KPI principales, como revenue, save cost y penetration. De lo cual se desprende el análisis de qué features aportan a la reducción de los costes, aumento de revenue y/o penetración en mercado. Justificar el “Business Case” u "Opportunity Assessment" y el valor aportado en las reviews. 

Hay que recordar que lo relacionado a valor es responsabilidad del PO y la calidad relacionada al mismo dependerá, en gran medida, de su seniority como PO. La excelencia es un principio en la agilidad, por lo que un buen PO debe procurar excelencia como analista del negocio y del valor del producto/servicio que el equipo entrega o brinda. Un trabajo de precisión ágil y excelencia requieren un PO de seniority alto que busca la excelencia. 

Referencias: 

[1] Scrum Alliance: Scrum Values. URL: https://www.scrumalliance.org/why-scrum/core-scrum-values-roles

[2] Book: Summary: Scrum - Jeff Sutherland: The Art of Doing Twice the Work in Half the time, by BusinessNews Publishing.

[3] Manifiesto por el Desarrollo Ágil de Software. URL: http://www.agilemanifesto.org/iso/es/

[4] Scrum Alliance: What Is Required for Business Value? Sumanth Reddy Bathula. URL: https://www.scrumalliance.org/community/articles/2016/april/what-is-required-for-business-value-(1)

[5] Scrum Alliance: Business Value Metrics. URL: https://www.scrumalliance.org/community/articles/2016/april/business-value-metrics

[6] Artículo: Desarrollo Ágil - Desarrollo mediante MVP. URL: http://programminglabpoint.blogspot.cl/2016/05/desarrollo-agil-mvp.html

[7] Book: Scrum The Art of Doing Twice The Work In Half the Time by Jeff Sutherland, 2014.

[8] Agile estimating and planning. Mike Cohn.

[9] Characteristic of a good product owner, Toqir Khalid, 2016. URL: https://blog.red-badger.com/blog/2016/04/20/characteristic-of-a-good-product-owner


Agilismo: Presentaciones ágiles


¿Cómo dictar una presentación ágil?



Podemos hacer que nuestras presentaciones orales, demostraciones de productos o resultados, sprint review, show cases, exposiciones educativas, informes de noticias, capacitaciones, etc., sean ágiles. Para lograrlo tenemos que tener en cuenta los valores ágiles en su desarrollo.

Pueden haber muchas maneras de hacer una presentación en el marco de la agilidad. Aquí se muestra una forma basada principalmente en tres valores ágiles y un principio.
A continuación ofrezco 6 aspectos a tener en cuenta dentro de este marco de agilidad:
  1. Tiempo: la atención ronda entre 5 y 18 minutos. Es recomendable no superar los 20 minutos de una presentación (principalmente si las personas están de pié) y en actividades largas fraccionar en tramos de 20 min. [1] [2]. No superar los siete segundos de silencio [6]. Y por último, respetar un time-box.
  2. Útil: Dar valor al público espectador con lo que se presenta [2] [7]. Debes poder presentar tu premisa en una o dos oraciones y hacerla interesante [2].
  3. Emoción:  Motivar con emociones, sensaciones o dinámica ágil por medio del lenguaje textual y corporal [6] [7]. Conoce a las personas a las que les hablarás [2] [3]. El ponente también puede ponerse en un rol de amigo o de igual [6].
  4. Interacción: Hacer preguntas y hacer pensar interactuando con los demás. Romper la barrera con el público y capturarlo [2] [6]. Puedes solicitar feedback para poder mejorar.
  5. Simple: Buscar ser claro, conciso y concreto presentando poca información y siendo visual y minimalista, “Keep it simple” [2] [4].
  6. Cambio: Orientarse a inspirar y/o generar un cambio en el oyente. Para ello ser desafiante, innovador, buscar impactar o generar nuevas ideas o reflexiones. Tu conclusión debe ser algo que deje a tu público con una sensación positiva sobre tu idea y cómo les afectará si la deciden implementar, que los motive al cambio [2] [3]. El ponente también debe estar abierto al cambio y a salir de su zona de confort [6].


Referencias:


[1] ¿Cuánto debe durar una presentación? por Roger Prat, febrero 25, 2013


[2] TED Speaker Guide by TED.com.
[3] Manifesto for Agile Software Development by Agilemanifesto.org
[4] Principles behind the Agile Manifesto by Agilemanifesto.org
[5] Cómo dictar una charla TED
[6] Presentaciones efectivas: Técnicas para la exposición oral de trabajos y proyectos académicos. Por Iñaki Bustínduy. Editorial UOC, 11-03-2014.
[7] Neuro Presentaciones efectivas, Miguel Figueroa, Youtube, Published on Dec 3, 2015
URL: https://www.youtube.com/watch?v=GD1QosoeRtY

Scrum: Scrum es ágil


¿Por qué Scrum es ágil?


Ser ágil es, en un sentido, ser ágiles tomando decisiones mientras nos adaptamos constantemente en la acción sin paralizarnos en la duda, pues:
"Dudar es mortal. Observa, oriéntate, decide y actúa. Determina donde estás, evalúa tus opciones, toma una decisión ¡y actúa!" Jeff Sutherland [1].
Para ello Jeff Sutherland creó un sistema como marco de trabajo que llamó Scrum.

Desde esta perspectiva, Scrum es un marco ágil porque fue creado para practicar los valores ágiles.

"Personas antes que procesos, productos que funcionen antes que documentar lo que se supone que debe hacer, colaborar con los clientes antes que negociar con ellos y responder al cambio antes que seguir un plan. Scrum es el marco que yo creé para poner en práctica esos valores." Jeff Sutherland [1].


Referencias:
[1] Scrum: The Art of Doing Twice the Work in Half the Time. Jeff Sutherland.

Scrum, Desarrollo Agil: Desarrollo mediante MVP


Bajo un marco de trabajo ágil, como SCRUM, el desarrollo de software se hará de forma evolutiva con entregas frecuentes de valor para el usuario. Una técnica complementaria es el uso de MVP para entregar valor que sirva de hipótesis de prueba de nuestro producto.

¿Qué es un MVP? 


El MVP (Minimum Viable Product) es la "Versión Mínima de un Producto"[1], características mínimas y necesarias para hacer foco y que el producto salga al mercado, de tal manera que nos permite obtener feedback rápido del comportamiento con el mercado y clientes [1]. El MVP tiene solamente las funcionalidades que permiten que el producto sea lanzado sólo a un segmento de clientes, tales como a los "early adopters" [1] o es un release dirigido a entusiastas "early adopters" [5]. Con el MVP lo que buscamos es testear nuestras hipótesis sobre nuestra visión del producto, es decir, tratamos de comprobar que hemos encontrado un problema que los early adopters están dispuestos a probar para determinar que nuestro producto es una solución adecuada [3].


MVP es una estrategia para el aprendizaje de forma iterativa sobre sus clientes para poner a prueba las hipótesis fundamentales del negocio. [11][4]

El o los MVPs son resultados del desarrollo iterativo en ciclos cortos con entrega o release de funcionalidad mínima, usable por el cliente. Un release o entregable no necesariamente es un MVP, sin embargo, un MVP es un entregable del producto mínimo tan pequeño como lo mínimo para probar la viabilidad de nuestro producto final [3], commodity o "end game". 

Como muestra la figura, cualquier entregable no es un MVP. Por ejemplo, un paso 1 de una aplicación dividida en pasos no es un MVP de un desarrollo evolutivo. Sí lo es un entregable que representa conceptualmente al producto completo (todos los pasos), aunque no lo sea. En el dibujo, la rueda es un entregable de valor, pero no es un MVP.


En concepto proviene de "Lean Startup" y en esta metodología el conocimiento se obtene de forma empírica a través del lanzamiento de diversas iteraciones del MVP [3].


Un MVP incluye entregables de valor y puede incluir al o los MMF (Minimum Marketable Features)[10] (este concepto se originó en Kanban y Lean). El MMF es un entregable con "el conjunto más pequeño posible de funcionalidades o features que, por sí mismas, tienen valor en el mercado"[1] [9]. Esta es una característica mínima, ya que cualquiera más pequeña no sería comercializable [10].


¿Cuántos MVPs?


Aquí surge una pregunta… ¿Hay solo un MVP o varios? La respuesta depende del autor y del criterio del equipo que decida conceptualizar sus entregables. Algunos prefieren tener muchos entregables de valor que prueban hipótesis hasta alcanzar un MVP que prueba las hipótesis principales de producto en forma iterativa. En Scrum parece que se maneja más esta idea: 


El verdadero objetivo de scrum es conseguir un MVP en manos de los futuros clientes cuan rápido sea posible y obtener sus comentarios. [12]



Aunque es común referirse a que pueden haber varios MVPs [8], en forma evolutiva, hasta alcanzar un mínimo producto que se lanza al mercado como tal. A este producto se lo puede identificar de otra manera, como MMP [6].


¿Qué es un MMP?


El MMP (Minimal Marketable Product) es el producto con el más pequeño posible conjunto de features y que crea la experiencia del usuario deseada, y por lo tanto puede ser comercializado y vendido, tempranamente, con éxito [6][11][13]. La clave para crear una exitoso MMP es desarrollar el producto para unos pocos usuarios [6].


Evolución iterativa e incremental de un producto


Resumidamente, un producto puede evolucionar mediante una secuencia de releases, de los cuales algunos pueden ser MMFs sin alcanzar a ser MVPs. Después de una etapa de creatividad y prototipado (si e producto es nuevo y/o novedoso), tendremos uno o una secuencia de MVPs hasta llegar a un MMP, que será el mínimo producto que se lanza al mercado como tal. De allí en adelante comienza el crecimiento en escalamiento (Growth) e incremento de funcionalidad hasta alcanzar una madurez (maturity), para finalmente constituir un producto final estable o commodity (ver siguiente figura [5]).

Finalmente, hay que tener en cuenta que sobre esto no hay nada tallado en piedra. La demarcación de estos conceptos dependen de cada autor y de la interpretación que haga quien los use. No hay ningún diccionario único y referencia única. Por lo tanto, cómo se los use será subjetivo al equipo y contexto particular. Lo importante es que el equipo se ponga de acuerdo en una manera y todos estén en la misma página.


Referencias:


[1] Book: Proyectos Ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos complejos, Martín Alaimo, 2014.

[2] Wikipedia 2016https://es.wikipedia.org/wiki/Producto_viable_m%C3%ADnimo

[3] Artículo: ¿QUÉ ES EL PRODUCTO MÍNIMO VIABLE? Por Xavi Sanchez sobre Creación de empresas, Metodologías Lean  http://www.emprenderalia.com/que-es-el-mvp-producto-viable-minimo/

[4] Book: The Lean Startup by Eric Ries.

[5] Book: Build It Like A Startup: Lean Product Innovation By Greg Gehrich.

[6] Article: The Minimal Marketable Product by Written by Roman Pichler on Wednesday 31st August 2011.

[7] Book: “El Equilibrio Dinámico entre Costo, Cronograma, Características y Calidad en el desarrollo de Software” Willian Junk, 2000 (Willian, S. Junk. (2000) The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects, Computer Science Dept., University of Idaho, SEPM-001).

[8] Book: Directo al Punto, Una guía para la creación de productos Lean. Paulo Caroli, María Fernanda Escudero and Freddy Coronel, 2016.

[9] Article: The Agile Alphabet, Scrum Alliance, Koti Reddy Bhavanam, 31 August 2012. URL: https://www.scrumalliance.org/community/articles/2012/august/the-agile-alphabet#sthash.WtiurBp3.dpuf

[10] Article: Agile Methods The various implementations of Agile, Scrum Alliance, Shri Naveen Kumar, 2 March 2015. URL: https://www.scrumalliance.org/community/articles/2015/march/agile-methodologies#sthash.uawtNykK.dpuf

[11] Article: What is an MVP? By David Lowe | April 15, 2014 URL: http://scrumandkanban.co.uk/what-is-an-mvp

[12] Book: Summary: Scrum - Jeff Sutherland: The Art of Doing Twice the Work in Half the time, by BusinessNews Publishing.

[13] Book: The art of agile development by James Shore. (Tools and techniques - value based priorization.)



Agilismo: Cómo ser ágiles


¿Cómo ser ágiles?


Este artículo es un documento donde se analiza cómo se puede fomentar la agilidad (en el contexto de marcos de trabajo ágil y/o desarrollo de software) y cómo se puede ser ágil en forma consciente en una organización, las acciones necesarias para poder lograrlo y una vía simple de contagiar la agilidad.


Introducción



Trabajando en una organización, en la cual los integrantes dicen ser ágiles e implementar algún marco de trabajo como Scrum, cabe preguntarse a modo de reflexión lo siguiente: ¿Nuestra organización es realmente ágil? ¿Somos realmente ágiles?
Para ello podemos preguntar, en cualquier momento y a personas tomadas al azar, si saben cuáles son los valores ágiles. Pues si no tienen la más remota idea o no los recuerdan, podemos comenzar a pensar que algo puede andar mal, en principio darle camino a la duda.


Si sospechamos, de algún modo, que no somo ágiles, también podemos preguntarnos por qué no… ¿Cómo ser ágiles? ¿Cómo contagiar la agilidad al resto de la organización?

Hay muchas maneras de llegar a ser ágiles, aunque hay una relevante que es la que se expone aquí: partir de nuestra forma de pensar.
 
Valores

La agilidad se construye en base a sus valores cimientos y estos son cualidades que consideramos valiosas o deseables tener en cuenta.


"To be agile, you need to adhere to the Agile Manifesto…
As long as you're sticking to the Agile Manifesto's values and principles and delivering high-value software regularly to your customers, you should be considered Agile." [Stephen Haunts 2015]


Un valor es lo que tu pones delante de otra cosa cuando decides algo [Sergio Fernandez 2014]. No es difícil tomar decisiones cuando sabemos cuales son nuestros valores (Roy Disney). Por tal motivo, si somos conscientes de nuestros valores ágiles tomaremos decisiones alineadas a ellos. Nuestros valores tienen una gran determinación sobre nuestros resultados. En consecuencia, nuestra praxis ágil dependerá de nuestra mentalidad, de nuestro


Desde esta perspectiva, para buscar ser ágiles debemos buscar ser conscientes de sus valores y tenerlos en presente en el día a día. Debemos reflexionar si en el trabajo diario actuamos acorde a ellos, si estamos convencidos de sus fundamentos, si comprendemos su alcance y cómo los aplicamos cuando resolvemos problemas o hacemos nuestra labor diaria.


Valores Ágiles

Los valores ágiles expresados en el manifiesto ágil reordenados son los siguientes:

    Individuos e interacciones, sobre procesos y herramientas.
    Colaboración con el cliente, sobre negociación contractual.
    Respuesta ante el cambio, sobre seguir un plan.
    Software funcionando sobre, documentación extensiva.


Suele resultar dificil memorizar la lista de valores. Para lograrlo, se puede recurrir a un mantra simple y/o nemotécnico.
 
Mantra

En vez de recordar cuatro oraciones se nos puede hacer más fácil recordar solo una, un mantra. En un artículo de una revista conocida, decía una frase: «La belleza de un mantra es que todos esperan que sea breve y dulce» (Guy Kawasaki). Aunque, más que breve y dulce, un mantra es una especie de faro para guiarnos. Es un lema de alto nivel que representa un ideal como objetivo guía y motivación. Y la agilidad no es otra cosa que un ideal a seguir.

El que se puede elegir como opción para guiarnos en el camino de la agilidad es el siguiente:


"Me relaciono, colaborando, como agente de cambio, para que las cosas funcionen mejor"
Aquí las palabras claves son: relaciono, colaborando, cambio y funcionen. Cada palabra se corresponde con un valor ágil en forma re-ordenada. A continuación podemos explicar el mantra.

 

Me relaciono



Relacionarse simboliza priorizar a individuos e interacciones. Si se aspira a una organización democrática en el que prevalecen las relaciones humanas en vez de los procesos y herramientas, las personas son absolutamente centrales y completamente imprescindibles; donde la impronta de cada individuo deja su aporte al sistema organizacional y no se subordina totalmente a los procesos del sistema. Esto favorece a lograr una organización orgánica y adaptable, y no a una mecánica y rígida.

Las empresas están formadas por humanos. Como dice Maturana, hay que reconocer que lo humano no se constituye exclusivamente desde lo racional. Es cierto que lo racional es importante en el tipo de vida que vivimos, pero el primer paso para revalorar la emoción sería aceptar que entrelazado a un razonar está siempre presente un emocionar. En el momento en que uno acepta la presencia de la emoción y amplía su mirada reflexiva se da cuenta de que la emoción es el fundamento de todo quehacer, el que lleva a la realización de la convivencia, a la realización del vivir con otro; esto solamente se puede dar en la medida en que la convivencia se hace en la aceptación del otro como un legítimo otro [Maturana 2004]. Esto fomenta lograr una organización creativa y colaborativa.
Maturana dice que el 99% de las enfermedades son consecuencia de la negación del amor (Maturana 2004). Con riesgo de sonar cursi, se puede decir que algo semejante sucede en las organizaciones empresariales. Pues, no somos máquinas, somos humanos, que trabajamos mejor si nos relacionamos humanamente con relaciones cordiales de confianza y de estas relaciones surge la libertad para cambiar a los procesos, para mejorarlos y trabajar mejor. Las personas deben estar a gusto para poder ser creativas, para hacer aportes productivos a los proyectos y a la organización. Esto ayuda a que las personas estén voluntariamente y fuertemente comprometidas con el éxito del producto, del proyecto y de la organización. Además, las personas felices trabajan mejor.

¿Cómo hacerlo?



  • Proporcionar oportunidades para que las personas funcionen como seres humanos, en vez de que sean considerados recursos de un sistema.
  • Motivar a las personas, darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. [Agilemanifesto 2001] Confiar en los miembros del equipo respecto a su forma de trabajo, por sobre juzgarlos y "medirlos" para control.
  • Brindar ambientes que posibiliten la auto-organización de las personas y la asociación voluntaria en vez de aquellos que fomentan la jerarquía y la obediencia (Google recomienda eliminar símbolos de
  • [Laszlo Bock 2015]). Conceda a las personas algo más de confianza, libertad y autoridad de la que a usted le resulta tranquilizador [Laszlo Bock 2015].
  • Proporcionar oportunidades a cada miembro de la organización para que puedan desarrollar su potencial acordes a su individualidad y tengan un crecimiento profesional a la par de su persona (desarrollo integral).
  • Formar ambientes donde las personas puedan reunirse en grupo para conversar y compartir.
  • Facilitar sistemas participativos para que las personas se sientan tenidas en cuenta y de que sus decisiones sopesan.  Solicitar se respete las decisiones del equipo por sobre los procesos "pre-establecidos" cuando es necesario y justificado (Cambio en los integrantes del equipo, participación en las entrevistas, definición de "RoadMap", DoD, etc.).
  • Desarrollar el liderazgo integrador donde la “la gente es lo primero”.
  • Fomentar el cara a cara. Priorizar las conversaciones cara a cara en vez de las hechas por mail, chat o herramientas remotas. [Steve Jobs 2015][Agilemanifesto 2001]
  • Priorizar las presentaciones sin dispositivas o con diapositivas minimalistas por sobre largas presentaciones formales y hacer los diálogos emocionales e integradores, que llegue a las personas. [Steve Jobs 2015]
  • Preferir levantarse, buscar y preguntar sobre soluciones hechas por otros a reinventar la rueda en forma aislada.
  • Facilitar herramientas que simplifiquen las conversaciones y aumenten la cohesión social.
  • Considerar que los estándares y procesos no están escritos en piedra y brindar la posibilidad de que las personas aporten a su mejora.
  • Permitir libertad razonable de horarios en vez de perseguir respetar jornadas estrictas de trabajo. La libertad razonable de horarios debe ser acordada en “bandas horarias”  [UNTREF, 2014] funcionales al equipo y a la organización.
  • Hay que respetar el trabajo "
  • ", haciendo el desarrollo en las jornadas que corresponden, condiciones que corresponden y la paz necesaria, pues el trabajo extra desgasta a las personas y perjudica su vida extralaboral.
  • No usar “argumentum ad hominem” o “falacia de ataque a las persona” en las discusiones. No buscar convencer o desacreditar las opiniones de las personas por su condición jerárquica, su rol, su aptitud o su actitud personal. Buscar discutir ideas.
  • No comunicar decisiones que repercuten en la vida de las personas sin la previsión necesaria. En este sentido hay que brindar transparencia para generar confianza.
  • Motorización de la "felicidad" de los miembros del equipo o de la organización.



 
Colaborando

Se busca la colaboración con el cliente sobre negociación contractual. Siendo extensible al resto de la organización y suponiendo que en cualquier relación de trabajo existe un cliente y un proveedor, buscamos que exista colaboración entre los mismos. Antes de priorizar un contrato o lo previamente establecido como lo que cada parte debe cumplir, se debe buscar colaborar. Nuestros clientes deberían ser nuestro punto de contacto principal, nuestro compañero de trabajo con el que nuestro accionar conjunto fluye en vez de ser frenado por fricciones burocráticas o contractuales.
 
¿Cómo hacerlo?

  • Compartir información y experiencias, y brindar los medios para que todos lo puedan hacer.
  • Plantear negociaciones ganar-ganar. Pues llevar a cabo una estrategia basada en la cooperación ganar-ganar debería ser mucho más que una actitud ante circunstancias específicas, debería ser una forma de relacionarse colaborando.
  • Hacer frecuentes reuniones técnicas en equipo. Los diseños deben ser emergentes desde la colaboración en equipo y no desde la anarquía grupal o de la mente de un iluminado esperto. También hacer frecuentes reuniones estrategias y tácticas.
  • Fomentar el liderazgo democrático y facilitar sistemas democráticos para la toma de decisiones.
  • Colaborar y coordinar con otros equipos para desarrollar componentes o soluciones transversales, en vez de resolver solo nuestros problemas funcionales a nuestras aplicaciones o a nuestra área en forma aislada. Desde el punto de vista del desarrollo, hay que tomarse un tiempo cada vez que tengamos que implementar algo, tratar dentro de lo posible de mirar hacia el lado, conversar con alguien, ver si lo que estamos haciendo tiene calidad, por ejemplo si puede ser reutilizado, si no deja deuda técnica o simplemente si existe una forma mejor de hacerlo.
  • El cliente debe estar presente colaborativamente en el equipo. En equipos Scrum el PO debe tener dedicación, en lo posible, exclusiva al equipo. Debemos tener presente a nuestros clientes internos y a las personas que les servimos para que realmente les sirvamos.
  • Buscar la ayuda temprana ante problemas. Poseer un sistema de "alarma" interna cuando alguien está bloqueado o entrampado con un tema.


 

Como agentes de cambio

El cambio parece ser la única constante en nuestras vidas y aunque no sea del todo bienvenido debemos estar abiertos a él. Ser agentes de cambio es lograr respuestas ágiles ante el cambio sobre seguir un plan. Con este valor buscamos, en general, priorizar la flexibilidad para la adaptación a cambios en vez de la rigidez de seguir un plan detallado, seguir documentación, o reglas y estructuras rígidas. Debemos buscar que la organización sea orgánica y dinámicamente flexible, adaptándose constantemente y no una automata mecánica que sigue una programación previa detallada. Además, no bastaría con ser aptos al cambio, aceptarlo y ser reactivos, sino que también hay que ser pro-activos. Debemos ser agentes de cambio, ser agentes de nuevas posibilidades, de que las cosas ocurran, facilitadores del proceso de cambio hacia una cultura ágil y de que el nuevo status quo ágil suceda.

¿Cómo hacerlo?


  • Buscar que se cumplan los valores anteriores. Tener la capacidad de relacionarse en forma efectiva con las personas de la organización y los participantes en el proceso de cambio, debe crear un clima de confianza, apertura, respeto y colaboración entre todos los participantes [García López 2010].
  • Buscar cómo se puede lograr el aumento de la eficacia de la organización en toda sus metas [García López 2010]. Proponer ideas, cambios y mejoras a los producto como a los procesos y políticas de la compañía.
  • Escuchar a las personas y comprenderlas aún cuando no esté de acuerdo con ellas para vencer la resistencia al cambio [García López 2010].
  • Diagnosticar situaciones y comportamientos que estén provocando problemas a la organización, o simplemente ver oportunidades de mejorar [García López 2010]. Levantar riesgos a las "noticias" o "decisiones" que se nos imponen y qué cosas obstaculizan la agilidad.
  • Confrontar a personas o grupos, proporcionándoles retroinformación constructiva para que acepten, adopten e impulsen el cambio y no lo obstruyan [García López 2010].
  • Sugerir soluciones y orientar acciones para desarrollar las organizaciones [García López 2010].
  • Reorganizarse como equipo frente a cambios o problemas antes que esperar que nos digan qué y cómo enfrentarlos. Ser proactivo como equipo.
  • Asegurar que las retrospectivas o reflexiones grupales de mejora contínua tengan acciones que se cumplan y no sean solo momentos de terapia o conversaciones de resultados estériles en el futuro.
  • Involucrarse en las prácticas de otros equipos que no aparentan ser ágiles e intentar generar nexos que mejoren la comunicación con ellos en prácticas ágiles; y compartirles experiencias motivadoras.

  • Buscar ser abiertos de mente y ser aptos para la adaptación a otras maneras de pensar o puntos de vista. Para ello no hay que tener miedo al conflicto, hay que lograr una aceptación del "conflicto positivo".

  • Experimentar buscando la mejora por sobre preferir hacer lo que veníamos haciendo.
  • Buscar que la organización sea inteligente, una organización que aprenda. Los mejores deben enseñar al resto [Laszlo Bock 2015].


Para hacer que las cosas funcionen mejor

Hacer que las cosas funcionen deriva de software funcionando sobre documentación extensiva. Este valor indica que hay que estar orientado al producto o focalizarse en él y de este modo requerir un incremento de producto completado y funcionando como resultado final de cada ciclo de trabajo, en vez de tener que cumplir con grandes y engorrosas documentaciones, protocolos y estándares o formalismos burocráticos. El producto concreto y funcionando es lo que permite a la organización guiarse hacia el éxito. Y esto se puede extender a cualquier producto, cualquier objetivo entregable o subsistema dentro de la organización y no solo al software. Lo clave es que lo que importa es que las cosas funcionen, que los procesos funcionen, que el sistema funcione y que nuestros resultados sean funcionales. Además, con que funcionen no es suficiente, deben hacerlo cada vez mejor; como un proceso evolutivo. El mero acto de hacer que las cosas sucedan es lo que crea el cambio y por lo tanto es garantía de éxito como agentes de cambio dentro de una organización.

¿Cómo hacerlo?


  • Buscar entregar valor en forma frecuente a nuestros clientes (o a todas las personas que laboralmente esperan algo de nosotros) y recibir retroalimentación constante de ello. Evaluar constantemente si lo que estamos haciendo o entregando aporta valor, desde la revisión de un estándar hasta la refactorización de código.
  • No trabajar bajo demanda o esperar que los demás nos contacten, que sigan los procesos, lo pactado o los planes; en vez de ello, hay que ir a los demás para asegurarse de que las cosas funcionan. No hay que descansar en nuestra autoridad, en comunicados memos, en documentos o en la definición de procesos; sino que hay que actuar y hacer que las cosas sucedan.
  • Buscar que las cosas fluyan, que los procesos fluyan. Resolver impedimentos y facilitar para que los procesos sean ágiles. Además, hay que hacer la vida fácil a las personas de la organización [Laszlo Bock 2015].
  • Buscar el aumento de la eficacia de la organización en toda sus metas.
  • Probar con usuarios, con el equipo o con el cliente; buscar el “feedback temprano” por sobre la investigación teórica para probar tempranamente el funcionamiento (del software, de diseños, de procesos, etc.).


Conclusión


Se puede concluir que una forma simple de buscar ser ágil es:

  • En primera instancia, tener presente los valores ágiles. Para ello podemos recurrir a recordar un mantra como el que dice:  "Me relaciono, colaborando, como agente de cambio, para que las cosas funcionen mejor".
  • Meditar frecuentemente sobre si nuestras acciones cotidianas están alineadas a ellos o a nuestro mantra ágil.
  • Pensar en cómo podemos hacer para que lo que hacemos diariamente respete algún valor ágil.

Entonces, cuando decimos "soy Ágil", estamos diciendo que aceptamos y nos comprometemos con los valores ágiles (que conocemos), y que estamos avanzando en esa dirección [Walter Bodwell 2009].
Siendo ágil contagiamos la agilidad, además lo hacemos compartiendo nuestro mantra con los demás.


Nota final

Recordar que para ser realmente ágiles también hay que aplicar los doce principios ágiles que se desprenden de los valores ágiles y que están en el manifiesto ágil [Agilemanifesto 2001], aunque estos 12 principios no fueran tratados en este artículo; y aplicar un marco o proceso ágil de trabajo (Scrum, XP, Lean kanban, etc.).


También hay que tener en cuenta que tanto los valores como los principios no son exclusivos de desarrolladores, programadores, Team Members, o; sino que se pueden hacer extensibles a cualquier rol dentro de la organización. Cualquier persona que desarrolla cualquier rol en nuestra compañía puede ser ágil.


Referencia:



[Agilemanifesto 2001] Agilemanifesto.org, 2001.

[UNTREF, 2014] UNTREF (2014). Construcción de software: una mirada ágil. Por Nicolás Paez, Diego Fontdevila, Pablo Suárez, Carlos Fontela, Marcio Degiovannini, Alejandro Molina. Universidad Nacional de Tres de Febrero (UNTREF).
[Stephen Haunts 2015] Agile Software Development Succinctly By Stephen Haunts Foreword by Daniel Jebaraj. 2015 by Syncfusion, Inc. Courtney Wright.

[Maturana 2004] Transformación en la convivencia. Humberto Maturana, 2004.

[Steve Jobs 2015] Lecciones de liderazgo. Walter Isaacson, 2015.

[Sergio Fernandez 2014] El nuevo paradigma laboral. Sergio Fernández, 2014.

[García López 2010] El agente de cambio organizacional: su rol y propósitos, García López, J.M., en Contribuciones a la Economía, abril 2010.

[Walter Bodwell 2009] What Is Agile? by Walter Bodwell, wbodwell on Sun (wbodwell's blog), 09/27/2009.

[Laszlo Bock 2015] La nueva fórmula de trabajo. Revelaciones de Google que cambiarán su forma de vivir y liderar, Por Laszlo Bock, 2015.