La mejor crítica que he leído de la Agilidad

  1. Business-driven engineering.
  2. Terminal juniority
  3. It’s stupidly, dangerously short-term.
  4. It has no regard for career coherency.
  5. Its purpose is to identify low performers, but it has an unacceptably high false positive rate.
  6. The Whisky Goggles Effect.

En el fondo el problema que está planteando es que Scrum y Agile se convierte en Micromanagement. Cuando eso pasa, tu carrera se está yendo al tacho de la basura.

Ya no tomas decisiones, alguien las toma por ti, y ni siquiera puedes estimar las tareas, alguien las está estimando por ti en una reunión en la que te preguntas ¿porqué estamos discutiendo esto?

Luego tienes que reportar día a día lo que hiciste y lo que vas a hacer, como si tuvieras 10 años.

Hay cosas que están muy mal con Scrum y con la agilidad.

1 me gusta

La maldición de toda “marca” que se hace muy famosa es que su significado se diluye a medida que aumentan los que quieren vestirse con ella.

La mejor contramedida está en este post de jeff Patton Agile Development is More Culture Than Process

Saludos!
Agustin

1 me gusta

Echo de menos un poco más de contexto en las críticas que Michael O. Church hace en su post. Ejemplos concretos.

No lo conozco a él, luego de hacer una somera búsqueda web encontré que alguien mencionaba que Michael trabajó en Google.

Parece que él vivió de primera mano ambientes de trabajo tóxicos que estaban aplicando prácticas de SCRUM. No me extraña.

Tiene un cierto tono pesimista el post, y por cierto no ví propuestas concretas de cómo mejorar el ambiente de trabajo y carrera profesional para software developers.

En todo caso, y luego de digerir el post poco a poco, veo que Michael tiene un punto (o varios puntos): El abuso de los trabajadores, el afán de lucro de las empresas por sobre el espíritu de hacer las cosas bien. Todo eso “maquillado” con prácticas de metodologías ágiles. El tono pesimista del artículo me hace “ponerme en contra de Michael” a medida que va quejándose de aspectos de la agilidad, en todo caso trato de rescatar sus reflexiones, ver el mérito de las mismas, y evitar caer en la trampa emocional de rechazarlo “porque su tono me cae mal”. :worried:

Seguramente con una segunda o tercera lectura podré identificar más notoriamente los puntos de Michael.

Gracias @Guillermo_Schwarz por compartir el artículo.

1 me gusta

Lo que dice agustin es verdad. Toda marca eventualmente tiene rechazo por parte de algun segmento del mercado, aunque sea simplemente una buena marca pero el precio no asequible, o al reves, todo el mundo la usa, y yo soy especial.

Sin embargo, en este caso la critica va un poco mas alla, la relaciona con el micromanagement, con el hecho de que debes reportar a diario, que debes explicae lo que hiciste y lo que vas a hacer y con que tropezaste. Eso significa que pierdes todos tus grados de libertad.

Las empresas puede que se salten todo lo que dice scrum, pero el daily scrum no se lo saltan.

La fantasia de un jefe es tenerlo todo controlado y la gente produciendo, pero eso es solo una fantasia, si alguien esta cansado, lo mas probable es que no produzca nada, y que si logra producir algo, eso debe ir directo a la basura, porque lo mas probable es que no pase siquiera un test.

Lo he visto. He visto programadores que se las ingenian para desactivar los tests.

El micromanagement es un problema mucho mas.antiguo que la agilidad, pero en mi opinion la agilidad peca de ser complaciente con el.micromanagement, permite demasiada intrusion, un no te veo trabajando, un no estas produciendo lo mismo que el resto del equipo… puras justificaciones que pueden ser solidas en algunos casos, pero que nos llevan directamente al lado mas malo y mas feo del micromanagement: hazlo como yo te digo.

Eso siempre termina con personas cosificadas, con personas que funcionan como automatas esperando instrucciones, ingenieros castigados por algun motivo estupido y que son castigados sin asignacion por un año, sin nada que hacer, y en vez de aprovecharlo inventando algo, se quedan ahi como C3PO esperando instrucciones, pensando que le.hacen daño a la.empresa o al.gerente por no hacer nada… en vez de aprovechar el tiempo.inventando cosas.

German, la pregunta que hay qur hacerse es que pasa con las.desviaciones?

Porque los proyectos se hacen por plata y usualmente los jefes de proyecto reciben bonos por evitar y corregir desviaciones, siendo las desviaciones sinonimos de atrasos.

El nombre desviacion viene no.solo.de atraso, sino.de que se ponen inventivos y se ponen.a crear cosas que no se les ha pedido. Yo he visto gerentes de proyecto con.escasa Preparacion sentados por dias y semanas al lado.de un programador, dandole instrucciones precisas de como javer determinada tarea… el final no ed muy bonito, porque como le dices que lo esta haciendo mal?

Convengamos en que puede que el tipo lo este haciendo bien. Solo porque esta haciendo pair programming.con.el programador, no necesariamente esta todo mal. Tampoco porque consulten el mamual 20 veces al dia significa que este todo mal.

Pero el problema es otro. El problema es un problema de control. Por muy bueno que sea tu mba, te aseguro que no te enseñaron a programar.

Y cuando.se trata de dirigir proyectos es aun peor, porque el unico lenguaje que entiende un mba es plata entra - plata sale. Ni siquiera entienden lo que es una inversion, y hablan todo el dia de inversiones.

?que se invierte en una inversion?

Una inversion es un gasto en que la plata gastada se recupera. Esta discusion la he tenido.con gerentes que llevan 40 años como gerentes generales y no lo entienden, porque para un gerente si no.hay venta, no hay recuperacion.de la.inversion.

Y que pasa si reduzco el.costo de lo que estamos haciendo por 10???

Un vendedor con.esteroides, que es realmente un mba, no lo va a entender nunca.

Bueno.si asumimos que se puede multiplicar la productividad por 10, lo que es imposible de demostrar en un espacio tan pequeño, explicame como hago eso en un ambiente con.scrum, porque estoy seguro que todas esas ideas pasarian al final.del backlog, porque el PO no ve valor en algo que considera que no le aports valor directo al negocio.

De hecho me.ha pasado que el control de versiones lo tiran al final, y lo he visto tantas veces que no creo que sea el unico que se encuentra con este problema.

Supongamos.que me.voy a comprar un bmw, pero en vez de ir a la.tienda, voy y me.meto a la.fabrica de los bmw y me pongo a dar instrucciones, porque tengo la.plata para comprarlo, por lo tanto soy el.cliente y yo mando.

Yo creo que me.sacan a patadas.

Creo que con la.agilidad deberia pasar lo mismo. Tu me puedes decir el.color del.auto, me puedes decir el modelo entre los.modelos existentes, y me pueded pedir accesorios entre los.accesorios existentes, pero si me.pides cosas raras, eso va a costar, dejame volver a la.mesa de dibujo, dejame armar un prototipo, dejame ver como queda primero.

Esa parte no lo veo que exista en agilidad. Existia en XP como spikes. Pero en scrum no lo.veo.

En kanban existe como aprendizaje. Se puede hacer cualquier cosa rara, porque la medida de avance en kanban es el aprendizaje, no que el sprint salga bien.

Hay una.diferencia de enfoque.

De.hecho he visto montones.de.proyectos hechos supuestamente con.scrum, que tienen jefe de proyecto, el.jefe de proyecto asigna tareas, y luego reta a la gente que no cumple.

Scrum dice que puedes tomar la parte que te guste de scrum. Esa es una.invitacion a tomar scrumbut.

Ni siquiera es necesario ir a scrum para.ver que ese problema.esta solucionado. Iso9000 es un estandar para operar en fabricas, con.maquinaria, y tiene una estimacion minima.y una.estimacion maxima para cada tarea. La estimacion.minima.puede ser 3 dias o 3 horas.

Luego hay un numero.entre 1 y 10 para estimar el.riesgo de cumplir esa estimacion. Si el.riesgo es 1 significa que no hay riesgo y la fecha se va a cumplir si o si. Si el riesgo es 10, de 3 horas pasas a 30 horas. Haz esto y nunca mas tendras proyectos atrasados.

Scrum por el contrario es una tremenda invitación al micromanagement, aunque diga lo.contrario, no hay manera de detenerlo.

La unica razon por la que he visto scrum adoptado es esa, las jefaturas mienten, y cuanfo uno les explics que lo.estan haciendo mal, se vuelven inubicables.

Porque es el.decueve ganar 8 palos, aparecerse 2 horas todos losndias en la.oficina, dar 2 o 3 instrucciones y tener a alguien sentado todo el dia, inglafo.como guruguru, mirando y repitiendo las.instrucciones, viendo que todo el mundo este trabajando, y cuando digo trabajando, en realidad me refiero a trsbajo esclavo, sin ideas.

Desafortunadamente la.formacion de los.ingenierod.hoy en dia esta excenta de ideas. No digo que antes fuera diferente. Siempre ha sido lo mismo, pero ahora los ingenieros estan mas seguros respecto de las ventajas de tener la cabeza vacia de ideas, de ser cabeza hueca, y recibir instrucciones.

Eso es exactamente lo que decia mary poppendieck que no habia que hacer. No quedarse con el.backlog, sino más bien entender el problema y solucionarlo.

Es la misma critica que hace kanban sobre la agilidad. Convirtieron algo sagrado como lean en algo sin alma como scrum.

Para que requieres ingenieros en scrum siblos tratas como.si fueran gente de la calle, sin preparacion, que requieren ser controlados respecto invluso a cuantas veces van al baño?

Y para completar la información, esto sí que es largo:

https://age-of-product.com/agile-micromanagement/

Bueno encontré montones de críticas de Agile y básicamente se resumen en que Agile no te da autoridad para tomar decisiones, pero te asigna responsabilidad.

En otras palabras, si soy responsable de que un producto salga en una fecha determinada, con los features que me indican, debo poder tomar decisiones.Tienes la responsabilidad, pero no tienes la autoridad.

El mundo al revés. La autoridad, como su nombre lo indica, viene de autoría. El autor de un trozo de código es quien lo escribe. El programador es la autoridad. El nombre correcto de “quien manda”, es quien “pone la plata”, ese es el cliente, por definición. O el cliente del cliente. Da lo mismo.

El cliente no “manda”, a menos que el cliente sea el jefe. En ese caso, el jefe debe saber hacer el trabajo del subordinado. Si es así, debe sentarse en su puesto y mostrar cómo se hace su trabajo. Lo que obviamente nunca ocurre, porque el jefe es un patán sin conocimiento, sólo se aprende algunas palabras y hace como que trabaja, se vuelve un parásito del sistema, un chupa sangre que no aporta nada y por eso Scrum lo saca del sistema, no hay jefe de proyecto.

Cuando estás en un proyecto que usa Scrum y el jefe de proyecto se transformó en Scrum Master, sabes que en realidad no están usando Scrum, sino que se están haciendo pasar por agilistas para ver si pueden apurar el tranco. La idea de fondo es que los programadores se las tiran. Y esto me lo dice hasta gente que no trabaja en programación, ni tiene nada que ver con informática.

Esto es raro, para mí por lo menos, porque estoy acostumbrado a ver gente que trabaja de noche, que trabaja fines de semana y que en algunos casos hasta le piden que trabaje toda la noche y además los fines de semana, dentro de la misma semana. Obviamente esos son proyectos fracasados, al punto que todos son despedidos al mejor estilo Office Space: No reciben su sueldo y terminan en tribunales resolviendo el conflicto.

Para evitarse problemas, es mejor cumplir el horario, así nadie le debe a nadie, no hay zombies en la oficina escribiendo código que a mí me daría verguenza mostrar. Y obviamente no hay que trabajar más de 5 horas diarias, pero en Chile nadie me cree porque acá se trabajan 10, porque en todo el mundo las horas de almuerzo se consideran trabajadas y acá en Chile no. En USA se trabaja de 9 a 5. Si se aplica la contabilización de horas que se hace acá, los gringos trabajan 7 horas diarias: de 9 a 12, almuerzan durante una hora, hasta la 1, y luego de 1 a 5. 3 horas en la mañana, 4 horas en la tarde. Esas son 7 horas diarias.

En Francia también es de 9 a 5, de 9 a 12, almuerzan de 12 a 2, y luego trabajan de 2 a 5. 3 horas en la mañana y luego 3 horas en la tarde. Son 6 horas diarias.

¿Quiénes son más productivos? Los franceses.

Andas lleno de energía porque además te tomas 2 cafés en la mañana y 2 cafés en la tarde. Esos cafés son momentos para conversar. Y son de 15 minutos cada uno.

O sea no trabajan más de 5 horas. Te sientes con tanta energía como si hubieras tomado 6 meses de vacaciones.

En Chile insistimos con largas jornadas como si eso nos hiciera más productivos, pero en realidad tenemos un montón de estúpidos en el teclado, porque el cerebro no es capaz de concentrarse 10 horas diarias. Es mentira. Quizás lo puedas hacer un día. Pero no 2. Imagina una persona con 10 años en esa rutina, es un imbécil, no es capaz ni de armar sentencias coherentes.

Esta es otra crítica que se le hace a XP, a la agilidad y a Scrum: No es posible tener tantas horas a gente programando en pares. Quedan agotadísimos. Nunca he calculado cuánto es lo lógico que una persona puede funcionar haciendo pares de manera continuada, pero imagino que no son más de 2 horas diarias.

¿2 horas en serio?

Eso me dejaría como 10 horas para vivir la vida y que no se me vaya en el trabajo, que de hecho tiene una significación igual a cero, nunca me han entregado una medalla o un diploma por terminar un proyecto, nada de lo que ocurre en el trabajo tiene ningún sentido en la vida real porque las empresas insisten en hacer cosas irrelevantes que no van a cambiar el mundo, ni cambiar el color de una pared. Nada. Toma datos de esta máquina, pégalos acá, listo. Irrelevante.

Incluso he tenido citas con algunas chiquillas de mi edad que una de las primeras cosas que me dicen es que la vida es lo que ocurre fuera de trabajo. No puedo estar más de acuerdo, pero eso es un sintoma de lo irrelevantes que son los trabajos.

¿Pero en serio 2 horas?

Van a pensar de que esto es una tontera, pero no lo es. Si el trabajo luego de la segunda hora ya no tiene sentido porque el cerebro está dormido, ¿qué sentido tiene trabajar más de 2 horas diarias? Quizás una hora hora más para temas de coordinación, leer y escribir documentos, y sería todo.

Las culturas originales eran cazadores recolectores. Para ellos el trabajo no existe, lo que nosotros consideramos trabajo, para ellos es juego.

El documento dice que trabajan 20 horas a la semana, pero eso es mentira. Cazar un animal significa que todos deben estar flacos para perseguirlo, no hay nadie con sobrepeso persiguiendo el animal. Además un sólo animal cazado puede alimentar la tribu por 3 o 4 días. Aún si trabajan por 6 horas un día para cazar un animal (lo dudo), y el animal dura 3 días, no son más de 2 horas diarias en promedio.

No encontré la referencia a que no se trabaja más de 2 horas al día, pero pensemos en un juego de fútbol, nunca es más de 2 horas.

Las culturas que aumentaron las horas de trabajo fueron las que cazaban humanos para convertirlos en esclavos. Lo normal de los esclavos es que trabajen para evitar el castigo, y como el tipo está sentado y con cadenas, su cuerpo se deforma y va a morirse de quizás qué enfermedad de todas maneras, así que los esclavistas lo hacen trabajar hasta que se muera, porque es lo más económico. Porque con el dinero obtenido se compran otro esclavo.

Y si pensamos, hoy en día esa es la situación de la mayor parte de la gente, estamos formando esclavos que no se atreven a pensar por sí mismos, de hecho no puedo creer que los niños ahora llegan del colegio a las 5 de la tarde a hacer tareas. ¿Es broma? ¿Qué futuro les espera si trabajan tanto en su juventud? Ah, y por cierto, saben mucho menos que nuestra generación, simplemente los tienen agotados, lo cual no me parece raro porque sus profesores no saben más que los nuestros, de modo que ¿qué les van a enseñar?

De hecho hay gente que prefiere trabajar a pensar. Mantener la mente ocupada en realizar todos los días lo mismo como si eso no fuera idiotizante. ¿Cuál es el tiempo que tienes para pensar en el día?

Sobre el post, hay un par de pasajes que capturaron mi atención:

Agile, as often implemented, increases the feedback frequency while giving engineers no real power.

Esto lo hemos estado reconociendo desde las primeras discusiones de ChileAgil, nosotros lo tenemos ultra claro, pero parece que es el ‘pitfall’ más común de las implementaciones de Agile.

It’s not always the best for engineers to drive the entire company, but
when engineers run engineering and set priorities, everyone wins:
engineers are happier with the work they’re assigned (or, better yet,
self-assigning) and the business is getting a much higher quality of
engineering.

Esto me llegó profundo, pero toda la crítica a Agile en desarrollo orientado al negocio me hizo pensar. A principio de año hice una re-evaluación interna sobre mi dirección y motivacion laboral, y me dí cuenta que quería mucho trabajar en un ambiente de ingeniería, ya que hoy trabajo en un ambiente muy multi-disciplinario. En fin, creo que hay un punto ahí, pero no concuerdo con la dicotomía entre orientado al negocio y orientado a la ingeniería. Si creo que la ingeniería se sub-valora en ambientes donde los ingenieros no tienen poder sobre las decisiones, lo que pasa si son puros junior, que es el otro punto que hace este señor.

“Agile”/Scrum process has nothing to do with computer science and that it adds no value, is a horrible idea.

Esto, en estricto rigor y fuera de contexto, es absolutamente cierto. Pero en un contexto donde ciencias de la computación se usa intercambiablemente con ingeniería en informática, no lo es. Agile si tiene que ver con ingeniería porque la ingeniería tiene que ver con proceso y con interacciones. La ingeniería sirve un propósito de negocio, la ciencia no necesariamente. Y si, sé que no somos una ingeniería real, pero el argumento sirve de todas formas.

Under Agile, technical debt piles up and is not addressed because the
business people calling the shots will not see a problem until it’s far
too late or, at least, too expensive to fix it.

Esto (y la gran mayoría del post) es solo cierto para métodos iterativos con timebox. Lean/Kanban u otros métodos no basados en timebox no sufren de estos problemas de corto-placismo y vértigo por aceleración.

Ya, hasta ahí llegué, me dio lata seguir leyendo algo que probablemente he leido/discutido tanto que siento que es lo único que se conversa sobre Agile.

Como siempre, David, tus comentarios son geniales.

Lo único que me gustaria comentar es que para convertir nuestro trabajo en ingeniería de verdad hay que asumir que tanto las mediciones como las estimaciones son aproximadas. Si partes de esa base, una medición es siempre 4+/-1, una estimación es siempre 6+/-2, es decir toda medición son 2 números, un máximo y un mínimo y toda estimación lo mismo.

Si haces eso todo se puede analizar como en primer año de ingeniería y sale perfecto. No hay ninguna razón para que no sea ingeniería excepto que los ingenieros que estudian ingeniería van a la universidad a puro perder tiempo. No aprenden nada, sólo pasan ramos. Y te lo dicen en la cara durante toda la carrera. Si después no aprendieron nada, no es mi problema.

Un ejemplo, toda estimación es una distribución Beta.

http://mathworld.wolfram.com/BetaDistribution.html

Le dices eso a un gerente y no es capaz de entender que toda estimación tiene un máximo y un mínimo. El gerente prefiere enojarse cuando no se cumple una estimación. ¿No es tonto eso? Eso es como decir que un puente se cae si se rompe un tornillo. Eso no puede pasar en la vida real, pero las cartas Gantt están hechas para que el puente se venga abajo cuando una de la tareas se atrasa.

Un gerente de verdad debería estimar cada una de las tareas usando una distribución. Si el tipo no entiende, no es mi problema. Que vuelva a estudiar ingeniería y esta vez que no pase copiando.

Ok, he releído l oque escribí y me salió absolutamente desagradable y petulante, no era mi intención, pero así me me salió, lo siento pero no lo siento. Debe ser que escucho a mucha gente petulante como Linus Torvalds y Alan Kay, y se me pegan las malas costumbres, pero en realidad siempre he sido así, no creo que sea culpa de ellos, simplemente refuerzan mi conducta natural, lo otro es simplemente una disculpa para contener a la audiencia.

El punto que quiero resaltar es que la computación es matemática, ya sea el mismo tiempo que aprendimos en el colegio o bien un nuevo tipo de matemática como dice Alan Kay:

Acabo de encontrar este post referenciado en LinkedIn, acerca de Agile Is Dead, Long Live Continuous Delivery.

http://gradle.org/blog/agile-is-dead/

Está escrito en un tono más ameno que el inicial de este artículo.

Y tiene propuestas acerca de cuál sería el siguiente paso o evolución en el desarrollo de software.

Deberíamos tener un repositorio de mejores prácticas.

Por ejemplo: source code control. El tema es tan amplio, sólo si te dedicas a usar git, usas feature branches? Feature toggles?

Integras dentro de cada branch? Cómo corres Jenkins? He visto empresas que ejecutan Jenkins sólo antes de de hacer code review con Gerrit.

Tienes una máquina de Staging dónde probar manualmente? Cómo podrías pasar a producción sin probar? Porque si tu plataforma es Netflix, supongo que da lo mismo si puedes ver una película o no. Pero si tienes que facturarle a un cliente, no poder facturar puede hacer que pierdas un cliente, y puede ser un cliente que compre el 80%… O sea, chao empresa.

El tema es más complejo de lo que parece a simple vista.

Lo mismo es verdad para el tema de unit tests, pair programming, etc. Cada uno de estos temas podría ser un tema aparte.

Cuando llegas a una empresa, sería bueno tener un repositorio de ideas para persentar y no tener que hacer un tremendo show de varios días, varias semnas o varios meses, dependiendo de lo perdidos que estén.

Ah bueno, y si hacemos eso, ¿porqué no crear una certificación?

Mi idea es que cada una de las prácticas debe ser certificada. No me refiero a una certificación como Scrum que dice “sí este tipo más o menos tiene una idea de lo que se trata la agilidad”, sino más bien una certificación para cada cosa:

  1. Unit testing.
  2. Pair programming.
  3. Release planning.
  4. Continous integration.
  5. Continous delivery.

etc.

La ventaja de esto es que podrías tener 20 certificaciones, lo que realmente te ayudaría cuando quieres formar equipos ágiles, necesitas al menos un miembro del equipo certificado en cada cosa y que entrenen al resto de tu equipo.

El paso siguiente sería certificar organizaciones, simplemente contestando cuestionarios y viendo que las personas que están contratadas tengan las certificaciones pertinentes y en la encuesta digan que efectivamente están siguiendo las prácticas como corresponde.

De modo que entras a la organización certificada y supongo que sería dificil que te digan “sí, somos ágiles”, pero no tienen la certificación y no tienen a la gente certificada.

My 2 cents…

Consideren que las certificaciones son una mala idea: http://blog.continuum.cl/las-certificaciones-debieran-morir-haz-tu-parte/. O cuando menos, miren alrededor y vean cual “útiles” son. (El test de utilidad es que las chances de que alguien certificado sea bueno debieran ser superiores a la de alguien no certificado).

Y cuidado con las mejores prácticas, que se transforman en cargo cult: http://techblog.leosoto.com/best-practices-vs-common-sense/ (no conocía el término cargo cult cuando escribí ese post, pero la idea está ahí).

Es divertido, porque por un lado no nos gusta el micromanagement, se plantea que la agilidad es más de cultura que procesos, y luego nos ponemos a conversar de estandarizar (o certificar) procesos y técnicas.

Atentamente, un MBA :stuck_out_tongue_winking_eye:

Opino lo mismo acerca de las certificaciones, aunque finalmente cumplen el propósito de “certificar” que un empleado hará las cosas tal como dice el manual y no se pondrá a buscar soluciones diferentes (aka creativas)… si es eso lo que una empresa busca, es su problema.

Finalmente, lo que valen son los resultados…

Estoy 100% de acuerdo contigo… de hecho estoy 200% de acuerdo contigo.

Las certificaciones son una mala idea, pero no porque las certificaciones sean en si inutiles, sino porque se pretende que la gente pague por aprender, y eso es imposible, porque son ellos mismos los que aprenden, tu les puedes presentar el material a aprender, hacer las dinamicas, hacer las pruebas, pero si se niegan a entender, lo unico que puedes hacer es reprobarlos… y dudo mucho que alguien quiera pagar para sacarse malas notas.

Por eso digo que las certificaciones deben ser de temas puntuales. Temas que se puedan aprender en un par de dias o un fin de semana.

Primero das la prueba y repruebas estrepitosamente.

Tomas el curso y es facil, se entiende todo.

Luego vuelves a dar la prueba y se vuelve trivial.

Porque yo no tomaria el.curso si paso la prueba sin el.curso, el curso se vuelve irrelevante.

Es divertido lo que dices porque para un antropologo todas las culturas son cargo cult, es decir, la gente no sabe porque hace lo que hace, somo lo hace, y es casi imposible sacarlo de ese estado que podriamos llamar idiotez… en el sentido griego, por supuesto.

Lo bueno de lo que dijiste es que todas las mejoes practicas son cargo cult, siempre. Si tienes una mejor practica A y aparece una mejor practica B, y te das cuenta que B es mejor que A, puedes reemplazar A por B. En XP dicen que eso hay que hacerlo con one hand on the yoke, lo que se traduce como una mano en la palanca, o sea lento y suave, para que el cambio no deje heridos.
Eso no significa que no tengamos mejores practicas, de hecho las prpfesiones mismas estan.definidas por la adherencia a loque se considera mejores practicas dentro de la profesion, y esto se lleva al extremo de que en USA te pueden llegar a demandar por no usar las mejores practicas y hasta quitar la licencia para ejercer una profesion.

Esa no es razon para no crear una certificacion en dicha practica. Cuando aparece un amejor practica, creas la certificacion adecuada. Problema resuelto.

Si, es divertido . Y tambien es correcto.

El micromanagement no se trata de tener reglas claras, sino que quedas al arbitrio de tarado de turno que se cree jefe y que no acepta ninguna responsabilidad. No da lineamientos, da instrucciones.

Y si todo sale mal es culpa tuya. Eso es micromanagement.

Nadie contrata a un MBA para que este respirando arriba de sus colaboradores.

Cultura significa que cada persona sabe que hacer en cada caso. Eso es cultura. Cuando llegas a un lugar y el jefe toma todas las decisiones, ese lugar no tiene cultura.

Cuando llegas a chile lo primero que te llama la atencion son las murallas blancas estampadas con un timbre: demuestre su cultura, no raye las paredes.

Primero que nada, como demuestras tu cultura si no puedes expresar tus ideas? Por que te marginan? No perteneces a este pais o este pais no te pertenece? O eres un esclavo que solo debe trabajar hasta morir y desaparecer para siempre?

Y porque alguien, el gobierno? , el dueño del muro, se arroja la decision de impactarnos con algo que es increiblemente mas feo que un grafiti? Y mas parece sacado de la pelicula 1984 o de la pelicula brazil???

La cultura son las ideas que todos comparten.

En ese sentido he encontrado muy pocas enpresas con cultura, mas bien las empresas tienen culturas de ratas asustadas que estan como locas tratando de abandonar el buque que se hunde.

Especial mencion honrosa a aquellas empresas que dicen que tienen culturas politicas, son las peores.

La cultura es algo.deseable cuando la.empresa es exitosa en lo que hace, y como somos informaticos, deberia ser una empresa de software acostumbrada a hacer software exitoso.

Por ejemplo ibm… a ibm no le.he visto software exitoSo en al menos 20 años… de seguro su cultura debe ser una mugre.

Estoy de acuerdo en que la.cultura es importante. Pero la cultura es el proceso. Si estas pensando en procesos predefinidos, como piensan los ingenieros industriales, entonces tus trabajadores no tienen cuarto medio.

Y si tienes razon, certificar proceso, tecnicas, personas y empresas. ?te parece contradictorio?
Es sumamente logico. Si hay una marca agile, hay que hacer que la.marca sea diferenciadora, o si.no pierde su valor.

Evitar el.micromanagement es poner al.gerente en.su lugar. Yo no voy como programador a decirle al gerente que hacer, no preguntale por su proceso de marketing, ni por su proceso de ventas, etc.

El.ve el.negocio, yo veo los temas tecnicos y me gustaria tirar una linea ahi. O si no quiero ver su backlog y que me.empiece a dar explicaciones, a ver si nos entendemos.

La certificacion no es micromanagement, por el.contrario, es cultura. Si vas a la selva y no sabes usar arco y flecha te mueres de hambre, lo primero que hace la tribu es entrenarte, si no te mueres.

Pero en chile.se piensa que todonds.lo.mismo, trabaja mas.hora… esa es la.solucion.para todo… y luego cuabdo se acaban.las.horas del dia y los dias de la semana, los proyectos se atrasan igual y luego de 5 años.sin.resultados, se cancelan.

La cultura es lo.mismo que la.certificacion. exactamente lo.mismo.

Otro mba por aca.

Las mejores prácticas son una trampa, y las certificaciones un error.

Si nos ponemos de acuerdo en eso, sería genial.

2 Me gusta

David,

Expresado de la manera que lo expresas, sería un suicidio. Tiene que haber una base para cualquier profesión que exista. Si no hay un mínimo de mejores prácticas, ninguna profesión puede existir.

De la misma manera, las certificaciones de esas mejores prácticas deben existir, de otra manera, cualquier animalito del bosque podría decir que es un ingeniero de software.

Las mejores prácticas en contexto A son distintas al contexto B. El contexto puede ser desde una persona a una empresa o una cultura.
Las mejores prácticas son una trampa. there is no silver bullet

2 Me gusta