Lo que pasa en realidad con Agile

¿Cómo mantenemos a los desarrolladores ocupados? “You are doing it wrong”…

Quiero que me evalúen bien… quiero que me evalúen bien… quiero que me evalúen bien… ¿ese es tu mantra? … Si fueras un perro o algún otro tipo de mascota, entonces estaría bien, pero no eres una mascota, ¿porqué alguien debería evaluarte?

Una empresa es sólo un grupo de personas, nadie tiene derecho a evaluarte… a menos que ellos pudieran hacerlo mejor que tú… lo que raramente ocurre en las empresas…

“Scrum is batch optimization”… Es como obvio.

+----------------------------------------------------------+
|                           Lean                          |
+----------------------------------------------------------+
            /                                       \
           /                                          \
+------------------+                         +------------------+
|      Agile      |                           |    Kanban    |
+------------------+                         +------------------+

De manera que Kanban no es agile. Agile y Kanban son Lean, o mejor dicho pertenecen a Lean.

Lean no es ni agile ni kanban, pero los incluye.

1 me gusta

Buena charla. No se trata de ir a la caza de story points, sino que de entregar valor.

Aplicar Kanban, Scrum o XP para equipos u organizaciones dependerá de su contexto.

Aquí la URL del libro gratuito que escribió el charlista Jesper Boeg: Priming Kanban

https://www.infoq.com/minibooks/priming-kanban-jesper-boeg

En la lista de correo, hace varios años, tuvimos una discusión super profunda sobre qué es Agile para nosotros. La respuesta no es novedosa, pero se ha quedado conmigo desde ese momento en adelante: Agile es una cultura profesional enfocada en la respuesta al cambio y comprometida con una mejora continua, es decir, una cultura profesional cuyos principios se basan en el manifiesto ágil.

Todo lo demás son procesos y herramientas. Scrum, Lean, Kanban, TDD, Deploy continuo, Microservicios, etc. Todo eso puede ser usado en un contexto Agile o no Agile, son solo herramientas y procesos.

Eso del valor para el cliente dio en el clavo, hacemos cosas realmente para el cliente y el cliente por definición es quien usa el servicio, es decir quien lo usa Y PAGA por el.

El resto, por ejemplo los jefes, son sólo intermediarios, gente que corta su tajada y en ese sentido ojalá agreguen valor.

Eso del respeto a las personas es como obvio. No necesitas estar en un entorno ágil para respetar a las personas, supongo, en cualquier trabajo se debe tratar con respeto, o por lo menos eso es lobque se esperaría.

Obviamente hay gente que prefiere tratarse mal, de modo que tsnto lean como agile tiene como principio tratsrse con respeto. Es raro que alguien tenga que ser explícito con algo tan básico, es como decirte que el baño tienes que usar papel confort.

Bueno Frederick taylor, quien inventó la ingeniería industrial, decía que si a los trabajadores los tratabas bien, ellos te trataban mal, porque te veían como que eras debil., de modo que desde su punto de vista, si el tipo te trataba como roto, había que tratarlo de la misma manera de vuelta.

En chile hay un dicho muy antiguo que reza “a los gente hay que tratarlos como gente y a los rotos como rotos”. Los tipos de XP en cambio dicen que si ves 2 personas discutiendo, una es tarada y la otra inteligente, no vale la pena la discusión, porque desde fuera, los 2 parecen unos tarados.

Llevando esto al mundo de los rotos, habría que decir que no vale la pena tratar a los rotos como rotos, porque o si no el mundo entero será una rotería.

Aunque en chile es súper raro encontrar gente con buenas actitudes, incluso frente a gente que piensa diferente, por lo menos yo he visto que en los grupos de agilistas esta costumbre de tratar mal a la gente no se da. Puede que digas algo que a alguien no le gusta, pero de todas maneras la gente conversa y no es necesario siempre llegar a un acuerdo, basta con intercambiar opiniones.

Y esa actitud nunca la había visto, en todas partes la gente trata de llegar a consenso aunque sea a la fuerza. Si lo piensas un poco, eso es absurdo. No necesitas estar de acuerdo en todo.

Ahora bien, me ha tocado trabajar en ambientes donde la gente miente. Y miente de manera descarada, dice una cosa en una reunión, y 5 minutos después se desdice… En la misma reunión, con la misma gente, y ni se arruga cuando le señalas que esta contradiciéndose.

?que respeto puede tener una persona que miente tan descaradamente?

No es por nada, pero que lata trabajar con gente así. Y el problema no es sólo que una persona mienta, sino que todo el resto actúa como que es normal ese comportamiento.

Cuando eso pasa, todos son mentirosos descarados.

Respecto al respeto a las personas. A veces lo que parece obvio para unos puede no serlo para otros. De ahí la necesidad de hacerlo explícito.

En la Bio de Jesper Boeg, dentro de la página de descarga del libro gratuito Priming Kanban, aparece esto:
“Jesper believes that trust is best established through an unrelenting focus on transparency in the entire organization.”

Transparencia es un atributo que debería respetarse a toda costa.

Bueno, no tengo problemas con el respeto a las perdonas, o con que se haga explícito, sólo me parece raro que se necesite, pero a decir verdad, si es necesario, porque hay gente que aparenta respeto, pero no lo tiene en realidad.

Si alguien no sabe, aprende, y se acabó el problema.

Ahora bien lo que dices de ser transparente y transparentar todo,de no tener documentos secretos, es fundamental. Tan fundamental, que hace la diferencia entre organizaciones exitosas y organizaciones que están condenadas a fracasar.

Por ejemplo en Microsoft cuabdo te contratan te muestran los resultados contables. Todos los documentos y todas las tareas del proyecto son de demonio público. Cuando una tarea llega a ti, puedes mirar hacia atrás como se llegó a eso.

La ventaja de ver claramente si lo que esta hecho esta bien hecho, o no, puedes ver si las cosas van bien o no. Porque típicamente las cosas están organizadas de manera que tienes una responsabilidad, por ejemplo la persistencia del sistema, de manera que se logra consistencia en el sistema.

Entonces se puede ver toda la lógica, desde el problema a resolver desde el cliente, todo el proceso de definicion del problema y de la solución.

Tanto Scrum como kanban promocionan que todo sea abierto, visual y claro. Eso hace la gran diferencia.

2 Me gusta

Cuando conversamos con @martin.salias después del meetup “Disfrutando los peores proyectos”, nos contó un poco sobre la transparencia de Kleer hacia sus “empleados” y comentamos también sobre 10Pines, que tienen un espíritu similar de full transparencia. Son sin duda ejemplos a seguir de empresas transparentes en latinoamérica.

Ok, estoy de acuerdo.

Pero la pregunta es ¿porqué la transparencia es importante?

Y acá me gustaría detenerme un par de segundos.

Una cosa es que declaremos que nos gusta la transparencia porque así somos todos felices y nos gusta nuestro trabajo. Ese es un objetivo que se ve repetidamente en el mundo lean y agile por extensión.

Pero la pregunta va más allá, ¿qué beneficio obtiene una empresa al ser transparente… aparte de tener a los empleados con una sonrisa (lo que no es menor)?

La respuesta, aunque parezca increíble, la obtuve de Bill Gates. El tipo indica lo siguiente: Si el gerente general tiene una estrategia para la empresa y no la comunica a los empleados, nadie va a saber que la estrategia existe. Los empleados van a hacer su trabajo normalmente y no van a dirigir sus esfuerzos a lograr los objetivos de la estrategia. Ellos van a hacer su trabajo independientemente de lo que diga la estrategia porque no la conocen. Ellos son quienes realmente toman las decisiones de la empresa cuando están interactuando con los clientes y entre ellos, y como no la conocen, no la pueden seguir.

Es muy usual que una estrategia del gerente general llegue sólo hasta los gerentes de segunda línea, y ahí se detiene, no se convierte en nada porque el resto de los empleados no se entera, el gerente de segunda línea no es capaz de convertir esa estrategia en acciones dentro de su gerencia y todo queda en nada.

Y he visto presentaciones así: vamos a conquistar Latinoamerica. ¿Qué implicancias tiene eso para tu gerencia de informática? Ninguna, porque no se le ocurre. Y si se le ocurre, no las comunica. Resultado: Cero.

Los empleados deben sentirse como que la decisión es suya. bueno eso está ampliamente documentado, lo que pasa es que lean y agile por extensión, toman esta idea y la llevan al extremo. Eso hace una gran diferencia.

Si, es empoderamiento, no del tipo manipulativo, sino del de a deveritas.

Al final, como dices, si estableces una estrategia y una dirección, es de todo tu interés también entregar todas las herramientas que puedas para que “el barco” se dirija en esa dirección. Si compartimentalizas la información, estás perdiendo muchas oportunidades de que la gente encuentre formas novedosas de llegar a destino que tu jamás te podrías haber imaginado.

Si, exacto, diste en el clavo.

Mucho meror explicado de lo que dije yo.

Cambiar la estrategia de la empresa, es muy difícil, por no decir imposible. Sólo cuando a la empresa le esta yendo muy mal se puede hacer eso, primero porque si la empresa no cambia rumbo se muere, y segundo porque el gerente general sabe que tiene cortar gente, si alguien se opone al cambio, se corta, de manera casi automática, se podría decir que el tipo se esta auto despidiendo.

Eso obviamente convence a los últimos indecisos de que la empresa debe cambiar rumbo.

Pero hay gerentes tímidos y empresas profiadas. No declaran el cambio de estrategia, mantienen silos o feudos que son administrados de manera secreta, y te das cuenta de esas empresas porque hay reglas secretas que debes seguir. En el fondo nadie puede actuar como realmente es y son todos esquizofrénicos.

Cuando esas empresas venden software te encuentras con que no han logrado tener un sólo build en 3 años. Si eso no te dice algo… Si yo fuera el dueño vendo todo y dejó de perder dinero.

No pueden sacar un build? En serio? Que hacen estos ingenieros todo el día???

Y tu les dices ok yo te ayudó, pongamos tr también tests unitarios para que podamos refactorzar…

No, los test unitarios son palabras mayores, partamos por el build…

O sea declarando la derrota desde el día cero.

Ok, te arreglo el build, tienes que pasarme a tu gente para que yo los dirija…

No, eso si que no, tu sólo reportas…

Ok, mejor te instaló jenkins y te cobro por hora de funcionamiento…

Cuando tu dices que las herramientas son sólo herramientas… Es como que me digas que nos vamos a isla de pascua, yor voy en avión y tu te vas a ir nadando… Por muy ágil que seas, sin las herramientas adecuadas, incluso una empresa no ágil pasa por arriba tuyo y llega en horas donde a ti no te van a ver nunca… Bastante literal la comparación.